Making Money from OpenSource Science Software. II. Sell Hardware

This is the second post in a series in which I’m trying to figure out a general strategy for developers of open source scientific software to make a living without closing the source to their codes.

The canonical examples of this in the commodity software community are Apple and Sun Microsystems. Both companies make substantial fractions of their valuable code available under open source licenses, although in Apple’s case the “crown jewels” (the graphical portions of their operating system and the various iApps) are not part of the open source mix. Sun has a much more scientifically-interesting open source approach; they make the code available for Solaris as well as GridEngine, OpenOffice, and the Java Development Kit.

It should not be a surprise to anyone that the majority of hardware we run our code on these days are Apple laptops and desktops and Sun Opteron servers. Are we rewarding these vendors for making their code available? Not directly. A better explanation is that since both companies are invested in open source, a wide range of open source developers are making sure their codes work on these platforms. The tools we use daily (Linux, g++, xemacs, xmgr, gridengine, ddd, gdb) usually work out of the box on these platforms, so that’s what we end up buying.

So what’s the scientific version of this strategy? I’d like to think that companies that make the spectroscopic instrumentation would make their spectral analysis software available with source, but that doesn’t seem to be the case. Bruker’s “TopSpin” software isn’t freely available, even though they have included what looks like some of Jmol (which is under GPL), and Varian’s VnmrJ is also a closed-source product. A brief survey of some of the newer fields that rely on instrumentation (like the various surface-probe microscopies) show either propietary (and usually windows-only) software from the vendors themselves or community-supported open source replacements like GXSM.

I’d argue that the scientific hardware vendors are actually much less likely to release their codes than commodity hardware vendors. Scientific instruments are expensive, and you typically need up-to-date software to drive the instruments. The vendors know that once you’ve bought their hardware, selling you the software is a guaranteed revenue stream, and purchasing decisions about scientific instrumentation are almost never made based on the quality or transparency of the bundled software.

Also, the scientific codes I’m most interested in professionally are in areas for which there is no scientific instrumentation. Specifically codes that perform Quantum Chemistry, Molecular Dynamics, and Monte Carlo calculations don’t have an associated hardware vendor which would support their development.
So we can pretty much eliminate “Sell Hardware” as a viable strategy for making money from OpenSource scientific software. It may work in a few rare cases, but two things are opposing this avenue:

• Many complicated and interesting scientific codes have no associated hardware to be sold.
• Vendors of instrumentation will see little benefit to themselves from providing open source software because purchasing decisions don’t take software availablity into account.

Tomorrow’s topic: Sell Services