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 _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel