Feature fund

* @dpdpforlife *

1. like in crowndfunding site, after a certain period you retrieve the money
2. an official blender dev look up the code, if the work is not done correctly, he give instruction for amelioration, the money is only recieve once the controller agree
3. on thoses 1500, blender could take 15% enough to pay the controller
4. see 123
5. if its crowd funded then people want it and not anything need to be merget into master, it still could result in an addon or custom build

that's it

* @dpdpforlife * valid points, thanks for bringing these up!

"$1500 may not be enough to develop this functionality fully. What happens to the money since no devs take up the task."

Complete refund - if no one claims a task because if insufficient funding in a given amount of time the money'd get refunded, similar as most crowd funding platforms.

"$1500 is enough money but the dev that takes up the task does a lousy job and the code is not up to the standards expected by BI or it is buggy or causes issues with the Suzanne head operator. Is the code trashed? Does the dev still get the money? Does the addition only live as an obscure branch?"

Fair point. What if testing and QC would be calculated in at determining the cost? That'd mean extra overhead I guess, making it more expensive but assuring quality as well.

"$1500 is enough money, but because of the huge volume of GoFundBlend projects, the core development team doesn't have enough time to review, make recommendations, or merge into master, do the 15 people of this project loose out on getting their project in Blender 2.93 because the Spatulizer Egg Flip Modifier GoBlendMe was turned in a day sooner?"

As with the last question, with parts of the cost going into QC that could cover the cost of people checking everything is in order.

"No one knows if $1500 was enough money for development, because the person that took up the task was actually a conman incapable of coding at all who is now living the high-life in south eastern Saskatchewan."

I think there needs to be some sort of validation of identity and relevant experience. A registration process if you want. Obviously we can't have random people taking that money. That'd ensure that at least the person working on the task has his/her personal reputation to consider as well.

"No one but these 15 people would ever use a wagon wheel generator, which takes up 50 mb of the Blender install. Does it still get merged into master?"

Another good point. The thing is, I'm using about 10% of the addons shipping with blender, but I'm using at least 15 regularly which are not shipping with it. I'm all for keeping blender as small as possible, wouldn't want to have it any other way. With an expanding user base things like these are to be expected, so what about optional expansion packs? Even if it's blender certified addons that can be downloaded from blender.org it'd be better than nothing.

My main point is - 15 people (I'm guessing professionals, if they are donating $100 for a wagon wheel generator) need wagon wheels. They are going to get them, one way or another. It's just a question of blender profiting from that money or someone else. I do get that it's a complex subject, way beyond my level of expertise as well, that's why I wanted to start a conversation - so thanks again for replying and taking the time to point out these issues.

* @3dddan * No problem. I don't want you to think I'm completely opposed to the idea and it's something I've thought about in the past. I just want to point out that there are issues with the idea. I really don't want to take away from the core developers' time, and if the Blender Institute makes this an officially sponsored thing, it will reflect negatively on them if there are any missteps or incomplete goals, so they will feel an obligation to make sure they are completed quickly and with the same high quality we've come to expect from Blender. But if the idea that is being funded is a fundamentally flawed one, where is their obligation? Is it to the people who put up the funds, or is it to the greater cause of making high quality, bug free software?

I would rather something like this be an unofficial project. I'm not sure how you could ensure that the developers that sign on to any given task are of a high quality without the BI being involved at least a little bit (ie vetting the branches for inclusion in blender, knowing the capable developers who aren't already in the core team, actually taking the time involved in merging the branch into master). I would rather those guys focus on making the the core capabilities of Blender as bug free and streamlined as possible.

End users tend to ask for shiny new features, but personally, I would rather the focus be on streamlining Blender. Right now, Blender lags behind other DCCs in large scene viewport and undo performance. The core devs are aware of this and are dedicated to bringing Blender up to speed in these areas. I don't want them to be distracted because people raised 40,000 EU because they wanted a Wagon Wheel generator.

* @dpdpforlife *

Absolutely, I agree with your concerns.

On the other hand, with the core developer team expanding and organizing in module teams ( wiki.blender.org/wiki/Modules ) the additional funds going for QC could cover their times reviewing things. It's not like there's a limitation on the number of developers, I guess if the development fund would go up so would the number of coders.

I'm not really an expert on the subject, was just thinking in the lines of streamlined funding (how much of the cost is going into quality control, testing etc, if a new feature get's into the main branch or becomes a certified addon is another question). With the current development it's really hard to see if and when features required by professionals are being either integrated or at least developed in a separate branch. Blender is definitely at a point where it doesn't scare away industry professionals anymore, and while I don't think it's necessary to speed up the process I think that's happening anyhow with the growing development fund. (which seems to be plateauing for the last few weeks. It's partially the reason why I was thinking of ways to accelerate things a bit)

The company I work for has nearly 100 people working in just the modeling team, as far as I know I'm the only one using blender on a daily basis, and I'm pretty new to it as well. More users would mean bigger pressure in the industry to utilize blender in production pipelines, and a good reason for big companies to back blender. Just restless to get to this point, that's all.

* @Deep Blender *

good points - some of these have been partially addressed throughout the discussion here. It's not like polished or bulletproof by any means but I think it's a good conversation starter. With costs or reviewing, QCing and testing being covered by the fund I think it could be feasible.

Miscommunication and Underestimation is partially covered in dpdpforlife's proposal - "Approach this like google summer of code. A developer, or group of developers makes a proposal and posts it on a website. They define what three levels of goals are. Alpha might be a proof of concept. Beta, might be a widely usable, but possibly buggy branch, and Gold might be a finalized version that is part of the Blender official release.

The developer makes a proposal that people bid on and sets a price point for each of the three levels of development. Once each of the financial milestones are met (alpha, beta, gold) the developer must meet the requirements they defined before they can withdraw the money in the fund. If they fail to get approval from 75 percent of the financial contributors at the end of what they call a milestone, the money is donated to the Blender institute. The fundraiser remains open, at all times so that if the wider audience of financial contributors are satisfied, they may contribute more money to bring it to the next level, or others may join in to contribute more funds. So, If someone says "I can develop a wagon wheel generator in 3 steps. One (alpha), I will make a generic wheel generator that will make a cylinder that spins. Two (beta), I will make the wheel look like a wagon wheel and spin. Three (gold) I will make the wagon wheel stable and a viable release candidate." People can then put their credit card number or other credentials into the website, basically committing to paying an amount that they chose if the alpha goal is met. Then if the people who contributed are happy with the alpha, they can contribute more and upvote it so that it appears higher in a list of projects that others can contribute to.

Taking this approach would make it so no one will be out a ton of money if the developer can't make it happen, and can be satisfied that at least they have contributed their 10,000 pesos to the Blender development fund. But if the developer at least gets to a certain level (alpha for example) someone else may take the reigns and develop the proof of concept further. We are talking about the gpl license after all."

I think it's not a bad idea, and I'm sure there could be a variety of ways to tackle this. As said before, for professionals the lack of 1-2 even small features can make a difference between using Blender for their everyday job or subsrcibing to something else instead. I'd rather back Blender and specifically parts of it that I'm actually using to make a living.

As for Merging - that'd be very much case dependent. If it get's merged into the master or exists in form of an expansion pack or certified add-on is pretty much up to the blender foundation. In any case, people would be able to use it one way or another, as opposed to hoping for a feature to be worked on and having to use other softwares in the meantime to stay in competition. There are way to many good feature ideas (some of them not even that complicated) sitting around for years, it's hard to do any planning for integrating Blender in a production pipeline like this.

* @3dddan * if I understand it correctly, the developers are supposed to write the specifications, is that correct?

The whole development process is split into milestones, that's what I expected anyways. My question is, are the goals for all the milestones defined upfront, or can they be made more precise? Do you expect that the price for each milestone is defined at the very beginning?

Let me just point two things out. First, if someone start a project and doesn't finish doesn't mean it can just be picked up by someone else. It is very often easier to start from scratch, because it is very difficult to understand what the intentions are in unfinished code. Further, not everything can be an addon. I would even argue that most of the easier to implement feature requests can't be addons, because if they could, someone would have implemented them already. Those need to be implemented in C and can only be used reliably if they are merged into master.

* @Deep Blender * My take on it would be something like this - There's an idea/request which is getting enough backing for a developer to get interested in working on it. The developer would make a pitch on how to tackle the problem, with timelines and spreading the cost of the development. That in order would be reviewed by the given module team inside the blender foundation (cost of reviewing this and further quality control would be covered by the fund) and as soon as everyone is on the same page development could commence. Since the fund can grow over time during development milestones can change as the development goes on I guess, but a fixed release schedule would be helpful.

" First, if someone start a project and doesn't finish doesn't mean it can just be picked up by someone else. It is very often easier to start from scratch, because it is very difficult to understand what the intentions are in unfinished code."

Valid point, and not necessarily one I'm qualified enough to address (I work in production for 15 years, most of that time at bigger production houses, I've written some tools in python but by no means am I a coder). Apart from style guides I'm sure this is an issue more frequent in the development of Blender than most other softwares, so I guess if and how to pick up code is a question someone with the relevant experience could answer.

Also, if it turns out that more projects are unfinished than not, a project like this wouldn't make much sense.

" Further, not everything can be an addon."

Absolutely, it's why I said it's case dependent. If I'd want extended outliner functionality it'd need to be in the master, where as a toolset of working with pivot points for example is better off as an addon. But again, not a decision for me to make, that'd be the foundation deciding what to put in their product and what to better keep separate.

Again, just thinking of ways to help/accelerate development, but most importantly without making it messy. If the general consent along the developers and main people in charge would be that's it's more harmful than helpful I'd be the last person to cling to the idea. However, as it stands a certain (slowly growing) number of professionals are using Blender, and have the financial means as well as the motivation to back controlled development in some areas. Just as an example - I'd be happy to put money into the development of production ready UV tools instead of paying for different software packages, and in the end it'd help the community as well by making those features accessible for free.

* @3dddan *

The cost in software development increases if more time is needed. So being able to get more money on the way while keeping the timeline simply doesn't make sense. In most situations more money is required as the development takes longer.

I need some time to create a template for the development process which is used in many places. It already covers plenty of practically relevant failure cases. It might be more productive to use it as a discussion basis.

* @3dddan * As mentioned in my previous post, here is a very rough description of the development process I have been using when dealing with non-technical people. It is very rough as I left out all the details to keep the focus on the most relevant aspects.

Main Goals

• Agree on the main goal
• Define the milestones (no details)

Upcoming Milestones

• Define the goals as precisely as possible
• Note how the progress is going to be visible
• Estimate the duration and cost
• Start the development if everyone agrees

Evaluate the Milestone

• Check whether the goals have been achieved
• Adjust the upcoming milestones as needed
• Payment for the milestone (if completed)
• Proceed with the next milestone if there are more (jump to "Upcoming Milestones")

* @Deep Blender * There seems to be some miscommunication - What I was saying is that the fund can grow over time, and that money could be utilized in a meaningful way to extend goals. Same this as kickstarter, There's a demand which gets met by an estimation and a plan to realise a product - if funding exceeds that expectation during the development process additional goals can be set to extend functionality.

* @Deep Blender *

Thank you for describing the process from a developers point of view - it's definitely helpful. They seem like very good points - on which stages the institute could get involved, or the funding community would have some input is very much up for discussion.

All in all I think it'd be great to explore this further as it could give a big boost to the development and the growing of the funding/community.

* @3dddan * The involvement of the Blender Foundation (not institute) would depend on the task and developer. For simple tasks, there may be no involvement at all, maybe except for the final review to include the code in the master branch. For complicated topics, they would need to be involved at every stage, from the initial planning, all reviews, the continuous planning and likely in unplanned technical discussions as well. In more involved tasks, you might want to make the inclusion into Blender's master branch its own milestone.

I am skeptical whether the Blender Foundation is overall interested in this idea. There is a risk that current supporters wouldn't contribute continuously anymore, but pick features they are interested in instead. There might be a chance, if it is organized by someone else, but in collaboration with the Blender Foundation, but initially more likely without them.

* @3dddan * Would you have a fund per feature or an overall feature fund?

* @Deep Blender * It's case dependent I think, but generally I'd be more interested in backing a specific feature/fix I need. If that's a small fix or something more general like a paint quest depends on everyone's preferences.

* @Deep Blender * Yes, it's not necessarily something that'd fit into their profile, not sure. The thing is though, I think many professionals (a number that's growing as well, hopefully) would be happy to back specific features, especially if they can see some sort of timeline associated with it. Freelancers/professionals will need to deliver work, I'd rather put that money into funding a feature I need than into a subsciption or a plugin for maya.

My thinking was something among the lines of "if AMD can fund a developer to work on their agenda full time at the institute (not sure of the difference between foundation and institute I mean the company where the developers work), it'd be possible for a number of like minded professionals to fund a dev to work on whatever they need". It'd probably be possible as it is, but it'd be more streamlined to have a unified platform for things like these.

* @3dddan * there are quite a few differences between a company like AMD compared to artists funding certain features.

AMD first of all knows the ins and outs of development. This heavily reduces the amount of the required communication and justification. So the developer(s) can focus on what they are best and have a direct communication channel to AMD for development and low level related questions.

Working with non-technical people is a whole different topic. It is necessary to work way more formal to avoid misunderstandings. This starts with the definition of the goal. Writing a specification can take a considerable amount of time just to get everyone on the same page. I have worked with one artist who wrote amazing specifications and I only had to clarify very few details. But usually, it was more efficient if I wrote the specification, as they had a hard time to write a very precise document which also considered the application's context, like consistency and not breaking existing functionality. It can happen that writing the specification takes as long as the actual implementation. But sometimes, it is just not avoidable.

If a developer works with many artists, it is clearly not getting easier. It is for sure doable, but it is way more complicated! Everyone involved needs to be open minded, because stiff and formal processes would be too inefficient. Sometimes, it can be important to try ideas out to get a feeling of what is best. At other times, you barely see any progress up to the end, because a lot of work takes place in the background. It is unavoidable that backers would get frustrated no matter how the developer proceeds within the project or communicates, because it is very difficult to understand as a non-technical person what is going on.

TLDR: My impression is that you are heavily underestimating the complexities. But that does not mean there is no way to have some kind of feature funding in my opinion. Knowing that it would be very very difficult is crucial to minimize frustrations.

* @Deep Blender * I don't think that I'm necessarily underestimating the complexities. I've been working at big production houses over more than decade, spending the last year being involved in re-vamping and improving the facial pipeline at Weta Digital. I worked with rnd teams, pipeline and tool development before many times.

Now the AMD comparison wasn't meant to be a one to one "that's how you do it" type of comparison, more that of a core concept. If the costs of planing and communicating are 50% instead of 10% (again, just throwing around numbers here) that wouldn't mean that the core concept is flawed, only that the costs need to be shuffled differently.

The thing is, Blender is a tool. It's used in production, whether it's a single individual or a bigger company. Currently not a super efficient one I'd have to add, so especially when making the step and trying to expand into production territory a lot of user feedback is expected. It's just a matter of shuffling the costs so that there are no surprises, or no huge issues if there are.

* @3dddan * the way Blender is being developed is not that exotic, it is pretty similar to what is happening in companies.

What's special is the idea that plenty of artists are paying for specific functionality. Because contrary to the usual way software is being developed, you have all of a sudden lots of stakeholders. They likely have different workflows and requirements and they need to be kept up to date about what is going on. The amount of time it takes to communicate with all of them would be quite significant. You can't ask for money and leave them in the dark. You have to take everyone of them serious, because they pay for it and they are the experts and users. But that makes it very inefficient.

That's the absolute core of the issue in my opinion and if there is a practically viable solution to make this drastically more efficient, we could be up to something. Every idea I have, would make it more expensive or would introduce the risk that the developer is not getting all the necessary information or that the users would feel ignored. All of those are not acceptable.

* @Deep Blender * I fully agree, and as you pointed out as well, setting the goal and getting on the same page in terms of expectations is something that would need to be established prior to any development.

I consider this a technicality - setting up a fund would never mean that development has to commence - only in cases a fund reaches a point where developers would see it feasible to get involved and make a plan of action is where any serious planning would even start.

Look at it like this - if right click select would have a feature proposal with the addition of professionals being able to back that idea with actual funding. As long as the consent of the developers is that the issue is way to complex to begin talking about it (given the funding being too low for the complexity of the task) nothing happens. There'd be a cutoff deadline, if no developer is interested the fund get's closed and the money refunded.

If a feature however reaches a funding where developers seeing it as something that could be implemented that's where a conversation would start.

As a practical example - I need a feature (might be in the data transfer modifier) to transfer vertex positions based on UV coordinates across 2 objects. I'd say I have $1000 to back this request. A couple more professionals would have the need for the same feature, the fund grows to $8000. If the general consent across developers is that the issue is more complex, it just remains one of the many requests that may or may not be realized, no harm done. However, if that fund would cover the costs and a developer is interested it might be resolved unlike by it being just another thing the community is asking for.

I completely get your points - I just wish there was a way not just to distinguish fun features wanted by hobbyists from features needed for actual production, but to actually back an idea in a streamlined manner.

* @3dddan * Finding solutions for the financial side is a lot simpler than the communication part.

Let's assume there was a platform where you present your idea and you provide an initial funding for it and others could join too.

The communication could e.g. take place on GitHub, as it allows everyone to relatively easily keep track of the changes. The goals could be the project's README which is directly visible. As the developer makes changes, everyone could keep track of them. If test builds are provided, the users could create issues to point problems out.

What do you think, would GitHub be a reasonable communication platform?

* @Deep Blender * Yes, good idea. I suppose most developers would be comfortable and familiar with GitHub anyhow. Has the ability to report issues, keep track of commits, option for branches, planing project, tracking progress, sorting tasks... Would work pretty well I guess.

* @3dddan * It would give a more manageable overall structure to minimize at least some overhead.

The core issue is still not resolved with it, which is that there are potentially way too many stakeholders. Having rules or hierarchies wouldn't work from my point of view due to a lack of flexibility. Ideally, the stakeholders with the developer(s) would work in a self-regulating way. However, that only works if everyone behaves accordingly which is usually an illusion. It only takes one person to destroy a constructive and decently operating group of people. The fact that this person invested actual money doesn't make the situation easier.

* @Deep Blender * I have no experience with crowd funding so I'm probably not the best person to address this - obviously when and where the funding community has the ability to give feedback is something that'd need to be established.

Here's a production example - a department has a need for a tool. They come to a consent how that tool should look and function. They get to make a bid, money folks at the company decide if it's feasible, if so they get to pitch it to the developers team in charge. There are usually 2 week sprints for the developers after which they release it to the department for testing purposes. It gets discussed inside the department, and the head of department or a lead will convey the feedback to the developers.

These are the (very crudely described) core mechanics I'm working in production. This could bring up the question of how this'd look without a hierarchy, but I think the major point here is that they come to a consent. Is it messier with crowdfunding? Of course it is. We're not a hive mind, there's the possibility it'd be way to chaotic.

That doesn't change the fact that there is a demand (one of which Blender could hugely profit from), and there are markets in which crowdfunding works very well - how to minimize risks and streamline such an endeavor is way out of my field of specialty, I merely pitched a vague idea.

The thing is, as it stands now Blender is not a tool that could be used in a larger scale production, nor will it be any time soon. With the current funding structure it is very friendly to developers, who have a broader ability to address or dismiss requests, which is not how solutions on the market function.

Now I'm not saying this should change, but IF a couple of professionals can come up with an idea and sufficient funding, currently there would be no way of making that a reality. Keep in mind that while it may look messy when we're looking at the feature requests on the left side here, professionals are working in streamlined production, very much like an assembly line for years and years, they have a very clear idea of what they want (I guarantee, more than 50% of it will be maya functionality they're used to, zeno for the ILM folks)

I do like Blender very much, and I do think it has the potential of being a serious tool for production, with the current pace it may or may not ever happen - the rest of the market is not in a standstill.

So to wrap it up - I don't feel like a competent person to address your concerns about the crowdfunding approach. I do think they are very valid, but I also think they can be resolved, or at least we could minimize or calculate some of the risks. I sincerely hope that there will be some sort of way for professionals to pitch in in a meaningful way at some point.

* @3dddan * just to clarify: I didn't invest time into this conversation to talk the idea down. In my opinion the Blender developers are doing a fantastic job and at the same time it would be awesome to have the opportunity to fund specialized features. There would be a huge value in my opinion.

Having those 2-3 week sprints has been shown to be quite successful and I have worked like that for quite some time in different roles, including management positions where I was mainly responsible for the communication and planning. That's why I know from experience how difficult the communication part is.

The first time you work with a team of artists or whoever needs something, it is quite rough. Just getting the specification right takes multiple iterations. Making sure they understand the process and how they are supposed to give feedback and all those basics takes a lot of time! Over time it certainly gets easier and initially a lot of the overhead can be transferred to the team leads which only works due to the hierarchical nature.

If we transfer this to the suggested Feature Funding: We have to assume that the experience is comparable to working with another team of artists for the first time. Unfortunately, that other team also consists of individuals and is not a team with the kind of common understanding a team usually has and there is also no hierarchy. On top of that, the communication overhead can not be offloaded. The developer has to deal with everything. That is a really huge burden, even in the standard case!

If we have a glimpse at a worse scenario where one person is very vocal or loud, it takes quite a thick skin and lots of experience to deal with such a situation and we have not even touched the territory where a deadline was missed.

* @Deep Blender * Haha, I've been there. Seeing the faces of developers when artists are explaining a request or even a bug for the first time is more often than not priceless :). So yes, I get the point, in most cases the artists don't necessarily have a background in coding or a deeper understanding of issues involved.

I'd argue though that while in a hierarchical structure it can be way more manageable, in this case artists would act more responsible being involved financially. Features that don't make much sense wouldn't get the funding in the first place, most features asked for would probably already exist in different packages and as such have working examples, and features that are highly complex like spectral rendering would probably require a much larger amount for funding, calculating the possible overhead.

I guess the biggest issue I see is something sketchy and vague like "make texture painting like substance painter" where it needs a substantial amount of time to even get to the point of starting development - thinking about this I'd probably handle these cases differently. Whenever it's such a broad feature set and not one specific tool, feature or bugfix. Similar to the way the sculpt quest or module teams are working, only with a general fund for that quest/team - with the difference of having the ability to vote for new features pitched by the developer in accordance with the community. Since these feature sets are ever improving I don't see a need for a hard cutoff deadline for the whole thing.

(Thinking about that brings up the concern that people investing in the development fund would rather invest in a specific team/quest, thus throwing off the balance of the main development. It maybe handled by allocating a fixed percentage of each fund to go into the main fund, not sure. I imagine the funds aren't distributed equally as they are now. There are too many variables and unknowns for me to come up with a possible solution or to determine if it even is an issue.)

The overheads would be quite big, and the developer/developers would need to be involved constantly, but they could get assistance for testing and QC. I get what you're saying though, if we involve a larger community at the end of each sprint we'd need to channel all those inputs into a plan. Since that involves usually leads in production and we can't have leads amongst the funding community how about this - an artist in charge from the relevant module team would act as a lead on the developer side. After every sprint there's an allocated time to voice concerns, give some input, and come up with a constructive plan of action for the next sprint, in conjunction with the developer and someone in the main Blender development team.

(With the overhead costs calculated this would probably result in more developers at the institute ( I need to read up on foundation vs institute, sorry if I'm not using the correct terminology) but with increased funding they are expanding anyhow. The exact structure is something to determine as well, as guess there would be a need for coordination and documentation, general management... All things you probably have a bigger experience with. I was involved in production scenarios in tool and pipeline development before, but mostly as the artist communicating with the developers and the department heads)

Ever since you mentioned that vocal and loud person everyone dealt with at some point, I can't get it out of my head and he/she is really raining on my parade here. I need some time collect myself and think about that. How is it working in regular crowd funding? I'm sure we have those everywhere, there must be an efficient way to deal with situations like these.

It also depends how frequently issues like these would emerge. If it's 50% of the cases that'd jeopardize the whole system, if it's below 10% that could be manageable. We can't account for every scenario and a lot of these things would only show in practice. That's not to say that it wouldn't need extensive planning, but I'd involve someone with relevant experience in crowd funding projects as well.

I'd also be interested in the opinion of the core team, whether this would be something immediately dismissed as being incompatible with how Blender is supposed to be developed.

I do appreciate your input by the way, I think it's very constructive.

* @dpdpforlife *

Yep, sounds good to me. I know that it's currently not possible for the current dev's to concentrate on some random things the community might want, funding is just not at that point. But that's where the community could pitch in. I'd gladly pay for some tool inside Blender that could get rid of a monthly subscription of whatever I need to get stuff done. Could help Pablo as well, making it Blender Today, not Blender This Week :).

* @Jason van Gumster *

That's true, there isn't any unified platform for it though.

Anyone can ask for a warhammer board game, say they have $500 to get it done, without a platform used by a widespread audience they're going to have a lesser chance achieving their goal.

I can post a job about making an addon to help with a facial based shape key workflow, some dev's might see it, probably no other facial modeller/animator will, and in the meantime I have to work 8-6 so I'd have limited time to spread the word and pitch my idea.

I don't want to convince you, I think it's more for the people who do see this being something worth exploring. Look at it like a market research, if everyone says it's not very useful than I guess it's not, if people think it could make a difference, even if nothing happens around it we know there is a demand.

* @Jason van Gumster * then there is the problem of how do you spread your crowdfund in the blender world if no sites group together all crowd funds ? it will be lost somewhere, and nobody will pay attention, like the manuel bastion crowd fund.

also you need a higher authority to have the responsability of judging if the code is well done.

* @3dddan * and * @dodododorian *, I disagree with both of you and I offer this site as a case in point. It's part of blend.community , but it started independently without any official backing from anyone. In part, I launched it specifically to show that a site without official sanctioning could gain traction in the community. Between this site and other projects like the OceanSim modifier, I feel it's a pretty-well proven fact that we don't need the Blender Foundation to manage something like this.

The bigger question (which, as far as I can tell, hasn't been addressed) is what happens to the code and the developer after the feature ransom is complete? Who maintains the code? Does the developer become an active Blender contributor and maintain it themselves?

Software development is more than just about adding a feature. Maintenance is something that we definitely have to keep in mind, especially for a project as large and long-lifed as Blender.

The bigger question (which, as far as I can tell, hasn't been addressed) is what happens to the code and the developer after the feature ransom is complete?

Blender is an open-source project. People contributing code sounds like a pretty typical scenario for open-source projects.

People doing videos about Blender could spread the word

This is true, but there's a cost when it comes to contributions without maintenance... especially when it's the kind of big feature that requires specific funding. Code can atrophy... then you're faced with user complaints that their favorite feature is being left behind because no one is adding to it.

Point is, we should avoid any system that involves "code dumps" or doesn't include a plan for maintaining that new code.

I think we both have vastly different idea of what such bounty-program should aim for.

Yes, there is cost. And it costs money.

Let Blender.org deal with maintenance

If your aim is to push the code to the Blender code-base then the maintenance (and costs related to it) are something that Blender.org would have to deal with. They have the funds, they have the developers who would be also reviewing the code, (as they do with any other contribution.)
If guys from Blender.org click "merge PR" they now obtained a chunk of nice and working code for free!

But in this scenario you have to make it clear in the bounty that the money will be paid only after the code gets "judged" (deemed acceptable) and merged...
...which might detract those who don't want to wait several extra months for their addon or their money. (But I might be wrong and maybe it would not detract almost no one.)

So you want to handle the maintenance

If the aim is to have the code delivered in form of addons then I would let each bounty deal with the maintenance question. Let the paying "customers" decide if they request maintenance for this particular addon, if they are ready to pay for it, if they think they can enforce it, if anyone will even agree to guarantee it.

In both cases, IMO, it does not make much sense for us to care about the code maintenance. We don't have the funds for it, and I don't think it is viable to expect a growing code-base of addons to be maintained for free outside of Blender.org .

My ideal scenario

I wish for a new feature. I am of the opinion that it is not realistic to expect maintenance funded or delivered, hence I would not care about it for now.
The 1st stated goal would be simply to obtain a beta-version of an addon that works with current version of Blender. (Do I want to be able to read the code? Do I want to pay for that? Maybe I do, maybe I don't.)
The 2nd stated goal would be to have minor bugs eliminated.

Depending on what kind of feature we are talking, I might make it clear in the bounty that another bounty will be created, goal of which will be have the new addon polished and merged into the Blender code-base.

If a need for maintenance arises (for Blender 4.0) I would create a separate bounty.

Add-ons can be handled now and easily managed independently. It already happens. Some of those add-ons find their way into Blender proper. Others are sold on the Blender Market.

My emphasis here is on features that cannot be implemented in Python... that must be done in C/C++ in Blender's core code. Those kinds of features touch more of the foundations of Blender and necessarily require more scrutiny for inclusion, including the idea of maintenance... especially if it's a large feature (the sort of thing that would require independent funding... otherwise, it's just a simple patch).

Someone else much smarter than I once said that open source is "free as in puppy." I think that's a great metaphor to keep in mind.

* @dodododorian * Thanks for the icon, good idea!

Yes, kickstarter for blender, that sort of thing. Could even be part of right click select, A nice feature comes up, everyone who'd like can say "Hey, I'd back that with a 50" and if the numbers match a developer can claim it, come up with a plan of action etc. Something among those lines.

* @motionblur.of.doom *

Good points.

Now this is just my 2 cent's, anyone can give ideas.

"The core question is: Who funds who and how do we make sure about quality management of the development?"

I think generally it'd be good to have development and QC/testing as 2 separate things, all calculated in the main costs. Someone more qualified than me might have clearer picture of how those costs would split.

If it's a specific feature (dpdpforlife wagon wheel generator as an example), people liking that idea are pitching in, if it reaches an amount where a developer (there could be a registration process for developers who'd like to be part of a pool, certified to claim coding tasks, so that random/unqualified people don't run of with the money) would say it's feasible to start working on it, a development process could start. Similar as with most other development, commencing in stages - pitch, alpha, beta, final, qc, release (again, I'm not a developer so the technicalities might be wrong or over simplified).

If it's something more broad, like paint quest or sculpt quest I think the summer of code thing you suggested with a flat monthly fee could work fine.

I'm using about 10% of the addons shipping with blender, but I'm using at least 15 regularly which are not shipping with it. I'm all for keeping blender as small as possible, wouldn't want to have it any other way. With an expanding user base things like these are to be expected, so what about optional expansion packs? Even if it's blender certified addons that can be downloaded from blender.org it'd be better than nothing.

What get's put into the main branch should be up to the main developers, but I do think that branches like the sculpting branch could use some support, one like that or a good texturing branch definitely could improve main blender by miles.

* @3dddan * Maybe this could be more of a grant type approach rather than putting professional level expectations on any project. This would make anything more like google summer of code where success or failure isn't really the main point. It is more a chance for a budding developer to try to hone their skills. If the tool isn't fully developed, it at least delivers valuable research towards a full featured addition. The improved normals GSOC project ended up becoming a reality even though it took a few years to finally be rolled into blender 2.80

* @dpdpforlife *

That could be a way to go as well.

My logic behind is was more like "I need paint layers, do I back a fund to make them or do I renew my mari/substance subscription when it's up in 6 months". It's not like everyone is using the full functionality of every software - I've been using zbrush since version 2.0 every day, and maybe using 10% of it's capabilities. If I could have that in blender I wouldn't need that anymore but it's hard to predict when it could happen, and there are bills to pay every month.

* @fun2tax * That's fair enough, I guess it could take away money from the dev fund which is currently used to keep development going on a larger scale and keeping blender alive.

How about part of the raised money going to the development fund? Just trying to think of ways to get something in more streamlined - let's say I'm a modeller/animator/architect, want a specific feature/bugfix and have 100 bucks to spare. That amount isn't going to do much, and putting it in the dev fund wouldn't really solve my issue. 100 people with the same agenda might make a difference.

* @3dddan * Yes I think same problem too. And I know my suggested way have pro and con. As for me I hope to keep blender free always. So I hope to buck up by joining as cloud member. And if , blender cloud offer option, to choose "purpose" which member hope to push , then 50 percent (or 30 or 25) will be used for the purpose, I think blender cloud can get more member.

User can feel, they contribute to protect blender (as whole meaning), and at same time, they contribute along to their private purpose too.

But I do not know, after all it will just take money from blender dev team to keep stable, Anyway your suggestion is really interesting for me. If blender officialy organize new fund (more sepecific) , I hope to join it.

* @fun2tax *

Yes, I fully agree.

It'd be great if cloud could offer to have at least partial control over where the money goes - but then again, where would we draw a line? Who's going to suggest which features to choose from? Eventually it can become the same thing, people voting for a feature/addon/fix, and deciding to put part of their contribution behind it. I would prefer blender to have control over it, but it'd mean additional overhead costs.

Keeping blender stable is one thing, especially with a limited amount of developers. You can't really jump on every wish from the community. But with a growing number of developers eventually it's going to steer into this direction more and more, they need to accommodate a market if they're looking to widen the user base - and they're doing an amazing job already, don't get me wrong. Of course the worst thing you could do is make hasty decisions, messy things up on the front end - I'm just throwing ideas around.