The problem, as I see it with MySQL forks, is that
there are too many
of them. Monty has his own fork now
Drizzle is a fork. See it as separate, there is no compatibility.
Traditionally, there have been some interesting patches around - by Percona, Google,
Facebook, and others. The reasons for the existence of the patches is that quite a few did
work on easier monitoring/management which for MySQL AB (later Sun, now Oracle) has been a
key area for commercial offerings. While building the functionality in to the server makes
perfect sense (IMHO), the companies have -for business reasons- chosen to build external
products to attempt to do the same. Admittedly they're pretty good, but it's still
silly if you look at it from this perspective.
The OurDelta project (ourdelta.org
) worked on packaging a set of these patches, not only
to binaries but to distro packages (Debian, Ubuntu, CentOS/RHEL initially), as most users
don't care much for compiling the whole thing, or recompiling when one bit gets
OurDelta has never been a fork, but rather akin to a distribution (like Red Hat packaged
up Linux with some extra patches and stuff, so OurDelta packaged the enhanced MySQL).
Monty left Sun Microsystems some time after MySQL AB choose to let itself be bought by
that company, and shortly thereafter he started Monty Program and the MariaDB branch.
I call it a branch as it still feeds from upstream (Oracle), and the reason for that is
that the MySQL team at Oracle has actually been doing some good things.
One could call it a "downstream fork", if you like.
I worked with Monty to incorporate the patches that OurDelta had in to MariaDB, and Monty
Program has also adopted our build system. So essentially what OurDelta had and did is now
merged into MariaDB.
Percona has some overlap in enhancements (such as XtraDB which replaces InnoDB in MariaDB)
but also does some of its own things, so it's doing "Percona Server" which
is really like a branch or a downstream fork of MySQL just like MariaDB. The reasons for
its existence separate to MariaDB are business choices for its clients - branding. It does
fly in the face of an explicit promise made by the Percona founders to Monty (I was
physically present at that occasion), but it's a fact anyway. Monty owes me a nice
bottle of special vodka because of this, he lost a bet ;-)
I am not aware of other branches/forks that specifically exist as a binary or package.
Facebook does some of its own patching, just like Google and others have done - much of
that is internal although ideas and also code does get fed back to one of the branches, so
that's good and does not mess with the ecosystem as such.
It's a good example of how Open Source software can indeed be adapted by a company to
suit its own specific needs, something that non-OSS software does not offer.
there are a few NoSQL forks around
A noSQL fork of MySQL? do clarify, as I don't see how that even makes any sense.
and a few other ones still that are trying to
themselves based on performance of added functionality.
Probably covered above, but feel free to name specifics.
The community hasn't coalesced around a single
and is very fragmented and so none of these have really taken off.
Primarily, the community does not have access to the development platform as managed by
Oracle. So it has to do its own thing anyway. MariaDB has its branches open on Launchpad -
others can branch, add good stuff, and submit for merge.
I got my OQGraph engine added earlier, and some other patches. The system works.
The fact they all go to these extreme measures to
with MySQL shows their struggles in getting traction.
You note correlation, which is correct.
However, you have not proven causality.
Binary compatibility makes moving from (for instance) MySQL to MariaDB a trivial drop-in.
Client API compatibility has similar advantages - note that MariaDB has a superset now.
Regardless of the merits of a particular branch, it's a pest to migrate if it involves
significant effort, such as having to modify then recompile applications to work with a
The merits of having a common base client API was proven long ago when MySQL first got its
SQL layer around 1995, and Monty specifically designed the client library calls to be
backward compatible with mSQL - while sharing no common ancestry (mSQL was written by
David "Bambi" Hughes on the Queensland Gold Coast - yes I've met him, nice
fella), there were at the time some apps using mSQL whereas obviously MySQL was new.
So with this library call compatibility, converting an mSQL tool to MySQL was trivial, and
that was very useful.
This is very much in contrast with, say the move from
LibreOffice or from XFree86 to FreeDesktop.org's X servers.
Both were very political cases, and to a degree that's also true for MySQL.
Consider a distro looking at MariaDB and pondering whether to replace MySQL with it.
Oracle can have very big hissy fits when it sets its minds to it.
Which distro is willing to take that on?
That is the primary conundrum, not technical merit or community traction.
Drizzle, being a completely separate thing (it was merely started on an earlier MySQL
codebase, so it shares common ancestry) is much easier, it can simply be added as it does
not replace anything in terms of packages.
If MariaDB were to ditch its binary compatibility to a degree, for instance by changing
paths and some naming aspects so that it could (technically) co-exist with MySQL on a
single server, then distros would have a much simpler task. However, that approach has
problems also, as described above. Given the politics, there is not really a win-win
situation and thus the process is quite slow. Perhaps too slow (not disagreeing there) but
it serves to understand what's really going on...
Exec.Director @ Open Query (http://openquery.com
) MySQL services
Sane business strategy explorations at http://upstarta.com.au
Personal blog at http://lentz.com.au/blog/