Hi Aryan
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 updated. 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 differentiate themselves based on performance of added functionality.
Probably covered above, but feel free to name specifics.
The community hasn't coalesced around a single development platform 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 remain compatible 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 different API. 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 OOo to 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... Regards, Arjen. -- 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/