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:
- There are some brilliant, long overdue ideas in the design of Sugar.
- It doesn't look like there is anywhere near enough time to implement them.
- 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.