[Note: In December 2021, I decided to write down my experiences with the founding of US-RSE. Vanessa Sochat convinced me that it would make more sense for all interested US-RSE members to write a collective post, which we have now done as https://us-rse.org/2022-02-06-a-brief-history-of-usrse/. So much of this blog post overlaps that one, but some of it doesn’t, and I’m publishing this as a record of my recollection.

While I was a program director at NSF, I led the SI2 (Software Infrastructure for Sustained Innovation) program that had been created by Manish Parashar and Abani Patra, then was led by Gabrielle Allen, before it was my turn to shape it and lead it for about four years, from 2012 to 2016. This program initially funded projects that developed and maintained software, as well as projects that planned and built community institutes around software.

I recently attended the hybrid SC21 conference in person, as one of the about 3000 in-person attendees, along with several thousand virtual attendees. (I don’t know the exact numbers, but in the past, an SC conference would have about 12000 attendees in-person.) In December, I’ll be attending the hybrid AGU Fall meeting remotely.

(by Daniel S. Katz, Kenton McHenry, Jong S. Lee) (in conjunction with a talk [slides, video] presented 28 September 2021 at SeptembRSE) Over the past nine years there has been growing acceptance of the role of Research Software Engineers (RSEs) and the value they bring to projects.

I’ve been watching and participating in FAIR work for a while, first in terms of data, and more recently in research software, workflows, and machine learning models.

While on a call today for the ACM Emerging Interest Group on Reproducibility and Replicability, I realized that for computational reproducibility to become pervasive, we need to solve a scalability problem. Today, a lot of computational reproducibility is checked by hand, whether this is in terms of artifact evaluation in a conference or a paper, or with post-publication checks.

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.

by Daniel S. Katz and Michelle Barker Most researchers and policymakers support the idea of making research, and specifically research outputs, findable, accessible, interoperably, and reusable (FAIR). The concept of FAIR has been well-developed for research data, but this is not the case for all research products.

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.

I’m excited by this paper: “Recognizing the value of software: a software citation guide [version 2; peer review: 2 approved]” and want to provide some context here (also in a thread of tweets). This is work by the Journals Task Force, which I lead with a lot of help from Shelley Stall. It’s part of the FORCE11 Software Citation Implementation Working Group, which I co-lead with Neil Chue Hong and Martin Fenner.