Ten simple rules for the open development of scientific software [LWN.net]

Ten simple rules for the open development of scientific software

Posted Dec 30, 2012 2:49 UTC (Sun) by yarikoptic (subscriber, #36795)
In reply to: Ten simple rules for the open development of scientific software by dskoll
Parent article: Ten simple rules for the open development of scientific software

> ..., Debian, the least bleeding-edge you can get with Linux

I beg a pardon... Debian is not only Debian stable -- there is also testing, unstable and even experimental. With unstable+experimental you might be as close to being bleeding as possible, while maintaining still usable and relatively stable system.

But this example is indeed a very nice to point out that source code itself, although a huge step forward, is not all what is needed for proper scientific methods dissemination since building/deploying of the "code" might be quite involved at times. Happened authors created proper Debian packages, uploaded them to Debian unstable (the entry point for new packages into Debian) -- it would have resolved many of those benefits others have mentioned:

-The "code" could immediately being used by Debian (and thus its >130 derivatives) users,
-its hardware platform agnosticism would be verified by building across >10 of those Debian supports
- happen there would be unittests ran at build-time -- at least some aspects of hardware platform "reproducibility" would also come "for free"
- longevity of such "code" would be in years due to inclusion/maintenance in Debian stable later on,

Want to read more on our (neuro.debian.net) position/experience -- you are welcome to read
http://www.frontiersin.org/Neuroinformatics/10.3389/fninf...
Open is not enough. Let’s take the next step: an integrated, community-driven computing platform for neuroscience

(Log in to post comments)

Ten simple rules for the open development of scientific software

Posted Jan 4, 2013 20:16 UTC (Fri) by pboddie (subscriber, #50784) [Link]

What you and others are saying is that what's missing is the software engineering. People can write code to consume and produce data in order to demonstrate something, get published, and so on, but if others are to benefit from that code in any convenient way, there's the usual amount of software engineering required to achieve this.

Some might dispute whether sharing the code is necessary, but if any algorithm is going to be described in detail - and I doubt that they are described in sufficient detail, especially in disciplines other than pure computer science - then it would be better if the code were available, better still if it could be conveniently used in order to rule out coincidental hardware- or infrastructure-related effects, and even better still if it were well-structured and well-documented. Once again, software engineering is the missing ingredient.

Unfortunately, the funding in many environments probably doesn't cover anything beyond getting something working and getting a paper out the door (and thus attracting more funding). After all, there's always another Web service to use or another bundle of Java class files to stuff into the JVM to massage one's data and produce a "result", and nobody's asking for money, so what's the problem? Right? That's probably the prevailing attitude that needs changing.