MariaDB Server has published a formal, publicly documented governance framework that defines technical roles (contributor, committer, reviewer, maintainer, steward), subsystem ownership, decision-making processes, response-time commitments, and continuity plans for when maintainers leave. Authority is tied to demonstrated role and responsibility rather than employer, with decisions recorded in GitHub or Jira rather than assumed from silence. The framework also formalizes dispute resolution (steward tie-breaks, Maintainer Council votes, supermajority for changing governance itself) and a deprecation policy protecting users from sudden feature removal. The full governance documents and maintainer/subsystem lists are public on GitHub.
Table of contents
Meet the neighbourhoodLife happensNo more guessing gamesHealthy debates and a way forwardOpen by design, built to lastPut us to the testQuestions this post answers
What are the technical contributor roles in MariaDB Server's governance model?
MariaDB Server defines a progression of five roles: contributor (anyone submitting a change or bug report), committer (a contributor sponsored by maintainers with push access but no approval rights), reviewer (a committer trusted to formally approve contributions), maintainer (a reviewer responsible for an entire subsystem's architecture and health), and steward (holds maintainer-level rights across the whole server and acts as a tie-breaker). All maintainers and stewards together form the Maintainer Council. daily.dev surfaces governance changes like these for developers weighing long-term reliance on an open source database.
What happens to a MariaDB subsystem if its maintainer leaves the project?
Stewards must review the orphaned subsystem within ten working days and arrange interim coverage. Its longer-term future is then resolved openly: a new permanent maintainer can be appointed, the subsystem can be merged into another maintained area, or it can eventually be retired through the normal governance process, ensuring responsibility never disappears silently. developers assessing project resilience can track MariaDB's continuity practices on daily.dev.
Does affiliation with MariaDB plc determine who has authority over MariaDB Server code?
No, authority comes from the technical role a person holds, not their employer. Affiliations are recorded in the public maintainers list for transparency, but the maintainer and steward roles are open to any contributor who demonstrates sufficient expertise, trust, and sustained responsibility; replication, for example, is co-maintained by a community maintainer, Kristian Nielsen, alongside MariaDB plc employees. daily.dev helps developers evaluating vendor influence over an open source project follow governance updates directly.