This is my second day perusing the open source Open-LIMS alpha release (version 0.3.9.6-2). Thanks to a response from the project maintainer I figured out how to build the database (only the latest version has a backup file...see the INSTALL.txt file for details). However, after getting things up and running I found several bugs in the release and no patches. My instinct was to look for the latest version of the source code but there is not any public code repository. My next step was to create a ticket on the open-lims.org website. The ticket was quickly closed and flagged as a duplicate. Indeed the problem was noted three months ago in ticket #6. Realizing that this project is taking forever to fix minor bugs I think it is high time for a quick review of where this project should rank as an open source project.
Here's the link again to one online source for this new open source rating system. I do not totally agree with this rating system, but it is useful for identifying some of the problems one can expect to find with an open source project. You can find definitions to some of the terms on that page as well. Ok, here it goes:
- Binary Components (Score: -10): The database for the system is released as a binary dump which will likely fail on older versions of PostgreSQL. It is just as easy to use pg_dump to get an ASCII version (although not as small).
- Mailing List (Score: +10)
- Bug Tracking (Score: +4)
- Patch Tracking(Score: 0). There is none.
- Beta Release Frequency - From this page it appears that there are only two alpha/beta releases per year, so this means min(5,1/6*5) == 0.83, which I'll round up to a 1.
The use of a PostgreSQL backup instead of an actual SQL file for database creation is a major drawback. Backups are small and nice but they live up to their namesake -- they are for backing up a particular database version, not for source distribution.
The lack of a patch tracking system is going to hurt adoption and will waste time. I personally spent (wasted) hours today trying to figure out why my version of the software was not working when the problem had already been identified months ago. If you are going to release software then please patch your releases when you encounter problems with that specific version. Saying that you will fix a debilitating problem in a subsequent release tells reviewers and early adopters to take a proverbial hike.
The presence of a mailing list is great but this is negated by an impossibly slow release cycle for non-production code. This project, in my opinion, is being hampered by a lack of an SCM system, patches, and an inclusive attitude for external developers.Go Back
Citation: Scoring Open-LIMS. (2011). Retrieved Wed Mar 22 22:17:39 2017, from http://www.limsexpert.com/cgi-bin/bixchange/bixchange.cgi?pom=limsexpert3;iid=readMore;go=1305075855