Wednesday, March 26, 2008

Time for Rambling OLPC Speculation

What's going on at OLPC? I have no idea.

Actually, that's not quite true. We've got insight into what's going on in the software development process; not so much in the overarching internal politics of OLPC. In particular, the most important thing: the fundamental financial pressures that they and their partners -- funders, producers, commercial spin-offs -- are unknowable to me. Obviously, Google alone has the capacity to keep the lights on at OLPC as long as they feel like it.

Also, it remains difficult to tell just how much the experience of an XO deployment in the developing world is different from that of a geek in the first world. Obviously, the answer is very, but it is difficult to say in what precise ways it is different, and what kinds of bugs can and can't be tolerated in different environments, and by both the people who use the devices and those who pay for them.

How much time OLPC has is the schwerpunkt here, because the one thing we do have plenty of insight into is OLPC's software development process, and that effort is demonstrably in the weeds. The software problems will not be solved quickly.

Brief pause for a quote by Mike Fletcher:

In case you missed it, this project is rather visible. Every little sneeze, every cough, is used by people standing on the sidelines to declare the death of the project. There are commentators who take every opportunity to seem supportive, while attempting to twist in a knife, cackling in schadenfreude and veiling all of their potentially useful critiques in a veil of false friendship.

The effects of that toxic critique is to shut down the channels of communication, so that all external critique is rejected far too easily. External developers and commentators who are not universally positive are seen as, at best, not "getting it", and at worst, as being intent upon derailing the project via false motives. The project needs some way to separate out the critiques intended to derail it from those intent on righting the path.

I want to at least make sure I'm being consistent here. I believe my position over the past couple years has been this:

  1. There are some brilliant, long overdue ideas in the design of Sugar.
  2. It doesn't look like there is anywhere near enough time to implement them.
  3. Maybe there'll be another OLPC miracle (a la the XO display).

I've felt the goals of Sugar were too important to simply say "They're foolish to try." I still can't quite bring myself to say it wasn't worth a shot. And there is still a chance it'll all work out, depending on how much time is left on the clock. I don't think they've done a bad job; they've just failed to pull off the nigh impossible.

However, that leaves them in a bad spot, and it is one that is not unfamiliar to me as project manager of SchoolTool. Frederick Brooks is famous for pointing out that adding programmers to a late project will only make it later. It is also true that prematurely releasing a framework for building other applications, what Brooks calls a "programming systems product," will only make the eventual stable release of the framework later. When you're forced to do this, you end up with end users who have to be supported, require documentation, and bugfixes; and hopefully you also have third party developers who want to write applications (or "activities") using your framework, who also require support, documentation and bugfixes. The increasing problem becomes that on both levels, you either have to maintain backward compatibility with your admittedly premature release, and/or you have to impose a significant load on users and developers to keep up with the changes you incur in finishing your programming system product. Also, at each step you have to keep user and developer documentation up to date. This won't necessarily wreck your project, but it will slow it down.

In particular, you lose a lot of the advantages of the open source process and open API's. Developers who try to build applications on your API's will get frustrated, complain, and probably leave and not come back until they hear that you've straightened out your problems. Developers who come along at this point who are interested in your core product will see that it is incomplete, behind schedule, and in flux, and will have a strong natural tendency to spend their time discussing what you've doing wrong and instead of sitting down and implementing feature or optimization X for application Y, they'll be discussing the nature of application Y. If they do write code, since the core vision hasn't been realized in code, it is more likely that their vision will be out of sync and peripheral or useless to the project. I'd note that these are observations based on a number of projects, including my own, not just OLPC, and not aimed at anyone specific at OLPC.

In my opinion, what a project has to do at this point is hunker down with its core team, narrow its vision, and plow through. Stay rigorously focused on stabilizing the core API's and clearing up serious user facing bugs. The thing is, there are no quick turnarounds in software. I can't say "Oh, maybe they'll pull a FooSoft," where "FooSoft" is the canonical example of a seemingly doomed project that was quickly saved by enlightened management. There is no such canonical example. There are certainly examples of seemingly failed projects which turned around -- Mozilla/Firefox leaps to mind -- but the time span is measured in years, not months.

3 comments:

Mark Ahlness said...

Tom, in my opinion one of the things the team needs to do besides "hunker down" - is to observe.

Watch their creation and what users are making of it. Those directions may well diverge from the intended plans.

There is incredible innovation and exploration happening unofficially on the XO. There are some great minds working out there, on their own, loosely joined...

I was thrilled today to connect to a community jabber server with the 4 XO's in my classroom. Is anybody thinking about the KIDS in all this jousting?

Tom Hoffman said...

Hi Mark,

My concern is that, while people are unofficially innovating and exploring the XO, underlying technical problems will cause there to be less innovation than there could be. Development is more difficult than it should be, and the underlying frameworks are still changing, so even if you do get an activity working, it can break at any point.

It is ultimately good technical infrastructure that lets that distributed, great minds loosely joined magic happen.

Edward said...

Yes, a lot of us are thinking about the kids, but you don't get to hear from the kids much unless you get down with them and their XOs and wait for it. The kids would be posting all over the Internet if there weren't such a security worry about them.

I got back from PyCon 2008 in Chicago last week, where we had an XO programming tutorial, an OLPC booth with three OLPC volunteers in it (including me), and an OLPC coding sprint for several days after the conference. There were about 250 coders in all of the sprints together, and about 15 working directly on OLPC software--games, speech synthesis for literacy and accessibility, and educational applications.

For next year I will be on staff at PyCon 2009, organizing a children's room. Part of the time we plan to have children with a year's experience in Python teaching adults how to work with the XO, and part of the time we intend to bring in children with little or no programming experience, so that attendees can see how they learn Python--very differently from adults.

In the meantime, I intend to talk to museums, libraries, and schools to get XOs in as many places as possible, and let the kids, their parents, teachers, and others see just what this is about. Specifically, the way the children's faces light up at sight of an XO, and even more as they gain control, understanding, and eventually mastery over it.

Children learn at a fantastic rate through what adults dismissively call "play". It takes a lot of work to slow them down to classroom speed and make them all do the same thing at the same time.

XOs let children discover, and they let children work together, in class or in their own homes, sharing a canvas with multiple brushes, or a document with multiple cursors, or multiple musical instruments, and so on. With source code for all of it.

Even if it isn't all there just as we would like it yet, there is plenty to get started with. It will never be perfect, but there will always be more of it. And soon there will be hundreds of thousands of Smalltalk and Python programmers in the schools adding to it.

Us haz teh bestest toyz evr, d00d.