No Free Lunch

(Ref Id: 1322768150)

Scientific software costs money to produce. Yes, you could make the software in your spare time and release it. Yes, it can be made by the government or some body that is compensated to release the software and thereby makes that software publicly available under some kind of agreement (as is the case with software like caLIMS, IsoLIMS, etc.), but these systems are often unsupported. If they are, there is little incentive to customize the solution to meet individual company needs.

You can get this stuff for free. But the costs associated with laboratory software include, but are not limited to:

In other words, you get the car for free but you have to pay for the gas...and the maintenance...and the toll fees...and the get the picture. A car, like a laboratory software package, does not exist in a vacuum. It is supported by other software (databases come to mind) and people who are knowledgeable in its operation.

Years ago I tried to help a major LIMS vendor sell its software. I met with smaller laboratories and discussed the possibility of purchasing the software. Inevitably they would get into a discussion of the other costs associated with keeping such a system up and running. After doing a real assessment of these costs most of them wanted to fall out of their chairs. At that point I realized that open source or very low cost options were in order for smaller labs.

I then elected to look into the smaller-scale software marketplaces. I realized that laboratories are spread out all over the world, so a smaller vendor will typically also be a local vendor. Many great proprietary systems were restricted to some country. Open source systems lacked enough of a following to ensure that local support could be obtained. Over the phone or purely virtual support is the only option. Luckily nowadays people are a bit more open to this type of support, but I have seen instances where the service provider simply did not have the customer's best interests in mind.

The smaller the organization the more likely they will be without in-house software support. This means that the service provider who cannot show up on-site and say, "here's why it doesn't forgot to plug in the network connection," is going to be at a disadvantage. I've seen third party support work best with good in-house support. This is kind of like corporate lawyers. They work best when they work with in-house counsel.

So what does that leave? Software as a Service. In my opinion this is the only viable option for the smaller enterprise. You may have multiple labs, disparate employees who work virtually, or other laboratories that work with yours in a partnership arrangement. Whatever the case -- SaaS sticks somebody else with supporting the software, the machines, and the network. Somebody else has to do nightly backups. Somebody else has to do software updates. Your job is to log in and hammer away at the keys to get you data into and out of that system.

This is the reason I elected to stop killing myself trying to find the holy grail of open source in the laboratory market and to switch gears back to LabTools. It was not an economic decision or based off of greed -- it was based on common sense taking into consideration the actual needs of the target market.

Go Back

Citation: No Free Lunch. (2011). Retrieved Sat Jun 23 10:14:14 2018, from;iid=readMore;go=1322768150