Hear Ye, Hear Ye: A Guide to MariaDB’s Governance Model
Be it known: MariaDB Server now has a clearer, publicly documented governance framework covering technical roles, subsystem ownership, decision-making, response expectations and continuity.
Open source begins with access to the code. Yet for infrastructure expected to remain dependable for many years, openness must also extend to how responsibility is assigned, how decisions are made, and what happens when people disagree or move on.
The framework formalises much of how the project has long worked, while making its responsibilities, decision paths and commitments clearer and easier to inspect.
The central principle is simple: authority should be visible, earned and connected to responsibility.
Meet the neighbourhood
MariaDB Server is divided into technical subsystems, each with identified maintainers responsible for its architecture and long-term health. Every part of the server belongs to exactly one subsystem, with Server Core as the default, so nothing is ever nobody’s job.
There is also a clear path through the project’s technical roles.
A contributor is anyone who submits a change, bug report or review. No standing commitment is required.
A committer is a contributor sponsored by one or more maintainers and granted the technical ability to push to the repositories. Commit rights do not carry approval rights, and every change still requires review.
A reviewer is a committer recognised as a reliable reviewer for a subsystem. Reviewers may formally approve contributions and are responsible for the quality of what they approve.
A maintainer is a reviewer responsible for an entire subsystem, including its architecture and health. Where a subsystem has several maintainers, they hold equal authority.
Across subsystem boundaries, stewards hold maintainer-level rights for the whole server without carrying responsibility for one particular subsystem. They can act as tie-breakers when maintainers disagree.
All maintainers and stewards together form the Maintainer Council, which handles decisions affecting the project as a whole.
Life happens
People change jobs, take breaks or move on. The project must continue regardless.
If a subsystem loses its last permanent maintainer, its status becomes explicit rather than allowing responsibility to disappear quietly. The stewards review it within ten working days and arrange interim coverage.
Its longer-term future is then resolved openly. A permanent maintainer may be appointed, or the Maintainer Council may decide to merge the subsystem into another maintained area or eventually retire it through the normal process.
The same commitment to continuity applies to users. Features cannot simply disappear from one supported release to the next without advance warning. MariaDB’s deprecation policy provides time to adapt, while development rules require review, preview releases and independent testing before new features reach general availability.
Governance therefore supports continuity on both sides of the project: responsibility for the code remains visible, and users receive greater predictability as the server evolves.
No more guessing games
The same rules bind everyone.
Affiliations are recorded in the maintainers list for transparency, but authority within the project comes from the role a person holds, not from their employer.
Today, most maintainers are employed by MariaDB plc, while replication is co-maintained by Kristian Nielsen as a community maintainer. The process itself is open to contributors of any affiliation who demonstrate the expertise, trust and sustained responsibility the role requires.
Technical decisions should not depend on private understandings or assumptions about what silence means.
Under the governance model, silence is not approval. Decisions must be explicit and recorded in GitHub or Jira.
Decisions affecting one subsystem belong to its maintainers. Changes spanning several subsystems require the relevant maintainers to agree. Project-wide matters, including changes to the subsystem structure, are handled by the Maintainer Council.
The framework also includes response times and escalation paths. Contributions and decisions should not remain indefinitely in limbo because somebody has stopped responding.
Healthy debates and a way forward
Put a group of experienced engineers around a difficult technical decision and disagreement is inevitable. That is healthy.
The governance model does not try to eliminate debate. It provides a dependable way to resolve it.
Maintainer disagreements can be referred to a steward. Project-wide disputes can be decided by the Maintainer Council. Changes to the governance framework itself require a broader supermajority.
There are also carefully bounded safeguards that can pause a consequential decision and require reconsideration, without allowing one individual to block the project permanently.
Technical authority remains with the people responsible for the code. The MariaDB Foundation provides institutional continuity and a final mechanism for exceptional deadlocks.
Open by design, built to last
Governance should provide stability without freezing the project in time.
The framework can itself be changed through the process it defines. Maintainer and subsystem information will remain publicly available, making responsibility easier to understand for contributors, users and organisations building on MariaDB.
Open by design means more than publishing source code.
It means making technical authority visible, connecting it to accountability, recording decisions and preparing for continuity before it is needed.
That is part of what makes open infrastructure dependable.
Put us to the test
Everything described here is public: the governance documents, the maintainers and subsystems list, and the response commitments the project now owes you.
The best way to test a written promise is to use it: send a contribution and start the seven-day clock.
Better still, make a significant contribution, stay to take responsibility for it, and begin your path towards becoming a maintainer.
We cannot promise shiny armour, but the commit rights are real.
