A year ago I posted a blog on The state of MySQL forks: co-operating without co-operating. (Also Giuseppe wrote about the topic at that time, and Peter Zaitsev covers it in his conference keynotes.) So I've been wondering if it would be good to write an update on the topic now, and in that case what to write.

Sometimes it helps looking at particular examples to understand a general thing, at least my brain works that way. It just so happens that this might be a good approach to give a snapshot of how the MySQL forks are doing. So I will here focus on the recent announcements on authentication plugins - but not to focus on the feature itself, rather letting this be my 2011 edition on the state of the MySQL forks.

Oracle MySQL

On September 15 Oracle announced new commercial (which is also code for closed source) plugins for MySQL Server: a thread pool plugin, an authentication plugin for Linux PAM and another authentication plugin for Windows. Since PAM can use many backends to store authentication information, the PAM plugin is also marketed as a way to store MySQL users in an LDAP directory.

Reactions

There was a broad array of reactions to this announcement:

• Some alarmed that Oracle is taking MySQL closed source.
• Monty Widenius was particularly upset about the fact that the code for the authentication plugin api, which directly enables these closed source extensions, was donated to Oracle by his company (it was created by Sergei Golubchik, who finished the work as a Monty Program employee) and felt that the good will of such an act had been let down.
• Some pointed out their satisfaction that the closed source features were implemented as plugins against a publicly documented api, so that the community is able to create open source replacements for them.
• Mark Callaghan announced that he already has code for a thread pool plugin.
• Some expressed their satisfaction that Oracle is more agressively monetizing MySQL and that this will enable Oracle to invest more in MySQL.
• Ironically, nobody has yet announced that they intend to use these plugins or that they became a paying Oracle customer because of them. I suppose it's not something you blog or tweet about. It will be interesting to see if Oracle announces such reference customers in the future.

The big picture

I personally don't understand why this particular announcement created so much controversy. Already since 5 years back MySQL has been selling a closed source monitoring utility and Oracle a closed source backup utility for MySQL. Even the JDBC client has sported closed source plugins (that integrate with the monitor) since two years back. But for many it seems to have been really critical that also the MySQL Server itself now has closed source parts. In any case the now announced closed source plugins are not an invention of Oracle, they (or at least the general model) were part of the MySQL AB roadmap since 2007. It is true that during the year of Sun reign this process was stalled due to a higher level decree inside Sun, since Sun was committed to become a full on open source vendor. Whether this makes Sun the good guy and Oracle the bad guy would depend on how much a person values open source as a feature in software.

Even for the Oracle period of Oracle reign this is not the first step towards closed source, as almost immediately after taking over the commercial MySQL server binaries were changed from GPL to a proprietary software license. (Until the Oracle acquisition the MySQL Enterprise binaries were GPL licensed, just not publicly available, similar to Red Hat Enterprise Linux.)

MariaDB

On December 2 Monty Program announced that they will release open source replacements of these plugins in a series of upcoming MariaDB releases. A PAM authentication plugin was released on December 6.

Reactions

As far as I can tell, this announcement brought MariaDB some positive publicity.

The big picture

Monty Program is positioning MariaDB as being committed to open source. Due to the GPL it's not like they have a choice anyway, but certainly it is a message that vibes positively with a large part of the MySQL user base. In this case they were quite quick to reap a nice publicity benefit by quickly countering the Oracle announcement, thus demonstrating quite clearly what such a commitment means in practice.

Percona Server

On December 5 Percona announced immediate availability of an early access release of their PAM authentication plugin. Percona's announcement highlights the ability to use an RSA SecureID server for authentication. Technically this is just another PAM backend but mentioning it gives an interesting view into what Percona customers might be using and at least to me gave a nice "high tech" Percona feeling to it :-)

Notably Percona didn't announce a Windows authentication plugin, which is no surprise, as they don't support Windows with Percona Server.

Reactions

This announcement brought up some further positive reactions, some can be read as comments to the blog post itself.

The big picture

In the spirit of my post a year ago, we see here a good example of co-operating without co-operating. It seems Percona and MariaDB folks worked on the same solution independently and unaware of each other. An authentication plugin is not a complex beast, so there isn't that much duplication of work.

MariaDB was the first to announce plugins, while Percona was the first to release code. (But only by a day, in this case.) This seems to fit into a more general pattern. However, in this case MariaDB actually was faster to declare their plugin GA, breaking from past trend. With the upcoming 5.3 release there will be also other GA MariaDB features not yet available in the other forks.

You'll also notice that MariaDB is working on more features, while Percona's announcement was more focused.

Drizzle

Drizzle has supported PAM based authentication since a long time ago, and it was included in their first GA release in April 2011. Drizzle also has a separate LDAP authentication plugin, which connects directly to an LDAP server rather than going via the PAM service. This is in fact a major advantage over the other MySQL forks: With PAM authentication the password is in fact sent in cleartext from client to server. (See Kristian Köhntopp for some community feedback on this topic.) The Drizzle LDAP module instead allows to use the traditional MySQL hashed password format where the password is hashed before it is sent over the network.

Drizzle also has a plugin for HTTP based authentication, which is really weird, since normally you'd want your webserver to use a database for authenticating users, not the other way around. But I guess the existence of this plugin is a testament to a) Drizzle plugins being really easy to write and b) Drizzle having good HTTP connectivity and c) this could be seen as a prototype for an authentication plugin that authenticates against some HTTP based service, such as OAuth or some cloud fabric authentication.

Drizzle also has a plugin to authenticate from a plain text file, and finally a plugin which allows all connections without authentication.

The one thing Drizzle didn't have until recently was a plugin that implements the familiar MySQL-style authentication with usernames and passwords stored inside a table in the database. Daniel Nichter recently implemented this and it is part of the Drizzle 7.1 beta download release some time ago. This was in part a reaction to all of the above mentioned alternatives being either a) insecure (plaintext password, no authentication), b) complex (first setup LDAP server) or just weird (HTTP authentication). It turns out the MySQL way of doing things was pretty good as a default!

Reaction

Most people had never heard of any of these authentication options that Drizzle provides, because until recently they were not documented at all, so they were a well kept secret. Nor did Drizzle make any announcement to compete with the other forks. So there hasn't been much of a reaction. I know of some people that have installed Drizzle to provide LDAP authentication long before any other MySQL fork implemented it.

The big picture

You probably got the point that Drizzle has a lot of plugins.

Also we see that sometimes quantity is not a replacement for quality, but the Drizzle community is great and Daniel's work proves that it can and does happen that when something is missing somebody can just come in, implement it and have it committed to the main trunk in a month or two.

The one thing Drizzle doesn't currently do very well is user awareness and marketing, but recent work (again, here exemplified by Daniel documenting his plugin and blogging about it) is showing some signs of improvement.