Reflections from the Accountability in Open Source Software Ecosystems Workshop at CMU

Last week (Oct 14–15), I had the pleasure of participating in the Accountability in Open Source Software Ecosystems Workshop at Carnegie Mellon University, organized by the Software and Societal Systems Department and chaired by Nandini Sharma. Over two days, participants from industry, academia, and open source communities came together to discuss how accountability, sustainability, and collaboration can be strengthened in today's open source landscape.

The event featured an impressive lineup of voices — including Brian Fitzpatrick, Nico Matsakis, Christopher Woo, Matt Germonprez, Nithya Ruff, Georg Link, Stephen Walli, Jim Herbsleb, Sayeed Choudhury, Gregorio Robles, and Bogdan Vasilescu. The mix of perspectives made the discussions unusually rich: people who build, people who manage, people who research, and people who depend on open source systems all confronting the same questions from different angles.

Across sessions, the idea of "accountability" appeared in different forms. Open source communities are not uniform entities; each has its own norms, governance style, and boundaries. For organizations that consume open source software, the message was clear: before asking communities to prioritize your needs, understand how they work, what they value, and how they define participation. Contributing resources doesn't mean asserting control; it means showing up, doing the work, and respecting community processes.

An interesting topic that came up was the difference between transparency and visibility in open source supply chains. We have more data than ever about dependencies, contributors, and activity levels, but visibility is about which data actually matter to users, maintainers, and decision-makers. Making every node in the supply chain transparent doesn't automatically create accountability. This distinction is subtle but critical for researchers and policymakers who want to understand or regulate software supply chains responsibly.

Several discussions focused on the human side of accountability, touching on the roadblocks faced by maintainers, volunteers, and early contributors. Many open source contributors still hesitate to participate because they feel like outsiders or doubt their qualifications. Others burn out under the weight of maintenance work that rarely brings recognition. Creating a welcoming environment was seen as a tangible form of accountability: mentoring newcomers, recognizing contributions beyond code, and valuing the "unseen" labor that keeps communities healthy.

As one may expect, AI and automation were also part of the conversation. A breakout session explored how agents might support open source projects beyond generating code, by handling license checks, reviewing pull requests, suggesting reviewers, or even detecting maintainer burnout. The potential benefits are obvious, but so are the risks: accountability becomes murky when AI begins acting as an agent in its own right. The balance between automation and human judgment will likely define the next phase of open source governance.

Another key discussion centered on Open Source Program Offices (OSPOs) and their growing role in companies, universities, and public institutions. OSPO leaders discussed the persistent tension between openness and risk management — how to harmonize policies across diverse business units, work constructively with technology transfer offices, and measure "value" in ways that go beyond code. The challenge, as one participant put it, is that the procurement systems we use were built for vendors, not communities. Establishing trust and accountability in that gap remains an open problem.

The workshop closed with reflections on how open source communities evolve from villages held together by personal trust, to towns with emerging rules, to cities that require governance and institutional scaffolding. Growth changes everything: communication patterns, power structures, even what it means to belong. Recognizing these inflection points and preparing for them is essential if open source ecosystems are to remain both scalable and humane.

Two days at CMU made one thing very clear: accountability in open source is not a single problem to solve but a set of relationships to understand. It lies at the intersection of people, institutions, and technology — and making it visible is the first step toward making it real.

Three reflections going forward

The workshop raised several questions that deeply resonate with my own research agenda and future work. I kept these three in mind as key outcomes of the meeting:

• **How do we conceptualize accountability when both humans and AI agents

co-produce open source software?** As automated tools take on roles traditionally performed by developers and maintainers, we need to rethink how responsibility, trust, and authorship are defined, and what governance models can accommodate hybrid participation.

• **What mechanisms can make the "invisible work" of open source visible and

valued?** Documentation, community management, and mentoring sustain the ecosystem, yet remain largely unrecognized in formal metrics. Designing frameworks that measure and reward this work is essential for genuine accountability and sustainability.

• How do human relationships shape accountability in open source ecosystems?

Beyond metrics and governance, accountability is ultimately grounded in trust, empathy, and shared purpose. Understanding how contributors perceive fairness, recognition, and belonging — and how these perceptions evolve as communities grow — is key to sustaining healthy collaboration over time.

These are not just questions for open source communities; they touch how we build and maintain shared digital infrastructure. The CMU workshop offered no simple answer, but it brought together the right mix of people to ask the right questions. That is a form of accountability.