Back to the drawing board. Let’s not merely repackage same-same, let’s not merely describe what we do. Let’s instead go back to first principles: What should we do?

Refiguring the process – from descriptive to prescriptive

In January, we spoke with a number of universities in several countries. We’re still in the early stages of setting up a MariaDB for Universities Program, and our goal is to be able to offer something valuable to universities. An open source RDBMS is a great way to easily learn about databases.

Streamlining means making contributors wait less, and give them guidance at the right point in time.

Our goal is to facilitate making MariaDB Server the default RDBMS for RAG and Vector storage.

Mixing the fresh with the experienced

Luckily, we got professional guidance from many Board members, particularly from Rohit de Souza of MariaDB Corporation and Jignesh Shah of Amazon AWS, both fairly recent in their Board membership – thus able to provide a fresh take.

At the same time, it was valuable to get their input further refined by the judgement from long-term board members, such as Steve Shaw and Sean Peng.

With January as an example, let me walk you through our goals.

1. Community Analysis: Know where we stand!

Which database do new developers use? The one they used when learning!

Focus, focus, focus! That’s the mantra of any successful organisation. With great input from our Board, we’ve managed to condense our strategic planning for 2025 into six goals.

We are engaging with universities in understanding how they organise their tuition, how students learn about SQL and DBMSes. MariaDB, with its focus on ease of use, makes for a great database to learn the fundamentals of SQL with. Can we help making MariaDB Server the sample database?

What is a great sign of a vibrant user community? A vibrant developer community!

2. Contributions: Make MariaDB vibrant as a developer community!

We note the contributions are not just code contributions in the form of Pull Requests on the MariaDB Server repository. They can also be documentation contributions, bug reports, and feature requests in Jira. We are working on streamlining the processes involved in this.

Our goal is to get this message out. At the same time, we want it to become even easier to migrate off MySQL to MariaDB. It’s hard to beat the less-than-ten-minute live production migration off MySQL 5.7 to MariaDB 10.11. But we’re working on simplifying any MySQL-to-MariaDB upgrade: Identify obstacles in ecosystem, product, compatibility, documentation.

Clearly, our focus is to drive adoption. Use MariaDB Server! Wait, don’t just use MariaDB Server in general – for development, go use the current release, with the current features!

Whom exactly should MariaDB Foundation be serving? We need a better answer than what we already have.

The metrics work in January has still been internal. Expect to hear about our MariaDB Adoption Index later; it’s intended to be a reasonably accurate metric for the size of the MariaDB community, given numeric information readily available.

What’s a no-brainer? That MariaDB Foundation should drive adoption of MariaDB Server.

3. Outreach: Evangelise the current and potential users to drive adoption!

What feature drives adoption through entirely new users? MariaDB Vector!

Streamlining also means making a clear process distinction between pull requests coming from MariaDB Corporation / MariaDB Foundation and those originating from the contributor community. We will become more granular in our metrics. We want to come with more meaningful contributor numbers, rather than just noting that the number of open pull requests has reached an all-time high (252), and that we closed 699 PRs in 2024 – a big increase from 454 in 2023.

In January, we reached out to open source projects on GitHub that mention MySQL compatibility but not MariaDB in their readme. Several added MariaDB within a couple of days.

One way to get more professional (thank you Jignesh!) is to synchronise our outreach with the exact MariaDB Server release plan. This means a quarterly delivery pattern of content, using web based material, self-organised events, and outside conferences.

Hence, to express our goal 1 more abstractly, it is to acquire and refine qualitative and quantitative understanding of MariaDB usage (qualitative referring to logics, and quantitative to metrics). We also explicitly want to grow and focus on the part of our community that we know on a first-name basis, something we’ve called our named community.

4. Vectors & AI: Bring in new users to MariaDB Server!

We’re happy to note lots of progress in January 2025:

In January, Daniel Black attended Everything Open Adelade, in Adelaide, Australia. We prepared for future events, such as MariaDB Day and our stand at FOSDEM in Brussels.

For 2025, this means special attention to MariaDB 11.8, which is our next LTS (long-term support) release, with GA planned for May. Its flagship feature is MariaDB Vector.

Our claim is that MariaDB is the future of MySQL. It’s growing. It’s compatible. It’s innovative. It has accumulated numerous features beyond MySQL over the past 15 years, and its vision for Vectors is Open Source, not limited to the cloud.

5. Enable MySQL users to use MariaDB even more easily!

Our goal setting started from mapping out our activities 2024. I asked myself: “How can we describe what we do on one page?”. There were 38 activities – think “Scrum Epics” – in 6 areas.

That’s it for now! We’d love to hear your feedback about our goal setting, including feedback about individual goals.

Our claim: Vectors should be stored in a standard, relational DBMS. As Open Source. Without introducing new components into your stack. Ok, you may have to swap MySQL for MariaDB, but that swap is easy.

Guess what? That’s too many. No Board member is interested in that level of detail. Oh well, I should have known.

6. MariaDB for Universities Program: Support database tuition with MariaDB!

Being open source, we don’t know all of our users. We don’t even have an exact measurement of the size of our community. A reasonable goal, “grow the community by 15 % in 2025”, is thus meaningless – for the lack of proper metrics.

Those who contribute to the MariaDB Server repository on GitHub are most frequently with MariaDB Corporation. As we noted in our Contribution statistics January 2025, 84 % of the lines of code come from MariaDB Corporation, and another 8 % from MariaDB Foundation itself. We want to increase the number of external contributions.

Where do we expect these new contributors to come from? From the current users of MariaDB, who by definition are developers – and we want to make it easy for them to develop code also for MariaDB Server.

What next?

For whom is an upgrade to MariaDB the easiest? The MySQL users!

Similar Posts