Go read this wonderful manifesto over at arXiv: Astronomical Software Wants To Be Free: A Manifesto by Weiner et al. The authors talk about some of the barriers to astronimical software development that are true in all scientific fields. The chief barrier they see is that there are no incentives (and are some real disincentives) for authors to release software and documentation to other users. The recommendations are great (modified here only to include all scientific fields):
- We should create an open central repository location at which authors can release software and
documentation. - Software release should be an integral and funded part of projects.
- Software release should become an integral part of the publication process.
- The barriers to publication of methods and descriptive papers should be lower.
- Programming, statistics and data analysis should be an integral part of the curriculum.
- There should be more opportunities to fund grass-roots software projects of use to the wider community.
- We should develop institutional support for science programs that attract and support talented scientists who generate software for public release.
The whole thing is a great read. Check it out!
I think these are also key points:
* Software releases also rarely garner wide recognition, and without an accompanying paper to cite, the work cannot be paid back in citation currency.
* Additionally, emphasizing one’s work on software or publishing methods papers carries a risk of being perceived as a programmer ï¬rst and scientist second, falling on the wrong side of the technician/scientist divide.
I have been told to be sure to publish “real chemistry” more, even though I want to get “citation currency” for open projects. After all, without publications or citations, I can’t get grant support for these activities either.
So is the trick to get grants for “real research” that have “broader impacts” in software development?
Geoff,
The open science coding projects I’ve been involved with (Jmol, OOPSE) have never been funded and have piggy-backed on other funded research. I’ve been lucky to be working on method development which easily translates into functional code. However, making this code ‘friendly’ and useful to the rest of the world has largely been a labor of love.
Yes, you should publish citable papers summarizing your work, although some of the most used tools in science (i.e. plotting and visualization packages) are never cited by the people who use them even if there are papers to be cited. CVs and tenure packets should include a section on software contributed to the community directly underneath the publication section.
Also, open projects should definitely be part of broader impact statements. My own projects (openscience.org, OOPSE) certainly were highlighted in my most recent proposal. When I’m reviewing proposals, I also look specifically for some indication that the code developed for the research won’t be lost to the community when the work is complete, and I make sure to voice my opinion in the review itself. If more of us did this, I think it would become acceptable for proposals to mention open-{source,data,notebook} as an integral portion of the funded research.
Pingback: Unilever Centre for Molecular Informatics, Cambridge - Jim Downing » Blog Archive » The Great Divide : A Rant
Pingback: A semana nos arXivs… « Ars Physica