mailwal

How VillageSQL does open source

The Village Crier

When a commercial entity says they are working on an open source database, community members fairly ask what that means to them. They also ask if the same rules apply to everyone or just the company’s employees. Can an outsider see what's planned? Does a pull request from a stranger go through the same process as one from an employee? This blog post explores how VillageSQL approaches open source by stepping through how we are operating the VillageSQL Server project. VillageSQL Server is the open source tracking fork of MySQL that adds an extension framework to enable permissionless innovation on MySQL.

GPLv2, inherited from MySQL

VillageSQL Server is licensed under the GNU General Public License version 2 (GPLv2), because that is how upstream MySQL is licensed and VillageSQL inherits that due to the copy left nature of GPLv2. The VillageSQL extension framework carries the same license and so do the VillageSQL authored extensions built from it.

We take community contributions to the extension framework. When we get contributions, we get a permanent license to the code as is standard with CLAs based on the Apache Foundation guidelines (including VillageSQL’s). We don't get ownership. Oracle accepts contributions to MySQL under the Oracle Contributor Agreement (OCA), which gives Oracle joint ownership of each contribution. Because of that clause, we can't send anything that contains community contributions back to mainline MySQL.

Planning in public

We work on VillageSQL Server in the open on GitHub: pull requests, issues, discussions, and planning. The contributing guide documents each step of a contribution, and the documentation works the same way (except it’s in its own public repository). We keep a few repositories private, such as the website and the managed service we're building, but the server and everything related to it is open on GitHub.

We treat GitHub Issues as the source of truth for VillageSQL Server. Planned work, work in progress, and shipped work all live there, and a public project board organizes those issues by milestone and status. When anyone submits a new issue, whether a VillageSQL employee or an external contributor, it starts on the board with no status and no milestone. Once a week, we triage these issues and assign each one a status and a milestone.

So if you want to know what's coming in the next release, you can read the same board we do. If you want something that isn't there, you can file an issue or upvote one that already exists. If you want to work on an issue, comment /assign on it and the bot assigns it to you.

One set of rules for every repository

Every contributor, whether they work at VillageSQL or not, follows the same written rules, and a bot applies those rules the same way to everyone. Because the rules are written down and the bot applies them, you can see what your pull request still needs without asking anyone. The bot is Prow GitHub Actions, a Cloud Native Computing Foundation (CNCF) project.

It enforces a few rules when you submit an issue or a pull request:

  • Give it a kind and an area. Comment /kind bug or /area vef, for example, and the bot applies the label. Until a pull request has both, the bot marks it needs-kind or needs-area. An issue needs a kind.
  • Link the issue. Add Closes #123 to a pull request that resolves issue 123, so the issue closes when the pull request merges.
  • Sign the CLA. A check on each pull request asks you to sign the contributor license agreement.
  • Pass the build and a review. A pull request needs a passing build and an approving review before it merges.
  • Write it yourself. Pull request descriptions, commit messages, issue descriptions, and replies to reviewers should be written by you, without help from AI. In the contributing guide's words: "We want to talk to you, not your LLM."

These rules live in one file, prow.yaml, in our public .github repository. That one file configures every repository that runs the bot, including VillageSQL Server, the docs, the Rust SDK, and all of our extensions. When we add a label or change a rule, we change it once, in public, for all of them. Kat Cosgrove, who is VillageSQL’s Developer Advocate, is a contributor of cncf/prow-github-actions.

Why we think openness is so important

We want the way we work to inspire the MySQL community and act as an experimentation platform for open governance and development structures. Oracle has taken real steps to open up MySQL development, including taking bug reports and pull requests on GitHub, and we wrote about MySQL's new governance model when Oracle announced it.

The practices we chose to adopt and which are outlined in this post are ones any MySQL project can copy: plan in public, and write the contribution rules down where everyone can read them. If more MySQL projects work this way, contributors across the ecosystem can see what's planned and how to contribute, and that's the outcome we care about.

If you want to get involved, start here: