[IAEP] Sugar Digest 2010-03-22

[Walter Bender]

==Sugar Digest==

1. LIBREPLANET was this past weekend. It was held that the Harvard
University Science Center and drew a large crowd of FLOSS movers and
shakers. RMS was there. He spoke about the risks that Software as a
Service poses to our freedoms. I unfortunately missed John Gilmore's
talk, where he outlined what he thinks are the next goals for the
community. It is no surprise that Eben Moglen gave an inspiring talk.
He spoke about how much we have accomplished: Free Software is no
longer an option; it is "indispensable". We talked about some of the
opportunities, especially in education, afforded by software that is
"reliable and has a unit cost of zero." I spoke briefly with Brewster
Kahle about how we might further leverage the Internet Archive. It has
a wealth of materials of potential interest to Sugar users (For
example, I just forwarded this link to the Sur list as I thought it
was a nice complement to some of the geometry problems they had been
discussing [http://ia331304.us.archive.org/2/items/amusementsinmath16713gut/16713-h/16713-h.htm#GREEK_CROSS_PUZZLES]).

I attended a talk given by some members of GNU Generation
[http://fsf.org/gnugeneration]. They are a group of pre-university
students involved in FLOSS development. Sugar Labs has great synergy
with this group; I have already tried to connect them with Jeff
Elkner's team at Sugar Labs DC.

I also met Asheesh Laroia from Open Hatch [http://openhatch.org]. Open
Hatch is a place to find volunteer opportunities and volunteers.
Asheesh was kind enough to add the "sugar-love" tag on
bugs.sugarlabs.org to the Open Hatch volunteer opportunities list. I
noticed that both Sebastian Dziallas and Mel Chua are new to Open
Hatch as well. They have done a nice job of describing Sugar and Sugar
on a Stick.

The title of my talk was "Beyond 'open': Making software easier to
modify." I began by showing two photos that Bernie Innocenti took in
Caacupe, Paraguay. Pictures of smiling children with computer is
always a hit, but chose my pictures carefully. The first photo was of
two young girls hiding behind their OLPC XO-1 laptops. The laptops had
been covered (end-user customized) with stickers ''despite'' the best
efforts of the designer. (The XO has bumps on its surface that in
order to hide scratches and deter the use of stickers.) The second
photo was of two young boys replacing broken displays. In this case
the design goal was to enable the end user to make repairs (if not
modifications) to the hardware.

I then quoted Eben completely out of context. He had said in the talk
prior to mine that only Free Software had achieved the elusive goal of
being "write once, run everywhere." I said that Sugar had a different
goal. We want our code to be written over and over again by our end
users because they will learn in the process. Of course we want to
write reliable code that will enable Sugar to run "everywhere" and in
fact, we have made great progress in this regard over the past two
years, in part by hanging onto the coattails of the GNU/Linux
community's efforts. I tried to make the point that the usual metrics
— robustness, efficiency, maintainability, etc. — are not enough for
education. We need to go a step further by ensuring that our code is
free and open but also practically amenable to manipulation. (The
license guarantees that all Free Software can be modified by the end
user, but for most users, this is just a theoretical freedom.) If
everyone learns to write code and if more code is written with
end-user modifications in mind, we will have a world in which everyone
is engaged in debugging, what Cynthia Solomon described as the great
educational opportunity of the 21st Century.

At this point, I meant to digress. In the mid-to-late 1980s, I worked
on digital video systems. The standard metrics used by the engineering
community at the time were complexity of encoding, channel robustness,
complexity of decoding, and, of course, the compression ratio. I tried
to introduce a fifth metric: the degree to which the encoded signal
was amenable to manipulation by the end user. I had in mind simple
things like remixing, which had implications regard to the mix of I-,
P-, and B-frames in MPEG. I didn't want us to repeat the mistakes of
SÉCAM, in which cannot easily be edited in its native analog form. (I
forgot to make this digression in the actual talk.)

I went on to describe some of the approaches we have taken at Sugar
Labs to encourage and facilitate end-user modifications:

* Setting expectations: establishing a culture in which it is the norm
to exercise the freedoms afforded by Free Software;
* Free Software: articulating the free modify aspect of Free Software
(Freedom 1);
* View Source: provide tools that make it easy to access the source;
* Scripting languages: use scripting languages (Python, Javascript,
and Smalltalk in the case of Sugar) so that changes can be direct and
immediate;
* Small steps: provide a scaffolding to enable the end user to get
started by taking small steps (while C might have a "high ceiling", it
does not have a very "low floor");
* "Crumple zones": reduce the risk associated with making mistakes; if
the penalty of introducing a bug is too high — either by causing
unbounded damage or by being irreversible — then people will quickly
be conditioned not to engage in the "risky" behavior of modifying
code;
* The "real deal": if in practice you can only modify toy versions of
your software, you cannot scratch a real itch; make sure the real
version can be modified;
* Supportive community: I think that it a fair characterization of the
Sugar community is that it is welcoming and tolerant of "newbies"; to
ask a question is to become a member of the community; we are stingy
with commit privileges to "mainline", but provide affordances to
encourage the creation of experimental forks.

By way of demonstrations, I highlighted the work of Tony Forster, who
"modified" Physics and has taken Turtle Art to new and unexpected
places.

We have a ways to go and there are more things, such as optionally
providing the GNU tools bundled with Sugar on a Stick, but I think
that Sugar is a great model for the broader FLOSS community. Thanks to
you, we are making great progress towards our goal of providing every
learner will high-quality tools for learning.

===Help wanted===

2. We have been accepted into the 2010 Google Summer of Code program.
Time to solicit mentors and interns. Kudos to Tim McNamara.

===Tech talk===

3. The Sugar team in Paraguay  [http://wiki.paraguayeduca.org] has
made great progress towards the goal of a F11/Sugar-0.84 build for the
OLPC-XO-1 computers (You can follow their progress at
http://wiki.paraguayeduca.org/index.php/Devel/Builds/Todo).

===Sugar Labs===

4. Gary Martin has generated a SOM from the past week of discussion on
the IAEP mailing list (See
http://wiki.sugarlabs.org/go/File:2010-March-13-19-som.jpg).

-walter

-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org