Daily Life in an Ivory Basement

Over at OLPC News, Wayan Vota asks: "Do you get better FOSS code ... if the developers are paid or unpaid?"

Interesting question, especially as considered in light of the OLPC code base.

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.)

At the time I felt that the OLPC code, which might have been a triumph for the OLPC project, a gem of Python code, and a win for the open source community, had turned into a cesspool of code and a potentially infinite time sink for people working on it.

I haven't revisited the project since then, and I know that community enthusiasm has waned for the OLPC. I don't think the poor quality of the code was a huge factor in this decline, but it certainly decreased the interest that serious hackers had in getting involved in the project -- at least, it did for everyone I talked with.

So, let's get back to the original question: in an OSS project, is it better to let the community write your code for you, or should you have a core development team?

Let me rephrase that another way, actually: if your business practices drive you to write crappy, hurried code, with no attention to any form of reasonable software development processes (agile or otherwise), no automated testing, and very little QA of any kind, are you better off turning software development over to the community?

The answer becomes less difficult then: yes, if it's an option, you should jettison your software development efforts. If you can't do things competently, you should remove yourself from the responsibility of doing it. Abdicating responsibility is the responsible thing to do in these circumstances, if you can make it work.

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.

I think that's actually a much more interesting question: at what point should an organization realize that they are so incompetent at managing and doing "in-house" software development that they should try to outsource it? What metrics should they look at, and how should the decision be made?

--titus

p.s. The general question of whether to go for paid or unpaid development is silly, of course. The answer is, "it depends." Duh. The interesting question is what questions you need to ask to figure it out!

p.p.s. Disclaimer: the individual OLPC people I know, up to and including lower management, are smart, enthusiastic, and good people. I place the majority of the blame squarely at the top.