La Dolce Vita: chapter 3
A very wise man said, not too long ago:

"If you're writing a desktop app or desktop development platform of any sort, you should be reading Innovator's Dilemma and figuring out exactly what you're bringing to the table against web apps and the web app platform -- how are you going to stop yourself from being disrupted by them? If you can't answer that question, you might want to think twice before writing more desktop apps or another desktop platform.

That's an uncomfortable question for fans of Sugar. It should be.

I spent a lot of my time at Sugar Camp today asking people this question. "What is Sugar's defensible value add?" Invariably someone would say something about the excellent monitor or the battery life, and I would politely remind them that those were traits of the XO hardware, not of the Sugar software, and an awkward pause would ensue.

Ultimately, for most, it came down to three things: the journal, "kid-friendliness", and collaboration.

The journal is good. In the next release of Sugar, it will be even better. But it is not necessarily a game-changer, and GNOME is already exploring some of these ideas as well. The "kid-friendliness" is largely anecdotal; Sugar may be truly more "kid-friendly" than Windows, but it's not like there's a wealth of double-blind studies from which you can draw a rock-solid conclusion.

Which leaves collaboration. The White Whale.

When I was first telling the story of OLPC to anyone who would listen, long before the device even existed, the linchpin of the story was always the promise of "collaboration by default." The idea, in theory, was fantastic, and the talking points were compelling. "When a child wants to share a toy with another child," I would say, "does the child have to install a special toy module, or sign a license to play with the toy? Of course not. Activities should be as easy to share as a ball."

Easy to say. Hard to do.

Tuesday night was a late night of pointed disagreements. On Wednesday night, with a somewhat smaller crowd and a hell of a lot more beer, it feels like we made more progress. There a ton of barriers to doing collaboration well in the current OLPC networking model, and it has been devilishly difficult to simplify our assumptions to get to a handful of key use cases. But that's what I think we accomplished tonight.

To wit:

1. It would be great to guarantee collaboration between activities regardless of the network topology involved, but the simple fact is that such a guarantee is, if not impossible, at least impractical in any near-term timeframe. The mesh networking functionality of OLPC works, but it's fragile, and the demands placed on the mesh by collaborative activities are likely to impose too high a cost. (In other words: two kids play a collaborative game, take down the entire grid.) Therefore, we have determined that we will not worry about making activites collaborate over the mesh. (Best line of the night goes to Eben, relayed to me via Scott: "we could just give the kids cat-5 cables, paint them green, and call them "collaboration cables".)

2. "Collaboration" is a very loosely defined term. This is, frankly, to our advantage; it means that we can aim for fairly modest collaborations early on. For instance, "collaborating" in Firefox could, at first, be a simple as sharing URLs dynamically. See your friend running a browser, click on your friend's icon, and your browser launches with whatever URL your friend is viewing. To begin with, simple is best. Tomorrow we will work to identify the minimal set of activities that should have collaborative behaviors (like maybe the activities that were selected to ship with G1G1), and then we will attempt to identify some simple collaborative behaviors to implement for each of these activities. If we do things right, a usable collaboration API will fall out of this effort.

3. Effective collaboration is clearly on the critical path for Sugar. However, that doesn't mean that it's the most important work item for current OLPC deployments. There are hundreds of thousands of laptops in kids' hands, all around the world, and most of their problems are more pedestrian. It's OLPC's job to support those customers -- and for OLPC to be successful, they must put customer requirements first. Therefore, Sugar Labs now has the perfect opportunity to step up and take the lead in solving this problem. It's an ideal division of labor.

4. Many of the problems of XO mesh networking can be attributed to the immaturity of the 802.11s protocol that was chosen. It should be noted, however, that 802.11s is not the only mesh protocol in town. The OLSR project is doing some very interesting things. Giving up altogether on the idea of improving the mesh is probably premature, so we're going to try to get the OLSR folks in touch with the OLPC Developer Program folks, and see whether, in exchange for some laptops, the OLSR folks can work some magic.

Another 16-hour day, but a really productive one. I'll sleep well, I think.