How open source project governance and maintainer roles work
BDFL model, committee governance, maintainer burnout, core team vs contributors, decision-making processes, governance documents, sponsorship models
Who Decides What Gets Merged?
Open source projects are not democracies where every contributor votes on changes. Understanding governance tells you who has final say and how to get your work prioritized.
Common Governance Models
BDFL (Benevolent Dictator for Life) -- One person has final authority. Python used this model under Guido van Rossum until 2018. Fast decisions, single point of failure.
Core Team / Steering Committee -- A small group of trusted maintainers votes on significant changes. Most major frameworks (React, Vue, Node.js) use this. RFCs drive large decisions.
Foundation-backed -- Linux Foundation, Apache Software Foundation, CNCF. Legal entity owns the project, sets policy, handles money.
The Maintainer Burnout Problem
Maintainers are often unpaid volunteers managing hundreds of issues. Good contributors reduce burden -- they write tests, update docs, respond to review feedback quickly, and help triage issues. Bad contributors create more work: vague PRs, no tests, ignoring review comments.
If a maintainer is slow to respond, they are probably overwhelmed. Follow up once after two weeks, then move on. Projects publish governance documents in a GOVERNANCE.md file. Read it for any project you plan to contribute to regularly.