How does open source software happen? Although many factors come into play, the majority of answers seem to revolve around a simple theme: developers building solutions to fill their own needs. Yet only a fraction of these solutions end up becoming open source software. And only a fraction of those end up being used by a wider audience. What's the key ingredient? There's still a lot to learn from studying individual cases.

Readable discussions about the origins of specific open source projects are pretty rare, but those dealing with the origins of open source cheminformatics software are more uncommon still. So it was with great interest that I came across Ivan Tubert-Brohman's account of how PerlMol was created.

PerlMol is an open source "collection of Perl modules for cheminformatics and computational chemistry." Many software packages fit into this category, and some of them are open source, so why write another? For Tubert-Brohman, the deciding factor was being able to work in his preferred environment, Perl:

I was surprised that CPAN [The Comprehensive Perl Archive Network] was sorely lacking in terms of modules for chemistry. The only available modules were Chemistry::Element, which allows you to convert between atomic number, element symbol, and element name and store other elemental information; and Chemistry::MolecularMass, which calculates the mass from the molecular formula. There were no modules that actually dealt with the structure of molecules. While some of the options in other languages are not bad, I was looking for something with the simplicity and conciseness of Perl that could allow me to write "chemical one-liners" to solve small problems very quickly, without having to compile anything. Hence, PerlMol was born.

The elimination of the need to compile, and relaxed syntaxes that promote succinct code are two of the biggest reasons to try a cheminformatics scripting environment.

There's a lot of great software still to be written in cheminformatics, and some of it will be open source. Although open sourcing that side project you've been working on may not be the best option for your career or your company, studying case studies like that of PerlMol gives plenty of food for thought.

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.

Recent articles have discussed Rubidium, the cheminformatics toolkit for Ruby. In this article, the first in a series, I'll go beyond the Ruby code to discuss the technical aspects of taking an Open Source idea from concept to release.

Finding a Home

Before setting up your Open Source project, you'll need to decide on how to host it. Project hosting can be as simple or elaborate as you wish, but the basic services include: a website; a mailing list; a discussion forum; a source code repository (typically CVS or Subversion); a bug tracking system; and a file release system.

The multitude of choices can be broken down into two basic options: host the project yourself or use a free hosting service. Fortunately, Ruby-based projects enjoy two excellent free hosting options: SourceForge and RubyForge. Although SourceForge could certainly be used for a Ruby project, RubyForge is a more popular option. One of the reasons is that any RubyGem your project releases automatically becomes installable through the RubyGems package management system with a simple one-line incantation:

$ sudo gem install <yourprojectname>

Another reason to use RubyForge is discoverability. RubyForge only hosts projects related in some way to Ruby. So, your project will stand out a lot more in its category than with a much larger site like SourceForge.

Given RubyForge's advantages, and my own interest in minimizing the work needed to maintain an Open Source project, Rubidium will be hosted on RubyForge.

Requesting a Project Space

Having decided on RubyForge as Rubidium's host, all that's left is to ask for free services. You'll need to register for a user account if you haven't done so already. Then, simply apply for project space. After about three business days, you should be notified whether your project was accepted.

Several days ago, I completed this process for Rubidium. Its new home on RubyForge will be:

http://rubyforge.org/projects/rbtk

The Rubidium home page can be found at:

http://rbtk.rubyforge.org

There's nothing useful there yet, a situation that will hopefully be fixed in a few weeks.

Next Steps

With powerful free services now available for the Rubidium project, we'll want to start taking advantage of them. The next articles in this series will discuss some ways of doing so.

Hanjo Kim of the Bioinformatics & Molecular Design Research Center (BMDRC) in Seoul, South Korea writes in to tell about his Korean-language cheminformatics blog Agile2Robust. Some of his articles, such as this one on PubChem have been translated from Depth-First; others are based on Depth-First articles.

This completes a circle. It was Kim's post to the Ruby mailing list in late 2005 and the responses to it that helped me in the early days of developing cheminformatics software in Ruby (and writing articles about it here), although Kim probably didn't know it at the time.

During this process, none of the usual scientific protocols have been observed: no journal articles were written or published; no grants to do any of the work were prepared or funded; no presentations were made; and no central authority was involved (at least on my end). In fact, if any of these conventions had been observed, the work would have never seen the light of day. Free tools, free services, and open standards enabled one scientist to connect with another in a way that's impossible to achieve through conventional means.

Greg Beaver has written an interesting set of ten golden rules for running open source projects. Many of these rules apply to running (or working on) anything. My favorite rule is "3. Despite the evidence, it's probably your fault." Greg develops the popular Open Source project PEAR, a packaging tool for PHP that looks similar in concept to RubyGems.

Cheminformatics, like all vertical markets, has is own peculiarities when it comes to Open Source. Most importantly, cheminformatics software has a limited, but captive audience. When done well, it is both highly profitable and expensive to develop. For insightful perspectives on Open Source software as it applies to cheminformatics and vertical markets, see Matt Stahl, Warren DeLano, Craig James, and Eric S. Raymond.