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.]
Babel (Pat Walters) => OELIB (Matt Stahl + ?) (language fork Java) => JOELib (Joerg Wegner)
OELIB (language fork C++)=> OpenBabel (Geoff Hutchison)
CDK (Christoph Steinbeck, Egon Willighagen, Dan Gezelter) => Egon
PeterMR => Joe Townsend + Chris Waudby => Peter Corbett
PeterMR => Joe Townsend => Peter Corbet => Daniel Lowe
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.