Archive/Current Events/2010-04-01
Sugar Digest
1. LIBREPLANET was this past weekend. It was held at 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 [1]).
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. 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 are 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, 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 freedom to 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 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.
During the Q&A John Gilmore asked me how many patches have been contributed by Sugar users. I responded that community members have contributed patches but no children as of yet that I was aware of. I did mention the contributions of the local labs and of high-school and university students. But I also said that it was not relevant whether or not patches were accepted. The learning happens in creating the patch and in submitting it or sharing it with a friend.
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 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
Gary Martin has generated a SOM from the past week of discussion on the IAEP mailing list.
