I promised to still post some general comments about the MySQL ecosystem, to conclude my outlook of State of the MySQL forks and Drizzle. I will do this now in the form of answering questions I got in the comments, twitter and some that I make up just myself.

Oracle has not stopped updating bzr trees

Ok, that's great. Would you care to make a comment about the missing test cases too? Even if it's something the community doesn't want to hear (the test cases won't be public, period) Oracle would do itself a favor in communicating more actively about these issues.

But Tomas Ulin wrote to the mailing list that they will be updated (you should have read that mail)

This took me completely by surprise. I have stopped reading mysql-internals a year ago when I concluded it was more or less dead. (Not that MySQL was ever very good at using public communication channels, but there used to be some discussion.) If you browse the archive, you'll see that Stewart's and Sergei's prior emails throughout the Summer went without responses. (The previous time the branches were updated was in May.)

That said, even if I didn't read it, I think it was great that Tomas did respond to Stewart's email eventually. If Tomas and other MySQL developers continue to email mysql-internals, I sure will start reading it again.

Is it really a fork? MariaDB and Percona Server are still file-format and protocol compatible with MySQL.

At least Percona Server is technically not a fork, but I follow the mainstream usage here. I am predicting that we will come to consider MariaDB 10.0 a fork. Compatibility is orthogonal to being a fork.

But I'm glad you pointed it out: Yes, all these three forks are still very much compatible with each other. You can start with one and rpm --upgrade to another and you wouldn't notice a difference. In fact, I remember at MariaDB they made a point of fixing some upgrade related bugs, so that MariaDB 5.5 is now more compatible with old MySQL versions than MySQL itself :-)

This is good to point out when users feel angst about choosing between these alternatives. You can choose whichever you want, and you can easily switch whenever you want. Users should therefore consider the availability of choice a positive thing!

That's it! Oracle is closed and evil, I'm switching to MariaDB.

Even if there seems to be something to complain about every year, many people (perhaps a majority?) in the MySQL community have not yet actually switched away from Oracle MySQL. Even here at Froscon where I'm writing this post, Johannes Schlüter's "What's new in MySQL 5.6" was by far the best attended database talk.

But if you feel that is the right thing to do, yes, MariaDB has always wanted to position itself as the new and alternative MySQL. Hey, they even chose the name such that you can migrate to MariaDB and it will still be the M in your LAMP stack :-)

Personally - and I've heard others say this too - I think the availability of choice is more important than any one alternative. Even those that continue to use Oracle MySQL, enjoy the fact they are not dependent on it.

Since @percona is tightly connected to MySQL upstream, what do they do with the closed development? get upstream from MariaDB?

Oracle is still publishing the source code for every release. They had just neglected to publish the bzr repositories, which contains the commit logs, on launchpad. Percona continues to apply their patches on top of each MySQL release. The lack of - or in this case, the delay - commit logs just makes it more difficult to understand what Oracle has been doing for each release. It's an annoyance, but not a showstopper.

My personal prediction is that Percona will continue to upstream from whatever their elite customer base likes to use (and those customers are not indifferent of the increased amount of closeness at Oracle). Currently this is still Oracle MySQL.

This is also the main difference in the value propositions of Percona vs MariaDB. For MariaDB it was from the beginning important to establish the credibility that MariaDB is a viable independent alternative to Oracle. (And this was important to many European MySQL users.) Percona's focus has always been to provide an enhanced version of MySQL. (...the enhancements being important to demanding Silicon Valley customers.)

That said, Percona and MariaDB are more interlinked than this "official marketing" would let you believe. MariaDB depends on Percona to provide XtraDB and Xtrabackup. Similarly, in the hypothetical situation that Oracle MySQL became more closed so that Percona could no longer practically upstream for it, then yes, I would expect them to work with MariaDB instead of just going independent.

And what about Facebook / Twitter MySQL branches that they develop inhouse? (for your next post)

I think they are great! Look, we finally have a MySQL community that almost looks like a real open source community.

But I don't think they are that important for the average user - which I'm focusing on here. In fact, their authors seem to discourage people from using them! Currently these improvements are flowing quite well to all of the different forks, then users consume them from there.

As a case in point, Sergei Golubchik is right now talking about the replication filtering now being dynamic in MariaDB - ie the replicate-do-db and related options are now dynamic variables. This was written by Davi Arnaut at Twitter. It's great to have Twitter joining the long list of MySQL contributors!

So which fork would you personally choose?

I would like to choose a fork that is good enough for now, and that I believe to be winning in the long term. I believe that open source projects that can include and balance both community interests and commercial interests are the ones that end up winning. In practice I believe more in community governed projects than vendor owned, because non-profit governance has proven its ability to cater to commercial interests, whereas vendor governed projects have often proven their ability to screw community interests. But then the project also needs to present a competitive, user-friendly product, and get user adoption. A project needs user adoption to be viable.

And if you've read the two previous posts you can see where I'm going. Such a MySQL fork doesn't exist! Only one is a true community governed fork, Drizzle, but it has lower adoption than the others and the productization isn't as good as for the others and these are just as important ingredients for long term success too.

So the way I look at it is that I'm glad about the ecosystem as a whole, both the forks I wrote about and the Facebook and Twitter forks out there that we write less about but that also contribute a lot to the progress. But in terms of what to use right now I would just use whatever has the features I most need today.

So which is that? Between MySQL (this includes 5.6), Percona Server and MariaDB, I would say the situation is pretty even right now. I'm often focused on high-availability, so Galera and Percona XtraDB Cluster are my favorites today. (Maybe next week there is a MariaDB Galera cluster too...) In terms of GIS it seems both MariaDB 5.5 and MySQL 5.6 have made important progress, with MariaDB doing exact math instead of floating point math having a small but important advantage. And so forth...

I should also mention that even if I don't mention any particular feature from MySQL, I'm really really glad to see the amazing progress they are making nowadays. When I joined MySQL AB as an employee, they were in the middle of the MySQL 5.1 release process. This release contained 5 features, only 2 of which were non-trivial (partitioning, row based replication). Yet, it took 3 years to make out of which 13 months was feature freeze! When you look back at that time it's kind of easy to see how any Joe Random Hacker might want to try forking MySQL and expect to perform better than that. But now, 4 years later, it is a different ball game entirely. Engineering wise (if you don't care about the creeping closedness) Oracle MySQL is usually as good an option as any. And if we take the whole ecosystem together, the progress over 3 years is just amazing.

This is why I still enjoy working with MySQL.