I recently read “Working in Public” by Nadia Eghbal (now Asparouhova). I discovered the book during my literature research for the “Proseminar Master Thesis” class with Ursula Lagger and got it through an interlibrary loan. As a former developer-relations researcher at GitHub who interviewed hundreds of developers, she offers a fresh, insightful look at the world of open source that I want to share.
Before diving in, it’s important to understand the difference between “free” and “open source” software. The “free software” movement, started by Richard Stallman, is about freedom, not price. The term “open source” was created later to be more business-friendly, focusing on the practical benefits of shared code rather than the ethics of user freedom.
Eghbal’s book focuses on a key distinction in open source projects today: the size of their audience. She describes two models: the “bazaar,” with many contributors (like Linux), and the “stadium,” with a few maintainers and a huge audience of users. Most projects today are stadiums, often run by a tiny group of 1 to 5 developers.
Many projects follow a similar lifecycle. They often start in private, and once they go public, the creators are looking for engagement and feedback. As a project gets adopted, the role of the maintainers shifts from doing the actual code work to managing the project, the community, and the influx of casual contributors.
This leads to a major challenge: how are these projects financed? For many, the answer is they aren’t. The book details the different ways funding works. There are two main types of funders: institutions (like universities and companies) and individuals. Institutions often care about the quality of the code and their influence on the project’s roadmap. For individuals, the reason for funding is often personal; they might use the project daily and simply want to ensure it continues to exist.
The funding target also matters. Is the money going to a project or an individual? Funding a project makes it easier to manage the money transparently. Funding an individual offers more flexibility, as a developer might work on multiple projects. Asparouhova notes that companies tend to sponsor projects, while individuals tend to fund developers directly through platforms like Patreon or GitHub Sponsors.
This brings me to what I think is the most important takeaway from Eghbal’s work: we need to rethink how we value the different kinds of labor in open source. We tend to celebrate the “creator” – the person who has the initial brilliant idea. But what about the “maintainer”? The person who shows up day after day to fix bugs, answer questions, and keep the project alive. Their work is often less glamorous, but it’s no less critical.
If open source is to be sustainable in the long term, we need to find ways to support the maintainers. This could mean more funding, better tools, or simply a cultural shift in how we think about our responsibilities as users of open source.
As I continue my research, I’m left with a question: How can we, as designers and users, better support the maintainers of the open-source tools we rely on every day? I don’t have the answer yet, but it’s a question I’ll be exploring in the weeks to come.
Ai was used to formulate this blogpost (Gemini + WisprFlow)
