(Please cite this post as https://doi.org/10.59350/rjt2m-2hy19) A few things recently have made me think about how we support the core work of maintaining research software and supporting its users. I was interviewed by Georgia Iacovou for her report, “The state of the open source ecosystem &

This post is cross-posted from Upstream: https://doi.org/10.54900/zks0k-pe034 I recently attended the FORCE2024 conference at UCLA. I’m a member of the board of directors of FORCE11, the parent organization for the conference, and the co-located FORCE11 Scholarly Communications Institute (FSCI), which I was not able to attend this year but have taught at in the past.

(with contributions from Michelle Barker, Neil Chue Hong, Matthew Turk, Jeffrey Carver, Hannah Cohoon, and James Howison;

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.