Dying Gracefully

(Ref Id: 1417019639)

Dealing with Death

Some projects appear dead when in fact they are used daily. I have BixChange which, just by looking at the online download statistics, is a dead project except that I use software built on top of this each and every day almost without fail. So the download statistics are not a definitive indicator that a project is dead. It might be a fair indicator that the author(s) consider it to be stable and only occasionally in need of updating.

Ways to Wake Up

For one thing make sure your releases match the underlying code. So I made a package out of my code and have it available as the download on Sourceforge but in fact the underlying code base doesn't match it. This is the same thing that Open-LIMS appears to be doing with Sourceforge and github. They maintain the sources on github and the official releases are on Sourceforge without any indication as to when those changes are going into the next release. You have to develop a release schedule and stick to it the best you can. Be transparent and honest about possibly missing a release date. Users will forgive you or, better, they might offer to pitch in and help.

Sometimes what should drive a new release is some kind of change in the code dependencies. If you included a third-party module you have to regularly check to see if there is a newer version out there and if the change made is a meaningful one. It may have been to fix a bug or to patch a security problem in which case it may mean that you have to add the new module, re-run your tests, and release a new version of your software. When you see a software package that has not been released for years it is a sign that this is no longer occurring.

Although it can be annoying and painful you have to periodically rerun your tests on a variety of operating systems (unless you restricted to a single system) and, if your system is browser-based, on a host of different, popular browsers. Problems here can prompt another release if only to fix a bug.

If you do not do these things people will think your codebase/framework/project is dead and will resort to potentially building their own systems without it.

Don't Die, Become Mulch

In my case I originally thought that releasing a framework for Perl CGI development was stupid but I kept running into small systems that were built on top of many of the same technologies like Sierra LIMS, ArrayPipeline, and the Workflow Information Storage Toolkit. With the exception of Sierra these other systems are actually toolkits in themselves.

It is actually not a terrible thing to work on a system for a long time in-house and then decide to open-source it. However, if you do not follow some of the Open Source development procedures for projects it is going to be tantamount to a code dump. In order to avoid this you'll need to commit to offering at least a project web page online, some kind of bug tracking, a project roadmap, contributor coding guidelines (optional), up-to-date contact information for developers/project management, etc.

At the time of this writing the only one of these systems under active development that has a home is Sierra (there are updates as late as Q1 2014 in the code base). That means that the right thing to do might be to develop a unified LIMS framework and then fork Sierra into it. The other systems effectively become 'mulch.'

Process

One of the reasons why people hold so closely to dying frameworks is that there are important things built on top of it. There is a pathway to freedom however but it requires building an intermediate layer.

An intermediate layer between the module and the framework is needed to handle the shift in API so as to minimize the number of changes to port over. So if a current module built on top of an existing framework makes a certain call to a certain class then a dummy class will probably have to be built into this intermediate layer that does things the standard way but perhaps adds a deprecation message into the logs.

Toward Unity

At some point, if we keep doing this with a roadmap toward LIMS interoperability, we might actually achieve modular DIY LIMS that work together despite language and architectural differences.

Go Back

Citation: Dying Gracefully. (2014). Retrieved Thu Sep 21 04:29:27 2017, from http://www.limsexpert.com/cgi-bin/bixchange/bixchange.cgi?pom=limsexpert3;iid=readMore;go=1417019639