A Man Who Values Peer Review

Mark Shuttleworth, who stood up the Ubuntu distribution of Linux, wrote about what he did after his “Open Source” development team wandered off into the weeds on another significant project. I like the way his mind worked. Comments afterward.

Recognising this, I decided to cut the code myself. [A two month hiatus] was part of this time, with me trying to recreate the good old garage days when I could spend all day working on the code that ultimately became Thawte. It took me that long to realise that times have changed – life is too good these days. Try as I might I don’t have the self-discipline to shut out the rest of the world when the phone keeps ringing, email keeps flooding in (although I did learn to ignore most of that, a useful exercise) and there are limitless opportunities to do fun stuff. I quite enjoy life as a retired cosmonaut with some financial security, but that enjoyment comes at the expense of focus. So much for plan B, what would be plan C?

I decided to hire the best Python developer I could to lead the project, then hire one or two other teams to work in collaboration with that core team. Hence my search for and appointment of Steve, Marius and Albertus.

How will we avoid a simple repetition of the previous problem? What makes this effort different? Nothing, so far. We once again have a bright team of developers who are at the end of the day motivated by a contract, not by a personal itch in education administration. But this is only the story so far. The next step will be to hire an additional team to collaborate with Steve’s. It may seems strange to hire a separate team rather than bolster the core one, but there’s method in my madness. Right now, a lot of the critical thinking and discussion happens inside an office in Vilnius, with no reference to the rest of the world. That makes it efficient, but not necessarily effective, since it may be efficiently going down the wrong road. Steve’s been pretty good about going to the list to get a sense of how different educational communities work whenever they start work on a new section of the project, for which I’m grateful. But the problem still remains – a lot of SchoolTool development happens in a non-transparent manner. By hiring a second team to collaborate on the core infrastructure I hope to force these discussions to happen online – in the mailing list and in wikis etc – in a way that makes them transparent and accountable. That way outsiders will be able to comment, and more importantly, we will be able to go back and understand what was decided, and why.

As for directedness, I came away from my visit to Vilnius with the impression that Steve really wants to see SchoolTool reach its full potential. There were some slight alarm bells (the dev team spent a lot of time showing me what their engine COULD do, and I spent a lot of time shifting the discussion back to what it DOES do), but at this stage I think we are still in reasonable shape. Perhaps we should actually have one or two schools that will deploy their work, to keep their debates grounded in the real world but that can come in due course.

Lessons Learned So the risk is that a well-funded open source team that is NOT led by someone with a personal interest in shipping the project will get distracted by other shiny tech toys and fail to actually ship something focused and constructive. How are we dealing with that in the current round of work on SchoolTool? First, I’m personally watching and asking the core team to focus on actual functionality. They assure me that their engine work is done, and that they are currently working on a usable tool that can be tested by schools. Time will tell. And second, we will shortly have a second, collaborating team, that will I hope also bring much of the engineering work into a more public forum.

Time will tell. These are expensive ways to learn, but I feel that the experiment is very much worth doing. There are lots of tools I would like to see developed in the open source world that developers have not yet done for themselves, and which I would be prepared to fund. Perhaps other philanthropists are in a similar position. We need to learn how to do this effectively, and the only way to learn is to try.

• Always know the business before you program for it.
• Peer review and feedback hurts your pride, but it’s an expensive jewel.
• Software can do anything. Don’t ever ask that question. Ask what it did or

does.