How to build and sustain a maintainer community

At Open Source Summit North America 2025, I had the opportunity to facilitate two unconference sessions: “How to Build and Sustain a Maintainer Community” and “Open Source Burnout: Prevention, Support, and Culture Change.” Both sessions sparked lively, collaborative discussions with attendees actively shaping the conversation. This blog features some of the discussed definitions, assumptions and key takeaways:

Definitions:

• A contributor: Someone who contributes code to the project and is considered the baseline for contributions. Contributors can have reviewer and/or maintainer privileges, though a majority of contributors do not have these privileges and are reliant on reviewers and maintainers to have their code submitted to the repo
• A reviewer: Someone who can review other people’s code contributions and have these reviews count towards ‘number of accepted reviews required’ to push code to the repo. Reviewers are also contributors in that they often are submitting code to be reviewed, and pushed to the repo.
• A maintainer: Someone who has the ability to push code and also has a large say in decisions involving architecture and code contribution.
• The Technical Steering Committee (TSC): A group that generally consists of elected maintainers and project leadership. They are usually the guiding voice on technical decisions for the project.  
• Special Interest Groups: These teams help break down large projects into areas of ownership and specialization, thereby helping to focus the knowledge scope of contributors, reviewers, and maintainers. For example, O3DE has 15 SIGs ( https://o3de.org/sig/) focused on areas such as graphics, security, content pipelines, supported platforms, networking, documentation, community management, CI/CD pipeline, and core engine code. 

From the discussions with about 30 attendees in the unconference sessions, several themes stood out with an emphasis on communication, respect for the community, and easy to follow and adhere to processes. 

Key Takeaways:

Communication: It is important to have a good, efficient, and easy to use discussion platform (ie, Slack, Discord, etc). This helps facilitate conversations between contributors, reviewers and maintainers. Communication is important to set expectations around consistency and quality of contributions, beyond just github PR reviews and comments. It creates an environment where contributors can ask questions and get feedback. This is especially important when it comes to maintaining consistency and quality across contributions—something that isn’t always easy to convey through code reviews alone. A means for near real time conversation is often important for hashing out difficult or potentially controversial contributions.

Community: When thinking about growing the reviewer and maintainer communities, it can be important to identify contributors who are active and most importantly, consistent in contributions. Consistency is important for these roles, as these are impactful roles that the project needs to trust to be present in a timely manner to avoid long stalls in the contribution pipeline.

Reviewers and maintainers need to reinforce the culture of the project and foundation, therefore it is important for a community and project leaders to understand and document expectations, as well as be willing to have difficult conversations with a reviewer or a maintainer who falls far outside of the culture. It was also discussed that maintaining a positive community that focuses on mentoring and learning, rather than just rejecting PR’s outright without explaining why, leads to more people feeling welcomed and comfortable to strive to be a reviewer and/or maintainer in the project. 

Trust: It is important to have a documented promotion process from contributor->reviewer->maintainer pipeline. This makes the process mostly objective, however the required trust aspect will always be subjective.

Trust, ability, and consistency are often the primary metrics used to determine if someone should be promoted to maintainer. How much trust is too much trust? Where does a project determine trust boundaries? Trust is earned, but how do you measure this? The issue of trust is why there should be a vote from leaders (SIG or project) as the last step to promote someone to a reviewer or maintainer. This vote covers the intangibles.   

Processes: SIGs should have the primary say for who is a maintainer for their areas of contribution. The TSC should have primary say in who is a maintainer across the project. These would be maintainers who can submit code across the entire project and are not bound by a single SIG.

It is important to remember maintainers are humans and not just a means to an end. Regular check-ins with the maintainers are important. How are they doing? How are they liking what they are working on? Anything leadership can do to help alleviate pain points? Also providing recognition and celebration of contributions. Another way to help out the maintainers is to have clear code contribution guidelines and automation to ensure these guidelines are being followed. 

Respect: Be cognizant of how much time is being invested by your reviewers and maintainers. They usually have the largest workload on a project, are passionate, and are prone to investing many hours into a project. Particularly if a reviewer/maintainer is on the project out of passion, rather than as a part of their job. These passionate contributors can be prone to accidentally burning themselves out as they care deeply about the project. 

To prevent this, it is important for project leadership to have regular discussions with their maintainers, as maintainers generally have the largest workload, to identify any issues and pain points before they can lead to burn out. It is also important for project leaders to encourage time away from the project (ie. vacations) and to have a succession plan in place in case a maintainer needs to take a sabbatical. A project’s contributors are people, and life happens to people, therefore a project needs to be prepared to be understanding about these situations and to be able to handle them effectively.

Building and sustaining a strong maintainer community requires strong leadership and community support. From fostering clear communication and recognizing contributions, to preventing burnout, the health of the maintainer community is directly tied to the long-term success of an open source project. By investing in the people behind the code, projects not only ensure technical continuity but also create a more welcoming, resilient, and collaborative ecosystem where maintainers can thrive.