Working in Public

Key Takeaways

Under Consideration — to be added.

Interconnections

Under Consideration — to be added.

Highlights

• Tim Berners-Lee, the inventor of the World Wide Web, envisioned “a pool of information … which could grow and evolve” in his original proposal to CERN, the European particle physics laboratory that incubated his project.1 “For this to be possible, the method of storage must not place its own restraints on the information,” he wrote. With his proposal as a blueprint, technologists built a Library of Alexandria bigger than we could have ever conceived in the physical realm, inextricably linking people and their ideas all around the world.
• Our online public lives became too much to handle, causing many of us to shrink back into our private spheres.
• The cycle looks something like this: Open source developers write and publish their code in public. They enjoy months, maybe years, in the spotlight. But, eventually, popularity offers diminishing returns. If the value of maintaining code fails to outpace the rewards, many of these developers quietly retreat to the shadows.
• It’s commonly thought that open source software is built by communities, which means that anyone can pitch in, thus distributing the burden of work. On the surface, this appears to be the right solution, especially because it seems so attainable. If a lone maintainer feels exhausted by their volume of work, they should just bring more developers on board.
• However, in speaking to maintainers privately, I learned that these initiatives frequently cause them to seize with anxiety, because such initiatives often attract low-quality contributions. This creates more work for maintainers—all contributions, after all, must be reviewed before they are accepted. Maintainers frequently lack infrastructure to bring these contributors into a “contributor community”; in many cases, there is no community behind the project at all, only individual efforts.
• I started to see the problem is not that there’s a dearth of people who want to contribute to an open source project, but rather that there are too many contributors—or they’re the wrong kind of contributors. Open source code is public, but it doesn’t have to be participatory: maintainers can buckle under excess demand for their attention.
• This distribution—where one or a few developers do most of the work, followed by a long tail of casual contributors, and many more passive users—is now the norm, not the exception, in open source.
• From the perspective of these maintainers, quietly tending to their code on the prairie amidst the tumbleweeds of unanswered issues, the world doesn’t look like the utopian vision, embraced by early internet pioneers, of large-scale collaboration among strangers. If anything, it looks like exactly the opposite of what these early advocates predicted.
• 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.
• We assume that open source projects need to grow strong contributor communities in order to survive. There’s even a term called the bus factor, where project health is measured by the number of developers that would need to get hit by a bus before the project is in trouble.
• The expectation that open source should be a collaborative effort leaves solo maintainers scratching their heads, wondering if they’re doing something wrong when nobody shows up to meaningfully pitch in.
• Code, like any other type of content available online today, is trending toward modularity: a mille-feuille layer cake of little libraries instead of one big, jiggling Jell-O mold.
• 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.”
• The role of a maintainer is evolving. Rather than coordinating with a group of developers, these maintainers are defined by the need for curation: sifting through the noise of interactions, such as user questions, bug reports, and feature requests, which compete for their attention.
• Given limited time and attention, solo maintainers need to balance reactive tasks (community interactions) with proactive ones (writing code).
• 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.
• Increasingly, our online worlds are being built by individuals, not just communities.‡
• If you consume any content on the Internet, you’re mostly consuming content created by people who for some reason spend most of their time and energy creating content on the Internet. And those people clearly differ from the general population in important ways.
• Like a book or video, code is just a bunch of information, packaged up for distribution. But its role as a utility is more explicit.
  • What is the understood utility of other types of media?
• It also helps that open source developers work in full public view, making their stories easier to study.
• But over the last twenty years, open source inexplicably skewed from a collaborative to a solo endeavor. And while more people use open source code than ever before, its developers failed to capture the economic value they created: a paradox that makes them just as interesting to reexamine today.
• We’re still trying to reconcile the rise of individual creators with the crumbling of newspapers, book publishers, and talent agencies: the decline of the firm as a principal agent of change.
• If creators, rather than communities, are poised to become the epicenters of our online social systems, we need a much better understanding of how they work.
• Even Wikipedia, the world’s biggest online encyclopedia, and a canonical example of large-scale collaboration, has Steven Pruitt, a volunteer who’s edited one-third of all the English language articles on the site.
• Rather than maximizing participation, their work is defined by the opposite: the need to filter and curate a high volume of interactions.
• The relationship between platforms and their creators is critical to the discussion of how our online world is changing.
• The term “hacker” was popularized by author Steven Levy, who memorably captured a portrait of the 1980s hacker generation in the book Hackers: Heroes of the Computer Revolution.
• His 1997 book-length essay, “The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary,” makes a compelling case for the benefits of open source software.
• Karl Fogel, who coauthored the popular version control system Subversion (a centralized predecessor to Git),§ echoed this sentiment to me: When we say: “that’s my bike” or “those are my shoes,” we mean that we own them. We have the final say in decisions about our bike. But when we say “that’s my father” or “my sister,” what we mean is we’re associated with them. We obviously don’t possess them. In open source, you can only have “my” in the associative sense. There is no possessive “my” in open source.26
• Git, the version control system used to manage code, works independently of GitHub or any other hosting platform, so anyone can copy and host a project’s code elsewhere. But GitHub’s community features—where all the conversations take place—are harder to export. (GitHub’s next-closest competitor, GitLab, which was launched in 2011, heavily advertises the fact that its platform is open source.
• But today’s developers hardly even notice “open source” as a concept anymore. They just want to write and publish their code, and GitHub is the platform that makes it easy to do that.
• App: The Human Story is a documentary about Apple App Store developers who struggle against the limitations of their platform.
• Ben Thompson, who writes about business and technology on his blog, Stratechery, goes so far as to suggest that delivering this kind of value is, itself, the definition of a platform, as opposed to aggregators. Platforms deliver value to third parties that build on top of them, whereas aggregators are pure intermediaries.
• Package managers make it easier to create, publish, and share reusable components for software development, managed through a single registry: imagine a public library, containing thousands of books, which anybody can access with their library card. These managers greatly accelerated what developers were able to do from the command line.
• JavaScript’s most recognizable developers are known for the talks they give, the videos they record, the tweets and blog posts they write. They command large followings and attract eager audiences in a way that, say, PHP developers just don’t. Kent C. Dodds, for example, spent so much time making content about React that he left his job as a JavaScript engineer at PayPal to become a full-time educator.
• The cult of personality thrives in JavaScript, even if its most prominent developers are reluctant to acknowledge it, perhaps because this attitude clashes with the professed ideal of open source as “community-built.”
• A few examples: Dan Abramov, a maintainer of React, a popular frontend framework, wrote a blog post that lists all the programming topics that “people often wrongly assume that I know.”
• Because GitHub is so easy to use, the hurdle to opening an issue or asking questions is low, and users ask maintainers for help with everything: how to resolve merge conflicts, how to write a test. These skills aren’t specific to any one open source project; they’re general “how do I open source” questions.
• Like every other social platform today, GitHub was designed for a use case that’s breaking down at scale. Every platform must figure out how to adapt to an emerging set of social behaviors that is still not well understood.
• Fogel is a thoughtful, and in my view underrated, voice of early open source culture. He wrote the only notable book to date on the production of open source: Producing Open Source Software: How to Run a Successful Free Software Project, first published in 2005. It’s available in its entirety online at https://producingoss.com/.
• Open source software is frequently characterized as participatory, which implies that anyone can modify its code. While this is theoretically true, in practice open source is not blindly open to every person who wants to change it. (By contrast, wikis, for example, are usually editable by the general public, with no additional permissions needed.)
• The process by which a developer gains commit access varies widely between projects and is subject to preexisting social norms. Some projects adopt the mindset of needing to demonstrate trust, while others prefer to operate on the basis of trustlessness.
• For example, Debian, an operating system based on Linux, requires that developers follow an extensive onboarding process in which they are expected to read a manual, find a mentor, and meet a maintainer in person who can vouch for their identity.71 On the other hand, it’s common among JavaScript developers to give away commit access more freely. The idea is to distribute the burden of maintenance by making it easy for others to contribute, and it’s assumed that strangers are trustworthy until proven otherwise.
• Depending on the size, complexity, and popularity of the project, as well as one’s proposed change and how much anyone is paying attention, pull requests can take anywhere from minutes to months to get a response. Sometimes, they’re merged within an hour. Other times, they are never reviewed at all.
• At minimum, open source projects hosted on GitHub can be broken into three parts: code (the final output of a project), an issue tracker (a way to discuss changes), and pull requests (a way to make changes).
• Issues tend to fall into three categories: bug reports, feature requests, and questions. From a maintainer’s perspective, bug reports are highest priority, because they mean that something isn’t currently working as intended. Feature requests are things that users would like to have. Questions are essentially support requests, e.g., “How do I do X?” Some maintainers do not use the issue tracker for questions, preferring instead to direct users off GitHub to other support channels.
• React also hosts its code on GitHub but keeps its documentation, tutorials, and community on a separate website.
• At this stage, the goal is distribution—getting new code in the hands of other developers—so the project transitions to a more open state of development. As when publishing a blog post or a video online, open source developers want engagement with their material, so they’ll encourage contributions while still retaining control over their vision of the project. If other developers are filing issues, starring the project, and asking questions, it’s a sign that people find it interesting.
• “Growth” means that more developers might be using the project, but that doesn’t necessarily mean that more developers are making meaningful contributions, or that there are more maintainers meeting this level of demand (as one might expect a successful company to grow employee head count). At this stage, community interactions get noisier—comments, feature requests, pull requests from strangers—which makes it harder for maintainers to be responsive to everyone.
• Once you pass a few thousand active users, you’ll notice that helping your users takes more time than actually working on your project. People submit all kinds of issues, most of them aren’t actually issues, but feature requests or questions.
• In a distributed state, maintainers actively recruit more contributors to pitch in, with the goal of retaining them in the project. In this case, maintainers are making an additional investment of time into growing the number of developers who are available to respond to user and contributor demand.
• A project’s contributor growth is a function of its technical scope, support required, ease of participation, and user adoption.
• It’s much easier to entice a new contributor to write an interesting new feature than it is to ask them to triage issues.
• User adoption refers to a project’s reach: What is the total addressable market of contributors? How many people could potentially contribute to this project? Since most contributors start out as users of an open source project, user adoption is one heuristic for estimating a project’s total potential contributor base.
• These factors can also affect projects in unintuitive ways. There are differences between how a project attracts new contributors and how it retains existing contributors. High barriers to entry, for example, might mean that those developers who make it through the gauntlet will feel a higher affinity to the project.
• Focusing on the relationship between contributors and users, we can think of projects in terms of their contributor growth and user growth. This gives us four production models: federations, clubs, toys, and stadiums.
• Instead of gatekeeping new contributions, these maintainers try to distribute ownership more widely, which encourages more people to become active contributors. Rather than try to contain enthusiastic developers, liberal contribution policies give them a path to spread and grow—like a forest fire.
• In a club, most users are contributors: you’re either participating or you’re not in the club.
• Unlike a federation or club, whose communities are decentralized, a stadium’s community assumes a centralized structure, centered around its maintainers. Decentralized communities are defined by many-to-many interactions, but centralized communities have a one-to-many social structure.
• The community exists because the creator has provided something for people to gather around.
• Avoid creating big decision hierarchies. Instead, invest in a broad, growing and empowered contributorship that can make progress without intervention.
• Jon Hendren, who helped run the popular online forum Something Awful, recalls that, as traffic waned to their site, “most of us moved to Twitter or whatever.”105 However, he says, “We kind of brought the community with us… . I’m in a group DM with most of the same guys I’ve been talking to for the past 12 years now. The community isn’t dead, it was just moved, mostly.”
• Similarly, What Would Virginia Woolf Do?, a community for women over forty, grew to over 30,000 members as a Facebook group before moving to its own platform. For a community of this size, Facebook became more of a nuisance than a lifeline. The group’s founder, Nina Lorez Collins, explained to a reporter that “Facebook is a flat landscape, so managing 38 [sub]groups—subject, regional, and admin—on Facebook was a bear, and they gave us no support whatsoever.”106 Collins decided that “the only way forward was to go with a subscription model and build a branded app [where] we could … finally control our own universe.” Creators, on the other hand, are tethered to the support that platforms provide, because platforms significantly reduce their costs, enabling them to accomplish far more than they could have on their own.
• 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.
• But a few people noticed that these open source projects operated like communities, so they instead explained the projects’ behavior by describing them as a commons, meaning a resource that is owned, used, and managed by a community. These communities rely upon self-governed rules, rather than outside intervention, to manage the resource and avoid over-provisioning or depletion.
• Through her research, Ostrom identified eight design principles that contribute to a well-managed, successful commons: Membership boundaries are clearly defined. The rules that govern the commons should match the actual conditions. Those who are affected by these rules can participate in modifying them. Those who monitor the rules are either community members or are accountable to the community, rather than outsiders. Those who violate the rules are subject to graduated sanctions, which vary depending on the seriousness and context of the offense. Conflicts should be resolved within the community, using low-cost methods. External authorities recognize the right of community members to devise their own institutions. If the commons is part of a larger system, its governing rules are organized into multiple “nested” layers of authority.
• Ostrom spent the latter part of her career applying the principles she had observed to the “digital commons,” where knowledge is the shared resource.
• For example, an online forum has regular members, who are distinct from first-timers, lurkers, or casual posters. These members have developed a set of social norms that may not be clearly visible to newcomers, but which are known and enforced among the core group.
• Benkler reasons that if individuals are personally motivated to do something, coordination costs will be lower.
• Unlike companies—which need to solicit, evaluate, hire, and manage employees—the members of a commons simply self-organize based on who wants to do the work most.
• Additionally, at a company, only employees can do the work, limited by their job function. But in a commons, anyone can stumble upon an advertised task and volunteer themselves. By removing “property and contract,” the commons will theoretically select for the best person for the job at a lower cost.
• But when you have a group of strangers who are loosely affiliated with one another and excited to participate, and nobody is officially in charge, it’s more likely that a bunch of people will volunteer all at once.
• Intrinsic motivation makes it easier for people to self-organize to achieve the same outcome.
• A few of the conditions that Benkler identifies as necessary to pull off commons-based peer production are intrinsic motivation, modular and granular tasks, and low coordination costs.
  • What is the #[[Playbook]] for creating this kind of project?
• Intrinsic motivation is the currency of the commons: members do the work because they want to do it.
• Benkler proposes that, in order to keep people motivated, tasks must be modular and granular: When a project of any size is broken up into little pieces, each of which can be performed by an individual in a short amount of time, the motivation necessary to get any given individual to contribute need only be very small.
• Modularity refers to how the project is organized. Can it be broken into clear subcomponents, and do they fit easily back together? Granularity refers to the size of each module. It should be easy for anyone to jump in and complete the task without too much preexisting knowledge.
• Finally, Benkler suggests that low coordination costs are necessary to produce in a commons. In open source, coordination costs include both “quality control over the modules” (such as reviewing code) and “integrating the contributions into the finished product” (such as merging pull requests).
• Coordination work is expensive because it’s not intrinsically motivated. (For example, developers tend to be more excited about writing code than reviewing someone else’s contribution.) And, as anyone who’s tried to delegate work has probably noticed, it’s usually faster to do things yourself than to train someone else to do it.
• A maintainer’s biggest coordination costs come from reviewing and merging new contributions, so there’s an incentive to keep these costs low. When the costs of coordination outpace the benefits, the commons breaks down as a useful production model.
• David Heinemeier Hansson, who created Ruby on Rails, is a vocal advocate for a commons-based approach to open source production: External, expected rewards diminish the intrinsic motivation of the fundraising open-source contributor. It risks transporting a community of peers into a transactional terminal. And that buyer-seller frame detracts from the magic that is peer-collaborators.
• Why are we seeing more centralized communities today? Platforms accelerated this transition by making it easier for people to move between communities, which made collective identity more porous.
• Before platforms, our online world was a scattered collection of forums, blogs, personal websites. People might have felt an affinity to, say, a particular message board, but they had little sense of who else was out there, and they largely stayed out of one another’s way.
• Blogger Eugene Wei describes the impact of the News Feed as such: In the annals of tech, and perhaps the world, the event that created the greatest social capital boom in history was the launch of Facebook’s News Feed… . By merging all updates from all the accounts you followed into a single continuous surface and having that serve as the default screen, Facebook News Feed simultaneously increased the efficiency of distribution of new posts and pitted all such posts against each other in what was effectively a single giant attention arena, complete with live updating scoreboards on each post. It was as if the panopticon inverted itself overnight, as if a giant spotlight turned on and suddenly all of us performing on Facebook for approval realized we were all in the same auditorium, on one large, connected infinite stage, singing karaoke to the same audience at the same time.
• Although Opalgate was ostensibly about whether a maintainer’s personal political views should affect their ability to participate in the project, another reason the issue blew up the way it did is because it was opened by, and attracted pile-on from, developers outside of Opal’s contributor community. But what defines an outsider in open source, when any developer is supposed to be able to participate? If everybody is a potential contributor, who gets to make, enforce, and follow the rules?
• If maintainers were to defer to their community, how could they assess overall opinion, given the lack of clear membership boundaries?
• In a consensus-seeking model, the goal is not to “win” votes or come to a unanimous agreement, but rather to ensure that there’s a forum for people to raise and discuss their concerns, and that nobody feels strongly enough to block the group from moving forward. Consensus-seeking emphasizes discussion over enumeration: “Rough consensus is achieved when all issues are addressed, but not necessarily accommodated.”
• In the sections that follow, I’ll examine the roles of maintainers, contributors, and users. None of these terms are easily defined.
• Membership is a two-way social contract. Some developers don’t want the responsibilities of being recognized as a contributor. It’s possible they just want to contribute a one-time fix and be on their way, the equivalent of picking up a stray piece of trash on the street. They might prefer the freedom of making video tutorials or organizing events on their own terms, without the additional overhead of coordinating with other contributors.
• MAINTAINERS are those who are responsible for the future of a project’s repository (or repositories), whose decisions affect the project laterally. Maintainers can be thought of as “trustees” or stewards of the code. CONTRIBUTORS are those who make contributions to a project’s repository, ranging from casual to significant, but who aren’t responsible for its overall success. USERS are those whose primary relationship to a project’s repository is to consume (or “appropriate”) its code.‡
• “Creation is an intrinsic motivator, maintenance usually requires extrinsic motivation.” —@BALUPTON, via isaacs/github139
  • Connect to Kurt Vonnegut quote
• Similarly, although maintainers are few in number, their impact on an open source project is far-reaching, because they’re the bottleneck to everyone else’s contributions.
• We can return to Spencer Heath MacCallum’s idea of “proprietary communities” to understand what a maintainer does differently from other contributors. MacCallum suggests that a proprietor serves three functions: selection of members, land planning (in the case of open source, “land” is the codebase), and leadership.
• While maintainers may do other work for the project, all other work can be performed by other community members, whereas a proprietor’s tasks are reserved for maintainers alone.
• Andrey Petrov, explains that “handing over the reins of a project is a natural part of a successful project.”
• The distinction between “author” and “maintainer” also underscores the inherent tension between creating and maintaining software. Some developers love to make things, but they don’t like maintaining them. Functionally, the work required by these two roles is quite different.
  • Kurt Vonnegut quote
• At the same time, reactive work may start to overtake the proactive tasks, while providing neither intrinsic nor extrinsic benefits. This phase of the project is like reading through an ever-growing comments section: maintainers experience diminishing returns on the marginal value of reviewing additional contributions.
• We’re used to thinking of publication as signifying the end of responsibility, as when a writer publishes a book, or a pianist finishes a performance. An open source maintainer, on the other hand, is expected to maintain the code they published for as long as people use it. In some cases, this could be literally decades, unless the maintainer formally steps away from the project. This is the equivalent of a writer being asked to edit and make changes to the same book every day, into perpetuity, long after they’ve reaped the initial financial and reputational rewards from its creation. What’s more, unlike other content, open source code is relied upon by people, companies, and other institutions that need it to keep working, long after the maintainer’s interest has waned. External contributions don’t necessarily reduce the burden of maintenance either, because they still require someone to review and merge them.
  • Connect to “Why Books Don’t Work” and the idea of publishing a book as a living repository of information rather than a snap shot in time (e.g. fundamentals of journalism)
• Active contributors (also called “regular contributors” or “long-term contributors”) are considered members of the project, based on their reputation or the consistency of their contributions. They’re what we typically imagine when we think of open source contributors: a community of developers in which members are invested in one another and in the project. Not every project has active contributors, depending on its size. Whereas a larger project might have three types of contributors—maintainer, active, and casual—a smaller project might just have a few maintainers and many more casual contributors.
• A study by Suvodeep Majumder et al. found that 85% of the open source projects studied had “heroes,” meaning developers who participate in at least 80% of discussions related to a commit, and that these developers’ commits contained significantly fewer bugs than others’.
• Whereas a casual contributor might begin by opening an issue or pull request (“I need something”), for example, an active contributor might start out by commenting on someone else’s issue (“I want to help with something”).
• Active contributors who stick around do so not because they successfully made their first contribution, but because they already came in with the intent to stick around.
• An active contributor is often motivated by a desire for community, but they might have secondary motivations around reputation and learning. They enjoy the social aspects of the project and want to feel as if they’re “part of something.” Brett Cannon, the Python maintainer, summarizes this mindset as such: “I came for the language, but I stayed for the community.”
• It’s tempting to attach a host of assumptions to casual contributors—that they are unfamiliar with open source, new to the project, demanding, destructive—but it’s better to simply think of them as self-oriented rather than communally oriented.
• For example, “68 percent of newcomers to Usenet groups are never seen after their first post,” “sixty percent of registered editors in Wikipedia never make another edit after their first twenty-four hours participating,” and “forty-six percent of the members of guilds in World of Warcraft leave their group within one month, generally migrating to other groups rather than abandoning the game itself.”
• Much like a YouTube creator must learn to manage their relationship with the audience in order to retain their desire to keep making videos, a maintainer must manage their relationship with casual contributors in order to retain enthusiasm for the project.
• In 2019, GitHub added a “dependents graph” to repositories for certain programming languages, which shows the packages and projects that depend on it.
• Although maintainers don’t always have a direct relationship to their users, some users do make contributions to open source projects, even if they don’t think of themselves as contributors. Common examples include:¶ EDUCATION, in the form of live-coding, or making videos, blog posts, or tutorials about the project SPREADING THE WORD, in the form of organizing events, posting about the project online, or giving talks at meetups or conferences SUPPORT, in the form of answering user questions on mailing lists, issue trackers, or chat BUG REPORTS, in the form of filing an issue with the project after discovering a bug**
• Much like casual contributors, active users don’t necessarily feel an affinity to the project’s contributor community. They’re motivated to make tutorials, organize events, report bugs, or give feedback on new releases, but they mainly do so with their own interests in mind, whether reputational benefits or the satisfaction of solving their own problems.
• At their best, active users test new releases, report bugs, and shield maintainers from, as researchers K. Crowston and J. Howison put it, “a barrage of setup, configuration, and build questions from passive users—those who use the code without contributing themselves.”176 They form the backbone of a user-to-user support system that can reduce a maintainer’s workload.
• At their worst, however, active users can be pushy, putting stress on the project by demanding work, or providing other users with “unofficial” answers that are outdated or inaccurate.
• What does it mean for a project to be doing “well”? There are three success metrics that are interrelated but distinct: POPULAR refers to how many people use the project. For example, a testing tool or text editor could be popular, even if other software doesn’t directly depend on it. DEPENDED UPON refers to how much software depends on the project, meaning that it is being actively used by other software, whether directly or transitively. If the project were to disappear, it would break someone else’s software. ACTIVE means the project is actively developed; this communicates an expectation that the project will continue to be maintained in the future. If a developer were evaluating whether to use this project, how would they know it’s reliable?
• We need to look beyond the total number of contributors, and instead consider contributor quality. Rather than measuring the quality of code that a contributor writes—which would be difficult to objectively evaluate—we could use the quality of a contributor’s reputation as a proxy. For example, if a contributor is frequently mentioned on other issues, pull requests, and code reviews, this suggests that other developers perceive they are important to that project. If their pull requests are reviewed more quickly than others’, this suggests that they are more trusted.
• Activity that directly feeds back into “work done” (meaning, changes to the code) should weigh more heavily than issues and questions. The latter might help us measure a project’s popularity, but a project that’s all talk and no action (lots of discussion, but no commits) is not necessarily healthy. By contrast, “issue zero” and “pull request zero,” with a steady rate of issues and pull requests opened and closed, would suggest that a project is in comparatively better shape.
• Looking at a project’s output, rather than its number of contributors, prompts a new question: What actually goes into those issues and pull requests? What is the work that maintainers need to do, beyond the initial authorship of a project?
• In their book Understanding Knowledge as a Commons, Elinor Ostrom and Charlotte Hess define users as “those appropriating digital information at any point in time.”
  • #books-to-read
• Firstly, software, once written, is never really finished. It might be feature-complete, but, in order to continue running, software almost always requires some sort of ongoing maintenance.
  • #Entropy
• Nathan Ensmenger, a professor of informatics and computing at Indiana University, suggests that “most computer programmers begin their careers doing software maintenance, and many never do anything but.”
  • Kurt Bonnegut quote; building vs. maintaining
• The cost of maintenance, coupled with a lack of intrinsic motivation to maintain, is why large open source projects tend to become modular as they grow.
• Code is not a product to be bought and sold so much as a living form of knowledge.
• Apollo 11’s code lives in static state: It’s a commodity, like lumber. When we treat code as a commodity, we’re thinking about it on the basis of pure consumption. It can be bought and sold and traded. We can inspect the code for historical purposes, but it’s not used in production.
  • Archival ideas vs. ideas that are “in production”
• In this state, code is easy to copy, share, and distribute. But the purpose of consuming code is, in most cases, not to simply read and study it but to use it. Open source code derives its value not from its static qualities but from its living ones.
  • Ideas for the sake of ideas. Ideas thrive in the actions they drive. “It is not enough to know, we must do!” Spencer W. Kimball
• If a developer is looking for help with a programming problem, they might come across an answer on Stack Overflow where someone’s written out exactly the code they need. That code is in static state: a commodity available for anyone to consume. But when a developer copy-pastes that code into their own software, it suddenly comes to life. It might break instantly. It might break their other code, and now they have to rewrite everything around it. When software transitions from static to active state, it starts to incur a set of hidden costs.
  • Think of when you read some idea. From someone long dead. And the impact that it had on you. When you put that “idea” into production it might have broken. It may have even crashed your system. But it gave you a chance to reboot. To improve you system of thinking.
• When Richard Stallman first described free software as “free as in speech, not free as in beer,” the distinction he wished to make is that the term “free” referred to what one could do with the software, rather than to its price.
• Jacob Thornton, the developer who cocreated Bootstrap, suggested that open source is, instead, “free as in puppy”: Open-sourcing something is kind of like adopting a cute puppy. You write this project with your friends, it’s really great, and you’re like, “OK, like I’ll open-source it, it’ll be fun! Like, whatever, we’ll get on the front page of Hacker News.” … And it is! It’s super fun, it’s a great thing. But what happens is, puppies grow and get old, and pretty soon … 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 incurs ongoing maintenance costs, both marginal (costs that are a function of its users) and temporal (entropy, or costs associated with decay over time).
• 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.
• Technology policy writer David Bollier paints a rosy picture of what he calls the “information commons,” or online information goods, including open source software, under the commonly held belief that these are non-rival goods.
• If most natural commons are finite and depletable (forests can be clear-cut, groundwater can be drained), [information] commons… are chiefly social and informational. They tend to involve non-rival goods that many people can use and share without depleting the resource. Indeed, many information commons exemplify what some commentators have called “the cornucopia of the commons,” in which more value is created as more people use the resource and join the social community. The operative principle is “the more, the merrier.” The value of a telephone network, a scientific literature or an open source software program actually increases as more people come to participate.203 Rivalry and excludability properties of economic goods. These two properties, taken together, mean that we tend to treat open source code as a public good. In the strictest sense of the word, however, software is not quite non-rivalrous.
• As when more cars merge onto a highway during rush hour, the marginal cost incurred between the first and second software user may be negligible or even undetectable. But eventually, some user N will affect the ability of user N+1 to access that same software. If ten people use the same software versus 10,000 people, its developers will feel the difference.
• In open source, user support frequently comes in the form of “how to” or “why” questions about the project. They’re different from bug reports in that they are considered noncritical, with value going primarily back to the users, rather than the developers of the project.
• Eric S. Raymond once coined the aphorism “Given enough eyeballs, all bugs are shallow.” His point is that open source software presents an advantage over closed source software, because if more people can inspect the code it will increase the chance that more bugs will be discovered.
• 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.
• In practice, software providers understand that the optics of being associated with undesirable content will be detrimental in the long run. Although it is not a “hard” cost of production in the way that physical infrastructure might be (if the software breaks, nobody can access it), community moderation is a “soft” cost that is enforced by social norms (“Ignore these costs at your own risk”).
  • How does anyone actually manage these costs?
• Rather than a function of use, these costs are a function of entropy: the inevitable decay of systems over time.
• When code changes, its documentation must also change. The most upvoted answers on a Q&A site eventually become outdated and incorrect.
• 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.
• 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.
• Knowing whether a project is worth maintaining requires a familiarity with the ecosystem acquired through experience.
• Software’s low marginal cost has democratized how people share ideas. If distribution is cheap, code can be consumed and shared more rapidly.
• It’s cheaper to reuse existing software components than to write code from scratch, which also makes it possible for entrepreneurs to start software companies with fewer up-front costs. The entire software industry owes its financial success to leveraging this arbitrage.
  • Easier to remix ideas and quicker to get to a breakthrough while standing on the shoulders of the best ideas that have come before you.
• Software producers have never really figured out how to sell code itself. Stratechery’s Ben Thompson makes a similar observation about the music industry: “The music industry was primarily selling plastic discs in jewel cases; the music encoded on those discs was a means of differentiating those pieces of plastic from other ones, but music itself was not being sold.”
• At one of MITS’s demos, a paper tape containing BASIC was stolen. Pirated copies of BASIC began to appear and permeate through the software community, cutting into Microsoft’s royalties. Gates, furious, penned his famous 1976 “Open Letter to Hobbyists,” in which he notes that “less than 10% of all Altair owners have bought BASIC,” and that “the amount of royalties we have received from sales to hobbyists makes the time spent on Altair BASIC worth less than $2 an hour.”238 BASIC software, once unbundled from the Altair computer, wasn’t worth very much at all.
• Although we continue to pay lip service to the idea that consumers should pay for software somehow, code struggles against its bonds, spurred perhaps by the famous observation, attributed to Stewart Brand, that “information wants to be free.”
• Everybody remembers Brand’s statement that information wants to be free, but Brand also points out that “information wants to be expensive.” Developer Ben Lesh once tweeted, “Open Source is such a strange thing. The open source work I do is clearly the most impactful work I do, but no one wants to pay me to work on it. Yet I’m asked to speak about it, and the work I’m actually paid to do no one really wants to hear about.
• The author Jane Jacobs explores these conflicting views in her 1961 book The Death and Life of Great American Cities, in which she tries to explain why urban planning policy failed cities. Jacobs’s major critique of urban planning in the 1950s is that the planners treated cities—the layout of their buildings, parks, and roads—as static objects, which were only developed at the outset, rather than continuously revised according to how people used them.
• In the case of cities, Jacobs argues that the “perfect” city cannot be designed once and for all, because how people use their environment changes over time.
• The rules of the “information economy,” like patents and licenses, lend themselves well to commoditized content, but when content is a living organism its value is better measured in terms of people and relationships.
  • Community is the thing that gives value to the commodity.
• This innate duality—software visible as both a fixed point and a line—is at the heart of today’s conflict around how we value not just software but online content more broadly. Is software worth nothing, or is it indispensable to society? The answer is both.
• Infrastructure is recursively defined by public consensus. It’s the set of structures that we’ve collectively decided are most valuable in any given moment, and, therefore, its boundaries and definitions are expected to change over time.
• Substitutability applies to other online content, too. Consider how many “10 Ways to Maximize Your Productivity”-type blog posts are published to LinkedIn every week, or how many “chill music” playlists you can swipe through on Spotify or YouTube, with little preference for the specific songs or artists involved. Each of these blog posts or playlists might attract thousands or millions of users, but they are also easily substituted.
• Someone might have written and published a software library that’s pretty good, but if I have access to a hundred other free libraries that are a lot like it, it’s unlikely I’ll want to pay for it.
• If open source code is like infrastructure, we want to measure its value based on a combination of dependencies (Who uses the code?) and substitutability (If this code disappeared, how hard would it be to replace?). It’s just as hard to measure the economic value of public infrastructure as it is the value of open source code, so these methodologies are more art than science.
• The tacit knowledge required to maintain a project—meaning knowledge that is difficult to externalize and transfer to others—suggests that the perceived value of open source code is also at least partly a function of who’s behind it.
• It’s Sorhus’s visibility, and his reputation, that make it possible for him to raise money through sponsorships. Like dependencies, the reputation of a developer is a dynamic property, based on their past and expected future value, viewed through the eyes of others.
• Consider the experience of coming across an article that you read and found useful. If you were to describe the value of that article, you could measure its page views, or the number of people who are talking about it online (dependencies). You could talk about whether anything else like it exists (substitutability). But if you really liked the article and felt compelled to support it somehow, you might also take a closer look at who wrote it. A one-time op-ed written by the CEO of a multibillion-dollar company might be enjoyable, but not something you feel the need to pay for, because it’s unlikely they’ll continue to regularly write similar posts in the future. By contrast, a thoughtful research piece from an independent writer might compel you to subscribe to their newsletter or sponsor their work, in hopes that they’ll write more of the same kind of material.
• The difference between likes and follows also helps us understand when maintenance costs matter. A viral YouTube video doesn’t necessarily have ongoing costs if its creator doesn’t plan on making more videos. But if the creator aspires to become famous for their work, they also become, in a sense, a maintainer, because they need to keep producing more content in order to maintain their reputation.
• If creators don’t produce anything new, their followers will eventually get bored and leave. Reputation, like software, requires maintenance over time.
• When explaining why nobody wants to pay for software, people often cite the free-rider problem, which is the idea that if you can’t exclude others from consuming a good they’ll use it without paying. Eventually, the good becomes overused, as producers lack the resources—usually provided by consumers—to supply it.
  • There is a balance between limiting the marginal cost while simultaneously structuring a logical process for getting paid.
• But when it comes to public goods—i.e., goods that are both non-excludable and non-rivalrous, like software—it’s a bit harder to see where the free-rider problem applies. After all, a thousand people can read the same article, or use the same snippet of code, without diminishing its quality.
• In the absence of government, we don’t yet have tidy answers to how online public goods are built, maintained, and paid for.
• But online, it’s not that expensive to write code, record a video, make music, or publish one’s thoughts. Intrinsic motivation fuels our ability to provide this content to others. We make it not because we’re calculating the dollars and cents involved, but simply because we want to.
• Our desire to make things is visible throughout our lives, not just while working at a company or collaborating with others, but as a part of who we are as humans.
  • We are children of the most creative being in the universe
• When it comes to online public goods, I think our struggle to come up with provisioning solutions is due to the fact we haven’t defined the problem clearly enough. Put another way: When software is in static state, what if there is no free-rider problem? When code is non-rivalrous, it only has first-copy costs, which the creator is intrinsically motivated to provide—so the problem doesn’t seem to lie in how many people consume it. For this reason, I’m skeptical of attempts to charge for access to information, whether it’s newspaper articles or open source software. If some people like to make things of their own accord, and most content is a highly substitutable good, it’s unlikely that online content will ever be underproduced. Someone out there will always want to make something for the rest of us. Why prevent anyone from consuming that content, given the enormous social benefits of making it freely accessible?
• I’d like to extend these ideas one step further and argue that managing open source code requires separating its production from consumption: treating them as not one but two types of economic goods. Anyone can consume code, but only a limited number of people can produce it.
• Much of the fatigue that open source developers experience comes not from making their code public but from expectations around making their code participatory.
• When production is a one-way mirror, creators are shielded from distraction, building things in public view but without the expectation that they engage with unhelpful contributors. We can think of this as a form of read-only access, not unlike the permissions system of open source projects themselves.
• The threat of induced demand explains why the solution to managing extractive contributions is not always to add more contributors—tempting as that may be—but to draw clearer boundaries between which types of tasks are worth allocating anyone’s attention to and which can be safely ignored.
• Even documentation is arguably a form of automation, anticipating answers to common questions and making them publicly available.
• John Resig, creator of the JavaScript library jQuery, confesses, The very first person I brought on to the jQuery project wasn’t another developer to help contribute … . It was someone to help manage our community. Because we were just getting so much feedback, so many issues coming in, and so many people using us, we needed a way to kind of keep track of it all, and ensure that people’s concerns were being heard.
• In Sarah T. Roberts’s Behind the Screen: Content Moderation in the Shadow of Social Media, she quotes Max Breen, a pseudonymous content moderator for an unnamed tech company, who notes that this kind of work is extremely non-fungible, even among human moderators: “I don’t think [outsourcing] works because … the culture is so dramatically different when you are trying to apply a policy that is based on [Western] culture.”
• For projects that want to aggressively grow their contributor base, maintainers will invest more in fostering a brand and sense of community, adopting measures such as speaking at conferences, encouraging developer conversations, and maintaining an active online presence. They might embrace liberal contribution policies that default to accepting new contributions, or give away commit access more freely.
• After publishing my initial set of research, I’ve heard from thousands of people sharing the full gamut of ideas on how to pay maintainers, ranging from promising to wacky. Throughout this experience, I’ve been frustrated that the conversation feels so scattershot. We still don’t have a common understanding about who’s doing the work, why they do it, and what work needs to be done. Only when we understand the underlying behavioral dynamics of open source today, and how it differs from its early origins, can we figure out where money fits in. Otherwise, we’re just flinging wet paper towels at a brick wall, hoping that something sticks.
• There is no one-size-fits-all solution here, because open source has matured to the point that, while its distribution licenses have been standardized, we can no longer tell a unified story about how it is produced.
• Much like a lake that requires paid licenses from fisheries to reduce overfishing, an open source project can require companies to pay to “appropriate” attention from the project’s developers.
• Paying a maintainer for their attention can also translate into full-time hires. Companies who hire open source maintainers are paying for a guaranteed, ongoing relationship to someone who can directly influence the project.
• Developers value their privacy, an uncluttered user experience, and the “quiet space” that coding provides. Still, the numbers suggest there is untapped potential, if only someone could find a way to do so without ruffling feathers.
• The typical rewards for content creators are reputational gains, which they can convert into attention (meaning, an audience). If creators want to keep making things, they find ways to convert that attention into money.
• Ben Thompson, suggesting that subscriptions could be the future of local news, defines subscriptions as such: First, it’s not a donation: it is asking a customer to pay money for a product. What, then, is the product? It is not, in fact, any one article (a point that is missed by the misguided focus on micro-transactions). Rather, a subscriber is paying for the regular delivery of well-defined value.
• As writer Tiago Forte puts it, “What people are paying for is not a bunch of text. They are paying for the perspective the writer brings to the subject.”
• Eugene Wei calls this “status as a service (StaaS)”: That many of the largest tech companies are, in part, status as a service businesses, is not often discussed. Most people don’t like to admit to being motivated by status, and few CEO’s [sic] are going to admit that the job to be done for their company is stroking people’s egos… … . . The solution … doesn’t lie in ignoring that humans are wired to pursue social capital. In fact, overlooking this fundamental aspect of human nature arguably landed us here, at the end of this first age of social network goliaths, wondering where it all went haywire. If we think of these networks as marketplaces trading only in information, and not in status, then we’re only seeing part of the machine.
• Researchers write and publish papers, which garner citations from other researchers, which theoretically earn the authors more negotiating power, and, eventually, tenure. But academia fails to create commensurate rewards for open source developers.
• Cassidy Williams is a software engineer who teaches React development. She also writes a weekly newsletter, live-codes on Twitch, has a Patreon with its own private channel hosted on chat app Discord, offers classes on the online learning platforms Udemy and Skillshare, and posts viral fifteen-second videos on the social video app TikTok, as well as to her nearly 90,000 followers on Twitter. There is no other social platform more prominently associated with developers than GitHub. And yet, Williams’s GitHub profile reveals hardly anything about her, except that she must be popular for something, given that she has a few thousand followers. Williams doesn’t build her reputation on GitHub, but on every other platform around it.
• Tiago Forte, reflecting on his experience moving from public to paywall-protected content, observes, The experience of blogging changed dramatically after I flipped the switch. My articles went from thousands of views to hundreds, but the quality of my readers spiked. I found my tribe. The noise of random passersby leaving inane comments dwindled to nothing, and we started having real conversations about what it would take to manifest a new vision of work. I started learning as much from them as they were learning from me. I went from having a blog that a large group of uncommitted readers perused, to a much smaller but more intimate group of people pre-committed to trying new things.
• Funding individuals opens up the possibility of sponsoring someone who makes great tutorials, writes books, answers support questions, or live-codes. It’s less likely that these developers would directly benefit from money raised by an open source project, because they’re just not as closely intertwined with “the project” as core developers are. Funding developers, rather than projects, changes what it means to fund open source.
• “Social media is in a pre-Newtonian moment, where we all understand that it works, but not how it works.” —KEVIN SYSTROM, cofounder, Instagram341
• With millions of lines of code freely available today, the focus has shifted from what developers make to who they are.
• Stratechery’s Ben Thompson calls this the “faceless publisher” model, wherein “atomized content creators, fueled by social media, build their own brands and develop their own audiences; the publisher, meanwhile, builds scale on the backside, across infrastructure, monetization, and even human-resource type functions.”
• We tend to assume that content doesn’t incur significant marginal costs, thanks to platforms that now absorb most of the distribution costs for creators. However, it’s the maintenance of content that incurs hidden costs with time and use.
  • This is why people publish books and only infrequently revisit them in new additions. It isn’t worth the cost of updating the content in full / real-time
• Our social platforms were built for distributed, small-scale, many-to-many use cases: the quaint social world of yesteryear. They were modeled after internet forums, chat groups, and mailing lists, because these were the only blueprints that we had for our online social infrastructure.
• When six people are gathered, they can all talk to one another; everyone is engaged in the same conversation. When a thousand people are gathered, they divide into two types of interaction. There’s the broadcasting effect, when someone climbs onstage to control the crowd and everyone turns to watch. And then there’s the small-group effect, when people strike up side conversations with their neighbors, ignoring the main stage.
• When social interactions are modular and granular, with fungible membership and low coordination costs, they can scale costlessly.
• As Damon Kiesow, a professor at the Missouri School of Journalism, puts it, “National and local journalism are not the same business. The New York Times can chase scale for profit, The Centre Daily Times can’t. Because what the New York Times has is an audience. In College Park, they have a community.”
• Overall, I’d expect to see in the news industry something similar to what happened in open source: a “dumbbell”-shaped distribution of contributors. On one end are purely casual contributors (breaking news, casual punditry, and commentary on the news), who post on social media because it’s low-effort with the potential for a bit of upside, and no expectation of maintenance, funding, or having to make ongoing contributions. On the other end are the maintainers (news columns, investigative journalism, and features): those with in-depth knowledge of their topic, who make highly non-fungible contributions, and who will make money off their reputations.
• We’re moving toward a future where rewards are heavily influenced by the quality of one’s audience more than its size.
• “Getting Started,” React, n.d., https://reactjs.org/docs/getting-started.html.