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.

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