Community Imbalance Theory

This is my best effort to summarize the last 4 years of community building, governance, and general open source sustainability work I’ve done into a consistent theory. It’s not perfect, and like the rest of the industry I expect it to evolve over time.

All problems in community generated software that threaten the sustainability of the project are due to an imbalance between those consuming the software and those participating in building the software.

This theory can be broken down into several points, each of which could probably have an entire post supporting its thesis.

• True technical “correctness” is a myth.
• Culture drives decision making. Technical decisions follow culture, not the other way around.
• Growth in usage broadens the community using the software.
• Broadening use of software necessitates broadening of the participants building the software.
• Disparities between the users and participants will create tension.
• Threats to the sustainability of a community sustained project are inherently rooted in these tensions.

I expect that nearly every reader at this point is silently asking “What about project […]?” and recalling a case where some combination of funding, time, corporate influence, or all of the above were the cause of a problem.

I‘ll argue that these are all symptoms, or preferred solutions, to other problems in the fundamentals of the project itself. If you will indulge me in continuing to read through this thesis you may be able to look back at these projects and unwind their issues back to those fundamentals.

True technical “correctness” is a myth.

Modern software is not as simple as implementing an algorithm. All software is, at some point, presented to humans. Software infrastructure (software that we use to build other software) is presented to other developers and the vast majority of this software is open source and sustained by a community.

Perspectives on what to use, and how to use it, change with different use cases. As those use cases shift the demands on each piece of software shift. As the demographics of the users of software shift so do their expectations and preferences.

A front-end developer has differing preferences from a back-end developer. A developer in China often has additional needs to one in America. These needs are obvious when presented as technical distinctions (promises vs. callbacks) but are harder to recognize when they are cultural.

Developers with different social backgrounds have different expectations on how combative a discussion should be. Developers with more experience in open source have expectations about the formality of decision making. Developers from different timezones have a hard time participating in projects that hold meetings at specific times.

None of these have a “correct” answer. Projects that believe in this form of correctness will, as a necessity, ignore these differences in perspective. These are not “differences of opinion,” they are differences in the perspective of those who have power over decisions and those who do not.

Culture drives decision making. Technical decisions follow culture, not the other way around.

Code itself is not a culture. The decisions and scope of that code may attract different users and participants but the culture is derived from the participants.

Many projects assume that the scope and decision making structures they form up-front will define the boundaries of their culture. Culture, both in the user and participant community, is derived from people and their perspectives. Homogenous cultures are formed when gatekeepers and barriers to entry exist, not because of any technical constraints within a project.

If a project’s culture changes, its technical decision making will also change.

Our history is littered with projects that made very different decisions following changes in contribution policies and governance. The technical basis for the projects remained the same, but as the culture building the software changed so did the decisions they made.

Growth in use broadens the community using the software.

Use of technology is greatly expanding, as is the industry developing it. Usage and participation in community sustained software is also growing dramatically. Projects that are not growing in use do not occupy much of our conversation. Growth and success are almost the same words in the technology industry, which itself has presented many challenges in our sustainability.

As a project grows the users look less and less like the originators of the software. It’s hard to think of a “successful project” that wasn’t used for something the originators never even intended.

It is never the case that a widely successful and adopted project does not also broaden the use cases it is solving. As it solves different problems the people solving those problems also broaden.

Broadening use of software necessitates broadening of the participants building the software.

With broadening users comes differences in perspective. Differences in expectations about what the projects presents, how it is presented, and most importantly how it is developed and how additional people are allowed to participate in that development.

If a project’s participants continue to grow and broaden along with this adoption we don’t encounter sustainability issues. In fact, projects that have done this successfully are the models we look to when solving issues in other projects.

Disparities between the users and participants will create tension.

When participation does not broaden along with broadening users you will find tension. These tensions flare up in any number of ways, often unproductive and divisive. As the division between users and participants widens so will the tension.

Acute problems like burnout, issues/PR hostility, and other “sustainability issues” can be traced to these tensions.

For instance, a project that has overburdened contributors is always due to these tensions.

Remember, the “burden” they are dealing with is work that needs to be done to satisfy these users. Work these users cannot participate in themselves for reasons. Whatever these reasons may be, the disparity between users and participants is what makes this burden fall on a small enough number of participants that they are overburdened.

Threats to the sustainability of a community sustained project are inherently rooted in these tensions.

Project’s with strong communities can overcome and recover from any problem. Even very big technical challenges are routinely overcome by healthy communities.

But when a community isn’t healthy, when tensions are growing and reaching a critical mass, that’s where you see issues that actually threaten the sustainability of the project. If a community fails then the project it sustains fails.

The foundation of a community driven project isn’t a pile of code and technical decisions, it’s the participants and their culture. Only issues related to the participants and their culture are true sustainability issues.

Disagreements between participants are common, even expected. The process of building the software is the resolution of these disagreements.

Only tensions from the outside, tensions from perspectives not represented by the participants go unresolved. These unresolved tensions only continue to build as long as there are disparities between the participants and the users.

There is a tipping point at which these tensions undermine the sustainability of the project. A point at which even critical work can no longer be accomplished.

Conclusions

This theory doesn’t give you a singular solution to sustainability issues. Solutions tend to vary quite a lot with circumstances, but it does greatly narrow the scope of solutions.

The largest challenge of open source sustainability is forcing people with power to adapt to models that empower far more of their users at the expense of their own control.

Dumping money on a project is unlikely to solve anything if the disparity between those receiving the money and their users is the source of their problems.

I’ve also been very careful to use the term “participant” and not “contributor” throughout this theory. Non-code participation is the easiest way to broaden the culture, which leads to decisions being made that are much more representative of the user community.

While I call out this theory as specific to “software” it easily applies to many, although not all, community sustained projects that aren’t open source software.

Participation Death Spiral

Technical solutions to sustainability problems should be viewed quite skeptically. At most, technical solutions make incremental gains in maintainer output. But if a project is growing exponentially, as are the tensions with users, these solutions often entrench existing maintainers into workflows that are even harder to broaden to new sections of the community.

Because we look to maintainers to describe the problems of their projects we miss the tensions between participants and users. We have a dramatic over-emphasis on the needs of existing participants at the expense of challenging underlying problems which are often perpetuated, often unknowingly, by those participants.

Given enough time this creates a participation death spiral. More users create increasing demands on a project and existing participants react by ratcheting up on practices optimized for their workload. These changes create additional barriers to more users becoming new participants. As users continue to grow, so do tensions, and as participants continue to optimize for existing rather than potential participants their acquisition of participants falls as their workload grows until the project can’t continue to sustain even basic maintenance.