As of about a year ago, virtually everybody I talked to was shocked and stunned at the poor quality of the OLPC code base. My personal encounters with the code left me frustrated at the poor Python style, angry at the simultaneously over- and under-engineered build process, livid at the poor quality control, and blue about the long-term prospects of the OLPC software. I was not alone, although most people were polite enough not to be a jerk about it like me. (Looking back, perhaps if more people had been jerks earlier, things could have improved. Or not.) (...)
But... what went wrong, anyway? I don't know. I'd guess that the OLPC software development team was overmatched from the beginning: responsibility of developing new software for a novel mix of hardware, together with a novel GUI interface, in an environment of much enthusiasm and relatively little funding, is hard. Add to this the enthusiastic but not very disciplined-sounding roadmap, as well as the unrealistic deadlines set due to PR and political considerations, and it's a recipe for disaster. When you also throw in an overwhelmed OLPC management team, I don't think you can expect anything but disaster.
So, looking back, I think the OLPC was probably headed into a mess from day 1, and while the fubar'ed software development process didn't help, it was at least partly driven by circumstances outside the control of the software developers. The software developers were hamstrung from the get go. And in that environment, turning the majority of your software development over to someone else -- someone not under your direct control -- may in fact be the best option.