The idea of a learning curve is fairly well-accepted, that one makes progress in gaining skills at some rate that can be “steep”, where it takes a long time to gain much proficiency, or “gentle”, where a fair amount of proficiency is gained relatively quickly. Here, I want to propose the parallel idea of a software development curve.

I’m really excited to have been able to share some thoughts and stories through a recent RSE Stories podcast, and after being interviewed for this by Vanessa Sochat (which was a great experience; Vanessa is a good interviewer and a good editor), I realized that I left out one story I meant to tell, and decided to write it here.

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.

I’ve previously written about the concept of workflows, sets of independent tasks connected by data dependencies, being expressed either as data, for example, a Pegasus DAG or CWL document, or as code, for example, a Python program written in Parsl.

While preparing for a workshop that the URSSI project is hosting on software credit today, I started thinking again about a recent blog by Titus Brown, “Revisiting authorship, and JOSS software publications.” Titus says, “fundamentally, in order to nurture a diverse array of valuable scientific contributions, we need new models of publication with new models of authorship,” a statement with which I strongly agree, and in fact, part of the

This blog post is intended as companion text for a talk I gave at the September 2018 NumFOCUS Project Forum in in New York, though I also hope it stands on its own. To address software sustainability, it is important first to understand how the term sustainability is used more generally.  It’s most often used in the context of ecology, often specifically in the relationship between humans and the planet.