(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

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.