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

[Matt Ebb]

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