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.

I’m writing this blog post in preparation for a contribution to the upcoming RDA Plenary 19 session “BoF: Sharing code that supports research articles: is it time to align goals and publisher policies?” at 0030 UTC on 23 June. I want to talk about how and why software (code) is shared.

I’m very pleased to see that the Netherlands group working on “Software Management Plans: Towards national guidelines” has released a draft set of guidelines for community consultation (through 20 June 2022) and is organizing a workshop on 9 June to test and discuss the guidelines with use cases from the research community: https://www.eventbrite.com/e/software-that-makes-you-proud-using-smps-tickets-341888165707.

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

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.

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.