Epochs and Full Circles

(Ref Id: 1377208316)

Years ago I wrote a LIMSExpert.com article titled, the 10,000 foot overview. The LIMSExpert.com website had previously been about general commercial LIMS, industry issues, etc. This article was an epoch, what the dictionary defines as "a particular period of time marked by distinctive features, events, etc." At that time I started working on ParadigmLIMS -- my own take on an open source LIMS. However, after a short period of development I abandoned it. Why? I honestly felt that I had not given other 3rd party systems a fair shake and did not want to give the appearance of having ignored their efforts.

So I set out to discover whether 3rd party systems written by universities or other public or even private entities could come close to the capabilities of a commercial LIMS product. This, I admit, was a bit like Forest Gump walking across the country. Like Forest I finally had enough and now figure it is high time to return home.

This site is about doing it yourself, but you really cannot do it yourself nor should you in many cases. We all need help to get things done. The way we get help nowadays in LIMS and laboratory informatics in general is we simply buy it. We hire vendors to sell us a system; consultants to help us work on it; and professional support personnel to keep it running. This model is expensive and presents a higher-than-normal risk of project failure. The commercial industry's latest trend is to offer purpose-built configurable systems with limited or no customization options beyond end-user configuration. So you get a LIMS that can only do exactly what it was intended to do with some variations that can be turned on or off given your preferences. The end result is that you give up your versatility for safety and low cost. After a long period of time creativity will suffer; broad-based pursuit of goals will give way to incrementalism; your organization will start to feel the pinch as brighter and more courageous competitors (using open source alternatives) take the lead in your industry and leave you in the dust.

The arguments you hear in public online spaces about the LIMS industry conveniently ignore open source as a viable solution due to the lack of quality and support that are characteristic of today's open source LIMS offerings. True, after two years of searching for viable alternatives to commercial LIMS in the open source space I've found that most are just not worth the effort. They do not fulfull all of the needs of the consumer and the underlying code base lacks the facilities to be versatile when trying to repurpose the system.

After much review my hypothesis explaining the reason for the current state of open source LIMS solutions goes something like this: open source LIMS solutions have employed the 'too much too soon' format of development. Rather than develop and deploy underlying systems needed to build a LIMS they opted to build a complete system targeting the end user. If we compare LIMS to the Linux operating system this would be like building Gnome before developing a working kernel. What open source or DIY LIMS needs is the underlying stuff -- the foundation, basement, and subsystems of the building -- upon which to develop a more complete and versatile system. This is what this website aims to now bring to the marketplace.

Here is a quick history of interesting turning points in LIMSExpert.com. Think of it as one of those 'recap' U.S. TV episodes that were popular in the 80's and 90's shown right before (or after) a character on the show left:

Now for some time I also hosted a system called LabTools at the LIMSExpert.com site that was built in Perl (actually, it isn't gone but is now used for housekeeping at this site). LabTools was developed mainly for a development team's use during large scale implementations of enterprise-level LIMS in corporate environments. A good portion was written for a chemical inventory system. It turns out that the larger the system you are trying to put into place the more you need other systems to maintain them, so I built LabTools to solve problems that normally came up like ad-hoc data entry, system modeling, monitoring, etc. For a while I thought that LabTools would be 'the' system but like a wiki or a CMS it just wasn't architected for that purpose. So like other systems I abandoned the idea of building a full-fledged LIMS in it.

Things at this site are about to get exceedingly technical and to the traditional reader I apologize for that in advance. We've reached an epoch where everything is the same except how we look at things. Today I look at open source LIMS as one would look at primitive languages or mathematical systems that lack the number zero. They serve as an excellent reference but little else. I've also abandoned the quest to find 'the' system -- there is no single open source system that will do everything, but rather, an amalgamation of system capabilities presented to an adopter as a framework is in order. This means that the target audience, at least for the short term, cannot be the LIMS end or power user but must be a technician or developer of such systems.

If you are an end-user some postings may get fairly technical and thus a bit difficult to read. Posts that are tech-heavy will be prefixed with Tech: [title]. Thanks in advance for your patience.

Go Back

Citation: Epochs and Full Circles. (2013). Retrieved Sat Jun 23 10:16:24 2018, from http://www.limsexpert.com/cgi-bin/bixchange/bixchange.cgi?pom=limsexpert3;iid=readMore;go=1377208316