DIY LIMS should not be considered a complete, out-of-the-box solution. Complete solutions are ones that you buy. You plunk down some bucks, some series of sales and technical people show up to your business; there's this talk about licenses/cost/ROI/etc.; they install something or give you access to a system on remote servers somewhere and you are in business. In contrast, when rummaging around the online code bins for something DIY you are going to find a few solutions that load and appear to do a few things but otherwise are missing features, have bugs, and generally need a lot of TLC (tender loving care). This guide will help you decide whether to spend the time/energy on such a solution.
The traditional way to deal with the LIMS problem is to hire somebody to do the hard work for you, but in DIY you are probably dealing with limited resources or you have a need to fulfill your burning desire to hack code. In either case, support is not going to be easy to find and oftentimes you are going to be on your own. You want to have something that can get up and running in very short order, with minimal effort, yet allows for change and customization to fit your specific needs. This website has extensively discussed licensing so that should no longer be a mystery to you.
This leaves some other things you should look for when evaluating an open source LIMS tool. Here are a few pointers:
- Check licensing. It should be GPL compatible and should be code complete. This means that all of the source code should be available to you.
- Check code quality.One of the first things to look at is error handling and coded tests. The more of it you see the more you can assume that the solution is in a polished state. Otherwise, take a look at the code structure. It should conform to the standards of the language and/or environment. You'll probably have to do some digging to identify if what you are looking at conforms to standards. You might also try and ask a developer for a professional opinion.
- Test setup time. Run through the process of setting up the software a few times (install it, remove it, and then reinstall it again). If that takes an inordinate amount of time you might reconsider using the solution.
- Verify extensibility. Look for places that the original developers intended for extension of the original functionality. If it is missing that means you will have to make a change to the core solution in order to make it do something different. When the next release comes out their changes will break your customizations.
- Check for separation of concerns. Graphical interface user (GUI) objects really should not contain much in the way of logical code. That is, they should contain whatever is necessary to facilitate interacting with the user and little else. The business logic should be elsewhere, preferably in separate packages/classes.
- Check for last updated date. Code has to be periodically updated for security and bug fixes. Code that has not been updated for years can be a sign of trouble.
- Check for dependence on outdated toolkits/frameworks. In an effort to save time developers often resort to using frameworks or toolkits. Over time the toolkit developers upgrade the toolkit and projects depending upon it should move with them. Check the toolkit developer's website to see whether the differences between your version and the latest and greatest are significant. If they are consider attempting to upgrade to the latest (this option might be painful); otherwise move on.
Citation: DIY Evaluation Process. (2013). Retrieved Wed Mar 22 22:15:25 2017, from http://www.limsexpert.com/cgi-bin/bixchange/bixchange.cgi?pom=limsexpert3;iid=readMore;go=1363288315