MySQL Community Governance Model
Open Development and Community Participation
Table of Contents
- Overview
- Guiding Principles
- Governance Structure
- Decision Making Model
- Development Model
- Contribution Model
- Proposal Process
- Release Model
- Issue Tracking and Backlog Management
- Conflict Resolution
- Code of Conduct
- Security and Exceptions
- Community Participation Goals
- Disclaimer
- FAQ
1. Overview
MySQL has grown through the contributions, feedback, and collaboration of a global community of developers, users, customers, and partners.
This governance model is designed to strengthen and expand that collaboration by creating clear, transparent, and inclusive pathways for participation in the evolution of MySQL.
The goals of this model are to:
- Encourage broad and meaningful community participation
- Foster transparent and collaborative technical decision making
- Enable faster feedback and iterative improvement
- Maintain the high standards of quality, security, stability, and compatibility expected from MySQL
- Build a sustainable and welcoming open source ecosystem around MySQL
This model is intended to evolve over time as the MySQL community, tooling, and development practices continue to mature. The approach balances openness with the responsibility of maintaining a stable and trusted database platform relied upon worldwide.
2. Guiding Principles
2.1 Open Collaboration with Progressive Adoption
MySQL is committed to increasing openness and community engagement.
The initial phase focuses on publishing release artifacts and enabling collaboration around released code. Future phases may expand toward more real-time public development, open design discussions, and broader participation as processes and tooling evolve.
2.2 Transparent Processes
Technical discussions, proposals, and decisions should be documented and made publicly accessible whenever practical.
Clear communication helps build trust, encourages participation, and improves collective decision making.
2.3 Merit Based Participation
Participation and leadership opportunities are based on demonstrated expertise, quality of contribution, collaboration, and sustained engagement with the community.
Community members are encouraged to grow into larger responsibilities over time.
2.4 Shared Stewardship
Oracle continues to provide long-term stewardship for MySQL while actively fostering meaningful community participation and ecosystem collaboration.
The project benefits from contributions and perspectives across users, customers, partners, hyperscalers, and the broader open source community.
2.5 Quality, Stability, and Security First
Every contribution should uphold MySQL’s standards for correctness, performance, compatibility, reliability, and security.
Maintaining trust in the platform remains a core responsibility shared across the community.
3. Governance Structure
The governance model defines several participation and leadership roles within the MySQL ecosystem. These roles help support healthy collaboration, maintain technical quality, and ensure sustainable project stewardship.
All roles are based on active participation, demonstrated contribution quality, and ongoing community engagement. Roles may evolve over time and participation expectations apply consistently across the project.
3.1 Contributors
Contributors are community members who participate in improving MySQL.
Anyone interested in helping improve the project is encouraged to contribute, whether through code, testing, documentation, bug reports, design discussions, reviews, or community support.
Eligibility
- Open to all participants
- Willingness to follow contribution, testing, and documentation guidelines
Responsibilities
Contributors are encouraged to:
- Submit focused and well-documented contributions
- Provide:
- Clear problem statements
- Technical rationale
- Appropriate test coverage
- Documentation updates where applicable
- Participate constructively in discussions and reviews
- Respond to review feedback in a timely and collaborative manner
Contributor Expectations
To help maintain project quality and efficiency, contributors should avoid:
- Repeated submission of incomplete or untested changes
- Ignoring review feedback or project guidelines
- Violating community or contribution standards
3.2 Committers
Committers are experienced contributors who help maintain the quality, consistency, and reliability of the codebase.
In addition to contributing code, committers play an important role in reviewing changes, mentoring contributors, and supporting healthy technical collaboration across the project.
Eligibility
- Consistent history of high-quality contributions
- Strong understanding of coding standards, testing practices, and design principles
- Active participation in reviews and technical discussions
Initially, committers will consist of individuals nominated by Oracle, with the expectation that participation expands over time as the community grows.
Responsibilities
Committers help ensure contributions meet project standards by:
- Performing detailed technical reviews
- Verifying:
- Correctness and completeness
- Adequate test coverage
- Adherence to coding and design standards
- No unintended regressions or performance degradation
- Providing clear, actionable, and constructive review feedback
- Escalating complex or high-impact changes to Project Leads when appropriate
Review Expectations
- Maintain thoughtful and thorough review quality
- Follow established review and merge processes
- Avoid conflicts of interest when reviewing related changes
- Remain actively engaged with the project over time
Committers may not approve or merge their own changes.
Promotion Guidelines
Typical indicators for promotion from Contributor to Committer may include:
- 5–10 accepted contributions over time
- High contribution acceptance rate
- Meaningful review participation
- Demonstrated responsiveness to feedback
- Contributions to testing and project quality
Existing committers may nominate contributors for promotion, and approved after review and consensus among existing committers.
3.3 Project Leads
Project Leads provide technical leadership and stewardship for specific MySQL components or subsystems.
They help guide the long-term evolution of their areas while ensuring stability, maintainability, and alignment with overall project goals.
Examples may include areas such as InnoDB, optimizer, runtime, tools, replication, or other major subsystems.
Eligibility
- Deep expertise within a subsystem
- Sustained high-quality technical contribution
- Proven ability to review complex changes
- Strong collaboration and conflict resolution skills
Initially, Project Leads will be identified and nominated by Oracle.
Responsibilities
Project Leads are responsible for:
- Providing final technical approval for major changes within their component areas
- Reviewing changes that significantly impact:
- Correctness
- Performance
- Compatibility
- Stability
- Helping align component changes with long-term architectural goals
- Resolving technical disagreements within their area of ownership
- Supporting maintainability and healthy subsystem evolution
Stewardship Expectations
- Consistently uphold quality standards
- Exercise balanced technical judgment
- Maintain active involvement in component stewardship
- Encourage collaboration and constructive technical discussion
Promotion Guidelines
Typical indicators for promotion from Committer to Project Lead may include:
- 30–50 high-quality contributions in a subsystem
- Significant review participation demonstrating technical depth
- Ownership of features, refactoring, or architectural improvements
- Demonstrated ability to balance innovation with stability and compatibility
Current Project Leads may nominate committers for promotion.
3.4 Core Project Leads
Core Project Leads help maintain the overall technical coherence, release quality, and long-term stability of the MySQL platform as a whole.
They operate across subsystem boundaries and help guide large-scale architectural and release decisions.
Eligibility
- Deep system-wide expertise
- Experience managing large-scale releases
- Strong technical judgment balancing innovation, risk, and operational stability
Responsibilities
- Maintaining overall technical coherence across the project
- Overseeing release readiness and release policy
- Reviewing high-impact and cross-component changes
- Approving, deferring, or rejecting changes based on readiness and risk
- Ensuring overall system quality, reliability, and compatibility
Stewardship Expectations
- Exercise careful system-wide judgment
- Maintain release quality standards
- Consistently uphold governance and technical review expectations
- Balance forward innovation with operational stability
Promotion Guidelines
Typical indicators may include:
- Leadership in cross-component initiatives
- Significant participation in architectural discussions
- Successful coordination of complex technical changes
- Proven ability to guide large-scale efforts while minimizing regressions
3.5 Steering Committee
The Steering Committee provides long-term technical and community governance for the MySQL ecosystem.
The committee helps ensure balanced representation, sustainable project direction, and healthy collaboration across the broader MySQL community.
Eligibility
- Broad understanding of MySQL architecture and ecosystem needs
- Proven ability to navigate complex technical and community decisions
- Interest in helping shape the long-term development process
The Steering Committee is intended to include representation from:
- Oracle
- Organizations implementing MySQL including other Hyperscalers
- Active users of MySQL
- Open source community participants
Initial committee members will be nominated by Oracle, for a term of 2 years. After the initial two year term, elections will be held for non-Oracle seats.
Responsibilities
- Reviewing major cross-component proposals
- Helping shape long-term roadmap direction
- Serving as the final authority for strategic technical decisions
- Defining release policy and broader governance direction
- Supporting a healthy and sustainable ecosystem
Participation Expectations
- Consider system-wide and ecosystem-wide impact
- Participate consistently in governance discussions
- Exercise balanced judgment across competing priorities
- Remain actively engaged in long-term project stewardship
Member Selection and Rotation
Typical indicators for participation may include:
- Leadership in architectural discussions
- Cross-component collaboration
- Long-term community engagement
- Contributions to ecosystem growth and governance
Every two years, non-Oracle representatives on the steering committee will be elected by the community. Long-serving members may transition into emeritus roles over time.
3.6 Vulnerability Group
The Vulnerability Group is a trusted team responsible for coordinating security-related matters for the MySQL project.
Eligibility
- Core project leads from within Oracle
- Security experts. These can also be members of the steering committee
Responsibilities
- Receiving and validating vulnerability reports
- Assessing severity and impact
- Coordinating fixes and responsible disclosure
- Protecting users through careful handling of sensitive security issues
Participation Expectations
- Exercise discretion and sound judgment
- Follow responsible disclosure practices
- Coordinate carefully with affected stakeholders
- Maintain active participation in security response activities
External security experts may participate following appropriate review and vetting processes.
4. Decision Making Model
- Minor code changes: Approved by committers
- Major code changes: Approved by project leads
- Cross component changes: Reviewed by core project leads
- Release decisions: Made by core project leads
- Strategic direction: Set by steering committee and may involve a future board
- Escalation path: Contributor → Committer → Project Lead → Core Project Lead
5. Development Model
5.1 Current Operating Model
- Development primarily occurs internally
- Select worklogs are published in advance, for the community
- Source code is published to GitHub following each release
- Public collaboration through issues, discussions, and pull requests on released code
5.2 Future Direction
Over time, MySQL aims to expand toward:
- More open development workflows
- Earlier public design discussions
- Increased collaboration during active development
The pace of this evolution will depend on tooling maturity, operational readiness, and community growth.
6. Contribution Model
All contributions follow a structured review and validation process designed to maintain quality while encouraging broad participation.
6.1 Contribution Flow
- Submission: Contributor submits a pull request with required tests and documentation.
- Review: One or more Committers perform detailed technical review. Additional reviewers may be required based on complexity.
- Approval:
- Minor changes (changes that are minimal and isolated): Approved by Committers
- Major or sensitive changes: Require Project Lead approval
- Cross-component changes: Core Project Leads
- Merge: Changes may be merged after required approvals are complete, automated checks pass, and review concerns are resolved.
- Release Integration: Release inclusion is coordinated through project leadership and release governance processes.
6.2 Contribution Requirements
- Submission through GitHub
- Compliance with project license and contributor agreement
- Required testing and documentation
- Adherence to coding and design standards
6.3 AI Contributions
- AI contributions will be accepted but need to be appropriately tagged
- Contributions written mostly or entirely by AI need to be tagged as “AI generated”
- Contributions with AI assisted components but with substantial human written code need to be tagged as “AI assisted”
7. Proposal Process
- Draft proposal submitted in discussions
- Community feedback gathered
- Reviewed by project lead or steering committee
- Decision made to accept, reject, or revise
- Accepted proposals implemented through pull requests
- Accepted proposals are documented
8. Release Model
8.1 Release Stages
- Development
- Feature freeze
- Code freeze
- Final release
8.2 Release Rules
- Features must be complete before feature freeze
- Only critical fixes are allowed after code freeze
- Final release must meet stability and quality criteria
- Incomplete features move to the next cycle
8.3 Early Access Releases
- Regular cadence
- Include features, fixes, and release notes
- Enables continuous feedback and validation
9. Issue Tracking and Backlog Management
GitHub Issues is the primary system of record.
Technical discussions also happen on GitHub.
9.1 Backlog Management
- Remove stale or duplicate issues
- Prioritize bugs based on criteria like crashes, wrong results, performance, etc.
- Track backlog to ensure that it stays contained
10. Conflict Resolution
- Discussion among contributors and reviewers/committers
- Decision by project lead
- Escalation to core project lead which makes the final decision
- All decisions include documented rationale
11. Code of Conduct
The MySQL Code of Conduct requires all participants to maintain high ethical standards and promote a safe, inclusive environment. It strictly prohibits harassment or discrimination based on protected characteristics (such as gender, race, age, and sexual orientation). Participants who engage in inappropriate activity risk losing access.
12. Security and Exceptions
12.1 Security Issues
- Private reporting channels
- Coordinated disclosure to the vulnerability group
- Review by vulnerability group
- Security fixes will not be included as part of Early Access releases
- Anyone who is part of the vulnerability group must sign the vulnerability group NDA
12.2 Exceptions
Licensing, trademarks, and legal matters remain under Oracle authority. Individuals are expected to sign the Oracle Contributor Agreement (OCA).
13. Community Participation Goals
- Increase participation and contributor diversity
- Improve collaboration and development velocity
- Maintain high product quality
- Build trust through transparency and consistency
- Create clear pathways for community leadership and stewardship
14. Disclaimer
This governance model may evolve over time as the MySQL community, tooling, development practices, and ecosystem needs mature. Participants may propose an amendment to improve the governance model.
Proposed amendments should describe the requested change, the reason for the change, the affected governance sections, and the expected impact on the project and the community.
Amendment proposals should be shared publicly for community feedback. After review, the Steering Committee may approve, reject, or request revisions to the proposal. Major amendments affecting project roles, decision-making authority, election process, security processes, or release governance should receive broader community review and include a documented rationale.
Oracle will continue to be the project’s primary steward, helping guide its direction, releases, and intellectual property processes in collaboration with the community.
15. FAQ
15.1 How are the members of each of the groups selected? How many in each group?
- Contributors - Anyone can be a contributor (refer to AI contributions doc for additional details).
- Committers – To start with, we want this team to consist of individuals from Oracle. As the ecosystem evolves, we will start expanding the set of committers based on promotion criteria listed above.
- For features that are not part of server core such as extensions, connectors, plugins etc., contributors from the community will also have committer privileges.
- Project leads – Area experts (tools, optimizer, runtime, InnoDB etc.) from within Oracle. People can get promoted as project leads based on the promotion criteria listed above.
- Core Project lead – Oracle is the project lead for MySQL community edition.
- Steering Committee – This will initially consist of a small group of 5-7 individuals that represent Oracle (majority), other hyperscalers, users of MySQL, and members of the open source community.