I recently re-read Nadia Eghbal's Working in Public: The Making and Maintenance of Open Source Software because I'm funding the development of an open-source project and really enjoyed my first read back in 2020.
Here are some takeaways.
Introduction
In the last 20 years open-source has shifted from being collaborative to being more of a solo endeavor. The role of maintainer has shifted from coordinating developer activity to curating user questions, bug reports, and feature requests.
Successful open-source projects don't suffer because there aren't enough contributors. They suffer because there are too many, or they're the wrong kind.
Developers have largely failed to capture the economic value they've created despite open-source being used more widely.
Chapter 1: Github as a Platform
Because Github focused on the developer experience, open-source became more about people than projects. Prominent Javascript developers are often known for who they are rather than the projects they work on.
Early open-source idealists prioritized freedom and openness. The Github generation prioritizes convenience. Because Github is so easy to use, maintainers are often overwhelmed by floods of requests from well-intentioned users.
Chapter 2: The Structure of an Open Source Project
Open-source projects typically go from being closed in the creation phase, open during evangelism, and either closed or distributed during growth depending on how many contributors there are.
A project's contributor growth is a function of its technical scope, support required, ease of participation, and user adoption.
There are four production models for open-source: federation, club, stadium, and toy.
Chapter 3: Roles, Incentives, and Relationships
Ronald Coase's theory of the firm fails to explain the emergence of open-source software. Elinor Ostrom's theory of the commons explains it well. Commons-based peer production requires intrinsic motivation, modular and granular tasks, and low coordination costs.
Github transformed the open-source ecosystem from one dominated by projects operating as isolated commons to one where most prominent projects are centralized stadiums. This is largely because Github, by aggregating all projects on a single platform, lowered the barriers to contributing to unfamiliar projects. Github fostered relationships between projects that were previously non-existent.
Developers are often more excited to create than to maintain, it's important to find people who enjoy maintenance. It's helpful for maintainers to think of contributors as either active (focused on the long term health of the community/project) or casual (motivated by self-interest).
We can assess the health of a project by examining its popularity, how much software depends on it, and how actively it's developed.
Chapter 4: The Work Required by Software
Software has three costs:
- Creation costs are low
- Distribution costs are low
- Maintenance costs are high
Marginal maintenance costs are a function of users. They include physical infrastructure, user support, and community moderation.
Marginal temporal costs are a function of time. They include technical debt, dependence management, and adapting to user needs.
Software can be understood as both a static artifact and a living organism. It is simultaneously worth nothing and indispensable to society.
Living code can be valued by:
- Its dependencies. Who else is using it?
- Its substitutability. How hard would it be to replace if it disappeared?
The perceived value of open-source code is partially a function of the maintainer's reputation.
Chapter 5: Managing the Costs of Production
It's harder for governments to provide public goods and services in the digital world than in the physical world. Open-source code is transnational, governments are beholden to national interests.
Charging for access to code or content doesn't make sense, it's the production, not the consumption of software that struggles with too much demand.
We should treat the production and consumption of open-source software as two separate types of economic goods. Open-source code in static form is a public good. Open-source code production functions as a commons.
Maintainers can manage their available attention by reducing up front costs, making themselves scarce, distributing costs to users, and increasing total attention available.
Subscriptions are an ideal mechanism for monetizing regular production and delivery of well-defined value.
Funding individual developers rather than projects is better aligned with the distributed nature of open-source projects. Open-source developers should focus on making themselves stand out to a select subset of funders.
Conclusion
Our relationship to creators is more important than our relationship to their content. We should be thinking more about the production side of content than the distribution side, who makes the content and how is it made?
Social platforms must accommodate two disparate use cases.
- The broadcasting effect–large crowds of people focusing their attention on a single actor.
- The small-group effect–people engaging in conversations with their digital neighbors/community members.
Our future is one where rewards are more heavily influenced by the quality of one's audience than its size.
