Recently (19-20 September 2016), a group convened at a workshop in San Diego under the auspices of FORCE11 (and with funding from the Helmsley Trust) to work on understanding the Scholarly Commons, a scholarly communications ecosystem designed for 21st century scholarship across all scholarly fields. Since the Scholarly Commons doesn’t yet exist, the overall goal is to define and to bring it into existence.
While at WSSSPE4 discussing possible WSSSPE mission statements, the question of what software sustainability is has been raised.
I’m happy to announce that I’ve started a project with rOpenSci under their recent award from the Helmsley Foundation. My work with rOpenSci will focus on sustainability of the project itself. Sustainability can be defined as having the resources to do the necessary work to continue and grow rOpenSci. This is one of the most difficult challenges for rOpenSci and for many other research software projects.
After a number of general discussions in the research communication community, mostly focused on software citation, and then a few separate discussions with Anita Bandrowski and Martin Fenner, it’s become clear to me that we need something like a group (perhaps hierarchical) object identifier (GROUPID), which is somewhat different than a DOI, or at least different than how DOIs are commonly used today.
The research community is moving towards the acceptance that data and software are both essential parts of understanding and reproducing many research (e.g., science, engineering, humanities) outcomes (e.g., papers, books, presentations) and are themselves valuable outputs that can capture and explain knowledge. However, we don’t currently have a good set of practices to support reuse and sharing of data and software.
In a series of tweets (starting with one from @dimazest and including some from @turingfan, @Iza_Romanowska, and @CIRCA_StAndrews), it’s become apparent that we don’t have a standard way of providing attribution (e.g., citations, acknowledgements, dependencies) within software like we do in papers, where we have standard acknowledgement and reference sections, and for at least the reference section, a standard practice
In a recent meeting, there was some discussion about a potential workshop recommendation that funding agencies should offer relatively small grants that would just be used for maintaining existing software, but not doing any new development. I had very mixed feelings when I heard this, and decided I would write up my thoughts and see what others felt too.
I am writing to point out an interesting experiment that’s started up in the ACM Transactions on Mathematical Software (TOMS) computational journal. There’s an editorial by Mike Heroux that explains the process. In brief, TOMS has created a “Replicated Computational Results (RCR)” review process, which is really a designation saying that the computational results published in an article are replicable.
Since we often forget what reproducibility means, particularly in the context of repeatability and replicability, I think it is worth highlighting this slide, taken from a talk by Neil Chue Hong, “Open Software for Open Science,” Young Alliance Against Cancer, 22-23 May 2015, Copenhagen, http://dx.doi.org/10.6084/m9.figshare.1424440 Note Since the Reproducible Scientific Computing blog created and curated by Doug
This post is inspired by a post from C. Titus Brown, where Titus asked “What do you think about the term & practice of ‘hardening software’?” and a few of us used comments to discuss the concept.