More on this book
Community
Kindle Notes & Highlights
The term “open source” refers only to how code is distributed and consumed. It says nothing about how code is produced.
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.
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.
There is no guarantee that someone with commit access will review, or even acknowledge, a developer’s pull request, which can lead to governance disputes. A company, for example, might release open source code but rely primarily on its own employees to maintain it. Although the project is open source in the sense that anybody can use, inspect, fork, and modify the code, it might be difficult to make substantial contributions as a non-employee. Anybody can submit a change, but that doesn’t mean it will be approved.
While code is the final output of a project, the term “project” refers to the entire bundle of community, code, and communication and developer tools that support its underlying production.
In the earliest stages of a project, there are probably one or a few developers who are writing code in a fairly closed state of development. While some open source developers write code in public from the very beginning, many prefer to do their initial creative work in private, so they can properly articulate their ideas before opening the project up for feedback.
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.
If other developers are filing issues, starring the project, and asking questions, it’s a sign that people find it interesting.
From “The Shape of Open Source,” by Arfon Smith. As contributor count increases, the type of activity on a repository changes, particularly in the form of comments.
As a project becomes more widely used, more developers will interact with it. One heuristic for when this transition occurs is when maintainers start doing more non-code than code work on the project, such as triaging issues and reviewing others’ pull requests.
“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
It’s much easier to entice a new contributor to write an interesting new feature than it is to ask them to triage issues.
One infrastructure developer, who worked for years on projects with different tooling, told me that he’s now so used to GitHub that if he finds a bug on a project that uses a different issue tracker, he won’t even bother filing an issue anymore—it’s too much work.
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.
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.
As their contributor community grows, federations typically “shard” contributors into smaller working groups, where maintainers specialize in certain areas of a project, such as infrastructure or community.
these working groups can experience the same bottleneck issues that the entire project did beforehand, with a lead maintainer serving as a point of failure for their subdomain.
some federations, such as Node.js, also experiment with liberal contribution policies,93 or what open source developer Pieter Hintjens once dubbed “optimistic merging.”94 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
Magnetic projects are those that attract a large proportion of new contributors. Sticky projects are those where a large proportion of contributors continue to make contributions.
a club, most users are contributors: you’re either participating or you’re not in the club.
(While stars aren’t a perfect measure of popularity, they can give some indication of how many people have come across the project.)
In a stadium model, one or a few maintainers make decisions on behalf of a broader user base.
“every streamer has a mini community who watch them and who like each other because they’re attracted to basically the same person.”
In comparison to decentralized communities, centralized ones don’t rely as strongly on defined governance processes, because social interactions primarily take place not among regular contributors but between a creator and their users.
Decentralized communities, e.g., clubs and federations, are characterized by the potential for high contributor growth. The future of these projects hinges upon recruiting new contributors, as well as reducing friction to contribute.
Mikeal Rogers, who worked on Node.js in the early days, describes this model in his blog post “Healthy Open Source”:
Avoid creating big decision hierarchies. Instead, invest in a broad, growing and empowered contributorship that can make progress without intervention.
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.”
By identifying these extremes, we can better understand how to think about the middle.
