index.md 6.0KB
title: Maintainer vs. Community
url: https://medium.com/open-source-communities/maintainer-vs-community-97edc28387ad
hash_url: 4d5851d18f
The increasing tension in how we build sustainable open source.
Open Source Sustainability is a hot topic these days. Everyone seems to be thinking about how we sustain the success we’ve had in open source adoption as the demands on contributors also grow.
In these discussions I’ve noticed a distinct disparity between two points of view. There is a maintainer centric view and a community centric view. These different views color not just how we frame solutions but also in how we understand the problem.
And because we have different understandings of the problem it has become increasingly difficult to collaborate.
The Maintainer Centric View
As adoption of open source accelerates so do the demands on those that maintain open source. Maintainers are increasingly frustrated and burnt out.
From this point of view the maintainers need to be protected from the worst parts of this growth and given tools to help them manage this ever increasing work load.
From this view a pull request that isn’t ready to merge is a liability. A bug report without steps to reproduce is a waste of time.
The solution to sustainability is to fund maintainers so their limited time can be more dedicated to important tasks. The solution is to add issue templates and bots that don’t allow any random person to access maintainer time until they can ensure that time is spent on something meaningful.
The Community Centric View
As adoption of open source grows so must the contributors to the projects being adopted. Growing the community’s competencies is the only way to handle ever increasing demands on a project as it is adopted.
From this point of view any “problem” in a project, anything that is not sustainable, is a deficiency in that project’s community to be remedied. Poor behavior is due to poor incentives. Too much workload on maintainers means there aren’t enough maintainers and that is likely due to a lack of incentives and tools to educate and retain more of them.
From this view a pull request not yet ready to merge is an educational opportunity and a lead on a potential future maintainer. A bug report without steps to reproduce is a window into a community member more representative of the project’s average user than a current maintainer.
The solution to sustainability is to build processes that can grow contributors and maintainers at the same rate the project is being adopted. Tooling and automation are there to help contributors, not to gate keep against new participants.
Exponential Growth
These views can also be viewed as a spectrum, with many sustainability ideas falling somewhere in between.
The problem with solutions along this spectrum, solutions that are not firmly from the community centric view, is that they can only, at best, offer incremental improvements to these projects.
It’s hard to imagine a new tool that makes more than incremental improvements in maintainer workflow. It’s hard to imagine a new funding mechanism that can double the number of existing maintainers.
Regardless of what view you have the problems we’re dealing with are exponential. Demands on projects track with their adoption and incrementally adopted open source projects aren’t the ones dealing with sustainability issues. In open source “successful projects” are the ones that experience exponential growth in their adoption.
The title of “Maintainer” is reserved for those already engaged in the project. “Community” refers to a project’s entire ecosystem, including its users. Solutions to sustainability that are not anchored to the community can’t scale along with a project’s adoption.
While I empathize with maintainers burning out and asking for support, trying to tackle sustainability from a maintainer centric view is a to paddle against the flow of the river. We continue to see barriers to adoption and participation fall away, enabling a new generation of contributors to be involved as long as we can view them as part of the solution rather than the problem itself.
Developers like to think they code their way out of any problem. We know how to scale servers but most of us are inexperienced with scaling people. It’s easy to fall into the trap of thinking of PR’s and issues as units of data to scale in a pipeline. The problem is that every PR, every issue, was created by a human being and, depending on how you view them, they can be a participant or a liability.