Sugar Labs

Sugar Labs: a software-development association

The Sugar development platform is available under the open-source GNU General Public License (GPL) to anyone who wants to extend it. “Sugar Labs”, a (soon to be established) non-profit foundation will serve as a support base and gathering place for the community of educators and software developers who want to extend the platform and who have been creating Sugar-compatible applications.

Goals

Sugar supports the notions that learners should “share by default” and be able to “explore, express, debug, and critique.” Thus Sugar puts an emphasis on “activities” rather than “applications.” The foundation will focus on solving the challenges that are relevant to these aspects of the interface, namely:

1. A goal is to make it “simple” to share Sugar activities. This will require an architecture that allows discovery of activities.
2. A second goal is to create versions of Sugar that run on multiple operating systems and on multiple hardware platforms. It should be “simple” to install Sugar everywhere. Specifically, it means packaging for every distribution and every virtual machine—removing hardware-related dependencies wherever possible.
3. A third goal is to make it “simple” to write Sugar activities. This necessitates stable APIs and example code that uses these APIs.
4. A fourth goal is to make Sugar activities even more secure. Our principal user community is comprised of children; they must be protected from malware, phishing, botnets, etc.

Principles

In order for Sugar to be successful, it needs the participation of a large number of people who share common goals while maintaining independence, so that each participant has the ability to act independently. For these reasons, Sugar Labs subscribes to these principles (from [1]):

Identity

• Clear mission – Full disclosed objectives.
• Declared commitments – Affinities and aversions explained.
• Explicit connections outside – Relationships with other organizations listed.

Structure

• Horizontal organization – Teams and facilitators work on responsibilities and agreements.
• Identified contributors – Who is who, people are reachable.
• Clear responsibilities – Who is in charge of what.
• Activities described – All the ongoing work is acknowledged.

Operation

• Open participation – Anybody can access the information and get a first responsibility.
• Meritocracy – Responsibilities are acquired (or lost) based on own skills and contributors’ support.
• Voluntary (non-)engagement – Nobody is forced to be involved or to keep responsibilities.

Information

• Regular reports – Reported activities and future plans allow monitoring and participation.
• Information accessible – Even internal operational information is available by default.
• Explicit confidentiality – It is explained what areas are confidential, why and who can access them.

Goods

• Economic model – Feasibility and sustainability plans are exposed.
• Resources – Inventory of items detailing who contributed what and why.
• Public accounts – It’s clear where the money comes from and where it goes.