If it wasn't so expensive to build bridges (and they could be built to span incredibly great distances) wouldn't we just build intercontinental roadways? Imagine a road that traverses the Atlantic. You could have rest stops and hotels every 50/100 kilometers. Hilton would triple its profits almost instantly as would virtually every petroleum company.
In software we see open source primarily as a way to guarantee freedom but its economic implications are undeniable. Like intercontinental roadways, open source makes it possible to build things that simply would not or could not exist due to cost. Getting people around the world to collaborate on a single system would cost millions and the risk conditions involved would make any analyst gag. But with open source it is all possible.
Open source helps build things that nobody even knows that they want yet.
But then, what about DIY LIMS? DIY LIMS is a philosophy for laboratory informatics development. At it's core it says this: 'it should not be any harder to construct a LIMS than it is to build a computer from store-bought parts.' Therefore DIY actually is an architectural mode. It dictates what the components you are building your system from should and should not be doing.
DIY LIMS Origins
DIY/patterns in LIMS were originally developed as a direct result of watching two laboratory heads try to figure out whether a particular implementation was 'correct.' At the end of conversation we all agreed that the lab promoting the implementation needed a way to describe what they had asked for but in a more straightforward terminology that could be understood by non-technical people (a pattern). Second, the would-be adopting laboratory could not simply throw out their methodology but rather wanted time to validate and evaluate the functionality against their workflows.
These things together led to the idea of using patterns to describe functionality and a long, at-will validation cycle for functionality for adopters. At the end however, this directly led to the DIY concept for LIMS as an architectural model. The adopters wanted to know what should happen if they accepted most of the system, but specifically wanted to leave a portion of it out. A cursory review of the system revealed that everything was haphazardly written (as is the case with most LIMS, even the commercial ones) so removing functionality was going to be just as expensive as writing brand new code.
Here the DIY concept was born as a solution. If the system had been written with a different architecture it would have been possible to pick and choose functionality rather than try to customize or configure it out.
The DIY idea virtually eliminates the need for lengthy LIMS purchasing cycles or requirements/specification reviews since the core, business critical functionality can be adopted immediately and other functionality added on an as-needed basis in the future. Today this is done via customization or via inclusion of vendor-provided modules. Customization involves opening, modifying, and potentially destabilizing the software. Vendors have been touting 'configuration' over customization as a way around this but that presupposes that needed functionality has been already conceptualized and included in the core system for your use. That is not always the case. That often leaves a vendor-supported module or customization as the last resort.
Poorly written modules can destabilize a system and often require system-wide modifications to support them. But they are a move in the right direction. If the entire system was a collection of independent modules the risk of destabilization drops significantly.
Why Care About Open Source Then?
Plainly, DIY promotes design and architecture over source code. But source code is still vitally important.
Think about the design for a bicycle. When bicycles were first produced there were scores of different designs and parts from one would not work with another. Today that is no longer the case. Today you can replace almost any bicycle part with ease with virtually no training and a minimum of tools. There is also no need to buy a wheel for a bicycle from its vendor. That is not by accident; it is by design.
Like the bicycle manufacturer, the DIY LIMS practitioner wants there to be standardization of almost all parts so that different manufacturers or purveyors can make them interchangeable. Where the open source practitioner says, 'ok, give me a system and I'll modify that' the DIY practitioner says, 'that system will be of less value than one that allows me to replace components with alternate ones as time/need/desire arises.' The DIY approach is faster, safer, and will cost far less in the long run.
The development of components to be used in DIY LIMS is best done in an open source setting. This allows different producers to see the core implementation and correct any mistakes that might have been missed. It gives others the ability to migrate the implementation toward a different set of patterns as they see fit. Without open source, on a whole, it just would not work. That doesn't mean that certain implementations could not be closed source -- just that it should generally be frowned upon and only used until an open source alternative is identified.
Citation: How DIY LIMS and Open Source Gel. (2014). Retrieved Mon May 1 02:04:33 2017, from http://www.limsexpert.com/cgi-bin/bixchange/bixchange.cgi?pom=limsexpert3;iid=readMore;go=1414855771