Working in Public: The Making and Maintenance of Open Source Software
Working in Public: The Making and Maintenance of Open Source Software
Author: Nadia Eghbal
Quick Summary: A comprehensive examination of modern open source software development that challenges traditional community-driven narratives. Eghbal analyzes how open source has evolved from collaborative communities into infrastructure maintained by small groups or individuals, exploring the economic, social, and technical dynamics that shape how software is built and maintained at scale.
Key Highlights
The Four Models of Production:
- Federations: High contributor growth, high user growth (e.g., Rust, Node.js)
- Clubs: High contributor growth, low user growth (e.g., Astropy, Babel)
- Toys: Low contributor growth, low user growth (early-stage projects)
- Stadiums: Low contributor growth, high user growth (e.g., React, Vue.js)
Core Insights:
- Maintenance is undervalued: Most open source work is maintenance, not innovation - fixing bugs, reviewing PRs, answering questions, and keeping dependencies updated
- Intrinsic motivation drives maintainers: Fame, skill development, and creative expression matter more than money for most contributors
- Attention is the scarce resource: Popular projects face an attention crisis where maintainer capacity becomes the bottleneck
- Platforms shape behavior: GitHub changed open source from mailing lists to pull requests, lowering barriers but increasing noise
- The creator-consumer imbalance: For every maintainer, there are thousands of users, creating asymmetric demand on maintainer time
Practical Takeaways for Staff Engineers:
- Recognize that most valuable work in software is unsexy maintenance and glue work
- Structure projects to minimize coordination costs (documentation, automation, clear contribution guidelines)
- Consider “stadium” model projects need different governance than “federation” projects
- Protect maintainer attention through automation, clear boundaries, and saying no
- Infrastructure projects require different incentive structures than applications
- Open source success metrics should include maintainability, not just adoption
Key Statistics:
- 96% of npm packages are maintained by 1-2 developers
- Most projects have fewer than 5 regular contributors
- 64% of package managers have a bus factor of 1 (only one active maintainer)
- Contributors become maintainers not through meritocracy but through persistence and visibility
Why This Matters for Technical Leaders:
Understanding open source dynamics helps Staff Engineers navigate dependency management, contribution strategies, and organizational open source programs. The book’s frameworks apply to internal platform teams that face similar dynamics - high user demand, limited maintainer capacity, and the challenge of sustaining infrastructure without recognition.
The shift from community-driven to creator-driven open source mirrors the shift in organizations toward platform teams and internal developer platforms, making these lessons directly applicable to enterprise technical leadership.