Biomedical Engineering Reference
In-Depth Information
14.5
NOTE ON ASSESSING OPEN - SOURCE SOFTWARE
It is said that there is no such thing as a free lunch, but in the case of software
it is probably more apt to say that the price of freedom is vigilance. The most
important aspect of open-source software is not that it is free but that it is
“open,” which gives you the ability to make your own assessment of the cor-
rectness and stability of the tools you use in your research. Even if you can
not really understand the code, you can read the comments in the code to
understand the intent of the author. If there are no comments in the code,
beware—this is indicative of a throwaway mindset and not a hopeful sign for
using the code outside the environment in which it was developed.
Here are some things to think about when assessing open-source software:
1.
Software Generality—Are You Working the Same Problem as the
Author?
Nobody sets out to write bad software, but in the research world
authors do generally set out to write pragmatic software solutions which are
just good enough to complete the task at hand. Beware of code which assumes
certain truths about equipment or lab procedures which may not match your
situation. How certain are you that there are no implicit assumptions that may
apply to the author's experimental setup but not your own?
2.
Software Stability—Is the Software Rotting? Can Anyone Tell?
Even
when software source code is untouched, the world around it changes and
eventually the software does not work the way it needs to: “Software rots”
goes the adage. Input formats are revised, feature requirements evolve with
newer technologies, operating systems change, and eventually software main-
tenance is required. This is when things get dicey: it is easy to unknowingly
break something while improving something else, especially in code written
with the kind of ad hoc fl air often found in research-grade software. Many, if
not most, writers of open-source biological software are biologists and physi-
cists trying to get a paper out, as opposed to engineers and computer scientists
trained (and given time) to write software designed for maintainability and
testing. Look at the source code directory tree for your software of choice—
Are there any fi les in there with a name like “test”? If so, it is a hopeful sign.
If not, how certain are you that the code you are trusting to analyze your data
remains correct as it gets stretched in new directions? Exceptions to this gen-
eralization about lack of ongoing regression testing do exist: Projects such as
LabKey Server [11], Skyline [12], and ProteoWizard [7] are very test focused
and thus very stable, but in general due diligence is called for.
3.
License Terms—Can I Use This the Way I Want To?
Open - source soft-
ware authors still have full copyright and usually specify the license terms
under which others may use their work. Some licenses are quite generous: The
Apache license, for example, does not place any restrictions on how you use
the code beyond acknowledging the authors. Other licenses may prohibit or
demand a fee for commercial use. Others may impose their terms on any
software you wish to combine with—GPL is the prime example of a “viral”
license—which can be an issue for would-be commercial adopters of things
Search WWH ::
Custom Search