[Sugar-devel] R&D vs Product Support
bernie at codewiz.org
Thu Jun 17 18:56:27 EDT 2010
El Wed, 16-06-2010 a las 18:27 +0200, Simon Schampijer escribió:
> I saw the talk from Mark Shuttleworth at Linuxtag and he said a few
> words on Releases, and why is makes sense to bundle forces. Basically,
> bundling forces is a powerful idea behind open source. We are a small
> project, if we keep being aligned with all the bigger projects
> especially gnome we will profit from this joined efforts a lot.
I couldn't agree more.
At the same time, I'm seeing a number of very skilled Sugar hackers who
would be more inclined to work on complex innovative projects and would
therefore prefer a less structured approach.
Long term, both approaches are essential to the evolution of a project.
Some large hi-tech companies I worked for in my previous life solved the
conflict of approaches by splitting their engineering staff into two
departments: R&D lab and Design/Engineering office.
R&D creates prototypes and then hands them off to the other department
which turns them into an industrialized product. Needless to say, many
projects die during the transition. Not everything that is technically
possible can become a finished, marketable product.
It may seem that R&D is doing all the hard work while engineering just
adds the finishing touches,but Brooks claims that there's a x3 factor in
effort between a working program and a finished product that could be
commercialized to paying customers. I believe that Brooks' law holds
also for a FLOSS project like ours.
Despite being used in production for ~2 years, Sugar still has many
traits of a half-finished prototype: it can backup but not yet
restore... Stuff that R&D people wouldn't normally do, but still takes
many years of organized engineering work to get right.
Moreover, some of these missing features are urgently needed. A simple &
pragmatic solution often serves our users better than a theoretically
perfect one which would require redesigning a large subsystem.
Every time I see a hypothetical design blocking the delivery of a quick
& effective solution available today, I think that we should rethink our
project structure to minimize this tension. Ensuring that the proper
design will eventually be implemented is as important as delivering a
sufficiently polished product to our current user base. It seems that
the two approaches should proceed in parallel.
// Bernie Innocenti - http://codewiz.org/
\X/ Sugar Labs - http://sugarlabs.org/
More information about the Sugar-devel