Making the Invisible Visible
Why Research Software Needs a Sustainable Future
For those of you who have joined my readership recently (by the way, I just surpassed 400 readers, can you believe it?), you’ve likely seen me deep in the weeds of AI ethics and the shifting trust in digital systems. But today, I’m returning to one of my foundational passions: the health and future of open source software (OSS).
Last August, I spent a day in Lower Manhattan at a workshop that felt like a glimpse into the big picture of how we produce knowledge today. Hosted by Ithaka S+R and the Apereo Foundation, the Sustaining Open Source Software in the Research Enterprise (SOSSRE) workshop brought together about 40 of us—a mix of open-source lifers, university administrators, research software engineers (RSEs), and funders. For many of us, it was a rare opportunity to engage with one another outside our typical silos, and it served as a powerful reminder that the people who make open source work come from incredibly diverse professional and personal backgrounds.
The goal of the workshop was ambitious: to stop talking about open-source sustainability as an abstract problem and start finding practical, scalable solutions for the software that powers modern research.
As the formal report released today points out, we’ve spent the last twenty years normalizing Open Access publishing and the last ten years making data sharing a standard practice. Yet, the code, standards, and technology that gather, generate, and validate that research are often left out of the conversation.
The Day’s Structure
The day started with an opening plenary that, to my delight, included all women, except for the moderator:
Patrick Masson, Executive Director, The Apereo Foundation (moderator)
Cat Allman, VP, Open Source, Digital Science
Dr. Karmen Condic-Jurkic, Executive Director, Open Molecular Software Foundation
Clare Dillon, Community Lead, CURIOSS
Dr. Allison Randal, Senior Researcher, Capabilities Limited
During the conversation, Cat Allman (who, like me, likes to craft with yarn during meetings) offered a metaphor that underscored why we need a nuanced approach to OSS: some software is built to be a hammer, a tool meant to be shared, reused, and passed down. But some research software is legit a Q-tip, purpose-built for a single person or a specific, one-off problem. As Cat noted:
You don’t reuse Q-tips.
Definitely the best quote from the whole workshop.
We spent the rest of the morning defining the challenges across four dimensions:
Motivational: Why do people do this work (and how do we keep them doing it)?
Infrastructural: How do we fund and maintain the “invisible” utilities of the digital age?
Archival: How do we ensure code is citable and preserved as part of the scholarly record?
Relational: How do we manage the communities and people behind the code?
In the afternoon, we transitioned from high-level definitions to actionable solutions. The group distilled the morning’s discussions into five specific, high-priority challenges that we then “solved” through a series of lightning rounds and mock grant proposals:
Defining the Value Proposition: How do we convince universities that prioritizing open-source research software (OSRS) is central to their mission?
Tracking Usage: How can we accurately identify who is using—or could be using—an OSRS product when the current ecosystem is so frictionless (and therefore invisible)?
Overcoming Cultural Barriers: How do we shift researcher culture to value “openness” and software maintenance as much as traditional publications?
Assigning Responsibility: Who should actually be responsible for sustaining this code—the project team, the institution, or the broader research enterprise?
Identifying Extra-Institutional Support: What kind of external leadership, policy, or funding models are needed to shore up the entire ecosystem?
It was energizing and a reminder of the communal solutions we can identify by diversifying our viewpoints and forcing ourselves to move past “this is hard” to “here is how we fix it.”
My Takeaways vs. The Report
Last August, I shared four key takeaways from the workshop. Reading the formal report today, I was glad to see I wasn’t the only one who found those takeaways valuable. Here is how my original takeaways compare to the report’s deeper analysis.
Takeaway #1: Open Source Software is More Than Code
My Original Thought: We need to stop framing sustainability as just a “developer happiness” problem. It takes an entire ecosystem—quality assurance, product managers, designers, and administrators—to make software thrive.
The Report’s Finding & Recommendation: The report focuses on Relational Sustainability, which emphasizes the management of people and communities. It highlights the routine tasks (maintenance, documentation, and coordination) that often get overlooked because they aren’t enjoyable for volunteers or profitable for researchers. To address this gap, the report directly tackles the afternoon challenges of Overcoming Cultural Barriers and Assigning Responsibility by proposing a systems approach that leverages student labor across various disciplines—not just in CS but also in art, marketing, and business—to meet the non-technical labor needs of software development. Additionally, it recommends that institutions professionalize roles such as Community Managers and Research Software Engineers (RSEs) by establishing stable, secure career paths. It also urges funders to explicitly approve grants for these non-technical roles and calls on scholarly societies to build communities of practice that provide peer support for those managing the social complexities of software leadership. Finally, the report specifically suggests that libraries should take the lead in holding and indexing archives of retired OSRS projects, ensuring they remain part of the citable scholarly record even after the community no longer exists.
Takeaway #2: Open Source is Not a Monolith
My Original Thought: Open source is a patchwork of sub-communities with different norms. What works for a repository system like Fedora might not work for a learning management system like Sakai.
The Report’s Finding & Recommendation: At its heart, Motivational Sustainability focuses on the incentives that drive or stall software production. By distinguishing between foundational “hammer” tools and niche, purpose-built “Q-tip” projects, the report calls for a new standard in OSRS classification. This right-sizing approach helps us normalize the retirement and archiving of software that has served its purpose. Crucially, the report highlights a Value Proposition Paradox: projects often need high adoption to attract investment, but they need investment to reach that level of adoption. To break this Catch-22, the report recommends that funders create distinct funding tracks—offering maintenance-only support for critical but non-innovative foundational tools, while providing separate pathways for experimental research code. This also ensures support aligns with a project’s actual function. The report also introduces “Software Nutrition Labels” or “Badging” to help users evaluate project health at a glance. The idea is that these labels or badges would help address trust and adoption by serving as a form of due diligence for institutional IT departments that are often hesitant to install OSRS because they don’t know how to assess its reliability relative to commercial products. This idea mirrors the classification system Nadia Asparouhova discusses in her book, Working In Public: The making and maintenance of open source software. For those looking for a starting point for creating something like this, check out the badges at Project Type Badges.
Takeaway #3: Mapping the Connections Matters
My Original Thought: Much of our infrastructure is invisible. We rely on standards and shared dependencies that we don’t appreciate until they break.
The Report’s Finding & Recommendation: The report highlights a responsibility gap where administrators often don’t know about this software, let alone which software their researchers rely on. To fix this, the report recommends addressing the challenges of Tracking Usage and Identifying Extra-Institutional Support. One way of doing this might be to appoint a central coordinator to promote open-source and manage institutional policy. However, the report acknowledges that university-level support isn’t always enough. It points to the German Sovereign Tech Agency, which treats open-source software as a matter of national security and public infrastructure, as a successful extra-institutional model for funding the standards and shared utilities that the entire sector depends on. By treating OSRS as public infrastructure, we can move beyond guesswork and conduct stress tests on critical dependencies using tools such as knowledge graphs (e.g., OpenAlex or Dimensions) and IOI’s Infra Finder, ensuring that institutional policy is backed by data. Notably, IOI is already advancing this effort by visualizing overlaps in governance and project dependencies, helping to uncover the hidden networks behind our digital infrastructure.
Takeaway #4: Software is Research (and should be treated like it)
My Original Thought: Libraries have led the way in open access and data sharing, but we’ve dropped the ball on software. We need to treat code as a first-class research output.
The Report’s Finding & Recommendation: This finding centers on Archival Sustainability and serves as the ultimate answer to Overcoming Cultural Barriers and Defining the Value Proposition. The report asserts that software is integral to the scientific method and that reproducibility is compromised without it. To bridge this gap, the report recommends that academic departments update Tenure and Promotion guidelines to formally recognize and reward software development and maintenance as legitimate scholarly contributions. Beyond the institution, the report notes that scholarly societies and publishers bear a significant responsibility for advancing software citation standards alongside article citations. This includes a call for societies to lead joint task forces that redefine what “scholarly contribution” means across disciplines, and for publishers to mandate that code authors receive formal credit in the scholarly record, ensuring software is preserved as a permanent part of it.
Would you love to continue the conversation? Send me a message!
Sustaining the Future
Coming back to these takeaways nearly a year later feels like a return to my own professional origins. While much of my recent writing has focused on the fast-moving (and often opaque) world of AI, this report is a reminder that the “shiny” new tools we obsess over are only as reliable as the open-source foundations on which they are built.
The SOSSRE workshop was a rare moment where the “invisible” people who keep our research infrastructure running were made visible to one another. But as the report makes clear, visibility isn’t enough because the sustainability of critical software is often left to chance, individual heroism, or precarious grant cycles.
The release of this report moves the needle from awareness to accountability. We now have concrete suggestions for next steps that involve every level of the research enterprise.
As I look at my own work, I feel extremely validated. We’re long past due; the research enterprise must formally recognize that software is a foundational and valuable part of scholarship. While mapping our dependencies and professionalizing these roles is significant work, they are a necessary evolution. After seeing the diverse expertise in that room in Lower Manhattan, I’m confident that the communal solutions are within reach, provided higher education, funders, and other organizations adjacent to higher education find the courage to fund and prioritize them.
I encourage you to read the full report here and consider: who at your institution is responsible for the research software you rely on? If you don’t know the answer, that’s exactly where the work begins.