Chapter 4
The Anatomy of Open Source Projects
Open source projects are more than just code - they encompass the entire ecosystem of community, code, and communication tools supporting production. GitHub-hosted projects consist of three essential parts: code (the final output), an issue tracker (for discussing changes), and pull requests (for implementing changes).
Issues typically fall into three categories: bug reports (highest priority), feature requests, and questions (support requests). Many larger projects use GitHub for code but employ different tools for other aspects - Django uses Trac for issue tracking, while React hosts documentation and community on a separate website. Projects utilize both synchronous communication channels (IRC, Slack, Discord) and asynchronous ones (mailing lists, Reddit, GitHub issues) for various purposes.
The relationship between maintainers and their community evolves as projects mature. At a high level, open source projects typically transition from closed to open development, then eventually return to either closed or distributed development depending on their size.
In the earliest project stages, typically one or a few developers write code in a relatively closed development state. While some developers create publicly from the beginning, many prefer doing their initial creative work privately, articulating their ideas before opening the project for feedback. Even when publishing early code, they may not widely advertise it until ready for release.
Once released, authors eagerly seek feedback, bug reports, and pull requests. They promote their project like startup founders: sharing in relevant online channels, giving conference talks, and encouraging others to write about it. At this stage, the goal is distribution - getting code into other developers' hands - so projects transition to a more open development state while maintainers retain control over their vision.
As projects become widely used, more developers interact with them. This transition typically occurs when maintainers start doing more non-code than code work, like triaging issues and reviewing pull requests. Community interactions become noisier with comments, feature requests, and pull requests from strangers, making it harder for maintainers to be responsive.
Chapter 5
Four Models of Open Source Production
As open source projects grow, their user and contributor bases expand at different rates. While a "perfect" user-contributor ratio would be 1:1, reality shows varied patterns. A project's contributor growth depends on its technical scope (how much more there is to build), support required (maintenance tasks beyond coding), ease of participation, and user adoption.
Based on the relationship between contributors and users, we can classify projects into four production models: federations, clubs, toys, and stadiums.
Federations are projects with high contributor growth and high user growth - the "bazaars" described by Eric Raymond that we typically associate with open source. Though rare (less than 3% of open source projects), they're disproportionately influential. Examples include Rust, Node.js, and Linux. These projects function similarly to companies or NGOs, developing formal governance structures like voting systems, leadership positions, foundations, working groups, and technical councils.
Clubs are projects with high contributor growth but low user growth, leading to a roughly overlapping group of contributors and users. Programming languages like Clojure, Haskell, and Erlang are not nearly as widely used as Java, C++, and Python, but they're useful in specific niches. Clubs function like meetup or hobby groups - they attract a narrow group of users who then become contributors because they have higher context for the project and feel affinity with the group.
Toys are projects with low contributor growth and low user growth. They're effectively personal projects - side projects or weekend experiments that developers tinker with for fun. While they might eventually become more widely used, at this stage their authors don't expect many contributions or even assume anyone is watching what they're doing.
Stadiums are projects with low contributor growth but high user growth. While they may receive casual contributions, their regular contributor base doesn't grow proportionally to their users. As a result, they tend to be powered by one or a few developers. Many widely depended-upon packages and libraries fit this model, including webpack, Babel, Bundler, and RSpec.
Chapter 6
The Commons and Its Challenges
While it feels obvious today that we want to freely share the things we make, the early success of open source captivated scholars and economists because it defied everything we thought we knew about how and why people create. Open source developers were frequently characterized as "hobby" developers, because the assumption was that only companies could make "real" software.
Previously, our understanding of how and why people make things was modeled after Ronald Coase's theory of the firm, which proposes that firms naturally emerge as a way to reduce transaction costs in the market. By contrast, the open source projects attracting attention in the late 1990s and early 2000s were produced by distributed groups of developers that transcended employer affiliations.
Elinor Ostrom spent decades studying the conditions that lead to a flourishing commons - resources that are owned, used, and managed by a community. She identified eight design principles that contribute to a well-managed, successful commons, including clearly defined membership boundaries, rules that match actual conditions, and monitoring by community members.
These conditions point to the need for a strong sense of group identity. When community boundaries are clearly defined, members know who belongs. They write their own rules and have high context for one another's actions, fostering mutual trust. Members also have "skin in the game," intending to participate for a while.
Yochai Benkler expanded upon Ostrom's model by applying her findings to the online world, terming this communal structure "commons-based peer production" (CBPP). The key conditions necessary for successful commons-based peer production are intrinsic motivation, modular and granular tasks, and low coordination costs.
Before GitHub, each open source project functioned as its own commons. Members shared ownership of the code, and users were treated as potential contributors - if you found a problem, you were expected to fix it yourself. Projects had distinct social and technical norms with high barriers to entry for outsiders.
GitHub transformed open source production by standardizing how projects look and operate. Every project now has the same basic structure: a README, code download section, issue tracker, and pull requests list. This standardization dramatically lowered the barriers to contributing across different projects.
This homogenization mirrors what happened to the rest of the internet. Before platforms, our online world was scattered forums, blogs, and personal websites. People might have felt affinity to particular message boards but had little sense of who else was out there. Platforms turned the "panopticon" upon itself, inducing floods of newcomers, spectators, and drive-by visitors. Collective identity was reduced in favor of personal identity, with individuals acting as free agents.
Chapter 7
The Hidden Costs of Software
Software, contrary to its shiny new appearance, ages quietly and stubbornly refuses to die. Unlike physical products, software is never truly finished - it requires ongoing maintenance just to keep running. At minimum, this means updating dependencies, but often includes upgrading infrastructure, fixing bugs, and updating documentation.
Most developers spend their careers maintaining existing code rather than writing new code. Even at Google, most software gets rewritten every few years as its environment changes. The cost of maintenance and lack of intrinsic motivation to maintain is why large open source projects tend to become modular as they grow.
Once software finds users, it's hard for it to ever really disappear. Some of the oldest code ever written is still running in production today. Fortran (1957) and COBOL (1959) remain widely used in aerospace, weather forecasting, and financial industries. As Byrne Hobart notes about COBOL's persistence in banking, "If the software works, there's a strong incentive not to change it."
When Richard Stallman first described free software as "free as in speech, not free as in beer," he was distinguishing that "free" referred to what one could do with the software, rather than its price. Years later, Jacob Thornton, who cocreated Bootstrap, suggested that open source is instead "free as in puppy": "Open-sourcing something is kind of like adopting a cute puppy... But puppies grow old, and 'your puppy's kinda like a mature dog... and you're like, 'Oh my god, so much time is required for me to take care of this thing!'"
Software has three major types of costs: creation, distribution, and maintenance. While software does have lower marginal costs compared to material goods, its actual costs depend on whether we're viewing it in active or static state. Code in static state can be bought and sold at nearly zero marginal cost. When maintenance is involved, however, software's marginal and temporal costs begin to add up.
User support represents a significant marginal cost that grows dramatically with adoption. When user adoption is low, support feels trivial, but at scale it becomes overwhelming. As more people use open source software, more questions will be asked, and more bugs will be found - but someone still needs to review, manage, and process these reports.
Beyond marginal costs, software requires ongoing maintenance to continue running successfully, regardless of usage levels. These costs stem from entropy - the inevitable decay of systems over time. Maintenance extends beyond code to all supporting knowledge: documentation must be updated when code changes, Q&A answers become outdated, and programming resources require revisions.
Chapter 8
Managing Open Source Production
When explaining why nobody wants to pay for software, people often cite the free-rider problem - the idea that if you can't exclude others from consuming a good, they'll use it without paying. Eventually, producers lack resources to supply it.
But with public goods - those both non-excludable and non-rivalrous like software - the free-rider problem is less obvious. A thousand people can use the same code without diminishing its quality. Physical public goods (street lights, national defense, clean air) are typically government-provided and tax-funded. Should government provide our open source software? Most developers would emphatically reject this idea.
Early cryptography illustrates why governments are ill-suited for open source regulation. In the 1970s-80s, cryptography was considered munitions in the US. Phil Zimmermann, who released Pretty Good Privacy (PGP) in 1991, faced criminal investigation for distributing his code. While code on floppy disks couldn't be exported, books containing code were permitted under free speech, so Zimmermann published PGP as a book to distribute worldwide.
Our desire to make things is visible throughout our lives - not just at work or in collaboration, but as part of our human nature. We like asking questions, thinking out loud, and tinkering with words, code, or imagery. People also want to share what they make. "Expressing ourselves" isn't just about externalizing something trapped inside, but having that part of us understood by others.
When it comes to online public goods, our struggle to develop provisioning solutions stems from not defining the problem clearly enough. What if, when software is in static state, there is no free-rider problem? When code is non-rivalrous, it only has first-copy costs, which creators are intrinsically motivated to provide - so the problem doesn't seem to lie in how many people consume it.
Instead, the real issue might be that software is actually overproduced. The problem isn't that anyone can use the code freely - it's when users cross an invisible boundary and make demands on maintainers' time and attention.
Open source maintainers leverage various strategies to allocate their attention wisely and realize value from their work:
1. Reducing up-front costs through automation, templates, and checklists
2. Making themselves less available by keeping everything in their head rather than coordinating with others
3. Distributing costs onto users through moderation and user-to-user support systems
4. Increasing total attention available by recruiting more contributors or dedicating more of their own time
Chapter 9
The Future of Open Source Funding
The conversation about funding open source requires examining fundamentals: identifying potential funders, their motivations for paying, what they're actually paying for, and what open source developers can realistically offer in return. We need to return to the idea of attention as the currency of production.
Companies pay for open source in several ways, primarily focusing on code quality, influence, access, and brand association. For code quality, businesses use models like dual licenses and "open core" approaches. Companies also pay for influence and access to projects they care about, which translates into priority attention and direct communication with maintainers.
While companies focus on code rather than developers, individual developers have limited financial capacity to support open source projects. Developers are more likely to sponsor the people behind the code rather than the code itself - supporting a maintainer's reputation and future work.
GitHub's Sponsors product encourages users to financially support "developers, maintainers, writers, teachers, and programmers" they depend on, opening possibilities for funding those who create tutorials, books, support answers, or live coding sessions. Funding individuals changes what it means to fund open source by supporting contributors who aren't as closely intertwined with "the project" as core developers.
Chapter 10
Reimagining Digital Creation
Our online social spaces are filled with artifacts of our creative endeavors. Today, "content" isn't something we deliberately set out to make but rather "an externality from our existing social systems." Content has become a snapshot of our civilization.
The evolution of software reveals how our attitudes toward content are changing. In the twentieth century, code was bundled into physical formats - books, floppy disks, CDs - making it easier to price and sell. As code became liberated from these formats and distributed under open source licenses, directly charging for it became more difficult. With millions of lines of freely available code today, the focus has shifted from what developers make to who they are.
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.
When people talk about the "attention economy," they're usually referring to the consumer's limited attention, as when multiple apps compete for a user's time. But a producer's limited attention is just as important to consider. As audience engagement grows, more consumers appropriate attention from creators. A tragedy of the commons occurs not from consumers over-appropriating the content itself, but from consumers over-appropriating a creator's attention.
Social platforms are evolving to address these challenges. Twitter has begun to experiment with giving its creators more moderation control, such as hiding replies to tweets and limiting who can reply to tweets. Instagram Stories is designed for broadcasting rather than conversing with one's audience. Podcasts and newsletters are surging in popularity, allowing creators to broadcast to large audiences without expectation of dialogue.
The first wave of monetization was about making meaning of the big - display advertising operates as a function of viewership. Today, making money as a creator is about making meaning of the small again: Kevin Kelly's "1,000 true fans," finally come to pass. We're seeing renewed interest in subscription models, sponsorships, and merchandise, all of which operate as a function of parasocial, or one-sided, intimacy.
For those in the latter category, the name of the game is building highly targeted audiences and optimizing for fewer people paying more money, rather than shilling for page views. Instead of maximizing for likes, these creators maximize for meaning. We're moving toward a future where rewards are heavily influenced by the quality of one's audience more than its size, affording creators an enormous degree of freedom and helping perpetuate the renaissance of ideas that is already well underway.
