[Bf-committers] The Future of Blender Projects WAS meeting notes

[Campbell Barton]

On Sun, Jun 24, 2012 at 1:29 AM, Matt Ebb <matt at mke3.net> wrote:
> On Fri, Jun 22, 2012 at 12:05 AM, Ton Roosendaal <ton at blender.org> wrote:
>> with the evident benefits but also with as danger that it can go out of control with a huge pile of postponed todo items and issues. :)
>>
>> http://en.wikipedia.org/wiki/Technical_debt
>
> This is an issue for blender, and has been for a while. It may not be
> as exciting to rally volunteer developers around, but I think
> post-2.6, a period of 'paying off these debts' would be very good for
> blender users, especially those using it in production.
>
> I think that this isn't just related to short release cycles though, a
> lot of it's also due to the open movie projects ('Business pressures'
> in that list, I suppose). They certainly have their benefits, but they
> also leave a lot of unfinished work in their wake.
>
> One of the original ideas for the open movies was to use a practical
> animation project to 'get blender ready for production', however in
> the heat of the project, under deadlines and resource pressures, this
> becomes more like 'fit in the minimum required to allow this
> particular production to get done'.
>
> Using blender in production at the time, I was quite sensitive to this
> happening during BBB, with features implemented well enough for the
> team's specific purposes, but not so practical for other use cases. It
> happened in Sintel (hair dynamics is one example), and it now seems to
> be happening in Mango. One example that I'm familiar with right now is
> how the render API seems to have been bypassed and all but forgotten,
> during the rush to get Cycles in a usable state.
>
> Another issue is that the open project are usually exploring new
> territory for the development team - that's often a major reasons for
> existence of the projects (eg. 'improve blender's furry hair styling
> and rendering' or 'improve live-action vfx compositing'). It's great
> to have a focused target, and it's often a good way to get things
> done. The danger however is that often the coders and artists involved
> have little experience in a particular field that they're exploring,
> and the design decisions and implementations may turn out to not be so
> good in hindsight, and maybe aren't so good to commit to for Blender.
>
> There's a tendency to think that since a movie project got completed,
> then that particular area of functionality is 'solved', eg. "BBB got
> finished, therefore hair styling and rendering is done, and we can
> move on". In reality, Blender users can be left with tools that really
> don't work that well outside of the project's specific needs, or tools
> that now with the benefit of hindsight and experience, should have
> been implemented in a better way. However if developers keep moving on
> to newer things, and if this happens across all areas of
> functionality, the end result is an application made up of parts which
> are all first-draft attempts, which work 'ok' in some situations but
> not in others, and never smoothly and elegantly.
>
> One positive example on the other hand was the render branch after
> Sintel. The easy thing to do would have been to satisfy the casual
> users who want to play with new toys, add it all in, and move on.
> After all the development work that was done on it, it was really
> commendable to see self-reflection and the willingness to step back,
> critique it, and say "This isn't right for Blender and its users, it
> needs to be done a better way", and throw a lot of it away. In the
> end, it led to cycles, which I'm sure most Blender users will be much
> happier using in the long term, and is hopefully shaping up to be
> something that's actually a great tool to use, not just a 75% done
> first-version.
>
> This is also a good argument for doing movie project-specific
> development in a separate branch. Adding these things into trunk as
> they are coded makes it much more difficult to revert later on.
>
> So! For these open projects to become more effective ways of achieving
> the goal of improving Blender as a package, not as a project-specific
> tool, there needs to be a period of critique and further work after
> each project. I know from experience that at the end of a tiring job
> when you just want to forget it all, have a rest, and move on, the
> last thing you want to do is go back over it all and re-work it, but
> that's the difference between doing this development for that movie
> project only, or for Blender in general.
>
> Questions need to be asked - "Is this the right way to go?" "Should we
> revise this with better design decisions?" "What worked and didn't
> work well during the course of the project?" "What hacks did we have
> to do to make this work, that we should clean up?". And even if the
> design is good, and it worked well, and you wouldn't do it differently
> a second time around, it's still very important to ask "Is this enough
> for general use by other Blender users, not just this open movie team
> working on this project?". Some of these will come out as feedback
> from other users during the course of the project. Each time a
> response to feedback is: "It's not a target for our project", it would
> be a good idea to write it down, and re-visit the idea in this
> debt-paying period afterwards.
>
> Anyway, this is just my observation from many years of watching these
> projects, and quite a few of using Blender in production. I know in
> the past I'd have found using Blender to have been a much more
> positive experience if more effort had been spent on finishing
> unfinished work and paying off these technical debts, rather than
> moving on to newer things.
>
> cheers
>
> Matt

Hi Matt, you hit the nail on the head!

This is something I'm quite conscious of and try to avoid the habit of
hacking in stuff just for the movie.

Even so - we aim to make blender great for some open movie but only
have 2-3 devs working on it and what with bug fixes, hardware failure
and random features that are needed `yesterday`, We end up something
much more limited/crappy - as you describe.

It would be interesting to investigate ways to mitigate this effect
(with follow up development projects, or more time spent before to
meet the dev targets needed for the project).

-- 
- Campbell