(with contributions from Michelle Barker, Neil Chue Hong, Matthew Turk, Jeffrey Carver, Hannah Cohoon, and James Howison) Ok, this title is a bit of a teaser, but what I really mean is that while we can say that research software has been sustained, we can’t predict with certainty that it will be sustained in the future, or even fully know what factors we should use to make an uncertain prediction.

Make-or-buy decisions are common in business and research. They often involve an analysis of the pros and cons of creating something (e.g., a physical item, software, a service) vs. acquiring it from someone else. Factors that are considered can include cost, trust in suppliers, and current internal knowledge and skills as well as desired future knowledge and skills.

Research software is an essential part of most research today, as I’ve written about before. One of the important models that allows people to develop and maintain it is grant funding: someone proposes building and/or maintaining software to a funder as an effort that aligns with the funder’s mission and programs.

When thinking about a group adding a new person, we often think that while the group will benefit from adding the new person in the long run, there is a cost to the group in the initial period.

While at the Chan-Zuckerberg Initiative’s Open Science 2022 Annual Meeting a couple of weeks ago, I was struck by a comment from Demetris Cheatham about how she hadn’t known about the scientific open-source community until she was introduced to it fairly recently, even though she has a huge amount of experience with the larger open-source community. This was especially confounding when she shared that she realized upon

(by Daniel S. Katz and Tom Honeyman) There are a number of challenges in rewarding scholars for their work in software, including the fact that both software itself and the idea of it being of scholarly value are relatively new, particularly given the centuries of experience we have with journals and the Humboldtian university model.

[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.

(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.

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.