Successful open source projects are usually initiated by someone with a clear vision and also the knowledge to set about turning that vision into reality. But what happens when someone has an idea and also has the resources to hire programmers to execute that idea?My experience with SchoolTool v1
This note was inspired by Tom Hoffman’s blog entry which referenced SchoolTool and Chandler. I thought he was touching on a subject which has interested me for some time – how best to fund open source development. Trust me this is not easy. Most open source projects are led by the person who had the original vision. It’s much harder to HIRE people to work towards your own vision. But if philanthropists are to invest in open source software, then we have to figure out how to do just that.
First, some more history on the SchoolTool project, because I think it nicely illustrates the phenomenon.
I hired a talented and diverse team to build SchoolTool just as I was heading to Russia to see if I could get into the Russian space program. All of the team members were familiar with and fans of open source software and open source development. There was no one at the Foundation that had experience managing an IT project, but I figured the that the team would have no trouble managing itself. They should have the best of all worlds, with steady salaries to allow them to focus their time exclusively on an open source project. Most open source projects are part-time efforts, with the team members constantly constrained in the time they can devote to their “hobby”.
While I was in Russia, the team sent me a series of regular reports on their progress. They settled on Java, not an environment I like, and SQL database, a reasonable proposition. So far so good. But over the next few months I noticed that they were spending a lot of time solving problems that didn’t really need to be solved. For example, we wanted SchoolTool to be cross-platform. They invested a huge amount of effort designing an XML-based UI description system, which would then automatically generate a UI for each platform. Why reinvent XUL, I asked? It seemed as if, given free reign, the developers pursued their own personal interests rather than the goals of the project. Sure, they could always argue that the tools they were developing were ultimately going to be USED by SchoolTool, but I was always left thinking that if I were in their shoes I would want to start solving the unique problems of school administration FIRST, and leave some of the other niceties till later.
After a while it became clear to me that the team was not going to produce a functional tool. So I canned the project and shutdown the development office, letting the developers go. This was a very unpopular decision, quite a few educational groups had pinned their hopes on SchoolTool. Rather than keeping those hopes artificially alive I killed the project outright and said we would not develop SchoolTool further. But at the back of my mind was still the belief that SchoolTool is a project that is both feasible and worthwhile, and that it should work in an open source environment once it has critical mass.
The issue, as I see it, is leadership. Most open source projects are founded by one or two people who have a very clear idea of what they want to create and how they plan to do so. They have an itch to scratch. Once they have a basic framework together, other people start to use it and the stone soup effect kicks in… some of the users become developers, and the bazaar magic happens. But here’s what’s critical – the success of the project continues to depend on it’s leadership, usually by the founders but sometimes in a more institutional way (like the Debian project).
Contrast this with my experience of hiring developers who had great skills but no personal attachment to the idea of having a SchoolTool out in the wild. They did what all open source developers do – they scratched THEIR itch.
In a proprietary development scenario the company and hence the developers are driven to ship product – they get no sales without a shipping product, and thus no salaries without shipping code. So there is an urgency and a pressure to ship something. We have all seen that sometimes that pressure is not constructive, and code is shipped in barely working state. Contrast this with open source developers who want a good, working tool out there – they ship it when it’s “done”. But that assumes that they really want it out there. If they are simply being paid to cut code, they cut the code they find most interesting, not necessarily the code that is on the critical path to ship the actual tool they’re working on.
Recognising this, I decided to cut the code myself. The two month hiatus Tom describes 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’s 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.
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.
A further email exchange between Tom Hoffman and I went along these lines:
Tom: Coming up with an RDF version of your REST api is definitely luring me as a shiny geek toy, of the type Mark wants you to avoid getting sucked into. I’ll start trying to delve into it though.
Me:The beauty of the open source process is that non-core developers ARE willing and able to play with shiny geek toys. It’s the core team that I need to keep focused, they set the release schedule and core functionality / infrastructure pace of development. But the fact that outsiders are able to think laterally, and experiment with code that can be proven outside of the main development process is what gives open source its real diversity and amazing ability to innovate. So as long as it’s not on my dime, please scratch whatever itch interests you most
I didn’t make it clear originally that I was mainly talking about the CORE development team, which in most projects stays pretty focused on getting the job done using the chosen infrastructure rather than very “shiny” rewrites. The beauty of open source development, however, is that non-core developers can spend as much time as they want experimenting, and it’s this experimentation which can result in dramatic and unexpected features being innovated outside the core tree and then incorporated once they are proven. We don’t want to stop geek playfulness at all, we want to encourage it, but we need to keep the core team focused on getting the infrastructure reliable, usable and regularly released.