[Sugar-devel] The Future of Sugar on a Stick
sebastian at when.com
Mon Sep 14 11:32:55 EDT 2009
This document is an open letter written to the Sugar Labs community. It
is an attempt to clear up the recent confusion about SoaS and let
community members know what SoaS is, what our goals are with regards to
it, and what possibilities we're considering for the future - both
technical and organizational - direction of the project. With the next
release of SoaS coming up in about three months, we also want to have
this discussion with our current release schedule in mind.
== What is SoaS? ==
Sugar on a Stick (SoaS) is a Linux distribution that enables kids to
reclaim computers for themselves in a world of computers made and
managed for and by adults. SoaS aims to make it easy for local deployers
to provide each student with a thumbdrive (stick), which can be booted
into the student's personalized Sugar environment from any machine.
Thus, SoaS advances in achieving its goal of giving each child in the
world access to its free and open source learning environment to create,
explore, reflect, and collaborate on any machine - at school, at home,
* Customizability - Deployments, as well as users, should be able to
build their own SoaS easily. It is crucial for the success of SoaS to
allow modifications and to make the process of creating derivates as
easy as possible.
* Deployability - SoaS must be easy to deploy. It should take as little
effort as possible to get to a working system, both for individual
sticks and for bigger deployments in computer labs.
* Local Support - We must encourage and foster the growth of local
community support for deployments. If we build things in a way that
means deployers can't fix most of their own problems, we're doing
A note on deployability: We want SoaS to always be the easiest Sugar
deployment option to support, which becomes more and more important as
the product matures and is used by more schools and teachers. In order
to properly support SoaS users, it is important that the upstream
components of the project also be well-supported, and that we have a
strong relationship with each upstream, especially our current base
system - Fedora, so we can rapidly resolve any issues that may arise.
But SoaS is not mature yet. It currently consists of various
technologies thrown together into a first working version of a product,
resulting in a number of inconsistent hacks. While we have been actively
trying to follow upstream development - for example within our major
component, Fedora - as much as possible, we didn't always succed here.
The more development took place, solutions got hacked up, causing a
difficulty of maintance in general. With the next release of SoaS coming
up in about three months, we are working on reducing these issues now.
One of these issues mentioned earlier is affecting users through the
possibility of installing and directly deploying SoaS. Right now,
teachers have to look for their own solutions to get SoaS in place,
which is a situation we want to change: Ideally, they would be able to
use a well-designed interface for installations and deployments.
On the other hand, the structure around SoaS is rather loose: decisions
tend to happen spontaneously on various mailing lists (since there is no
dedicated one), as well as in IRC channels. To create a place where the
project itself lives, to advance in realizing technical innovations, we
need such a mailing list - as well as a development team. Yes, we need a
SoaS development team for being able to implement all the cool things
out there. And since I don't have the bandwidth to handle all of this
myself and open source is about sharing experiences, about working
together, we need to find a good way of letting more people participate
in the process of working on SoaS.
Following the goals and visions stated above, the subsequent short-term
steps for SoaS are outlined below, with the goal in mind to become a SL
project. However, the technical communication will proceed on the newly
created mailing list and on Launchpad, whose pilot usage as our bug
tracker will continue, too.
Short Term Action Items:
* We create a SoaS mailing list.
* We establish the SoaS development team.
More information about the Sugar-devel