Home > Sugar > The making of Sugar

The making of Sugar

January 30th, 2009

We used to be a project directed by a single organization, with no upstream community. And we are now at the opposite of the spectrum, we have a strong upstream and the downstream land is trying to grow up or to recover from organizational changes.

When we created Sugar Labs we made a very conscious decision about the scope of the development. Following the model of GNOME, we were not going to ship and support an end user product, but we was going to rely on linux distributions and OLPC to do it.

The model we had in mind is the classical situation for free software desktops and it goes more or less like this:

  • An upstream entity, usually formed by individual volunteers and company funded engineers develops a code base and a release process around it. Their final product is a set of source tarballs, which went through the testing of developers and project supporters.
  • Several distributors take the source tarballs, build packages out of them, apply customizations and fixes and distribute it as complete operating system: a user consumable product. This usually involves some level of formal QA, beta testing and support.
  • A bunch of end users acquire the distribution, to install it on their machines.

The OLPC step back from active development uncovered several problems in our model.

  • It’s unclear at which level beta testing and QA should be done. If we followed our logic it should happen at the distribution level. It’s not going to happen because Sugar is a niche product in every distribution and that’s not going to change soon. We might even argue it should never happen because our audience is very different from the traditional linux one. To put it bluntly, we are not working on the perfect desktop for geeks.
  • Distributions like Sugar on a stick are hosted and perceived as Sugar Labs products. Upstream/downstream is a good abstraction but it needs both streams to be strong and active to work. Sugar Labs should ideally not work directly on end user products, but it’s forced to do so if no one is covering that role.
  • The feedback from the end users is not reaching upstream developers. There is no entity in the middle which is able to proxy it. And I don’t think traditional distributions will be able to cover that role, their target audience and hence their priorities are different.

The way Sugar reach his ends user is different. There is no direct link between distribution and end users. We have deployments in the middle. And I think that’s where the opportunity to fix our model lies. One or more deployers communities can cover several fundamental roles in the making of Sugar:

  • Testing. We need people to test Sugar based products and to file bugs appropriately, either in the distribution bug tracker or in the upstream one.
  • Feedback. We need to learn more about deployments necessities. A proxy in the middle will ensure that this feedback is actually gathered and appropriately dispatched, without requiring a huge effort from the development team, which should be busy fixing the issues.
  • Release process. Sugar on a stick is fundamentally a different product from Fedora 10, even if it’s based completely on it. Only a subset of Fedora is relevant for us, and part of that is only minimally relevant to the Fedora community. Ideally the deployment community should not do any development at all. But even in that case selecting packages, creating a spin, testing it, making sure that both Fedora and Sugar developers knows about the issues relevant to Soas, are all tasks that should happen at the deployment community level.

There are several deployers communities which are forming. olpcfriends, the Sugar Labs deployment team, Caroline for Soas. We need to encourage them to grow and take their responsibilities. And we need to start considering them as a fundamental part of the process which brings our code in the hands of the kids.

Probably incoherent but I have to run out. I’m still thinking this through. Comments and criticisms are welcome. A well shaped beautiful solution even more, it would make me sleep better tonight :)

Comments are closed.