The latest Research Software Alliance (ReSA) newsletter includes the fact that: The 2018 European Commission report, Turning FAIR into Reality, concludes that FAIR digital objects (including software) need to be supported by metrics, incentives, skills and FAIR services that provide persistent identifiers, metadata specifications, stewardship and repositories, actionable policies and Output Management Plans.

I recently led the writing of a report on software sustainability and high-energy physics: https://arxiv.org/abs/2010.05102. This report effectively has three groups of authors, with each group listed in alphabetic order: Katz – Stewart, the organizers of the workshop, leaders of the analysis and summarization, and lead authors of the report; Assamagan – Sexton-Kennedy, speakers in the workshop and authors of sections of the report;

As I’ve been involved in the new FAIR for Research Software (FAIR4RS) activity (jointly run under FORCE11, RDA, and ReSA), I’ve been leading a subgroup looking at the FAIR (data) principles and thinking about how they can be applied to software. One of the things that has become clear to me is how fundamentally different software and data are, and the consequences this has on how software can be made FAIR.

Based on some recent experiences, I want to try to redefine cyberinfrastructure. While I think Craig Stewart’s 2010 definition is still useful, new thinking might also have benefits. Let’s start with the elements of cyberinfrastructure. At the most basic level, these elements are simply people and things.

As I’m getting ready for the first meeting of the Chan-Zuckerberg Initiative’s Essential Open Source Software for Science program, with grantees, advisors, funders, researchers, and industry partners, and with the goal “to identify shared needs and how funders might support these needs in the future”, I wonder how much software maintenance should cost, and how we might determine that answer.

About a month ago, I attended (thanks Sloan Foundation!) the Scientific Software Registry Collaboration Workshop, which had very interesting discussions. While there, I continued thinking about how software should be cited, focusing on open source. My thinking was certainly influenced by talking with Anita Bandrowski, Bryce Mecum, Shelley Stall, Katrina Fenlon, and Carly Robinson at the workshop.

While I’ve never been in an improv class, I really like the idea of saying “yes, and” as a way to move the activity forward. As others have also pointed out, this can work in business and research as well.

by Daniel S. Katz and Kenton McHenry We typically think of Research Software Engineers (RSEs) as working to support one or more researchers, either one-on-one or through a university’s centralised RSE group. We’ll call this the traditional RSE role, while being fully aware how ironic this phrase is. Simon Hettrick has used the following image, where “Here” indicates where the RSE fits between software engineering and research.

(a white paper for the 2019 Collegeville Workshop on Sustainable Scientific Software (CW3S19))

As some may know, the first image of a black hole was announced April 10. This quickly led to a lot of different institutions explaining how they were involved (e.g., my own University of Illinois), as well as a bunch of software projects explaining how their software was used (e.g., Matplotlib). Those of us concerned with open source research software and its sustainability are trying to raise the profile of such software in research.