More on this book
Community
Kindle Notes & Highlights
Our online public lives became too much to handle, causing many of us to shrink back into our private spheres.
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.
A developer who’s employed at a private company works primarily with their colleagues. A developer who writes code in public must work with thousands of strangers: literally, anybody with an internet connection who cares to comment on their code.
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.
Maintainers recounted how those who’d expressed interest sometimes disappeared before they’d even submitted their first contribution.
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.
in a sample of 275 popular GitHub projects across various programming languages, nearly half of all contributors only contributed once. These contributors accounted for less than 2% of total commits, or overall contributions.3 The regular presence of hundreds or thousands of contributors making few substantial contributions, rather than a smaller group of develop...
This highlight has been truncated due to consecutive passage length restrictions.
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.
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.
Given that the average software developer easily relies on hundreds of open source projects to write code these days, it’s inevitable that they’ll only be able to passively consume most of them.
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.
just as tweets are easy to read and retweet without context as to who wrote them, code is easy to copy-paste without knowing, or caring, where it came from.
In contrast to big, monolithic software projects that give rise to persistent communities, npm packages are designed to be small and modular, which leads to fewer maintainers per project and a transitory relationship with the code they write. Viewed in this light, the lack of contributors today reflects an adaptation to changing environmental circumstances, wherein the relationship between a maintainer, contributors, and users is lighter, more transactional.
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.
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.
it’s not the excessive consumption of code but the excessive participation from users vying for a maintainer’s attention that has made the work untenable for maintainers today.
Like any other creator, these developers create work that is intertwined with, and influenced by, their users, but it’s not collaborative in the way that we typically think of online communities.
while more people use open source code than ever before, its developers failed to capture the economic value they created:
The fact that most open source developers now use GitHub represents more than just a shift in personal tastes; it also signifies a shift in developer culture.
hackers care about improving the world, but don’t believe in following the rules to get there.
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.
However flawed the metric may be, stars became—and still are—a mark of success for developers, giving them a way to rank their projects against others’.
the GitHub generation of open source developers doesn’t see it that way, because they prioritize convenience over freedom
Members of this generation aren’t aware of, nor do they really care about, the distinction between free and open source software. Neither are they fired up about evangelizing the idea of open source itself. They just publish their code on GitHub because, as with any other form of online content today, sharing is the default.
Platforms deliver value to third parties that build on top of them, whereas aggregators are pure intermediaries.
Thompson suggests that Facebook is not actually a platform but an aggregator, because there is “no reason for Facebook, beyond goodwill, to do anything for [media] publishers.”
platforms add value to creators by first improving their distribution, exposing them to potentially millions of people. The discovery benefit primarily aids creators who are still building an audience. This feedback loop is positive-sum, encouraging more creators to join.
platforms must make themselves indispensable in order to encourage creators to stay, which usually translates into reducing costs for creators.
GitHub helps his team “automat[e] the development process as much as possible while cutting back on the infrastructure” that Python’s developers have to maintain.
the platform-creator relationship necessarily resembles a symbiotic, “Russian doll” hybrid production model, where creative talent is widely distributed but nested in the cocoon of a centralized platform.
While creators come from just about anywhere in the world, they need these platforms to grow and survive.
Why is it a problem that the concepts of free software and open source are intrinsically tied to licenses? It’s that the aims and goals of both of these movements are about distribution and therefore consumption, but what people care about most today is about the production of software. Software licences regulate distribution, but cannot regulate production. . . . This is also the main challenge of whatever comes after open source.40
Coding became like tweeting in more ways than one. The advent of package managers provided an easy way for developers to install and manage software libraries associated with their programming language of choice.
Package managers make it easier to create, publish, and share reusable components for software development, managed through a single registry:
These managers greatly accelerated what developers were able to do from the command line.
JavaScript dominates more than any other language. On GitHub, JavaScript is more than twice as popular as Python, the second-place contender.
It has rapidly grown to become the most common programming language among developers, according to the site Stack Overflow.
because JavaScript must maintain compatibility across browsers, its official core library is smaller than that of most other languages. So developers are forced to customize it for themselves, writing their own packages to fill in the gaps. As a result, each project tends to be smaller and more disposable, like LEGO blocks that fit together instead of a castle carved from stone.
Rather than being associated with just one project, or a few, prominent JavaScript developers often create hundreds of small yet widely used projects. They’re known for who they are, rather than which projects they’re involved in.
That is what it’s about. You follow your favorite developer and you’re like, “I want their style guide.” That is how it goes.
Sarah Drasner, a maintainer of Vue, another popular frontend framework, cowrote an “open source etiquette guide”
The locus of open source culture has shifted from celebrating heavy-handed authoritarianism to seeking out thoughtfulness and stewardship.
Many people, on both sides of the issue, noted that Stallman’s comments—in which he dissected the definition of “rape” with the same pedantry that he dissects the term “free software”—weren’t unusually out of character from his past behavior. It’s the times that are changing.
Because of its trendiness, JavaScript attracts inexperienced developers who are learning how to code for the first time, and who also aren’t familiar with how to interact with an open source project.
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.
“After having reviewed 10k+ pull requests on GitHub . . . ~80% of contributors doesn’t [sic] know how to resolve a merge conflict.”56 A few years later, he followed up with more observations: Almost no one writes a good pull request title More than half don’t know about the ‘Fixes #112’ syntax ~30% don’t run tests locally before submitting a PR ~40% don’t include docs/tests57 I’ve also noticed that the general PR quality has gone considerably down in the past few years. I guess it’s a result of GitHub’s increased popularity. `¯\_(ツ)_/¯`58
...more
the more successful you are, the more you get ‘punished’ with GitHub notifications.”
Instead of treating platforms as adversaries, we might think of platforms as powerful allies for creators, and try to understand the strange, symbiotic relationship they’ve formed with one another.
Open source is complicated because it contains a messy mix of both technical and social norms, most of which play out in public. It is documented extensively (nearly every decision is written down somewhere) but not clearly (you have to dig through years of mailing list archives to find what you need).
Developers don’t contribute to open source for lack of technical ability, but rather due to fear of committing a faux pas.