**Author:** [[3. Resources/Authors/Nadia Eghbal|Nadia Eghbal]] # Working in Public ![[Working in Public Visual.excalidraw]] ## Book Overview ### About the Author Nadia Eghbal is a writer and researcher focused on the economics of open source software. She previously worked at GitHub improving the developer experience and authored the influential Ford Foundation report "Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure" (2016). Her work examines how individual creators produce public goods online and the sustainability challenges they face. She brings both practical experience (working at GitHub from 2016-2018) and rigorous research to a topic often discussed anecdotally. ### Central Thesis Open source software has shifted from a model of large-scale community collaboration to one dominated by individual maintainers serving massive user bases with minimal active contributors. The problem facing maintainers today is not how to attract more contributors but how to manage a high volume of frequent, low-touch interactions. These developers aren't building communities; they're directing air traffic. The common assumption that open source projects need strong contributor communities to survive no longer matches reality. One study found that in more than 85% of examined GitHub projects, less than 5% of developers were responsible for over 95% of code and social interactions. Rather than being a failure, this distribution reflects an adaptation to changing circumstances: code has become modular, relationships are lighter and more transactional, and the role of maintainer has evolved from community coordinator to curator. Open source developers have more in common with solo creators on YouTube, Instagram, or Twitch than with the collaborative communities of early internet forums. Like other creators, they must manage crowded inboxes, protect limited attention, and lean on enthusiastic fans for support—all while working in full public view on platforms that shape their opportunities and constraints. ### Why This Book Matters This book reframes how we think about open source sustainability. Instead of asking "why don't more people contribute?" Eghbal asks "what if the problem is too much participation, not too little?" This shift illuminates why traditional solutions (more contributors, more funding) often fail to help maintainers. The book also connects open source to broader trends in the creator economy: the decline of firms as principal agents of change, the rise of platforms as gatekeepers, and the challenges individual creators face when producing public goods for massive audiences. Understanding open source helps us understand the future of all online creative work. **Readwise Highlights**: [[3. Resources/Readwise/Books/Working in Public]] --- ## Chapter Summaries ### Introduction Eghbal introduces the paradox at the heart of modern open source: developers who write code used by millions report feeling overwhelmed and unsupported. The default hypothesis—that maintainers need more contributors—turns out to be wrong. In fact, initiatives to attract new contributors often cause maintainers anxiety because they attract low-quality contributions that create more review work. The data tells a different story than the myth. In a sample of 275 popular GitHub projects, nearly half of all contributors only contributed once, accounting for less than 2% of total commits. Projects like Bootstrap (used by 20% of websites) have three developers authoring over 73% of commits. The "collaborative community" model doesn't match how most open source actually works. Code is trending toward modularity—small, single-purpose libraries rather than monolithic projects. This creates lighter, more transactional relationships between maintainers and users. Casual contributors don't want to learn a project's culture; they want their fix merged so they can move on. The maintainer's job has shifted from coordination to curation. ### Chapter 1: GitHub as a Platform GitHub transformed open source by consolidating development onto a single platform, creating network effects that drew in ever more developers. Before GitHub, open source used fragmented tools—different mailing lists, bug trackers, and code hosts for each project. GitHub standardized workflows and made code discoverable. The platform's design choices shaped open source culture. Pull requests (originally called "merge requests") made it easy for anyone to propose changes. Forking became normalized rather than contentious. Stars provided social validation. The shift from mailing lists to issues and pull requests changed how developers communicate. But GitHub also introduced new dynamics. Maintainers became more visible and more vulnerable to demands. The platform's metrics (stars, forks, contributor counts) created expectations that don't always serve project health. Being on a platform means accepting its constraints and incentives. ### Chapter 2: The Structure of an Open Source Project Eghbal introduces a taxonomy of open source projects based on contributor growth and user growth, yielding four models: **Federations** (high contributors, high users): Classic "bazaar" projects like Linux or Node.js with distributed governance, formal processes like RFCs, and genuine community decision-making. **Clubs** (high contributors, low users): Niche projects where users and contributors overlap significantly—like meetup groups where members actively participate. **Toys** (low contributors, low users): Small projects without much adoption, often personal experiments or utilities. **Stadiums** (low contributors, high users): The increasingly common pattern where one or a few maintainers serve massive user bases. Examples include webpack, Babel, and many npm packages. Stadiums have centralized (one-to-many) social structures rather than the decentralized (many-to-many) communities of federations. The maintainer is a performer on stage; the audience faces them rather than each other. ### Chapter 3: Roles, Incentives, and Relationships This chapter examines who does what in open source projects. **Maintainers** are distinguished by their responsibility for the project's overall success, not just specific tasks. They make trade-offs between competing interests and hold final decision authority. The term can mean either "core developer" (proactive, writing features) or "caretaker" (reactive, reviewing contributions)—an important distinction. **Active contributors** participate regularly but aren't responsible for overall direction. They often specialize in particular areas and arrived with intent to stay, not by accident. A key insight: active contributors who stick around were never really casual contributors—they came in already committed. **Casual contributors** are in an "I want this fixed, and then I'm done" mindset. They have minimal context and don't want to invest in learning project culture. Their primary interest is personal, and maintainers must weigh their needs against the project's. **Users** are mostly invisible. Maintainers generally don't know who uses their code. Unlike physical goods, software leaves no trace of consumption. This invisibility creates challenges for understanding demand and impact. ### Chapter 4: The Work Required by Software Software requires ongoing maintenance regardless of how many people use it. Unlike marginal costs that scale with consumption, maintenance costs are a function of entropy—the inevitable decay of systems over time. A 2018 Stripe study found developers spend 42% of their time on maintenance. **First-copy costs** are the initial effort to create something. Software's first-copy costs are substantial, but marginal costs approach zero. Richard Stallman's distinction—"free as in speech, not free as in beer"—clarifies that "free software" refers to freedoms, not price. **Technical debt** accumulates when shortcuts create future maintenance burdens. **Scope creep** bloats projects as features are evaluated incrementally rather than holistically. **Refactoring** pays down technical debt by cleaning up code without changing functionality. Security vulnerabilities require constant vigilance. Dependencies can introduce problems—the 2016 "left-pad" incident broke thousands of projects when a developer removed an 11-line package from npm. Maintenance is unglamorous but essential. ### Chapter 5: Managing the Costs of Production The chapter reframes the "free-rider problem" for software. Traditional economics says public goods (non-excludable, non-rivalrous) get underproduced because consumers won't pay. But Eghbal argues: what if the problem isn't under-production but over-demand? A thousand people can use code without diminishing it—that's non-rivalrousness. The problem surfaces only when users cross into demanding the maintainer's attention: filing issues, requesting features, expecting support. Attention is the scarce resource, not code. **Funding options** include: - Companies paying for influence, roadmap priority, or brand association - Individual developer patronage (Patreon, GitHub Sponsors, Open Collective) - Foundations managing funds for projects (Django Fellowship, Apache Foundation) The best funding relationships are "high context, low discount rate"—funders who understand the project and plan to stick around. Boiling the ocean (seeking broad funding) works poorly; targeted relationships with stakeholders who genuinely care work better. ### Conclusion Eghbal concludes that open source maintainers are creators, not community managers. Their work is closer to that of YouTubers or indie musicians than to traditional images of collaborative software development. The platforms they work on shape their possibilities and constraints. The shift from communities to creators reflects broader changes online. We've moved from clusters of villages (forums, mailing lists) to stadiums where creators perform for anonymous audiences. Understanding this shift helps us support maintainers more effectively—not by throwing more contributors at them, but by respecting their attention and providing resources that match how they actually work. --- ## Key Themes and Highlights ### The Stadium Model > "The problem facing maintainers today is not how to get more contributors but how to manage a high volume of frequent, low-touch interactions. These developers aren't building communities; they're directing air traffic." The stadium metaphor captures the modern open source dynamic: a small number of maintainers on stage, a massive audience in the seats, everyone facing the performers rather than each other. This is fundamentally different from the "bazaar" model celebrated in early open source literature. > "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." ### The Attention Economy > "Casual contributors are often aware that they have little context for what is going on behind the scenes of the project. But more importantly, they do not want to spend time familiarizing themselves with a project's goals, roadmap, and contribution process. These developers primarily see themselves as users of the project; they do not think of themselves as part of a 'contributor community.'" > "A creator prioritizes work based on scarcity of attention: saying no to contributions, closing out issues, reducing user support. While the commons is tasked with resolving coordination issues, creators are defined by the need for curation." ### Maintenance as Hidden Labor > "Maintenance makes up a significant aspect of software's hidden costs. A 2018 Stripe study of software developers suggested that developers spend 42% of their time maintaining code." > "In addition to marginal costs, software also requires ongoing maintenance to continue running successfully, regardless of how many people use it. Rather than a function of use, these costs are a function of entropy: the inevitable decay of systems over time." ### Commons vs. Creator Models Eghbal distinguishes between Ostrom's commons principles (designed for community self-governance) and the reality of creator-driven projects. Key tensions: > "In order for sanctions to be effective, for example, communities need cohesion. But if developers don't see themselves as 'members' of a community, they might not necessarily mind being shamed or kicked out." > "Defining membership boundaries in an open source project turns out to be one of the hardest problems to solve." ### The Hacker Ethic > "Hackers believe in sharing, openness, and decentralization, which he calls the 'hacker ethic.'" > "Hackers are characterized by bravado, showmanship, mischievousness, and a deep mistrust of authority." > "The locus of open source culture has shifted from celebrating heavy-handed authoritarianism to seeking out thoughtfulness and stewardship." --- ## Analytical Reading ### Main Arguments 1. The dominant model of open source has shifted from collaborative communities ("federations") to creator-driven projects ("stadiums") 2. The problem is not too few contributors but too many low-quality interactions demanding maintainer attention 3. Open source maintainers function like other online creators (YouTubers, streamers), not like community coordinators 4. Traditional solutions (more contributors, more funding) often don't address the actual problem 5. Attention, not code, is the scarce resource in modern open source 6. Platform dynamics (especially GitHub) shape how open source works 7. Software's "free-rider problem" is better understood as an attention-extraction problem 8. Funding works best with "high context, low discount rate" relationships ### Methodology Eghbal combines: - Extensive interviews with maintainers and contributors - Analysis of GitHub data on contribution patterns - Economic frameworks (public goods, commons, first-copy costs) - Comparison to other creator economies (YouTube, Twitch, Patreon) - Case studies of specific projects (Bootstrap, left-pad, Linux, Vue.js) She moves fluidly between quantitative data and qualitative insights, grounding theoretical claims in concrete examples. ### Strengths - Reframes a misunderstood problem with fresh analytical lens - Grounded in real data and extensive interviews - Connects open source to broader creator economy trends - Practical implications for maintainers, platforms, and funders - Accessible writing that doesn't require technical background - Challenges assumptions held by both open source advocates and critics ### Limitations - Primarily focused on GitHub; other platforms and ecosystems get less attention - Corporate involvement in open source is explicitly set aside for future work - Some analysis may not generalize beyond the npm/JavaScript ecosystem - Could benefit from more international perspectives (U.S.-centric) - Published 2020; rapid changes in AI tooling may shift dynamics further --- ## Personal Reflection ### Key Takeaways The shift from "why don't more people contribute?" to "how do maintainers manage excessive demand?" is transformative. It explains why well-intentioned contributor initiatives often backfire and why funded maintainers still burn out. The stadium model clarifies something I've observed: successful open source projects often have very few active maintainers despite thousands of users. This isn't failure—it's adaptation to how modern software development actually works. The attention framing is powerful: code is non-rivalrous, but maintainer attention is fiercely scarce. Every issue filed, every feature requested, every contribution submitted claims a piece of that attention. Maintainers who succeed learn to say no. ### Questions Raised - How will AI coding assistants change these dynamics? Will they reduce maintenance burden or create new categories of low-quality contributions? - Can platforms redesign to better protect maintainer attention while still enabling legitimate participation? - What would "sustainable open source" look like if we took the stadium model seriously? - How do these dynamics differ in non-English-speaking open source communities? ### Connections to Other Works - Eric S. Raymond, *The Cathedral and the Bazaar* (the "bazaar" model Eghbal complicates) - Yochai Benkler, *The Wealth of Networks* (commons-based peer production theory) - Elinor Ostrom, *Governing the Commons* (community self-governance principles) - Kevin Kelly, "1,000 True Fans" (creator economy framework) - Cal Newport, *Deep Work* (attention as scarce resource) --- ## Reading Notes Published by Stripe Press in August 2020. Builds on Eghbal's 2016 Ford Foundation report "Roads and Bridges." Written during her time at GitHub (2016-2018) and draws heavily on that experience. The book is relatively short (~230 pages) but dense with insight. Part of a broader Stripe Press catalog focused on technology, economics, and infrastructure. The production quality is high, typical of Stripe Press titles.