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

[Sascha Silbe]

Excerpts from David Farning's message of Sun Oct 24 06:42:24 +0200 2010:

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

Was there something going on behind the scenes? From Tomeus mail I would
have thought his reasons were entirely personal ones (i.e. something
like having to take care of his parents or his girlfriend not wanting to
have to share him with Sugar Labs anymore).


> At the risk of angering pretty much everybody....

Thanks for asking hard questions! Sugar Labs is certainly living in
interesting times [6] and will continue to do so in the near to medium
future.


> Premise 1. Sugar is open source, written in python, and the source is
> easily available.  Therefore kids will develop and improve 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.
[Premise 2 pulled up]

Your premises 1-2 are not useful because they fail to make an important
distinction: Hacking Sugar might be easy, but producing something that
is good enough for millions of users is hard.

Sugar Labs is trying to build a product with exceptional goals
(Collaboration [1], Journaling [2], easy hacking [3], Security [4] to
name a few). It's only natural that this requires extraordinary
capability of the people involved.

Hacking is easy. Everyone can learn it. But building a complex system
that works _well_ is a craft. It requires years of experience. You can't
teach it in front a class and expect students to be good at it. Sure,
a lot of the knowledge taught at university can be useful, but it isn't
sufficient. I've seen teenagers write better programs than most of the
(ex-)students I know that finished information science.

Additionally, we are working with technologies that are often bleeding
edge and with complex interactions that even I (as an experienced Sugar
developer) don't understand fully. This means there a few people
experienced enough to work on Sugar core and a steep learning curve.

Fortunately, there are ways to manage complexity without requiring
everybody to be a genius. I highly recommend reading the iMatix essay
about software design [5] at least once. It still requires at least
one exceptional developer (called architect in the essay) and hard work
(e.g. writing test suites).

The current design is quite monolithic with virtually no automated
testing. It's fine for Proof-of-Concept code, but not sound for an
actual product. Bugs in one part can affect the entire system (e.g. the
pass phrase dialog locking up the entire UI); the only way to discover
bugs is by exposing humans to the software. This makes it even more
important to accept only high-quality code into Glucose.


My long-term goal is to split up and factor out as much possible from
"the Shell":
- moving out our custom functionality into mainstream components like
  NetworkManager (for automatic Ad-Hoc/Mesh network selection),
  window managers / pagers / panels (parts of or the entire Frame),
- separating independent functions into individual processes (Journal)
- using (now-)standard protocols.

I firmly believe this will make Sugar easier to maintain (we can tap on
the resources of the mainstream projects), more reliable, easier to
customise and enhance. The latter will facilitate a growing developer
community.


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

Depends entirely on your definition of useful contribution. Fixing a
typo: as low as one day (with outside help). Writing a useful activity: 
a few weeks or months maybe. Non-trivial patches to Glucose: Several
years minimum.


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

I am certainly guilty of this attitude, so let me state my intentions:

Creating good patches (code contributions) can only be learned by doing.
Improvements to the personal style and abilities only happen if there's
something you know you can (and want to) improve on. This is at least
my personal experience.

So rather than accepting a patch and fixing it up myself, I try to show
the submitter how to do it.

Of course, my well-meaning intentions don't necessarily make this is a
good idea. However I am open to suggestions on how we (and specifically
I) can improve the review process.


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

While 1) is certainly true, I don't think 2)-3) matter much. E.g. I am
targeting adults, not children, thus failing #3.


> There is the lack of accountability to stakeholders.

I'm not even sure what that phrase means in the context of an Open Source
community.

Sascha

[1] https://wiki.sugarlabs.org/go/Human_Interface_Guidelines#Presence_is_Always_Present
[2] https://wiki.sugarlabs.org/go/Human_Interface_Guidelines#Journaling
[3] https://wiki.sugarlabs.org/go/Human_Interface_Guidelines#View_Source
[4] https://wiki.sugarlabs.org/go/Human_Interface_Guidelines#Security
[5] http://www.imatix.com/articles:how-to-build-utterly-reliable-systems
[6] http://en.wikipedia.org/wiki/May_you_live_in_interesting_times
--
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20101024/bccae3f8/attachment.pgp>