[Sugar-devel] [IAEP] The Future of Sugar on a Stick

[Tomeu Vizoso]

FWIW, as a (upstream) Sugar developer what I would like to see is:

== Further separation between upstream and downstreams ==

Without artificially privileging nor discriminating any downstream. So
a big +1 to giving a stronger identity to the SoaS project and to
creating a separate mailing list.

We already have devel at lists.laptop.org for OLPC,
fedora-olpc-list at redhat.com and others for Fedora,
debian-olpc-devel at lists.alioth.debian.org for Debian,
ubuntu-sugarteam at lists.ubuntu.com for Ubuntu. Why SoaS would be
different and share the mailing list with the upstream developers?

As I'm also personally involved in SoaS (because as an individual I
chose to) I will subscribe to the new SoaS ml and will crosspost as I
see fit, but I don't think this should be SLs policy.


== SLs to decide if it wants to produce an end-user product ==

If we agree on this, then I think it will be easier to decide if
there's value in designating one as the preferred consumer-oriented
product and which distro that would be.


== SLs to keep empowering the people who choose to do stuff ==

We have almost no budget, so we cannot tell people on what they should
work. So unless people can do what they want and they feel supported
by SLs, we are going to disappear quite soon.

Just to make it clear, by "do" I don't mean only to code. Actually, we
could say that we have a surplus of coders if we see releases as a
continuous process that starts from identifying needs and ends with
publishing solutions to them.

We need people that talk to users and deployers, that translate and
consolidate the feedback, that provide this information in a way
usable by coders and, very importantly, that close the cycle by
telling deployers which of their needs have been addressed in a new
release.

The GPA deployment team has done a remarkably good job at explaining
their needs and I have been giving priority to those issues over the
ones expressed by individuals. But still there's lots of room to
improve: needs should be expressed in a more appropriate moment of the
release cycle, we need to find a way for deployers to engage in the
feature process and we need a very simple way for a developer to know
which issues are important where.

Most other deployments are totally absent from our community and a few
others have made too timid attempts to express their needs. This needs
to change. We have made a call for help with bug triaging and the
developers are having to do that ourselves because no one replied.
Several people have spent hours writing emails criticizing developers
for how little we care about OLPC, but cannot spend less than that
time in helping triaging bugs.

With such an enormous hole in our community I don't think we can tell
an individual like Sebastian that he should row his boat in some other
direction. We are still too weak and depend too much on such
passionate people to waste them.

Regards,

Tomeu

On Mon, Sep 14, 2009 at 17:32, Sebastian Dziallas <sebastian at when.com> wrote:
> 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
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning