When buying a large piece of software, such as a LIMS or an ELN, there are many types of systems, available. Some of your choices depend on your industry or the size or your laboratories. Other choices are based on your organization’s other needs and desires. Today, I’m specifically going to talk about COTS, SaaS and Open Source since these are some discussion points of current interest.
COTS (Commercial Off-The-Shelf)
Customers who go out to buy a COTS often have the impression, a wrong one, that COTS software is something they buy and merely implement fairly simply. However, many of these systems require programming in order to make them work as the customer thinks that they should. This makes a huge difference in the amount of time these systems can take to implement, and in the overall price of the project beyond the licenses and other standard costs. But this fact is hidden by the fact that our industry insists on calling it “configuration,” “scripting” or any other number of names to hide what it is – which is programming.
I’m not saying there’s anything wrong with programming. I make some of my living programming (scripting? configuring?) these systems. I’m merely saying it changes the scope of the project. Software implementations have improved, in general, over the years. We’ve seen them improve in this industry, as well. However, we still get terrible statistics on cost overruns. There are many factors to this, but when a customer comes to that awful point of realization when they realize they’ve taken on something much different than they thought they were committing to, they elect to continue rather than just throw what they’ve done away. However, they’re then left scrambling to get more budget, more people, adjust the project schedule, etc… Sometimes, they really end up with something they had to cobble together rather than lose what they’ve done, and that leaves the project in a lower quality state than if they’d been able to properly plan with the entire understanding of what they need to do.
I’m now switching from my programmer’s hat to my project manager’s hat: planning is everything! Well, it’s most of it, at least. But good planning requires proper expectations.
SaaS stands for “Software as a Service” and it refers to the way you buy and use the software. Instead of buying licenses and services for a project, you’re really renting the software, more-or-less. Let me explain this a little differently: larger companies that are established have budgets. These plan these ahead and include projects, software licenses and support for the software projects they’re going to do and the software they must support. And you can do a good job of planning for this if your company is well-established because you know how many resources you need for the year, within a close estimate.
But what if you’re a startup company? You don’t have that same kind of long-term budget. Maybe you’re still trying to get funding, as we speak, and don’t know exactly how much money you’ll have from month-to-month. You might be gaining and losing a person here-and-there and, if you’re a 3-person shop, a difference of one person is a huge difference. SaaS allows you to pay for what you use without making large commitments. So, you might pay for three people to use the software, this month, two people the following month, four the month after, etc… Not only is this kind of cost savings critical to a company that small, but it evens-out the cost among shorter increments. So, that little company can pay-as-they-go.
SaaS supposedly costs more than the traditional model, on a per-unit basis. This is part of what they’ll tell you if you were to go to one of those MSP (Master Service Provider) courses for the SaaS providers, as opposed to what we tell you customers when we try to sell this to you. However, this is just one example of how it can be a useful choice.
First of all “open source” isn’t just about code sharing. Sharing code gives people something to start with. If you want me to apply the fancy lingo to this, code-sharing provides a “springboard.” In the Open Source model, we don’t just write and share code, but we test it, too. So, if I write some code and I think it could be useful for the “community” (all those people participating in the effort, that is), I would share it to the community and I might even adjust it to make it as generic and useful as I can think to do. If I want to give high-quality code to the community, I will test it, too, before I share it, make sure it’s readable, all the things good programmers and testers do. Once the community gets it, they can test it and propose changes to it, but it will end up in a library of shared code that is available to everyone. As a responsible person, I would also make sure there was nothing in the code that’s proprietary to the installation. After all, if it’s being shared, it shouldn’t give away any company secrets.
So, we’re still talking about programming. Then, you might ask, “How is this different than COTS if there’s programming involved in most of those, too?” Well, with COTS, there will theoretically be less programming. Whether that’s true or not depends on how well the project is managed, for one. And, by the way, just because software is created using Open Source doesn’t necessarily mean there are no software licenses involved.
In any case, some of the COTS vendors are providing what is similar to an Open Source model, where they are sharing code that is common and tested – code that can be reliably reused. So, where software vendors create libraries of code for their own customers to use and participate in, you might wonder why we don’t use this term for these private code libraries and why these libraries are given brand names, instead of calling it “open source.” It doesn’t mean they’re not useful; it’s just that they want to make it clear their code isn’t open to absolutely everyone, just their own customers. It’s just a terminology issue not a value judgment.
The other piece to this is you might not need to care about a lot of the details behind Open Source. If you’re paying someone to create a LIMS or ELN for you and they’re doing it using Open Source, all you care about is that it should cost you less than if the company putting this together for you wrote the code entirely from scratch. They shouldn’t have to write all the security features from scratch, as merely one example. But if you’ve decided your company will be the one doing the entire effort, you should do this someone like you’d plan for a COTS implementation, where you gather your true requirements and then match what you can find in the code library to that in order to determine the true cost of the solution. So, you’ll still compare what you can “take” versus what you have to “create.”
To give a couple more comments on the true open source communities:
- To continually provide new code for new features, although it is often possible merely to “take” code, these communities depend on “give and take.” If too many people join merely to “take” and not to “give and take” then the library doesn’t flourish.
- To continually provide new code for new features, some of these communities have quite a large number of participants.
If you’re among the companies truly interested in Open Source, there are legal and other issues you’ll want to understand if you’re going to undertake this, yourself. Wikipedia gives a good overview of what “open source” means: http://en.wikipedia.org/wiki/Open_Source_Definition