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.
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
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
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.
Maintainers - responsible for the future of a project's repositories, whose decisions affect the project laterally - "trustees" of the code
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.
Contributors - make contributions to a project's repositories, ranging from casual to significant, but who aren't responsible for its overall success
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.
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 Growth
Low User Growth
High Contributor Growth
Federations (eg Rust)
Clubs (eg Astropy)
Low Contributor Growth
Stadiums (eg Babel)
Toys (eg ssh-chat)
Excludable
Non-Excludable
Rivalrous
Private goods (Cars, domain names)
Commons (forests, online privacy)
Non-Rivalrous
Club goods (Netflix, Spotify)
Public goods (air, open source code)
What I got out of it
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)
In the Latticework, we've distilled, curated, and interconnected the 750+book summaries from The Rabbit Hole. If you're looking to make the ideas from these books actionable in your day-to-day life and join a global tribe of lifelong learners, you'll love The Latticework. Join us today.
