Running June-Aug ’18 

Margaret Hamilton standing next to the navigation software that she and her MIT team produced for the Apollo Project. 1 Jan 1969, Draper Laboratory; restored by Adam Cuerden, public domain, source Wikimedia Commons

Get in touch if you have a contribution or question. Contact Simon Worthington, Editor, | DM @Gen_R_ | Chat on Gitter

About research software citation

The submission of software as a research output is becoming more common. As a result a number of areas need addressing in research workflows and in the research life cycle of a software project to improve the use of research software.

Two areas for such improvement in the theme of ‘software citation’ in terms of Generation R’s editorial remit of taking ‘a needs based approach to researchers’ are:

  • the use of software and 
  • the development of software.

The benefits can be,

  • that scientific knowledge systems and experiments using research software can be more reliably replicated and built upon more easily, and
  • in the area of software development itself — of making software — can be helped, and increased discovery and reuse.

In this editorial theme of ‘software citation’ we want to look at what initiatives and projects are working on these issues of software citation. We also want to look at practical steps that a variety of users and public institutions can take to improve their systems for software citation. Our initial use cases are:

  1. the software maker or contributor,
  2. the researcher citing the software, and
  3. the researcher literature reader wanting to reuse the software cited.

Pointing to the near future: Open Science(fiction)

Software citation and versioning systems go hand in hand. With further integration we should end up with much better software research infrastructures, where software can be reliably retrieved, and run in real-time.

Advanced software maintenance systems make use of systems for version control (Git) and dependency management (Debian Packaging). The effects of these two types of technologies results in the ability to have any version in a software’s release history being automatically available, and be able to run the software where applicable. With the recent addition of technologies such as continuous integration (Travis CI) software can be validated to be in good working order and so ensure it is fit to be used.

Building on these three technologies, in the not too distant future, the working environment for software R&D will offer much greater sustainability. Related examples are a project like Binder for republishing Jupyter notebooks, where software and data sets can be run live in the browser.

The Editor. Generation R – Issue #1, June-August 2018, ISSN 2512-3815

How we organize themes

Our themes are run over a flexible time period, but as default for six weeks, and then periodically we will revisit a theme. For this initial theme we will start early June and carry on over June and July. Our editorial approach is to support the Open Science community in its ongoing work in a given area. We do this by carrying short blog posts, and by maintaining a ‘Notebook’ engaging in discourse and carry resource documentation to partner learning resources.

  • Themes are set in consultation between: the editor,our advisory board, stakeholders, and the Open Science community
  • We announce themes in advance
  • To develop a theme we collate key information prior to release on our Notebook
    Run blog posts and other material for a scheduled time-window
  • Finally we use our Notebook to transfer findings to partners learning resources and informational projects in the form of: MOOC contributions, recommendations, how-tos, and literature lists, etc.