Recent Features
| |||||||||||||
Ten simple rules for the open development of scientific softwareTen simple rules for the open development of scientific softwarePosted Dec 30, 2012 0:07 UTC (Sun) by oever (subscriber, #987)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
The fact that Tartini does not compile under current Debian shows that an application that was working fine with a previous version of the libraries stopped being compilable, let alone usable, because Debian has changed so much in just a few years that Tartini does not compile. Is that Tartini's fault or Debian? Should we expect researchers to keep software up to date with changes in compilers and available libraries? Tartini uses Qt4, a perfectly fine library as is Qt3 and Qt2. Yet, software that relies on Qt2 has a hard time working on a current Linux system.
(Log in to post comments)
Ten simple rules for the open development of scientific software Posted Dec 30, 2012 0:30 UTC (Sun) by dskoll (subscriber, #1630) [Link] The fact that Tartini does not compile under current Debian shows that an application that was working fine with a previous version of the libraries stopped being compilable, let alone usable, because Debian has changed so much in just a few years that Tartini does not compile. Is that Tartini's fault or Debian? Clearly, Tartini's. Debian is about the least bleeding-edge you can get with Linux. The build files for Tartini contain hard-coded paths to specific directories like /home/inferno/research/pitch/lib I've worked in both academia and industry and know that academic software is not often built with the thought of actually distributing it or maintaining it in mind. It's just an unfortunate fact.
Ten simple rules for the open development of scientific software Posted Dec 30, 2012 2:49 UTC (Sun) by yarikoptic (subscriber, #36795) [Link]
> ..., 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,
Want to read more on our (neuro.debian.net) position/experience -- you are welcome to read
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.
|
|||||||||||||