Remarks on the Work of Sugar

[Martin Dengler]

meta-comments: 1) I think all this discussion should be interpreted in
the spirit of "how can we do better, and what can we be focused on in
the next year", rather than "this is why things are bad" (because
they're not).  I'm not sure a casual reader would understand this.

2) I'll leave more involved people to comment on the main substance; I
have just a few tangential but possibly interesting notes:

On Tue, Jul 22, 2008 at 07:49:23PM -0400, Michael Stone wrote:
> After mild provocation, Marco and Tomeu asked me to publish some of my
> reactions to sugar's architecture, design, and implementation. Here are
> a few initial comments.
> 
> 1) Sugar could better hold contributors if it (and its web presence)
> were designed to be extended and to highlight external contributions. 
>
>    Evidence: Trac and xmonad both have thriving communities of
>    contributors based around their plugin architectures and community
>    sites like trac-hacks.org.

It's not immediately obvious to me that community building around
developer-targeted software is the same as around Sugar's community
building needs (as Sugar isn't meant to be used primarily/only by
developers).

Notwithstanding, this visualization of python's contributor pattern:

http://www.vimeo.com/1093745

...would seem to caution against getting too despondent about
community contrbutions just yet.  For the impatient (but it's kind of
good eye candy.; check it out), it's about two (2) years before any
major contributors appear, four (4) years before the next infusion of
checkins, after five (5) years some significant documentation (and a
documentor) appears, and after about *eight* (8) years there finally are
over three very substantial committers.

>    Evidence: Sugar has already attracted new contributors by creating
>    three different extension points:
>    
>      Activities themselves
>      Device entries on the Frame
>      Control Panel Entries
> 
>    Evidence: Non-extensible aspects of Sugar like activity launching,
>    home view layout, frame contents, and the presence service have
>    stagnated.

You're slightly begging the question ("non-extensible aspects" have
"stagnated").  But I think others have pointed out the home view
layout and (less so) frame content progress.  I think a better phrase
than "stagnated" is "not progressed as fast", and that this is a
natural and expected outcome of too little development and community
building resources.

> 2) Sugar would run more smoothly on-XO if jhbuild were retired. By
> running at non-XO speeds, jhbuild permits Sugar developers to retain
> faulty assumptions about the environment in which their code will
> run.

I think this is a good point in the abstract.  Do any frequent contributors
*not* have an XO?  Has anyone considered "marketing" the development
by unsolicited "indefinite loan" XOs being sent to vulnerable ( :) )
developers?  Consider positive benefits like:
http://www.artima.com/weblogs/viewpost.jsp?thread=148064

> Regards,
> 
> Michael
> 
> P.S. - Let me know if you'd like to see more such remarks in the future
> (perhaps on other subsystems?) or if you'd like to see more detailed
> exploration of any of the items noted above.

I think these types of comments are very valuable, but would be (even
more) constructive (because they'd be less general) if they were made
on a subsystem-by-subsystem basis.

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080723/fc472440/attachment.sig>