[schooltool] My due diligence on SchoolTool

[Mark Shuttleworth]

[I'll try to paste this as a comment onto the web site too. The latter 
part of this applies directly to the current SchoolTool developers, so I 
would ask them to read it and comment on the list.]

This is a fair review, and it uncovers an interesting dynamic around the 
open source development environment that hasn't been widely discussed 
and isn't really covered in the Cathedral and the Bazaar.

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.

Lessons Learned

So the risk is that a well-funded open source team that is NOT lead 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.


Tom Hoffman wrote:

> It is probably polite to point out a post I made on my weblog about 
> Schooltool's history, at least as much as I could gather from Google 
> and SourceForge.  Let me know if I made any errors.
>
> It is here: http://stone.tuttlesvc.org:880/2003_11_16.html#000378

-- 
Try Debian Linux. Software freedom for the bold...
See www.debian.org for more information.