According to some recent articles in the science technology press, ELNs are a growing market. For example, a 2006-2007 article at Scientific Computing estimated that the market was about 50 million USD in 2005 and was growing at 20% to 30% per year. This makes a great deal of sense when we take into account the growing complexity of science and the massive amount of data that is collected and needs to be analyzed. This is true especially in the life sciences, and several of the commercial ELN offerings are targeted primarily at that market (e.g., CERF by Rescentris, Inc.).
What does this mean for non-commercial ELNs, however? And what does it mean for academic institutions who desire to prepare their students for a future where ELNs will be more and more common place? Of course, it is obvious from this website where we think at least one good solution to these questions lie. But let's take a step back and see why we have chosen the particular solution that is presented on this website. What are the alternatives? What are the criteria to use in developing an ELN appropriate for an academic setting?
What are the criteria to use in developing an ELN appropriate for an academic setting?
Let's tackle the last question first and then see what kind of alternatives can satisfy our criteria. Some of the main criteria are as follows.
So using these criteria, we can narrow our choices. Criteria 3 suggests that the choice should be a popular open source platform. Criteria 4 suggests that it should run primarily on the web versus on the desktop. And criteria 2 suggests that it be fairly mature or robust so that people will have developed add-on components that can be re-purposed for scientific purposes. Criteria 5 suggests the use of a scripting language versus the use of Java, C or C++, at least for the mainstream of web developers.
Ruby on Rails has the advantage of being written in Ruby, which is a relatively elegant scripting language and growing in its use. The framework itself lends to great productivity as well because of its standardized approaches. The myExperiment project has taken this approach.
Django has the advantage of being written in Python, which is also a relatively elegant scripting language with an even larger support community than has Ruby. It also shows itself to run at about twice the speed of Ruby or PHP and can be run simply on the desktop as well as the web in a straightforward manner. There are also numerous Python modules written for scientific purposes on the desktop that can be repurposed for the web as needed. However, Django itself is a web framework instead of a CMS. And for the CMS platforms built upon Django, then there do not seem to yet be a mature set of modules available "out of the box" for many capabilities.
Plone is probably the most mature of the CMS platforms built with Python, and is relatively easy to set up as long as one has full access to server configurations. However, like Django, it is not as widely supported by internet service providers and thus becomes less available in many cases.
Joomla is a popular web framework also, and has thousands of add-on modules and s ome very nice looking templates available.
In the end, though, we chose Drupal because of the following reasons.
So that is some of the reasoning that went into the choice of the Drupal platform for our ELN. We continue to be happy with the choice, but also are interested in any feedback, pro or con.