[Dextrose] [AC UPDATE] The "upstream" side of Sugar

[David Farning]

On Mon, Feb 14, 2011 at 7:22 AM, Sascha Silbe
<sascha-ml-reply-to-2011-2 at silbe.org> wrote:
> 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.

Tuning is an excellent metaphor.

david

> 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/
>
> _______________________________________________
> Dextrose mailing list
> Dextrose at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/dextrose
>
>