In this whitepaper GenoLogics says, "we think the complexity associated with life sciences makes
LIMS development something best left to reputable vendors." My translation is this: 'We don't feel that you are intellectually gifted enough to know that you should avoid writing your own LIMS from scratch OR that you can make yourself aware of the alternatives.'
Let's look a the rest of the paper and my witty interpretations of other key statements. Remember, they are saying that: "...we convey the experience of several labs who have just deliberated on the dilemma and what drove them to eventually buy rather than build a LIMS..."
Translation: 'we found a bunch of people that agree with us and here is what they said.'
- 1) "Purchasing was a better use of resources."
Translation: 'Our resources should be doing lab work, not writing code.'
Retort: When the LIMS does not fulfill your needs you either have to get the vendor to change the software or hire some programmers to write some code. Don't be fooled -- in many cases fully vendor-supported and licensed LIMS can require extensive customization (via programming) when your business needs change. Having a really smart vendor doesn't guarantee a thing.
- 2) "Flexibility can be found in the right LIMS."
Translation: APIs are all you need...customization is now "moot."
Retort: API stands for Application Programming Interface and these can really hide underlying implementations from you that MAY BE WRONG. Yes, that's right, WRONG. I know of one commercial LIMS vendor that was releasing buggy software that everyone was happily utilizing the API for to import data until some LIMS technician noticed the error. If they had the code it might have been noticed faster. Also, APIs change over time, forcing you, the poor hapless buyer, to upgrade the software to keep up.
- 3) "Scalability is about technology and people."
Translation: This one is too hard to translate cleanly because it bounces around all over the place. Essentially it starts by saying that the University of Washington originally built its own LIMS but then wanted to scale and couldn't afford to do it. It doesn't talk about whether U of W delivered the system as Open Source and tried to build a community around it and looked to that community to help scale the software. It says "the development costs add up..." Right, that's why you either build a community around your Open Source offering or work with others (by using pre-built components) to lower your costs.
The other part talks about essentially the same thing claiming that an in-house built LIMS became unusable once the only person who understood it left the organization. This completely ignores the concepts behind DIY or Open Source entirely. Building your own siloed system is just that, building your own system. If you are not going to even try to build or participate in a community you are on your own.
- 4) "Don't underestimate the user experience."
Translation: 'Our system is going to be prettier than the one you build in-house because a commercial system has to do a lot with usability.'
Retort: I don't know but Open Source systems are getting prettier by the day. I installed Open-LIMS v0.4 and was impressed by how the UI looked. It wasn't distracting and used newer jQuery features that normally I would consider 'icing.' In short, nothing precludes either a DIY or pure Open Source system from having a nice UI and pleasant experience. It all has to do with those running the project. Consider that Linux used to be completely a command-line system with very primitive UI but over time it got better. Nowadays the commercial vendors are emulating portions of Linux UIs. Ain't life grand?Go Back
Citation: GenoLogics on DIY. (2015). Retrieved Mon May 1 02:09:04 2017, from http://www.limsexpert.com/cgi-bin/bixchange/bixchange.cgi?pom=limsexpert3;iid=readMore;go=1422580383