I got several comments and questions on my previous blog "The State of the MySQL forks". One question was "Why didn't you mention Drizzle?" So I will say something about Drizzle here before concluding with other remarks.
So why didn't you mention Drizzle?
Mainly because the post was already long and also I had to wrap up and call into a meeting.
But yes, it is also true that if something was to be cut out, not mentioning Drizzle can be justified in a couple of ways. It is true that Drizzle adoption is nowhere close to Percona Server and MariaDB, for instance. Also, Drizzle is different enough that it is not a drop-in replacement like the 3 other forks are of each other. So it is not possible to just mention it in passing as an equal alternative, it would in any case require more explanation to give an accurate picture.
Even though InnoDB is the underlying engine, the data format is different. With the other 3 forks you can just switch between them with an rpm/apt install, but to move to Drizzle you actually have to mysqldump (or rather, drizzledump) your data to put it into a drizzle database. Some small changes will be necessary in the migration, for instance you must convert the character set of your schema to UTF-8, which is the only character supported in Drizzle. Of course, you also need to get rid of unsupported features like views, triggers and procedures.
Other than that, it's not too much different. A MySQL user like myself will immediately feel at home in Drizzle. SHOW commands and INFORMATION SCHEMA are there, and the SQL syntax is the same. It's a comfortable choice and much easier to go to than, say, PostgreSQL.
So what is the big picture?
While the MySQL ecosystem is in many ways doing very well nowadays, my criticism of it usually falls under the umbrella of "I wish we could make it a sane open source community like Linux, Drupal, Libreoffice... basically any other open source project out there". To start with the positives, this is Drizzle's strong point. I remember when it was launched in 2008 it was like a breath of fresh air. Monty Widenius welcomed it with these words:
My personal reaction to Drizzle is that I am very enthusiastic for this new kid on the MySQL block. I don't agree with everything that is done, but most things makes a lot of sense. I am looking forward to a lot of very interesting discussions about solutions in Drizzle that will help improve both MySQL versions.
In 2008 Drizzle immediately gathered over 50 code contributors, which was a testament to the pent up demand for a more open fork that existed already back then. Today it is not quite as vibrant, but in terms of diversity it is still far more community oriented that either of the other forks. In the past Spring there were still around 30 different code committers. Many of those (roughly 20) are students driven by their interest to apply for Google Summer of Code. This way Drizzle serves as an excellent entry point for new young talent to join the wider MySQL ecosystem too.
In addition to the diversity of the developer pool (all other forks are primarily developed by employees of their vendor) Drizzle is also formally governed by a non-profit: Software in the Public interest.
Can you summarize Drizzle pros and cons?
It is also worth pointing out that Drizzle 7.1 is ok to use, even for production. During the time I have been involved I haven't seen any crashing bugs or data corruption bugs reported. Drizzle 7.0 (the first stable release) had several cases where it would crash during startup phase, such as when reading an invalid configuration file. But even that version didn't - as far as we know - have any instability once actually up and running.
On the con side the major issue is lack of polish, and lack of attention to actual end user needs. This was already apparent in the long time to market Drizzle took: The developers enjoyd rewriting the code base so much, they didn't produce a stable release for 3 years! MySQL too used to have a 3 year release cycle, but that was the good old days. Nowadays quite a lot happens in 3 years. So even if Drizzle was the earliest fork of the ones still alive, it was the last one to actually deliver a stable GA release. It is possible that in terms of getting end user adoption, Drizzle did lose the window of opportunity there.
The list goes on: Like I said, the 7.0 version actually wasn't that great in handling various error situations in configuration, and I know of cases were testers gave up on Drizzle due to those bugs. Still today there isn't an example configuration file that would get you easily started. Nor does the project offer binary tar or rpm packages, so unless you are on Debian or Ubuntu, you need to compile it from source yourself. MariaDB, Percona, even PostgreSQL (which used to be known as too geeky and unfriendly) provides packages in nice apt and yum repositories, MySQL provides packages but not a repository. Documentation and code comments, of course... So yes, sometimes I feel the Drizzle developers only did Drizzle for themselves, and they don't really care whether anyone is ever going to use Drizzle as an end user or not.
The other complaint is a bit surprising: Lack of open communication on behalf of the core developers. I don't know why, but almost all Drizzle core developers use exclusively off-list private emails or Skype. To an outside observer or newcomer this makes the project look either dead or closed. A case in point, except for myself and the student I was mentoring, the other 5 GSoC students have managed to complete their semester without a single email to the mailing list. It is somewhat ironic that the community friendly Drizzle comes out looking pretty bad here. For instance if you go and look at maria-discuss, maria-developers and #maria IRC channel, there is activity every day. The Drizzle developers should really kick themselves on this point.
So would you recommend Drizzle?
If you want to hack on something in the MySQL space, Drizzle is a good option. The code is easier to approach than the classic, backward compatbile MySQL forks where some dark corners of the code date back to early 90's, maybe 80's. Also for me personally it is more satisfying to work on a community project than to donate my code to a vendor who wants to own it - I know this is not an issue for everyone.
Also, if you are able to commit a lot of time, Drizzle offers a good opportunity to actually take on a lot of responsibility in a relatively big and high profile open source project. For instance one of our GSoC students is now responsible for release management - something to put on your CV for sure.
Drizzle is also quite ok to use for end users. But I would mainly see it attractive to the more geeky users, for instance those that actually enjoy or prefer compiling their software from source code. Or you might want to support Drizzle for "political" reasons if you prefer community developed open source projects over vendor controlled ones.
Finally, Drizzle certainly has a lot of potential. The refactoring took long, but it is done. The modular architecture provides a lot of possibilities for rapid innovation. If some organization is looking to invest in significant development on a MySQL codebase, Drizzle is certainly an option. And like I said, some players may prefer to choose a neutral community zone instead of picking a vendor fork.
In practice, Drizzle adoption is still clearly lower than either Percona Server or MariaDB, and most end users will simply follow the masses. This is a bit sad for everyone that believed that there was demand for a more open approach to MySQL development. But it also proves one important point: open is just one thing, you also need to deliver, and not just deliver but you need to deliver against the competition.
Those that know my views on this subject know how hard it is for me to say that in public, but I also always wanted to be objective, so there you have it. Drizzle has lots of potential, but not yet enough end user focus.