Remember blender storm? What if we could fund projects we liked directly and have the money held in a bucket and released as certain milestones were met?
That way if certain milestones aren’t met, the money returns to the investors out of the bucket–and no one feels like they’ve been duped or wasted money.
I like the idea, but who decides when these milestones are met “to standard”.
The people who have their money in the bucket?
Which has the potential and hence, given some people on the Internet, the 99.9% guarantee that there will be people that don’t pay up when the feature is finished.
And, of course, it ignores the potential for the code to be ignored by the Blender Foundation even if completed “to standard”. Hell, just a day or so ago Ton is trying to change keymap changes Campbell made some time ago (that I happen to agree with), so even being in the dev team doesn’t guarantee a change gets incorporated.
The biggest issue with paying others to develop features for Blender at the moment is the need to get the Blender Foundation on side. I’m not saying they are complete control freaks or any such nonsense (so don’t go verballing me on this), but they have their own POV on what Blender should be and how it should work. A company paying for something that unknowingly goes against this view will probably feel ticked off when that money paid for a temporary patch solution only.
They put their money in the bucket first. It’s returned “if” the milestone isn’t completed.
Kickstarter is awesome, except that only US-based citizens can start a kickstarter project. Which means that all developers who wants to use Kickstarter to fund something in Blender must be located in the US, or know someone with a US bank account. 
a good compromise then would be that only the starter of the ‘blender storm’ would be judging that
or maybe him/her and one administrator of blenderstorm both would have to give an ok?
I’d consider this a slightly different topic from the above discussion but non the less related, yes,
so possible solution to this would be that the donation drive would only start once an
experienced(/senior) programmer at BStorm has agreed to mentor the idea’s implementation perhaps?
One pitfall is that although a developer might provide a good-faith estimate of how long something might take to code, and thus its price, there can be unanticipated difficulties or changes to the relevant Blender code that could cause the project to take much more time than anticipated. In that circumstance, do you re-price the project, drop it, or…
I worked in software dev for a large ISP and I saw teams of veteran software people hit snags similar to the ones I mentioned with the result that the completion dates for some projects had to be moved back several times. Sometimes there was some screaming and there were always long, long hours when this happened but, we kept getting paid. With donated funding this might not be the case.
“If you want it so bad, pay a developer to do it and fund the project yourself”
yeah, money can be a good motivator, but throwing money at a coder won’t make him smarter, more experienced, or more capable of solving problems…
I would tend to think that finding a developer with the right capabilities is the bigger issue here
I like the core thought of it, however, I prefer them official Blender dudes to do it their way; I know they’re working on stability more than features at the moment. If there’s a feature I’d like to see, I’d check out graphicall, though that’s probably not a valid answer.
I guess the best thing would be if the Blender institute could handle such fundraisers.
And, of course, it ignores the potential for the code to be ignored by the Blender Foundation even if completed “to standard”
What struck me is how “unmodular” blender seems to be if you compare it with other packages. Everytime somebody would like to hire somebody to do something, you will get the point that you paid some money for things that may not end up in Blender anyway. And there is nothing wrong with this as Blender would potential grow into a big monster.
In a wonderful world you could pay a developer to develop feature X that acts like a kind of plugin. That seems the way that a lot of other commercial (and non commercial/open source (!)) programs do it. You have plugins for modeling, fluids, fire , physics, rendering ,… that works without altering the core of the program itself.
Off course Blender 2.5 is still in development and it wouldn’t be honest to criticize it in this stage, but I really hope that in the future that they will focus on also playing nice with external stuff. And yes I am aware we do have scripts but that isn’t really the same thing. I love python but it isn’t perfect for everything and the possibility of writing C plugins (If I read correctly) are very limited.
The party line is ‘why do you need plugins if you can just change the source’ since proprietary programs, by their very nature, don’t allow this and must be extended by other means.
It wouldn’t be too hard to add this (I’ve done ~90% of the work already by porting libplugin to blender) but there is very little (zero) interest in such a system by the core devs so…
That is really a shame because even if it is something philosophical with regards of non proprietary you could always release the api headers under a GPL license.
It would be great if BF could just raise enough money to hire Blackstar Solutions to help with the Blender development, those guys are all but inexperienced and would surely be able to speed up the development process.
It wouldn’t be too hard to add this (I’ve done ~90% of the work already by porting libplugin to blender) but there is very little (zero) interest in such a system by the core devs so…
You don’t say… who would have thought that’d be an issue?
I’ve been wishing for a kind of package system for blender, a central repository with all the patches in one place in different staging areas like stable (Blender Foundation) unstable (reviewed) and experimental (completely new) or something. Then you would have a python app for example that let’s you browse this repository and add patches to your build. Upstream (the patch developers) would have to update the patch to the current svn status, which could be a pain. But the app could sort this out too, so you get the patches applied to a version of trunk where they all, or most of them, work, like a dependency system with metadata.
Edit: Of course bug reports for stable should (could?) only be filed by people using “clean” BF builds. There is the chance of bugs that come from the unstable or experimental patches but that is not guaranteed right now either.
