I did not totally despair when OLPC announced that it was cutting most of its engineering team. I am confident that Sugar can continue as a FOSS project independently of OLPC but its effectiveness hinges on how closely it can tie the development of Sugar to the needs of deployments. Further, the SugarLabs community needs to expand the diversity of its membership and to broaden its pedagogical approach.
Walter envisions Sugar's Future
Customer Service
One of the greatest losses in OLPC's recent job-shedding was in Project Manager Greg Smith. He had a tremendous talent for working w/ deployments and pushing their requirements into Sugar.
Before Greg, I often felt like that my requirements for Sugar fell on deaf ears. When I presented a requirement I was answered with roughly "That's not a problem, you're just doing it wrong." I don't see anyone taking up Greg's role currently and nor is it clear to me how SugarLabs will support deployments.
More simply put: The weaker SugarLabs' ties to deployments, the less relevant Sugar will be. At this time, those links are tenuous. Sugarlabs currently relies on an informal network of people like myself to push requirements to the developers.
Now, one can argue that Sugarlabs is still young and can develop these systems in time. But Sugarlabs should at least have a roadmap to build up these systems.
An (almost) All-Boyz Club
There are far too few women and no professional primary or secondary school teachers involved in Sugar. This is a critical weakness. Mel Chua and Caroline Meeks are women making an important impact on Sugar but two is too few. Educational software designed largely by male engineers will reflect the perspective of male engineers. We know that different people learn in very different ways. Sugar has to encompass those differences in order to be effective.
Too many of us are operating on the assumption that Sugar is a better UI for kids than traditional UI's. We need to put those assumptions to the test. Sugar has been in existence for some time now and needs to be put to some serious HCI testing.
Long on Ideas, short on pragmatism
Papert Pros and Cons
Dr. Seymour Papert is the pedagogical saint of OLPC and Sugar. Dr. Papert had a lot of great ideas about how kids can learn mathematics and science.
He had no professional experience as a primary or secondary school teacher, nor did he spend much of his career navigating the bureaucracies of public education systems. Sugar reflects many of Papert's great ideas. The difficulties one faces when integrating Sugar into schools reflects either Papert's lack of experience working within educational bureaucracies or a lack of interest in them.
The early development of Sugar was completely oblivious to the existence of an already great piece of educational software: moodle. Moodle excels at helping teachers organize their materials, distribute them, and monitoring student progress.
Too often, sugar developers discuss new features for Sugar that moodle already has. At XO Camp 2 last week, someone proposed a new feature for Sugar. Martin Langhoff, XS architect and long-time moodle contributor, quickly spoke "But, moodle already does that."
I get the sense that the principle "What Would Seymour Do" (WWSD) guides design decisions for Sugar. Jon Camfield's piece "Seymour Papert's Past is OLPC's Prologue" does an excellent job of detailing Seymour's mixed results working in real schools. It is time for Sugar to broaden its pedagogical moorings. The best place to start is establishing effective channels of communication with deployments.
Papert's theories are great but Sugarlabs needs to take its cues from educators who have and/or are actively implementing technology in education, particularly those in disadvantaged places.
Going Forward or Backwards?
Dr. Seymour Papert's educational ideas and work have been hugely influential. Sugar may likewise be hugely influential but will fall well short of helping every child "learn learning" unless Sugarlabs makes some important changes.
Bryan Berry is the co-founder and CTO of OLE Nepal, the organization implementing OLPC in Nepal in partnership with Nepal's Department of Education.
I think Sugar is very important. For several reason I posted earlier
http://www.olpcnews.com/software/applications/background_on_olpc_technology.html
I am still behind these choices, but I completely agree that Sugar should be better integrated with moodle.
However, what I think is most important in Sugar is that it is the first GUI that tries to go beyond the Desktop Metaphor of hierarchical menus.
Really, a common Desktop is simply a graphical interface to a static branched menu list. Functionally equivalent to "ncurses".
Such menus have become impossible to manage. Absolutely no-one is able to find everything in, say, MS Office and to actually understand what is all happening. Let alone actually find all files and link them to the correct applications. Add to this version control and backups, and almost all computer users are lost.
I think one of the attractions of the Sugar interface+journal to the FLOSS community is the simple fact that it allows a simpler, but still powerful access to the computer. Simple enough to be used by anyone.
Winter
@Winter I agree with your points but sugar still needs to be evaluated by Human computer Interaction experts. We can't just assume that these features are helpful.
Additionally, hard-to-navigate programs are better than having fewer programs. The difficulty in running native X11 apps in sugar makes it less useful.
I would not fear the absence of "real teachers". Computers once only "just worked" and I dont see anything wrong with that happening again. Developers are teachers and teachers are developers...
Is there anything to ever integrate with Sugar and moodle? Recognizing users automatically? I could imagine integration with something like XS far better...
Umm, most teachers have spent most of their professional lives trying to help children learn. I think you are too quick too discount their expertise. Reminds me of CEO's who don't appreciate the work engineers do . . .
Moode should be integrated in backing up and restoring the XO's, monitoring attendance, tracking student performance, delivering content, help teachers create custom courses, students can use it to create portfolios, I can go on forever
Sugar is trying to play to two (or three?) different tunes, which is not unusual, but it needs to accept this - it's a GUI and also an educational platform. To keep geeks and developers happy, it needs to provide a good challenge as a new interface, as an educational product, it has to prove its utility in real classrooms and work with existing technologies (like moodle), but also be flexible and friendly enough to connect to custom educational systems and databases. I'm not too worried about that being possible, but it still has to be done at some point.
It'd be nice to begin to separate the learning environment from the underlying GUI so that both can grow without having to balance one against the other. The lack of this is why we are seeing have bootable Fedora and Ubuntu memory-sticks, which may be the part of a solution.
Well, I guess Sugar Labs *does* work closely with deployments, because they sent one of their founding members to Nepal for three months with this exact mission!
I don't agree that we should create a customer/vendor relationship where deployments specify their requirements and Sugar Labs merely implements them. OLPC went exactly this route and failed to please even one of their deployments. Not to mention that I can hardly see how this business model could ever scale or become self-sustaining.
What we need to do is embrace deployments as first class members of Sugar Labs and teach their engineering staff how to implement their requirements autonomously or in collaboration with other deployments.
Anyone interested is also invited to join our
public board meetings and talk with our development team on IRC at any time.
Oh, and we knew right from the start that deployments and teachers were underrepresented within Sugar Labs, as proved by these board meeting minutes.
In particular:
walter: Which brings me to another issue: I'd like to propose we
explicitly invite some folks to these meetings.
walter: The board is a great group, but very tech-centric. We are
underrepresented in the deployments and learning.
gregdek: As recurrent guests, or from time to time depending on the
topic, or what?
bernieXO: true
walter: I think as permanent -- non-voting until/if we change the
by-laws -- members
[...]
walter: We never had a deployment committee on the list. If we create one and appoint some folks from Peru and Uruguay to kick-start it...
walter: We can ask that they report back at each OB meeting...
walter: Same with Learning...
gregdek: +1 to a deployment committee.
gregdek: So I understand. The goal of the deployment committee would be to serve as ombudsman for deployments?
walter: We had 3-4 very strong candidates who'd make a great kernel of a deployment committee: Paulo, Rabi, Hernan, etc.
walter: More than just ombudsman, which is my mind is a more reactive role
bernieXO: I'd like to get rabi or bryan involved if they want to
gregdek: Actively bringing issues to the board?
walter: I'd like to see them actively pursuing issues... and bring the important ones to our attention.
Hi Guys,
I saw my name mentioned so I thought I would chime in (between sending out resumes :-).
I gave a talk on this subject at the Sugarcamp meeting in November. You can see my presentation by searching for Greg here: http://blog.tomeuvizoso.net/2008/12/sugarcamp-nov-08-part-ii.html
Another reference on this topic is my laptop wiki home page:
http://wiki.laptop.org/go/User:Gregorio
The first point is to try and be constructive. If Bryan is asking for better ways to get his input in to the sugar development, the best response is "we're listening".
If every time someone says "I wish I had sugar feature nnn" the answer is "great idea, please build it" then people will stop asking. Then you get no good feedback and communication breaks down.
Much better is to respond with: "good idea I can help you learn how to build it" or "good idea but we can't work on that right now because we are doing nnn"
We had a very good thread on TurtleArt with Luis and Walter on the Sugar Education list and the OLPC Sur lists. It resulted in some new code, more people working on TurtleArt and more kids using it.
Bottom line is that you have to be as nurturing and supportive as possible.
Keep a list of all suggestions or requests. Just logging them shows you care. Then maybe someone will show up who wants to build one.
There's no product manager anymore so its developer to user directly all the time. Contrary to some comments, I'm happy to say that the XO did have successful and happy customers. Most notably Peru and Uruguay but also Ethiopia and others. We didn't do it by having a customer/vendor relationship. We did it by working together with the customers as a team.
The product manager makes sure everyone's voice is heard, keeps track of requests, helps users organize and prioritize their input and helps engineering do the same for their work. That can all be done in community but it takes great listening skills and focus.
HTHs.
Got to run for my next interview...
Keep the faith!
Greg S
Bryan, this was an excellent post as always. I wanted to say that your comments and strong advocacy for educational focus is always a pleasure. Perhaps you can recruit directly some of the people you would like to see take part in the discussion. People often tend to recruit those they know or that already think in similar ways; it is hard to change that pattern.