1. Tomeu's departure from the project has set off a lot of introspection, speculation, 'blunt' emails, and thoughtful responses. There is no doubt that we will miss Tomeu. He has been not just a prolific contributor to the project, but also a steady hand, with the professional's eye. Under his leadership, we have been able to raise the quality of Sugar and we are much better integrated into the work flows both upstream and downstream from Sugar. We must ensure that this level of professionalism is not diminished.
The occasion of Tomeu's departure has triggered the voicing of many unrelated frustrations with Sugar and Sugar Labs. Yioryos Asprobounitis posted a thoughtful email to the Sugar Developer list. In it, he reminded us of those things that every successful project needs:
- Clearly defined aims
- Clearly defined road map
- Clearly defined tools/methods of implementation
- Clearly defined, tangible, milestones and annual _external_ evaluation
While I think that the Sugar Community has worked hard towards providing clarity, there remain deficiencies and disagreements.
Personally, my aims for Sugar are unwavering: Sugar is a software platform that is designed for children for learning. Sugar is developed and maintained by Sugar Labs, a global volunteer community of software developers and educators. Our goal is to raise a generation of critical thinkers and problem-solvers by establishing a culture of independent thinking and learning. Through Sugar, we strive to provide every child with the opportunity to learn learning within a context that will allow them both to engage in an on-going critical dialog with others and to develop independent means towards their personal goals.
The technical underpinnings of Sugar are deliberately designed to maximize the probability that children will learn. Through the Sugar-platform affordances, we encourage learners to explore by digging deeply into topics for which they are passionate, to express by building upon what they discover, and to reflect by engaging in peer-to-peer and personal criticism. Free Software is fundamental to the project not just as a means to an end, but also because of its culture: it is no coincidence that Free Software developers don't just write code; they talk about Free Software, they criticize it, and they discuss other people's criticisms.
Regarding road maps, in my opinion we are quite disciplined in terms of our day-to-day release process. However we are lacking a long-term road map, which I would equate to an architectural specification. Such a document could serve as a metric that would help us with some of our short-term decisions and also help shape the project going forward.
Regarding tools and methods of implementation, while there has been lots of heated discussion, I don't think we are so far apart in our opinions. The seemingly endless debate about git vs email vs trac for patch review is winding down. And we are getting better as a community in showing patience with our handling of the influx of patches and questions from newbies. Perhaps the best evidence that we are not so far off track is the great job that has been done packaging Sugar downstream by various organizations and deployments. We are producing a product that they can work with and want to work with. Of course there is always room for improvement and no doubt the debate about tools and process will continue. That said, one legacy of Tomeu is to be uncompromising on quality. I have submitted many patches and have had very few accepted. But I have gotten thoughtful feedback and learned a great deal in the process. My subsequent patches are better for the effort of the Sugar maintainers.
Regarding tangible milestones and evaluation, I give us a mixed review. We have a reasonable mechanisms in place for our release process and we are cultivating ever-increasing feedback from the Sugar deployments. However, we are lacking clarity around our long-range technical goals. In terms of evaluation, Sugar in the context of deployments is undergoing some level of scrutiny. There are on-going evaluations underway in all of the major deployments. But with few exceptions it is not clear how Sugar itself is being evaluating in the field. We have some active testing teams, but we have not provided them with very good tool chains; we have almost no automated data collection to inform us as to how children are using Sugar. These deficiencies are mitigated in part by an increasingly vocal community of teachers and mentors and facilitators. Ultimately I think we will learn more from our user community than is typical of other software projects. Indeed, the fact that two teachers are running for positions on our Oversight Board is really encouraging.
Dave Neary wrote a blog post about Ubuntu's plans to move to Unity as the default desktop in which he mentions Sugar.
- OLPC had many teething problems with the Sugar desktop environment. Bugs, stability and performance issues plagued the project for many months, to the point where they abandoned the development of the stack as the primary target platform for the devices. The project lives on in Sugar Labs, thanks to a broad and vibrant developer community.
- There is not one out-and-out success story of a company building a great high-quality custom user interface on the standard Linux stack, except Android, which is hardly a model of collaborative software development.
- There is another possibility which seems to me more plausible: building a rock solid and functional desktop is hard. Really hard.
What we are doing is hard. But it is also worthwhile. For those of you who have never had a chance to visit a Sugar deployment, I urge you to do so. What you will see, despite all of the shortcomings, is children learning. That is why we are doing this.
2. I had an opportunity to visit Caacupé last week. (I was in Paraguay to give the opening keynote at CLEI 2010, which was hosted by the National University of Asunción. After my talk, I was approached by the university, which has agreed to offer students course credit for working on Sugar.) The formadores at Paraguay Educa have created Saturday 'clubs' to offer opportunities to explore Scratch, Etoys, and Turtle Art in more informal settings. I got to meet with the Club ¡Formando Artistas con la Tortuga! and see first hand what the kids were doing with Turtle Art. I introduced to them a new feature: the caparazon de tortuga (turtle shell) block lets them turn the turtle into a sprite. I recruited a volunteer, Pablo, who made a self portrait using Record. We then loaded his image onto the turtle shell. Needless to say, it was a hit with the kids. I did spend some time introducing the concept of the 'box' (variable block) as a place to put a number and subsequently retrieve it. That was less successful. It occurred to me in discussion with Roberto Alcala, the new technical lead for the project, that if the box shows it value, it may help with the abstraction. Turtle Blocks v102 has that feature and the formadores have promised me feedback. In the meantime, the kids have been sending me their projects, on display []. And check out Miguela's blog.
3. Just before hopping on the plane to Paraguay, I did a video conference with faculty and students from about 1/2 dozen universities in Pakistan to discuss establishing a Sugar Lab in Pakistan. While the potential for funding from USAID has momentarily fallen through, nonetheless, there is great enthusiasm.
4. I visited with Educ.ar in Buenos Aires on the way back from Asunción. It was a chance to catch up with old friends and to find out more about the government program to give laptops to secondary school children. We talked Sugar and there is a good possibility that it will be part of the offering.
In the community
5. The OLPC/Sugar/Realness summit was held in San Francisco. Adam Holt reports that 130+ enthusiastic OLPC/Sugar community members attended. You can read detailed summaries of the sessions here: .
6. speaks for itself!!
Gary Martin has generated a SOM from the past few week of discussion on the IAEP mailing list.
Visit our planet for more updates about Sugar and Sugar deployments.