Ten simple rules for the open development of scientific software
Posted Dec 30, 2012 0:00 UTC (Sun) by
man_ls (subscriber, #15091)
In reply to:
Ten simple rules for the open development of scientific software by oever
Parent article:
Ten simple rules for the open development of scientific software
Reproducibility in software is a big challenge. Churn in FOSS libraries is large. Making sure software runs exactly as it did originally is very hard. This is due to the way software development and distribution currently works.
Your comment is a good argument to keep scientific software as simple as possible. In essence there should be a few data files and a few source code files in a standard language, that generate a binary; both sets of files should be under version control. The binary then takes the data files and produces a new file with results, which can then be plotted or manipulated as desired. This is specially important for all charts, graphics and tabulated data on an article.
There are a few issues in this scheme:
- Input data should be fully documented: origin, conditions and other constraints.
- The language used should also be specified. It should be a well-known standard, and ideally a language that maintains backwards compatibility so results can be reproduced in the future. (This rules out e.g. Python.)
- If binary generation goes beyond compiling a few source files, a standard mechanism such as make should be used.
- Use of libraries should be reduced to a minimum, and the version for each one should be specified in the documentation (or added to version control).
But it should be workable.
(
Log in to post comments)