I'll save you the trouble of having to read through this entire article to obtain the answers to the question of when and where you should consider a DIY LIMS project -- I think everyone using a LIMS should also be similarly engaged in a DIY project. The fact of the matter is that some of the largest buyers and thus contributors to LIMS have been doing this all along. They have been customizing a commercial LIMS and submitting their changes for inclusion in the vendor's code as well as quietly building their own LIMS 'in the basement' of their organizations. In the latter case many organizations simply never publish the system, but that is not always the case.
Believe it or not, some of the commercial systems you may be familiar with started out as one of these 'basement' systems. In these cases the founding organization was induced to release the system to a third party that was interested in capitalizing on the software. Your organization may elect to go this same route, so technically speaking today's DIY LIMS may well be tomorrow's system of choice. This makes the lines between your in-house LIMS initiative and a marketable product rather blurry.
All of this is actually how innovation in software happens. It often begins with an organization electing to either try out new concepts or to build something new that the marketplace simply does not offer. There is no rule that says that an organization cannot primarily be interested in the software for their own purposes. And what about organizations that do not have in-house software development resources? In this case contributions to someone's publicly released DIY LIMS project can still be made in the form of bug reports, documentation, and meaningful discussion about current and prospective functionality.
The software business is constantly changing, so what used to be sufficient three years ago may be downright defunct today. If nothing else a DIY project allows an organization to obtain a sneak peek at the future and ascertain, practically, how some of the upcoming technological advances will impact their organization as a whole. Sometimes you can do that with a vendor-supported system, but often you do not have enough control over the base system to make a meaningful go of it. You may be adding Hadoop as an integral part of your LIMS while your vendor may be pursuing some expensive commercial alternative. In many cases you'll need a complete system to ensure that you are in control of the initiative.
Before wrapping up here I'll discuss a concept that is often promoted as an alternative to what I've presented here, the so-called joint application development (or JAD) groups provided by LIMS vendors. These are mainly composed of a small association of organizations using the same LIMS. They work together to come up with specifications for the vendor, submit their proposal, and test the prototypes arising out of their interaction with the vendor. These initiatives can work but they can also fall well short of a DIY initiative because of their limited scope. The participants to a JAD group will often be in the same industry and the size of the group will purposefully be kept small to limit the scope of the proposed enhancements. This methodology does not take into consideration that meaningful enhancements in LIMS are often cross-bred from totally different initiatives going on in different industries. A food processing LIMS enhancement may be exceedingly useful for some deficiency found in infant formula processing performed at a major pharmaceutical company for instance. Since you cannot predict where good ideas come from it is better to be more inclusive rather than less, as JADs oftentimes are.
In future articles in LIMSExpert.com we'll cover customization strategies that allow for better, safer interactions with third parties. We'll also touch upon the redundancy argument -- the problem of having multiple systems that perform the same work and how to partition problems so as to ensure your DIY project is doing meaningful work and thus getting the attention it needs.Go Back
Citation: 'We're not in the software business'. (2012). Retrieved Mon May 1 02:04:24 2017, from http://www.limsexpert.com/cgi-bin/bixchange/bixchange.cgi?pom=limsexpert3;iid=readMore;go=1347989780