More on this book
Community
Kindle Notes & Highlights
Started reading
September 25, 2024
As one sports fan, Ryan Regier, observes in a Medium piece, “This is a fascinating revelation about illegal streamers. Even though people can acquire content for free from them, they still give them money.”
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.
Reputation, like software, requires maintenance over time.
It’s easiest to see how free-rider problems apply to non-excludable, rivalrous goods, a situation better known as the tragedy of the commons. If a public park is free to access, people will use it without paying for maintenance and upkeep. As more people flock to the park, its quality is diminished. The trash cans will overflow, the crowds get packed, the grass ground down to mud. To address this problem, we typically pay for public parks with our taxes; some national parks also charge an entrance fee.
the online world, we don’t have governments to provide our public goods. Open source software, in particular, often involves developers from different countries committing code to the same project. If an open source project has one developer in Australia and another in India, which government’s job is it to support production? Whose laws govern the project’s code?
Zimmermann found himself under criminal investigation by the United States government for distributing PGP, although no charges were ever formally filed.
At the time, the US State Department ruled that, while code on a floppy disk could not be exported, books containing code—protected under freedom of speech—were permitted. So Phil decided to publish the same PGP code as a book, titled PGP Source Code and Internals, which he could then send around the world.
When it comes to software and other forms of online content, it’s not clear whose governments are in charge, if anyone is. We have to find new ways of thinking about the problem. The need for a new approach is why Elinor Ostrom’s writing has gained renewed appeal in recent years. Her work provides a framework for understanding how people can self-manage non-excludable resources without resorting to outside institutions like the government.
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 like asking questions. We like to think out loud. We like to tinker, whether with words, code, or imagery. Sometimes, we’re lucky enough to find other people who want to make things with us, but the urge to create is innate to each of us individually.
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.
It’s the production—not consumption—of software that suffers from too much demand. Our expectations about unfettered online participation have caused consumers to spill over to the other side.
Van Rossum’s suggestion highlights the critical difference between content that is public and content that is participatory. Content can be made available for anyone to read and consume, but that doesn’t mean it needs to be open for anyone to participate. Much of the fatigue that open source developers experience comes not from making their code public but from expectations around making their code participatory.
The production of open source code, however, functions more like a commons—meaning that it is non-excludable and rivalrous—where attention is the rivalrous resource. Maintainers can’t stop users from bidding for their attention, but their attention can be depleted.
Open source code itself is not a common pool resource but a positive externality of its underlying contributor community.
what the commons actually manages is not code but attention. When developers make contributions, they appropriate this attention from the commons.
To reduce the over-appropriation of attention in open source software, we can think of its production as a one-way mirror, where we design for the parasocial, or one-sided, relationships that are endemic to stadiums, rather than for the interpersonal relationships that are associated with clubs.
Users may consume code all they like; their public conversations might indirectly influence future iterations; and they can even “see into” the production side (for example, by having read-only access to mailing list discussions, chat logs, and pull requests). However, it’s mutually understood that they do these things from a respectful distance.
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 one-way mirror pattern is used by a number of online communities today, such as Lobsters, a computing-focused community,268 and Product Hunt, a community for discovering new products.269 These communities are public for anyone to read, but in order to post new users need an invite from an existing user.
Jonathan Zdziarski proposes moving to a model that he calls “peer source,” where all his projects would become private repositories, which only trusted developers (people he knew, or that someone could vouch for) could access. “The rest of the community can download binaries, and have the satisfaction that there is accountability on some level, just not to them,” he writes.
The idea of “peer source” is similar to private, invite-only torrent communities, which arose as a way to avoid the over-appropriation of file sharing.
The ability of non-members to consume code should be treated as a positive externality, rather than a sign that they are part of the community. Tourists are allowed to visit Paris, but they’re not Parisians.
In open source, anybody should be able to not only view, download, and fork open source code, but also to witness the interactions between members. There’s no reason to prevent users from accessing any of this information, so long as they don’t appropriate attention from producers.
When there have already been 770 comments on a subject, you’re obviously not going to read them all. . . . Every comment added to a discussion thread is ultimately a form of debt, and its [sic] a form of debt with compound interest. . . . . No matter how many GitHub issues we create, it seems that every single one will grow in length until it becomes an unsustainable conversation. We have a problem of induced
Casual contributions are non-extractive when they resemble Benkler’s modular, granular tasks, which require little additional input from maintainers and are inexpensive to review and merge. Bigger, more substantial contributions can also be non-extractive, if the benefit of the contribution exceeds the cost of reviewing and merging it.
Best practices for managing the commons, however, suggest that maintainers should avoid allocating attention toward extractive contributions. In Ostrom’s language, this is the equivalent of members ignoring outside input (whether from the government, the market, or other opinionated outsiders) on how to manage their shared resource, if the advisor is not part of the community that governs it. Not everybody can participate, regardless of enthusiasm or good intentions, because if producer attention is not carefully managed it will be depleted.
It’s not just open source developers but software companies more generally that make heavy use of automation, particularly in the realm of product support and content moderation.
Kraut and Resnick emphasize that screening mechanisms aren’t just about “weeding out potential members who are not a good fit for the open source project”; they’re also about “increasing the commitment of those who attain those privileges.”278 Screening mechanisms are a “double-edged sword,” which “may drive away some potentially valuable members who are unwilling to make the initial investment.” Some maintainers cite similar concerns around adding issue templates, checklists, and error messages: they don’t want to deter new contributors by making the process too complicated.
On the other hand, when developers feel that they’ve earned their contribution, they’re more likely to stick around. Whether maintainers should gatekeep, versus opening the floodgates, depends on their current needs. They can choose to dial contributions up or down based on the level of demand.
maintainers can reduce their up-front costs by making certain actions more expensive. They could charge money to open an issue or pull request, similar to how highways charge a higher toll during commute hours to reduce the number of cars on the road. We haven’t yet seen many developers experiment with these ideas, partly because it’s still seen as violating the particip...
This highlight has been truncated due to consecutive passage length restrictions.
Researcher Mairieli Wessel et al. found that out of 351 popular, active projects sampled on GitHub, 26% use bots to manage their workflow.
Maintainers sometimes use checklists to make sure that contributors have read and agreed to all their conditions before submitting a pull request. React Native Firebase, a collection of React Native modules that connect to Firebase services, asks those filling out a bug report to add a fire emoji to the subject line, which proves they read the entire template:
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. And so being able to kind of delegate some of that responsibility meant that I could spend more time focusing on writing code.
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.
Maintainers can make their attention excludable by charging for access, which turns it into a private good. Paid support, patronage, and bounties (meaning, paid rewards for certain tasks or contributions) are all examples of ways that maintainers price their attention. By making attention excludable, the quality of contributions will increase, as contributors and users compete for the attention of producers.
The developers of Oni, a text editor, decided to dual license their code on a “time delay” for a new version of the editor, Onivim 2. Its code lives under a proprietary license that requires purchase for commercial use, but every commit converts to open source, under an MIT license, after eighteen months. In this way, Onivim 2’s developers can freely license older versions of the project while charging for access to the newest, most desirable version of the code.
Brand association via sponsorships tends to appeal to smaller companies, like consulting shops whose business relies on a particular open source project, as well as to bigger companies that might have financial resources but lack the brand to attract engineers.
Patronage is an emerging funding system for online creators today, but it’s frequently conflated with the concept of “donations.” Patronage isn’t motivated by altruism but by an interest in following a creator’s future work, based on their current reputation. It’s more like a subscription than a donation. When an individual sponsors an open source developer, then, they’re ideally not paying for code but to feel closer to the person who writes the code.
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.
But who provides the content is a form of differentiation in itself.
Fernando Pérez is the author of Jupyter, a set of open source tools and services for interactive computing, used by researchers and companies around the world. It is arguably one of the most impactful pieces of scientific software in circulation today. Yet Pérez, a physicist by training, had trouble finding a tenured academic position for many years. Similarly, Tom Caswell, lead developer for Matplotlib, a data-plotting tool for Python, and Andreas Müller, core developer of scikit-learn, a machine learning library for Python, both have PhDs but are employed in non-tenure-track positions. There
...more
It’s still not easy to understand who a developer is, or what they do, from their GitHub profile. Profile pages highlight code activity, but they miss an opportunity to highlight educational content, questions answered, or even the projects that a developer is associated with—all
One hypothesis is that “open source” is quickly becoming indistinguishable from “doing code stuff in public.” The story that binds these people together is that of creative developers becoming well known for the things they make and share with an audience, whether that’s code, videos, classes, or newsletters. Building a public reputation often requires doing highly visible things,
When it comes to vetting funding opportunities for open source, Ostrom’s principle of seeking “high context, low discount rate” opportunities serves us well. It’s not a company’s or individual’s job to fund every open source project that they use. But some projects will mean more to certain funders than others, and those are the best opportunities to pursue.
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
...more
Hacktoberfest is an initiative that is sponsored by cloud infrastructure provider DigitalOcean and developer community DEV. (GitHub was a sponsor in previous years.) During the month of October, anyone who makes five pull requests to an open source project is eligible for a free T-shirt.
Bounties can be effective when the tasks are vetted by maintainers themselves, and when they fund well-scoped, finite tasks that are specialized or otherwise difficult to attract talent for, such as design work or database migration.
Instead, funding can become a useful motivator in places that are absent any other sort of motivation, such as the later stages of software maintenance. Because maintainers are more familiar with the project than casual contributors are, and are responsible for most of the work done, it makes more sense to fund their time over anyone else’s.
Funding developers, rather than projects, changes what it means to fund open source.
Content is a snapshot of our civilization.
