Working in Public: The Making and Maintenance of Open Source Software by Nadia Eghbal

Summary

  1. This book is an attempt to identify, and expand upon, what it means to be online today, told through the story of open source, where individual developers write code consumed by millions. Rather than maximizing participation, their work is defined by the opposite: the need to filter and curate a high volume of interactions. I try to explain why this came about and how platforms shifted the focus from online communities to solo creators. 

Key Takeaways

  1. It’s not the excessive consumption of code but he excessive participation from users vying for a maintainer’s attention that has made the work untenable for maintenance today
  2. Like any other creator, these developers create work that is intertwined with, and influenced by, their users, but it’s not collaborative in the way that we typically think of online communities
  3. Like a talent agency, platforms add value to creators by first improving their distribution, exposing them to potentially millions of people. The discovery benefit primarily aids creators who are still building an audience. This feedback loop is positive-sum, encouraging more creators to join. So long as more people keep using the platform, there’s no sense that any one creator will ever suck up all the oxygen in the room.
  4. Maintainers – responsible for the future of a project’s repositories, whose decisions affect the project laterally – “trustees” of the code
    1. To borrow again from conservation biologoy, maintainers can be thought of as keystone species. A keystone species is small in population size but has an outsize impact on its ecosystem. If we were to imagine a forest, for example, while there may not be many wolves in absolute numbers, if the wolves disappeared there would be cascading effects on the rest of the forst. The deer population, lacking a natural predator, would grow out of contorl, the plants would start to disappear because there would be too many deer, and so on. 
  5. Contributors – make contributions to a project’s repositories, ranging from casual to significant, but who aren’t responsible for its overall success
  6. Refactoring is the process by which developers pay down technical debt: rewriting, simplifying, and otherwise cleaning up the codebase without changing its functionality. Much like editing a book versus writing it for the first time, refactoring code is often dreaded and unrewarding work. Since open source developers tend toward work that they find intrinsically motivating, not only are open source software projects more susceptible to technical debt but there are also fewer incentives to clean up messy code. 
  7. Historically, most of our questions about the value of content have focused on the distribution side, rather than the production side. Today, the most interesting questions we can ask will focus on how content is made and maintained, and by whom. We’ve previously treated content as a first-copy cost problem, and have developed solutions like patents, intellectual property, and copyright to incentivize its creation. But these solutions don’t address the costs of maintenance, which accrue over time. The challenges facing online creators today derive from the fact that they are playing a repeated game, not a single one. 
High User GrowthLow User Growth
High Contributor GrowthFederations (eg Rust)Clubs (eg Astropy)
Low Contributor GrowthStadiums (eg Babel)Toys (eg ssh-chat)
ExcludableNon-Excludable
RivalrousPrivate goods (Cars, domain names)Commons (forests, online privacy)
Non-RivalrousClub goods (Netflix, Spotify)Public goods (air, open source code)

What I got out of it

  1. Another beautiful book by stripe press that helped me learn about some of the more technical details of open source, and a new framework in which to think about them (federations, stadiums, clubs, and toys)