[Sugar-devel] [AC UPDATE] The "upstream" side of Sugar

[Sascha Silbe]

Hi everyone,

David has asked me to write a bit about the "upstream" side of things.
Since I'm also going to provide a glimpse about my future plans for
Sugar, I'm CC'ing sugar-devel.

As a general rule, the more "downstream" you get, the nearer to "the
user" you are and the more immediate are the problems you're trying
to solve. Reverse this and it reads: The more "upstream" you get, the
larger and more diverse the (indirect) user base will be, the more
general your solutions need to be and the focus needs to shift to long
term development. Or to put it short: Downstream is about tuning for
particular users, while upstream is about the Big Picture.

This doesn't imply upstream doesn't do any "day-to-day" tasks and is
always slow - the number of bug fixes and minor tweaks that went into
Sugar last year is too large for me to count (there were 300 commits
total). The last week, culminating in yesterdays Design Team meeting [1],
was a nice example of how efficiently we can work together.

But as upstream we need to think about long term development. How to
adjust to changing user needs and technologies [2] and also ensure
that the code doesn't disintegrate into an incoherent mass, but stays
understandable and working: maintainable.

According to the latest rumours [3], Sugar has a user base of over two
million children. Every single bug will likely affect thousands of
students. It's unavoidable that this influences our decisions: we want
to provide them with an optimal "experience" so they can learn _by_
using the computer, not learn how to work around bugs and deficiencies.
This means we strive for very high code quality - emphasising the
maintainability over short term solutions that might improve some part
of the Sugar "experience".

Of course, raising the bar too high for contributors is bad in the long
run, too: If it's too hard, people will simply stop contributing. And
this hits our most precious "resource" (on the "technology" side of the
project): developers. Few developers means fewer time spent on fixing
bugs, adding features, making Sugar better. I.e.: only minor
improvements in "experience".

Hopefully we are now on a way to avoid at least some of the pitfalls.
Dextrose and OLPC are taking up the downstream role and work on the
immediate needs of users. They will take care of working with users
on their problems and fixing them. That leaves upstream Sugar free to
worry a bit less about bugs and focus more on expanding Sugar.

Of particular importance is welcoming new contributors and their work
(and of course welcoming back some former contributors!). Instead of
asking them to improve their patches during many rounds of review, I
will now do the fix-ups (including phrasing good commit descriptions -
these are more important to the "core developers" than to occasional
contributors).

But even working better with contributors is not going to be enough.
The number of open tickets is approaching four digits [4]. OLPC is going
to work on tablet PCs [5] once the XO-1.75 is finished, rendering the
current Sugar interaction design (based on particular characteristics
of pointer devices with relative coordinates and more than one button)
unusable.

What we need is much more developers. More than we can train "from
scratch" (by hiring university alumni) using the available resources.
What we need is to tap into the "pool" of Open Source developers that
already exist.

We need to "take" more existing components where possible, focussing
on "making" only the ones ourselves that are clearly insufficient or
missing [6] (like the Journal and data store). This leverages the
work of the communities around the existing components - in particular
the Gnome community.

We also need to make Sugar more interesting for developers. "Eating
our own dog food" is the best way to get bugs noticed and fixed fast or
even at all. Developers are specialists and require a "tool box" that is
tuned for them in order to be productive. Most of the Sugar developers
do their Sugar hacking outside of Sugar because they are more productive
that way. If we want them to work "inside" Sugar, we need to make it
adjustable to their needs. We need to allow them to mix & match
components like the window manager, and to configure Sugar in a way that
works best for them.

Some might argue that this misses the target user base of Sugar. But
I'll argue back that Sugar is not just about low floor (I'm not
intending to get rid of that part), but also about "no ceiling".
Children evolve into adults, "users" into "developers". And with
activities like EToys [7], the latter distinction is blurred even today.

Thanks to everyone who followed me through to the end. I didn't intend
this text to get that long (actually I was more worried about not having
enough to write about :) ). Seemed like there was a lot to talk about
piled up.

I invite everyone to take a look at my current brain dump [8] and start
discussing the individual ideas. Let's work together to make Sugar a
(better) place for all of us!

Sascha (silbe@{sugarlabs.org,activitycentral.com})

[1] http://meeting.sugarlabs.org/sugar-meeting/meetings/2011-02-13T14:01:43.html
[2] http://meeting.sugarlabs.org/sugar-meeting/2011-02-13#i_2629691
[3] http://one.laptop.org/news/olpcmap-2-million-xo-laptop-olpc-deployments-mapped
[4] https://bugs.sugarlabs.org/query?status=accepted&status=assigned&status=new&status=reopened
[5] http://www.marvell.com/company/news/press_detail.html?releaseID=1418
[6] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.94.5439
[7] https://wiki.sugarlabs.org/go/Activities/Etoys
[8] https://wiki.sugarlabs.org/go/User:sascha_silbe
-- 
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: 494 bytes
Desc: not available
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20110214/98698f43/attachment-0001.pgp>