[IAEP] SoaS as a Sugar Labs project.

Bernie Innocenti bernie at codewiz.org
Tue Aug 25 10:13:53 EDT 2009

El Mon, 24-08-2009 a las 20:58 +0200, Martin Langhoff escribió:
> And also... and completely from the outside... I'll apologise in
> advance for saying something I know might be controversial. I worry
> that SL seems to have -- for a external party like me -- more
> bureaucracy than it has people "doing". IMHExperience, the projects I
> enjoy working on, and that I see being productive have  a much lower
> "procedure/label/committe " : contributor ratio.

I don't necessarily disagree with you, but just 2 days ago I was offered
an advice on the other side of the spectrum by Michael: he notes that a
lot of important things are falling through the cracks because nobody
organizes the available resources.  His suggestion is to introduce real
project management into the game, which is basically what David's
Projects idea seems to bring.

My initial reaction was that community projects work by employing
maintainers rather than project managers.  The substantial difference
between the two is that a maintainer does not proactively set priorities
and allocate resources.  There was an hidden assumption in my thinking
that a maintainer /could not/ tell people what to do based on the fact
that his workers are unpaid volunteers.

But, as Michael pointed out, besides the volunteers who are strongly
self-motivated, there are also many others who are seeking for guidance
and would actually feel confused by the fuzziness and apparent lack of
direction of an organization with plenty of individual freedom.

Some wasted effort happens when a volunteer looses focus or motivation
along the way and nobody else takes over.  This is common even among
highly successful communities such as the Linux kernel hackers.  The job
of any half-skilled project manager would be detecting these stalls and
mitigate them whenever possible.

Hopefully, the formalization of our development efforts into
well-defined entities called projects led by officially appointed
project leaders will help rebalance things.

> Time for me to shut up. From now on I assume you know about these
> risks, and won't mention the topic in polite company no more. After
> all, I am not working my ass off on SL, you are.
> Thanks for your patience :-)

A meta-comment on your post: you don't need to apologize and be shy for
offering your criticism, no matter how many people will disagree with
you.  A culture of open criticism is essential for improving our
processes, especially when a good advice comes along with the critical

I recently got useful criticism from Bemasc, Christoph and Daniel on
#sugar regarding our relationship with Deployments.  Their feeling is
that we didn't do enough to get them involved, mine is that our efforts
to reach out have been largely unsuccessful for reasons I do not fully
understand.  By discussing it through, it became apparent that we
actually had in mind two fundamentally different things: I'm interested
in getting *contribution* from deployments rather than offering them

I now realized that the two things should go together and we probably
shouldn't ask for contribution without offering some support in exchange
for it.  This is the essence of participation, the antithesis of passive
dependence, which would be unsustainable both for SL and for its

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

More information about the IAEP mailing list