Working in Public: The Making and Maintenance of Open Source Software
by Nadia Eghbal
In "Working in Public: The Making and Maintenance of Open Source Software," Nadia Eghbal explores the paradox of open source development, where a small percentage of contributors often drive the majority of projects, despite an increasing number of users. The book highlights the challenges faced by maintainers who, while initially enthusiastic, can become overwhelmed as projects grow. As user demands increase, maintainers find themselves spending more time addressing issues and feature requests than developing new code, leading to burnout. Eghbal discusses the dynamics of centralized versus decentralized communities, noting that centralized projects often revolve around a single creator who manages interactions, while decentralized ones thrive on collective governance. The author emphasizes the difficulty of retaining contributors in open source projects, with many newcomers lacking the context or motivation to engage deeply. This results in a cycle where maintainers face low-quality contributions and struggle to onboard casual contributors. Ultimately, Eghbal advocates for recognizing the unseen labor behind open source software and the need for a sustainable model that compensates maintainers for their contributions. She calls for a shift in perception, viewing platforms not as adversaries but as allies in fostering vibrant open source ecosystems. The central message underscores the importance of maintaining a balance between public access to code and the economic and emotional sustainability for those who create and maintain it.
3 popular highlights from this book
Key Insights & Memorable Quotes
Below are the most popular and impactful highlights and quotes from Working in Public: The Making and Maintenance of Open Source Software:
One study found that in more than 85% of the open source projects the researchers examined on GitHub, less than 5% of developers were responsible for over 95% of code and social interactions.7
But just as tweets are easy to read and retweet without context as to who wrote them, code is easy to copy-paste without knowing, or caring, where it came from.
The bigger your project becomes, the harder it is to keep the innovation you had in the beginning of your project. Suddenly you have to consider hundreds of different use-cases . . . . Once you pass a few thousand active users, you’ll notice that helping your users takes more time than actually working on your project. People submit all kinds of issues, most of them aren’t actually issues, but feature requests or questions.84
