Previous Entry Share Next Entry
OLPC kerfuffle
cananian

It seems I missed a nice little Slashdot/Negroponte/Krstić OLPC/Sugar row while I was away in Europe savoring the efficient intercity rail. While Tomeu and OLPCnews choose to blame particular words or phrases ("Sugar", "$100 laptop"), both J5 and gregdek seem to think the Real Problem was the fact that OLPC wouldn't upstream its patches.

I beg to disagree. As I wordily tried to explain in a comment to gregdek's post, I think Ivan is mostly right here: OLPC tried to do "seven new things" (as Mary Lou explained to me when I was hired) -- and "new things" end up costing a lot of debugging and development time, in one of the Iron Laws Of Writing New Code And Making New Hardware. But another problem was just Picking The Wrong Partners. With the exception of the display (one of the few unalloyed successes of the XO hardware), most of our hardware and software partners were working at cross purposes. Red Hat didn't really want to build an embedded OS product, "mesh networking" to Marvel meant household networks between your TV and your stereo with maybe 10 participants, the Geode was an orphaned offering from AMD, the display and flash NAND controller was a unloved one-off, etc. Success is found by aligning your partners' interests with your own.

At Litl our OS partner has many other embedded-systems clients, and has developed the toolsets to handle forks and customization without all the angst I'd grown used to at OLPC. We just say, "we need feature X turned on/off" or "set to Y" or just "somehow Z needs to happen" and it's done. We're not fighting, we're not destabilizing their core OS, we don't waste time with elaborate justifications why This Is The Right Thing To Do. If the change is appropriate to upstream, they upstream it, and maybe the work benefits the other embedded-systems clients. There's no drama, because We All Want The Same Thing.

I think "upstreaming" is entirely the wrong hero for OLPC here. If anything, I think OLPC's best hope is to continue to aggressively innovate -- no one buys a computer because its code has been upstreamed. Unfortunately, I don't think OLPC has enough current funding to do anything but follow the upstream, so maybe this current round of praise for Fedora-ization is just the old cliché: making a virtue of necessity.


  • 1

Note that wad defends the hardware-development process in a comment at OLPCnews. He's correctly points out (a) that the OLPC hardware development effort wasn't terribly dissimilar to any other hardware development effort, and (b) that most of the bugs Ivan linked to were fixed during development. The phrase of Ivan's that I think hits the target is simply, "the gross, hairy, complicated systems development work that OLPC was doing to support the XO’s special hardware features." I argue simply that work is unavoidable given the features desired and should have been anticipated and/or shifted to partners -- or some features should have been cut, or scheduled for a later release... *managed*. You can't wave a magic wand to get rid of the systems development work, without also getting rid of the features they were attempting to enable: theft-deterrence, aggressive power management, maintainability, collaboration, etc. Now of course, in retrospect, cutting features *would* have been a good idea....


  • 1
?

Log in

No account? Create an account