[Sugar-devel] [IAEP] stepping down as maintainer

[David Farning]

On Tue, Oct 19, 2010 at 11:50 AM, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:
> Hi,
>
> for personal reasons have to drastically reduce my involvement in the project.
>
> Will be leaving maintenance of my modules and unsubscribing from the
> mailing lists. My place on the board is vacant from now on and I'll be
> adding to the wiki the new vacancies:
> http://wiki.sugarlabs.org/go/Vacancies
>
> Cheers and good luck,
>
> Tomeu

Sugar Labs lost its lead developer.  It is unfortunate that no-one has
done a public review of the reasons and implications of Tomeu quiting.
 Tomeu's leaving is significant enough that Sugar Labs should take a
hard look at what is working, what is not working, and how to fix the
pieces that are not working.

At the risk of angering pretty much everybody.... Sugar Labs has three
fundamental problems.  Sugar Labs is optimistic to the point of
untruthfulness.  Sugar Labs is lead by veto rather than vision.  There
is a lack of accountability to stakeholders.

Sugar Labs is optimistic to the point of untruthfulness.  The main
_symptom_ of this is the current state of Sugar Labs.  Sugar is not
perfect. Sugar Labs is not perfect.

The _disease_ is an adherence to faulty premises rather then the use
of the Scientific Method of: Ask a question. Do background research.
Construct a hypothesis. Test your hypothesis by doing an experiment.
Analyze your data and draw a conclusion. Communicate your results.

Premise 1. Sugar is open source, written in python, and the source is
easily available.  Therefore kids will develop and improve Sugar.
What fraction of useful and usable improvements have been committed
into sugar by the target users.  The key metric is commit ratio.
Everyone has an antidote about some budding hacker.  As with the patch
acceptance process, developing Sugar requires more than solving logic
problems.

In theory this premise is sound, and desirable, the overall technical
capabilities of a nation will improve as more people are exposed to
Sugar at an early age.  The question become what is the time lag
between exposure to Sugar and useful contribution to Sugar?

Premise 2. Sugar is open source, written in python, and the source is
easily available.  Therefore deployments will develop Sugar.  What
fraction of useful and usable improvements have been committed into
sugar by deployments.

In theory this premise is sound, and desirable, Sugar deployments and
their associated support infrastructure provide a catalyst for
building local technical capability. The question becomes, considering
the limited resources of deployments, is the benefit of contributing
upstream worth the cost?

Premise 3.  Any problems with Sugar are because the user, teacher, or
deployment is not smart or motivated enough.  What are the usability
concerns of users, teachers, and deployments? How are those concerns
being addressed?

In theory this is true yet undesirable.  A significantly motived
person _can_ figure out just about anything.  The primary decision
making factor for users, teachers, and deployments is marginal
benefit.  Does using and learning to use the laptop/Sugar prove a
marginal benefit over other learning opertunities.

Sugar Labs is lead by veto rather than vision. A _symptom_ is the
development process. It it easy to have fix commited to Fedora or
OLPC.  It is hard to have a fix commited to Sugar Labs.  When someone
sends a useful fix to either OLPC or Fedora, a senior developer takes
the patch, review it, fixes it up (if necessary) and thanks the
contributor.  This provides an incentive and on-ramp for less
experienced developers to participate and contribute.

Sugar Labs rejects most patches.  Once a patch is technically correct,
which can take several iterations for a new developer, it is forward
to another developer for their vote of approval.  The end result is
that very few people bother to submitted patches upstream.

The _disease_ is a marginalization of anyone who dissents.  As a
result no one is willing to take a risk.  There is an unwritten
checklist for participation.  1) Are you a knowledgeable, experienced,
and patient open source developer? 2) Is your goal open source
advocacy? 3) Are you a strict constructionist? 4)....  This results in
very low participation in Sugar Labs.

There is the lack of accountability to stakeholders.  The Board of
Directors of an non-profit organization the board reports to
stakeholders, particularly the local communities which the nonprofit
serves.  The Executive Director is responible for carrying out the
strategic plans and policies as established by the board of directors.

As a starting point for bringing Sugar Labs out its current crisis, I
suggest the following plan:

1. Each Oversight board member, or candidate, identify a stakeholder
and spend the next 12 months advocating for that stakeholder.
Advocating includes: Identify the specif needs and goals of the
stakeholder.  Identify the resources that stakeholder can contribute
to Sugar Labs.  Identify how Sugar or Sugar Labs can better meet those
needs and goals.  Identify how that stakeholder's resources can be
more effectively used to improve Sugar and Sugar Labs.  Propose and
implement solutions for how Sugar Labs can better meet that
stakeholder's needs.

2. The Executive Director should modify Sugar Digest to include a
'Meeting Stakeholder Needs' section which describes what tangible
steps Sugar Labs has done to meet the needs, as identified by each
board member, of various stakeholders.

Anyone not willing to take the above responsibilities should
reconsider their motivations being a leader at Sugar Labs.

david