This is the third post in a series exploring how scientific software companies might be able to make money while still keeping their code open. The previous articles are:
There’s also a related thread going on at Notes from the Biomass.
The point of these articles is to find a way for producers of good scientific software to make money while still keeping their codes open for skeptical review. I think it is good scientific practice that codes be open to review, but I’m also sympathetic with the desire of the developers of this software to put food on the table.
One of the more common business models in the open source community that produces commodity software (e.g. operating systems) is to sell services. There are many examples of companies that provide source-level and binary downloads of one version of their product, while charging for the “enterprise” or supported version. The canonical example of this is RedHat, and judging from much of the chatter on the various scientific mailing lists (e.g. ccl.net), enterprise-level support for some of the major computational chemistry packages is sorely lacking. There’s clearly a demand for scientific software support, but would a support-based system be a viable way to support a company that opens up its code?
Again, the economics seems stacked against this model. First, scientific software targets a relatively small group of users, and at the same time, the development and support costs are often quite large. Problems with the software are often so complex they can’t be addressed by online FAQs or with banks of inexpensive support staff. So the support contracts would need to be expensive.
Secondly, academic users of scientific software have pools of relatively cheap but intelligent and highly-skilled labor. Why would a researcher spend $10000 on a support contract if the problem could be solved by throwing a graduate student at the open source version of the code for a few months?
The entire expense of the software development and support services would then fall on the few corporate clients of the producer of the software. Simply dividing the costs to the company by the number of expected buyers of the software means the initial price of a license or support contract would be prohibitively high, and if the software was high-quality software, I would expect that some of the corporate clients would attempt to run with the source just like the academics would.
For this reason, I’m reasonably sure that “selling support” isn’t a viable model for the scientific software community to adopt.
However, there is another way to sell services. Suppose a given software company acted as a service bureau that performed a specific kind of calculation for industry and academic labs. That is, if a company was producing an open source ligand docking program, they could supply the service of screening a particular set of potential drug molecules against a specific binding domain on a known protein target. The cost to provide data for one molecule docking with a binding domain could then be set reasonably low so that academic researchers could become familiar with the service. Clients that had larger demands (i.e. pharmaceutical companies) could subscribe to this service for an annual fee.
Essentially, this model has the company that wrote a piece of open source scientific software acting as a single-purpose supercomputing center. Since the developers of the primary application would be on staff, the company would already have the scientific and computational expertise to run the service. All that would be required would be clients willing to submit their “jobs” to the service bureau.
Would this model work in all scientific fields? Probably not. The company would need industrial clients with relatively deep pockets and a need for their services. But in chemistry, at least, the trend has been for the fine chemical and pharmaceutical companies to scale down their in-house computational groups. Would they be willing to farm-out their computational tasks to another company, particularly when the relevant information (like drug leads or even the targets of those drug molecules) are trade secrets? I don’t know yet, but I’m not aware of anyone who has tried this approach.
So my conclusions thus far are that “sell hardware” and “sell support” won’t work to fund open source science software, but there might find some scientific fields where computational service bureaus spring up around a piece of open source code.
Next up: Dual Licensing
Dan,
I think you’re right about the ‘sell knowledge’ service, instead of the support service. It is the way current open source software is developed too: as a mean, instead of a goal.
Nice reading!
Egon
This is a little tongue-in-cheek, but its not easy selling knowledge to scientists. Too many of them think they know everything already. But you are right, service is about expertise, not support. Support is follow-on service, which is important, but not part of the current “software as as a service” paradigm.
I am still not convinced that computing services as you suggest will work. In addition to trade secrets, many companies still fail to realize the value, and until that happens, they will only make small investments, making it very difficult to run a viable business. I think many people are trying to find out which is the right model (and there is probably more than one).
An interesting series of articles.
But I have to say I’m not very hopeful there is a way for companies to make money in this area. This is simply because of the dynamics of the open source development process, and conditions under which companies can make money from free software.
Nonetheless, I think there may be a solution of sorts – see
http://opendotdotdot.blogspot.com/2006/03/science-of-open-source.html
for the full argument.
I think it might be worth noting that there are examples of companies built around open-source scientific software; this discussion should include the experimental data, as well as theorizing!
In particular, in my own field, the OpenFOAM computational fluid dynamics code has been open-source for nearly a year and a half, and the company webpage gives the impression that their business model was based around a contracting-and-support basis even before the licensing change.
An excellent set of articles. I am looking forward to the upcoming articles. In particular, because I wan to make a living out of developing and releasing free and open source scientific software.
About how to make money from open source scientific software, I think that any company wishing to make a living by opening scientific software has to embrace several options at once, i.e. a combination of the options that you mentioned in the first post of this series. I will put Kitware (http://www.kitware.com/) as an example. From their about page (http://www.kitware.com/profile/about.html), we have that:
“Kitware’s mission is to provide state of the art visualization, graphics, and image processing software solutions. This includes developing turn-key, end user applications; creating customized applications for clients; porting our open-source tools such as VTK, ITK, and CMake to custom hardware; supporting these open-source software tools with documentation and tools; providing professional consulting services; and offering on-site and off-site training.â€
So, how is Kitware making money?
1.- By working under contract with the U.S. National Library of Medicine to develop and provide support to the Insight Toolkit (ITK, http://www.itk.com) a set of open source libraries for medical image processing, analysis, and registration;
2.- By selling licenses of a proprietary software application for medical image registration and segmentation (VolView) that is based on the open source software libraries VTK and ITK;
3.- By providing training courses at a price;
4.- By providing several levels of support and consulting services at a price; and
5.- By selling books about their products.
Point 1 fits into contract work category (I did not see that category in your first post)
Point 2 fits into the dual licensing category
Points 3fits into training and certification category (I did not see that category in your first post)
Point 4 fits into the selling services category
Point 5 fits into the selling related products category (I did not see that category in your first post)
By the way, I have been using ITK for three years. That is how I learnt about Kitware.
Again, I am looking forward to the upcoming posts
Lino
The ITK’s website is http://www.itk.org . It is not the one I mentioned in my comment above.
Lino
P.S. The websites for VTK and CMake are http://www.vtk.org and http://cmake.org respectively
Excellent series of articles…some of the ideas appear infeasible, but, for the time being at least, I think very niche software developers might be able to apply concepts such as dual licensing to derive revenues…but frankly, unless the software is so sophisticated that no one can develop it, I doubt revenues based on product sales (even under dual licensing) is a way for the future…
I guess it boils down to somehow using expertise/service to make money rather than making money on the product itself…I do not agree that service/support models do not make sense for scientific software…might have to figure out the right service or support
You might want to refer to a page from eIT.in that provides an extensive list of web resources for the topic of making money from open source software …some of the support ideas discussed there are quite interesting and who knows, one of them could fit the scientific software industry
Some thoughts from the BPO Database Online @ eBPO.in
Pingback: Open Source and the Small Company » geoff hutchison: blog