The Business Case for Open Source and the Small Company 5
Few would argue against small companies using open source software - indeed many owe their very existence to it. But what real, tangible good can come from a small company releasing open source software?
Signal to Noise, the company blog of 37signals, offers a worthwhile perspective on this issue. To summarize the business case:
Certain kinds of software, like infrastructure software, take vast amounts of time and resources to get right - something that few small companies can afford. Open sourcing can accelerate the process.
Open sourcing provides a public arena in which your own company's developers can learn from other great developers.
That public arena provides unique access to a pool of smart, motivated developers - and offers a way to evaluate their work before even deciding to interview them.
Open source generates press attention and goodwill from potential customers.
And about the elephant in the room:
A big fear that a lot of people have is that they’ll somehow be giving away their secret sauce. Unless your actual product is what you’re open sourcing, it really doesn't matter (and there are even plenty of examples of that working well). It’s unlikely that the piece of code that’s only seen internal development is such a silver bullet that you’re going to outshine your competition by its use alone.
The distinction between infrastructure software and a company's secret sauce is particularly important.
By just about any standard, 37signals is a leader in the deliberate use of open source software to achieve business objectives. We can all learn from them.
I give as a counter-example for this field, OpenEye. They released OELib (now Open Babel) as GPL but during a rewrite closed it. One reason is they got little back from their customers. After all, pharmas are not in the habit of distributing code back to vendors, and some had to go through too much legal work. Another was that pharmas made internal changes, making the code harder to support.
Did that licensing model benefit them for that stage in development? I don't know. Only one customer somewhat complained about the GPL->proprietary transition, and most of the others were more concerned that they have a solid business model so OpenEye would be around to support the code.
Open source as a business model only works if there are enough people in the community that you get something back. (Free software has entirely different goals.)
How many users are there of Open Babel, CDK, or visualization programs like PyMol? How many have sent patches in? How many are non-trivial contributors? How many projects could continue if the main developer left?
In response to those points: 1) "can", but not necessarily", 2) there's no culture of review in chemistry software -- how many CDK developers review OpenBabel or RDKit code? -- and without review there's less chance of learning, 3) money also gives a "unique access to a pool of smart, motivated developers" 4) not if the customer's first thoughts are "can you survive as a company?", and how important is that vs. having fast, robust, full-featured software?
Andrew, thanks for the comments. To me the most important bit in the entire 37signals article wast the distinction between "Infrastructure" and "Secret Sauce". 37signals never open sourced their secret sauce and DHH wasn't really saying that was a good idea.
Unfortunately, the experience of Open Eye with OELib is the only example of fully open source cheminformatics "Infrastructure" software supported by a company that I'm aware of.
How representative was their experience likely to be?
Unfortunately, I'm not sure OELib was given enough time as a GPL "experiment," so even that data point is suspect. I'm egotistical enough to think that Open Babel is a "success" at this point, with 30-odd projects using it.
I can't find the quote, but most open source projects go by the 10% rule. That is, 10% of all users might become developers. Some 10% of all developers become really active.
I've personally participated in many open source projects, dating back to around 1996-1997. The great thing is that sometimes someone just comes around and says "here you go, here's this huge advance." Sometimes they disappear again. But if you grow the project and the community, that 10% (and those random gifts) become something very significant.
It takes patience and a steady hand to grow a community.
As far as a culture of review? There's definitely some cross-project review. Otherwise Blue Obelisk wouldn't exist. It may not be a formal review process, but I certainly check other projects carefully. For example, I'm cross-validating the UFF implementations in Open Babel and RDKit (and Towhee).
One more data point exists. eMolecules donated a full canonical SMILES implementation to Open Babel, continue to help with maintaining the project, and are working on an Open SMILES standard.
Actually, I just came across an interesting way to measure the number of active contributors. Ohloh project comparison. One interesting graph shows the number of active contributors in a given month. For example, Open Babel vs. Jmol vs. Pymol.
While not quite "chemistry", another open source project to compare is RasMol vs. Chime, and the lawsuit between Glaxo and MDL over it. One consequence is it made Roger Sayle, the author of RasMol, wary of doing anything that might put millions of dollars into MDL's pocket.
Was RasMol a success? Yes! People still use it even though there's been very little development on it for years and some of the code is no longer valid for modern machines.
But there's a difference between that an business success. Geoff? Do you think you can get $90K/yr income from developing Open Babel? That's what you would need to provide comparable income to what you could probably get in industry, including overhead. I don't think so, so in the context of presenting a business case for it - vs. a science case - it is not a success.
Based on my experiences with VMD, that "10%" number is a highly optimistic estimate. VMD was not open source when I maintained it, but it was source available with lenient license for reuse of portions of the source. With thousands of downloads and many users, I received a handful of patches.
Chemists are not programmers. Most chemists want to do science, and not maintain software. Or compare it to the gcc world - you use gcc, but have you ever sent in any patches? I haven't. So that number is well less than 10%
I co-founded Biopython, which has had a large number of contributors over time, and done several transitions of leadership. I know that Open Source projects with multiple diverse contributors are possible. But how does someone make a living out of it, except by getting grants from the government? (Which I don't want to do.)
Remember also that I'm a company. But I make my money consulting and writing custom in-house code that never sees the bright light of the outdoor world.
I looked at Ohloh but I don't know what the numbers mean. According to that, PyMol has 0 developers now? Is that based on version control logs? I think people email patches to Warren, which he commits, rather than giving out an account. Even looking at the "total lines of code" I think there's a problem: I count 220,000 LOC when I add up the .c, .h and .cpp files in Open Babel. Ohloh says 500K.
By "culture of review" -- who does peer review of source code? It's not common, in part because it's not seen as "doing science." You yourself pointed out that you "have not done thorough testing of [the InChI] code, so I do feel guilty when I read the current discussions" and you do review code. Is there the equivalent of a journal club for looking at code?
In my very narrow focus on SMILES parsers its obvious that none of them copied from each other, and that few know how to write fast, succinct and clean code. Most of what I've seen is slow, lengthy and ugly.
How do I change things so that people write better code? I had this conversation a couple of days ago, with the response being along the lines "you can teach good paradigms but when something needs to get done, people will write dirty code." That's the dominate view of software in this field and it's wrong. Not in the theoretical, but in the practical in that most people are not at the point where they have to make that trade-off. They can write better code more quickly by learning to program better, and they can do that through training and developing the ability to critique software, which is assisted by code review.
Anyway, /rant off.