4 ms·

I noticed this paragraph about code to do this analysis: "Code availability. The numerical code has been developed with a dedicated application to the DAMP

I noticed this paragraph about code to do this analysis: "Code availability. The numerical code has been developed with a dedicated application to the DAMPE data analysis. Due to the uniqueness of the DAMPE design and the complexity in- volved in the data analysis, the software package has limited application to the relevant community. We have opted not to make the code public." I'm just an IT guy, and not familiar with how disciplines distribute source-code for this type of analysis, but is this approach common? what does "...limited application" mean here and why not release the code?

shakna 9y ago
It's frustrating but normal not to release code. It makes it easier to release further papers, with less work. Limited application means, "this is our work, all rewards should go to us", preventing others from doing any further research, so no one can "beat them to the punch", so to speak. However, on the other side, it does also prevent checking results accurately.
lsh 9y ago
I'm a tech, not an academic, but I see it as part of the broader problem of science reproducibility. Software plays a huge huge part in modern science publishing and, in the case of data derived using proprietary software, it's expected we just trust the results - that the software is infallible. The comment "We have opted not to make the code public." really gets my goat, but is probably less because they sampled community opinion and found it wanting but more because it's just plain inconvenient or unknown how to publish software. Authors are not actively discouraged from publishing details about the software used (in journals in general) or including copies in the supplementing files, but the process typically has the editors (who guide the authors through the submission process) paring back the submission to just bog standard and familiar media types: image, audio, video, pdf, etc that are known quantities and can be nicely formatted in the final pdf. My small contribution to combating this has been encouraging our editors at eLife to be alert to authors using bespoke or modified software and capturing that software at a specific revision at the time of publication (https://github.com/elifesciences-publications https://github.com/elifesciences-publications) and making sure it meets some basic criteria, like being openly licensed. I'm hoping this effort will help resist general entropy and bit-rot, software moving on or getting lost, licence changes and the overall mandate of eLife to improve science publishing, which means reproducible results and software amenable to audit.

shakna 9y ago

It's frustrating but normal not to release code. It makes it easier to release further papers, with less work. Limited application means, "this is our work, all rewards should go to us", preventing others from doing any further research, so no one can "beat them to the punch", so to speak. However, on the other side, it does also prevent checking results accurately.

lsh 9y ago

I'm a tech, not an academic, but I see it as part of the broader problem of science reproducibility. Software plays a huge huge part in modern science publishing and, in the case of data derived using proprietary software, it's expected we just trust the results - that the software is infallible. The comment "We have opted not to make the code public." really gets my goat, but is probably less because they sampled community opinion and found it wanting but more because it's just plain inconvenient or unknown how to publish software. Authors are not actively discouraged from publishing details about the software used (in journals in general) or including copies in the supplementing files, but the process typically has the editors (who guide the authors through the submission process) paring back the submission to just bog standard and familiar media types: image, audio, video, pdf, etc that are known quantities and can be nicely formatted in the final pdf. My small contribution to combating this has been encouraging our editors at eLife to be alert to authors using bespoke or modified software and capturing that software at a specific revision at the time of publication (https://github.com/elifesciences-publications https://github.com/elifesciences-publications) and making sure it meets some basic criteria, like being openly licensed. I'm hoping this effort will help resist general entropy and bit-rot, software moving on or getting lost, licence changes and the overall mandate of eLife to improve science publishing, which means reproducible results and software amenable to audit.