On Mon, Feb 14, 2011 at 7:22 AM, Sascha Silbe <sascha-ml-reply-to-201...@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 > dextr...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/dextrose > > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel