[Sugar-devel] R&D vs Product Support

[Tomeu Vizoso]

On Fri, Jun 18, 2010 at 00:56, Bernie Innocenti <bernie at codewiz.org> wrote:
> 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.

I'm always puzzled when I hear this argument. In which ways is the
stable release process impeding people to experiment?

If you want to do weird stuff, do it. And when this becomes something
that can get into a stable product, propose it for merging.

> 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.

Do you have an example of a FOSS community that has done such a split?

> 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.

I'm also concerned about this, but frankly, if we haven't learned yet
to discuss things in a productive way, no project reorganization will
save us.

I see people worried about their work not being upstreamed because it
doesn't match the maintainer criteria. This is about the most common
conflict in FOSS communities and we really need to get better at
handling it.

Downstreams and upstreams need first to, for every case, define
together the problem space so we are all discussing the same thing.
Often the maintainer would accept a change if she knew the whole story
behind it, but that information is not passed upstream.

Sometimes, the maintainer will be mistaken (surprise!), and though I
don't think we should override her prerogative about what gets in and
what not, the submitter could try to gather some consensus from the
community so the maintainer can reconsider her decision with more
information.

But right now, there are some conflicts going on that haven't even
been explained in the mailing list.

And one more thing: not EVERYTHING needs to be upstreamed, we should
use common sense to decide what really needs to and what doesn't need
to.

Regards,

Tomeu

> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
>
>