The Doctor Who Model of Open Source

How do we sustain Open Source in a distributed world? We are facing this challenge with several of our chemical software creations/packages. People move, institutions change. Open Source does not, of itself, grow and flourish – it needs nurturing. Many packages require a lot of work before they are in a state to be usefully enhanced by the community - “throw it over the wall and it will flourish” does not work.

Many OS projects have clear governance and (at least implicitly) funded management. Examples are Apache, Eclipse, etc. Many others have the “BDFL” - Benevolent Dictator For Life with characters such as RBS, Linus, Guido Python, Larry Perl, etc. These command worldwide respect and they have income models which are similar to literary giants. These models don't (yet?) work for chemistry.

Instead the Blue Obelisk community seems to have evolved a “Doctor Who” model. You'll recall that every few years something fatal happens to the Doctor and you think he is going to die and there will never be another series. Then he regenerates. The new Doctor has a different personality, a different philosophy (though always on the side of good). It is never clear how long any Doctor will remain unregenerated or who will come after him. And this is a common theme in the Blue Obelisk.

Many projects have a start-up time. This is not surprising and is usually a Good Thing as the project does not know where it is going and almost always needs a strong framework on which to build. It's not normally useful to have a random self-selected community try to continually refactor complex platforms in an oligarchic meritocracy – that can some later. This start-up is normally done by a single BD or possibly a small group working together who know what they want to do and need to create something that works before the first release. This is the long dark night of the sole developer – working towards something that they believe is valuable, for which initially they will get no recognition, often no funding and non infrequently criticism from the wider commuinity. Not “this is a promising beginning” but “it doesn't work”, “it's not got enough features”, “there's no support”. I've been there on multiple occasions. It's lonely.

However at some stage the software obtains critical mass, at least enough to attract fellow-minded Open Source developers. They often come from surprising sources. The s/w is not normally good enough to release to the community in general as it lacks features, testing, documentation, etc. But it know it is on the right path.

Jmol was originally intended to be a fully functional replacement for XMol which was a molecular viewing program developed at the Minnesota Supercomputer Center....

XMol's demise left a need for a similar tool. Dan Gezelter, the originator of Jmol, chose to avoid the same problems by making Jmol open source. ...

Later, Bradley A. Smith took over the project and did a lot of work in streamlining the project as well as the software. ..

In the end of 2002, Egon Willighagen became the new project leader and a start was made with integrating Jmol with The Chemical Development Kit, ...

Miguel joined the project at the end of 2002, with the explicit goal of helping build Jmol into a viable repacement for the Chime plugin (www.mdlchime.com) …

Shortly after 10.2 was released, Bob Hanson started leading the work on Jmol source code

This is an excellent exemplar – a piece of code written for a specific purpose (Xmol was fairly basic and ran on Xwindows), which then lay fallow before it passed through 5 Doctors and there is no indication that Bob is not with us for a long series!! But at each stage the project had enough visibililty and enough e-charisma to attract high-quality developers who could take over when required and add their own personality.

Note that these Doctors have the same force within the community as the Doctor has on TV and a BDFL with their developers. The Doctor finds their own way of regulating and encouraging development. Miguel used to make very clear lists of questions which were to be answered in a clear timescale. Bob has a similar but different way of gathering and prioritising.

[The following is not historically researched and I welcome contributions to set the record straight.]

But however we got there and wherever we are going we have a single Doctor for each of these.

[There are variants. Currently JUMBO has a BDFL (PeterMR), mainly because it has been continually refactored and it is asking a lot for anyone else to be involved in this maelstrom. With the success of Chem4Word (and dotNUMBO) that may change. ]

“what happens if a Doctor dies and does not regenerate?” Well, just like the TV we know it will work out. The software above is sufficiently widely used that we are sure that someone would step in. Miguel came from nowhere (Gallifrey?) - he wasn't a chemist but a computer scientist and he filled the role perfectly and handed over to Bob in an exemplary manner. Doctor-based Blue Obelisk works.

I'd be interested to know of other OS projects where this model has been generally successful.

23 Responses to The Doctor Who Model of Open Source

Peter, great analogy (full disclosure - Dr. Who is a show I've enjoyed a lot over the years).

To extend it - Dr. Who (the series) got more done with less money than any other Sci-Fi series I know of. It seemed to work by staying within its constraints - not by throwing more money at the problem. For example, the idea of Doctors regenerating was a brilliant way to deal with the problem of the show losing its star actor every few years.

Open source offers many powerful ways to turn constraints into creative solutions.

An excellent analogy, Peter. On reflection, it's one that's been true for many years, long before we talked of open source. I've seen exactly the same model emerge with software distributed via user groups such as DECUS or SHARE, and for much the same set of reasons. But it does help to think of it in the way you've set out.

Since 2004 I've been running an open source project called TiddlyWiki. It's reasonably successful, with a vocal and inventive community gathered around it. The weird thing was that about 2 years in, due to an email configuration mess up on my part, for about a month, none of my posts to the mailing list were appearing. They were silently being rejected in a way that was impossible for me to notice, since my messages still appeared correctly in the threaded GMail view I usually use when posting to the mailing lists. So, for about four weeks, I was happily posting to the group, not realising that I was actually invisible. The really strange thing was in the way that the community reacted in a rather similar way to the Doctor Who episode "The Christmas Invasion" (see http://en.wikipedia.org/wiki/The_Christmas_Invasion). In that episode, the Doctor is out of action for the first 20 minutes or so, laid up in bed. His "community" meanwhile buzzes around, getting on with what he would have done if able bodied. It made me think that perhaps open source communities don't actually even need the reality of a leader, just the idea of one....

@Jeremy many thanks. I think this may work when (a) the project has got off the ground and (b) has a clear set of goals. If it needs refactoring that normally needs the guidance of a central person. In chemistry relative few projects are so clearly defined they can work without a point of reference.

I strongly believe in this bottom-up model of decision making and evolution. We have seen that things are not always easy, but honestly, I think founding the 'blue obelisk' was one of the smartest moves, ever ! Especially to show the world (and ourself) that independent projects can move together, learn from each other, and teach the next generation.

The Blue Obelisk was/is a mission statement, a credo, something we all wanted and needed !
And this is a concept new people can buy-in or modify to some degree for their own needs. We have seen how powerful it can be being part of a crowd, and how lonely it can be, when left out.
There is typically no leader, but key people the others are trusting. You can not force anything, you can only encourage and try to convince. It has its own dynamics, and you need a long-breath, but when it starts lifting, you can not take it back, or as someone else said "Taking something out of the internet is like trying to take pee out of a pool"

@Joerg many thanks. This is very encouraging. Yes, The BO works because it is almost undefined. And we are steadily building up all the tools that are needed. Talking with Geoff Hutchison on Pittsburgh was also very reassuring.

The Doctor Who model of community leadership is quite common in FOSS projects. I know, for example, that I am the Third Doctor of the SCPlugin project (http://scplugin.tigris.org), which integrates Subversion version control commands into the Mac OS X Finder menus.

Indeed, the seminal work in open-source community dynamics, Eric S. Raymond's "The Cathedral and the Bazaar," is built around his own experience of taking over a successful, once-active project (fetchmail). As he mentions in the essay, the experience led him to conclude that the final responsibility of every open-source developer is to prepare the project for the next owner.