[IAEP] The Future of Sugar on a Stick

[Sebastian Dziallas]

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, 
and elsewhere.

Values:

* 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 
something wrong.

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.

Thanks,
Sebastian Dziallas