MariaDB & Ecosystem Fragmentation

We hear you, Kristian Köhntopp! Thank you  for taking the time to articulate what many others are probably thinking.

For those of you to whom this sounds cryptic, let me share how I interpreted Kristian Köhntopp’s blog MySQL: Ecosystem fragmentation (https://blog.koehntopp.info/2020/10/28/
mysql-ecosystem-fragmentation.html
), published last week:

Kristian noted that the question “Which version of MySQL do you run on?” for a long time hasn’t been merely answered by a simple version number, since there are reasons to perceive MariaDB and Aurora to be “variations to the same theme”. 

On top of having a common root codebase forked into three trademarks (MariaDB, MySQL, Aurora), he notes a commercial dichotomy (Community, Enterprise). And he points out that the exact available functionality isn’t just dependent on the combination of the above two dimensions with a particular version number. Platform dependent functionality (on-prem, cloud) adds to the complexity. This makes the ecosystem fragmented and Kristian Köhntopp sad. And J-F Gagné too.

Kristian adds that the complexity causes incompatibilities and discourages third parties from putting their energy into the joint “frenemy codebase” of MySQL derivatives, giving Postgres more attention than before. 

All in all, the ecosystem “frenemy” behaviour shows indifference to the developer experience of a diverging codebase, with the parties innovating in different directions.

Correctly understood so far, Kristian?

Now, this invites a comment by the MariaDB Foundation. 

Kristian and others may expect us to reply with a self-glorifying MariaDB spin. “It’s not our fault. We’re doing great. We’re model ecosystem citizens. If only the others were as benevolent.” And conveniently forget about any of our own deficiencies.

MariaDB’s own view of the differences between MariaDB 10.5 and MySQL 8.0

We’ll try to do better, but this reply may still have some elements of attempts at point scoring. And the reply comes from the inevitable insight that we at MariaDB Foundation can only speak for ourselves. Not for Oracle, not for Amazon, and not even for MariaDB Corporation – the other key players affecting the issues addressed by Kristian Köhntopp.

Let me start by acknowledging Kristian’s view. To state the obvious: His observations are correct and his points clearly relevant. The products certainly form a joint ecosystem, despite many differences and incompatibilities. One could even add AliSQL from Alibaba, TSQL from Tencent, Percona Server, and the dimension of having or not having Galera Cluster as an add-on.

The one item I might slightly object to is the positioning of PostgreSQL. PostgreSQL has a lot more forks than MySQL/MariaDB, as witnessed by https://wiki.postgresql.org/wiki/PostgreSQL_derived_databases.

Some may argue that the existence of a lot of forks shows that the project is highly successful, especially if the forks share code from time to time. Others find it confusing. Both are right in the sense that forks is one effect of working with Open Source projects.

Let me continue by pointing out how MariaDB is different. Better, we’d like to think, but that’s for the developers and product users to judge:

1. MariaDB Server aspires at giving choice by offering compatibility outside also the bubble of the M-database community. We want to mitigate the hardships of migration, also from Oracle Database – not just Oracle MySQL Server. Through our Oracle compatibility mode, we see a lot of migration from Oracle to MariaDB (eg. DBS Bank). We encourage this. You are unlikely to see Oracle MySQL do that, for completely logical reasons, so in a way you could of course argue that this causes further divergence. We still believe it improves developer experience, though.

2. MariaDB Server is developed by entities that make their code available as Open Source. And we do so with an Open Source development model. Amazon keeps their Aurora code on their own servers. You are unlikely to see Amazon come with a hybrid offering, where the same code can run in the cloud and on prem, again for completely logical reasons.

This means that one should not use Aurora if one wants to run the same application against any other cloud or on premise as the databases will behave differently. End user benefit  of MariaDB’s model: Flexibility. And the possibility for others to increase their compatibility by porting our features released as GPL.

We reciprocate. MariaDB Foundation employees participate in the non-MariaDB parts of the M-database community eg. in fixing MySQL-8.0 PHP bugs (https://github.com/php/php-src/pull/6127), hopefully decreasing fragmentation.

3. MariaDB Server is developed within a unique dual constellation of a Corporation (for-profit) and a Foundation (for-openness). While MariaDB Corporation is bound by similar business model constraints as Oracle and Amazon, MariaDB Foundation is not. We are a not-for-profit organisation owning the keys to the code base. We own the code repository. MariaDB Corporation, which employs the majority of developers contributing to MariaDB Server, is the main entity driving the overall product roadmap. Yet functionality is also being contributed by others, such as our many other sponsors – Alibaba, Tencent, Microsoft, ServiceNow,  DBS Bank, IBM, Visma – sometimes through direct code contributions, sometimes indirectly through their work with MariaDB Corporation. And we are happy to note that the number of accepted code contributions within the last 12 months is higher than the lifetime code contributions accepted into MySQL Server. 

4. When it comes to contributions, we allocate our own MariaDB Foundation resources to incorporate patches by other entities. Sometimes we work selected patches ourselves into MariaDB (such as with Oracle MySQL), and sometimes we share the burden of work in merging and incorporating features from other providers (such as with Alibaba, Tencent, and Percona). 

One such compatibility feature is the recently-pushed MDEV-18323 Convert MySQL JSON type to MariaDB TEXT in mysql_upgrade, enabling a correct porting of JSON fields when migrating from MySQL 5.7 to MariaDB 10.5. It took time, but hopefully still matters.

Please don’t dismiss all of the above as a self-glorifying MariaDB spin reply to Kristian’s concerns. The points are meant to show that we try to be open to improving developer experience, and that there are fundamental logical reasons why we are poised to be more successful at it, than the other entities indirectly addressed by Kristian.

On a process level, we allocate developers to attend not just MariaDB conferences, but also MySQL, Percona, Alibaba, Tencent and other conferences – with “ecumenic” Fosdem soon coming up. This hopefully makes it easier to connect with us, within the MySQL, MariaDB & Friends community.

Our ambition is to be the main branch of the ecosystem with joint roots in the MySQL code base. Results are showing. We are the default or only representative within Linux distributions. We’ve climbed the adoption ladder in DB-Engines. And our recent MariaDB Server Fest in September collected an audience of over 27.000 views across the world.

We’d like to think that our openness and our active work with the developer community is a root cause for the added attention to MariaDB

Is it? 

Kristian laid the groundwork. Now, we’d like to hear feedback from other members of the developer base. We at the MariaDB Foundation invite you to collaborate on how to improve the developer experience. We want to do what is within our power to lessen ecosystem fragmentation.