Working in Public: The Making and Maintenance of Open Source Software
Rate it:
Open Preview
Kindle Notes & Highlights
1%
Flag icon
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.
2%
Flag icon
In my conversations with maintainers, I heard them express a genuine conflict between wanting to encourage newcomers to participate in open source and feeling
2%
Flag icon
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.
2%
Flag icon
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.
2%
Flag icon
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.
3%
Flag icon
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.”
3%
Flag icon
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.
5%
Flag icon
Git (along with Mercurial, a competing system that launched at nearly the same time) was the first major distributed version control system to go mainstream, which made it technically feasible for developers to work independently from one another.
7%
Flag icon
If GitHub is like Facebook, SourceForge was the MySpace of code-hosting platforms: the first significant product of its kind, and, though still alive today, mostly remembered as a blueprint.
7%
Flag icon
By 2017, GitHub hosted 25 million public projects, and the service is still growing. GitHub claims that it had more new users in 2018 than in its first six years combined.
Liam
Woah
8%
Flag icon
GitHub’s popularity among modern developers is the classic technology tale of convenience triumphing over personal values.
8%
Flag icon
For those hoping to reach an audience, platforms and creators have become inseparable.
8%
Flag icon
Thompson references a quote attributed to Bill Gates, who defines a platform as “when the economic value of everybody that uses it exceeds the value of the company that creates it.”
14%
Flag icon
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.
14%
Flag icon
Despite impassioned rants to the contrary (if there’s one thing I’ve learned, it’s that developers have opinions), there’s no one right way of doing things, just different communities that each have their own cultural norms.
17%
Flag icon
A project’s contributor growth is a function of its technical scope, support required, ease of participation, and user adoption.
20%
Flag icon
Given the high fixed costs of entry into maintainership, the knowledge required to maintain tends to stay concentrated among one or a few people. The longer they go without externalizing this knowledge, the more difficult it becomes for newcomers to participate.
22%
Flag icon
Ronald Coase’s theory of the firm, which proposes that firms (i.e., companies, organizations, and other institutions with centralized resources) naturally emerge as a way to reduce transaction costs in the market.
23%
Flag icon
Benkler reasons that if individuals are personally motivated to do something, coordination costs will be lower.111 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.
23%
Flag icon
of people will volunteer all at once. Intrinsic motivation makes it easier for people to self-organize to achieve the same outcome.
23%
Flag icon
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.
23%
Flag icon
Intrinsic motivation is the currency of the commons: members do the work because they want to do it.
24%
Flag icon
If production runs on intrinsic motivation, money is an extrinsic motivator that is thought to interfere with an already well-coordinated system.
24%
Flag icon
While the commons is tasked with resolving coordination issues, creators are defined by the need for curation.
25%
Flag icon
In order for sanctions to be effective, for example, communities need cohesion. But if developers don’t see themselves as “members” of a community, they might not necessarily mind being shamed or kicked out, and may indeed even thrive on such conflict.
28%
Flag icon
Membership is a two-way social contract. Some developers don’t want the responsibilities of being recognized as a contributor.
30%
Flag icon
Yochai Benkler suggests that all members in a peer production model are intrinsically motivated to participate.
31%
Flag icon
There are many more orphaned projects than there are developers clamoring to become maintainers.
32%
Flag icon
Following the collective effort model they cite, active contributors aren’t necessarily a function of how many users the project actually has, but rather of how many perceive that they can make a meaningful contribution.
37%
Flag icon
We can form a picture of a project’s overall activity by first looking at the volume of work required, such as commits (both the date of the latest commit and the rate of new commits) and the rate at which issues and pull requests are opened.
37%
Flag icon
But the problem is not quite that simple. Code is nearly free to distribute, but maintenance can still be expensive. Although it’s not immediately visible from the code itself, software does incur a hidden set of costs over time.
41%
Flag icon
We can think about software as having three major types of costs: creation, distribution, and maintenance.
44%
Flag icon
Nathan Ensmenger, the informatics professor, notes that, since the early 1960s, maintenance costs account for 50% to 70% of total expenditures on software development.
49%
Flag icon
Is software worth nothing, or is it indispensable to society? The answer is both.
50%
Flag icon
Open source code also tends to be a highly elastic good, meaning that its consumers are sensitive to price changes and restrictions, and will happily switch to a competitor if needed.
53%
Flag icon
Open source code is transnational, affecting developers and users across many different countries, whereas governments are beholden to national interests (such as national security). And the world of software moves so fast that the law can’t keep up.
53%
Flag icon
Instead, I’d flip the question to ask: What if, rather than being underproduced, software is actually overproduced?
54%
Flag icon
Open source code itself is not a common pool resource but a positive externality of its underlying contributor community. Users can consume, or “appropriate,” code at zero marginal cost, because what the commons actually manages is not code but attention.
55%
Flag icon
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.
56%
Flag icon
Rather than asking “How do we do everything that’s required of us?,” the better question is “How do we assess what’s most important to do?”
62%
Flag icon
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.
66%
Flag icon
Twitch, Instagram, YouTube, Twitter, and Facebook are all status-based platforms. Who provides status as a service for developers?
67%
Flag icon
If not “open source developers,” then what do we call these developers, and how do we reconcile their relationship to open source? One hypothesis is that “open source” is quickly becoming indistinguishable from “doing code stuff in public.”
68%
Flag icon
Open source developers are chronically undervalued because, unlike other creators, they’re tied to a platform that doesn’t enable them to realize the value of their work.
71%
Flag icon
Funding developers, rather than projects, changes what it means to fund open source.
72%
Flag icon
With millions of lines of code freely available today, the focus has shifted from what developers make to who they are.
72%
Flag icon
Chapter 4 revisited the question of marginal cost. 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.
73%
Flag icon
A tragedy of the commons occurs not from consumers over-appropriating the content itself, but from consumers over-appropriating a creator’s attention.
75%
Flag icon
A paywall is more like the ticket kiosk at a theme park than a price tag on a car. Most comments aren’t useful, so charging readers to leave a comment helps ensure that participants have meaningful skin in the game.
77%
Flag icon
We’re moving toward a future where rewards are heavily influenced by the quality of one’s audience more than its size.