1 2 next »

1. MySQL
2. The forks

MySQL and the forks in the road

by Andrew Hutchings

At the beginning of 2008 Sun Microsystems purchased MySQL AB, and ever since then there have been divisions in the ecosystem. As with any software community or ecosystem, where there are divisions there are usually forks, both in the community and the software itself.

Just over a year after the Sun acquisition came the announcement that Sun itself was to be bought out by Oracle. It was at this point that the cracks in the ecosystem really started to show. Many inside Sun stayed quiet – not by choice – while outside things were getting very vocal and heated.

The 451 Group's 2012 user survey showed over 25% less likely to use MySQL.
Source: Matthew Aslett of The 451 Group The fear was that Oracle would destroy MySQL, and there are still some today that do not trust Oracle. They watched what happened to Hudson, OpenOffice and similar ex-Sun projects and wondered what would happen in the future. In 2009, the 451 Group surveyed MySQL users and found a lack of confidence in Oracle as a steward; in a 2012 survey that lack of confidence manifested with over a quarter of users less likely to use MySQL.

During the nine months of trying to appease the regulators Oracle made a five-year promise to the EU regulators as to what it would do with MySQL, post-acquisition. It has been a bumpy ride since then: the bugs database has for the most part been closed to the public, there have been arguments over keeping test cases private, and there are feature plugins which are only available to paying customers. No one can argue that there certainly have been adjustments – there were many who didn't like the change and subsequently left Oracle, often to new companies set up around the MySQL ecosystem.

The way security bugs, fixes and test cases are handled can be obscure and are in line with how things work at Oracle and other corporations. Unfortunately the subject of security fixes is a difficult one with regards to open source software and it is even more difficult when you have commercial customers – exposing details of a security flaw to an open source community could lead to a 0-day exploit arriving before a company has had a chance to deploy a patch, but keeping security patch details private makes it difficult for downstream forks to pinpoint the cause and fix it. A similar problem can be seen with RedHat's change in kernel patch policy.

The changes Oracle has made have led several vocal people in the ecosystem to believe that Oracle is slowly closing off the open source side of MySQL. Whether or not this will happen is still anyone's guess: the end of the five years is December 2014 and many eyes will be watching what Oracle does at that point; until then FUD will unfortunately still be spread.

One thing Oracle seems to have got right is the merger of the MySQL and InnoDB teams. A couple of years before Oracle purchased Sun it had already bought Innobase, which was the company behind the InnoDB engine. This worried many and in fact caused a couple of new transactional engines to be developed in case Oracle destroyed it. Innobase, however, was still kept mostly independent inside Oracle and was left to do its own thing. Now the engineering teams work as one on MySQL.

There were forks of MySQL prior to version 5.0 and prior to the Sun acquisition, but most of these were in order to add changes specific to a certain use case; Google's fork being one of the most famous of those. OurDelta was probably the most prominent 5.0 general-purpose fork. This basically contained patches from the MySQL community that didn't make it upstream. Today OurDelta has been merged into MariaDB and appears to no longer be maintained. Several patches from the early forks actually made it back into MySQL itself, although some not until later major versions. It wasn't until after 5.1 that the really high-profile forks started to appear.

Unfortunately, rightly or wrongly, MySQL has not had a great reputation for accepting patches. Whether this is due to copyright assignment, designed to allow the dual-licensing model to continue, or whether the path to submit patches is a difficult one, is not clear. Some have been accepted in the past, but the number is not huge. Either way it is not surprising that forks are created when features or bug fixes are needed by the ecosystem.

MySQL

Back in January 2009, the first alpha of MySQL 6.0 was released to the community. This was an incredibly ambitious project that started long before and which contained many new features in almost every part of the code. It could almost be seen as a dumping ground for new features. There were two new storage engines inside this version: Maria, which was to be a crash-safe replacement for MyISAM, and Falcon, which could have been an ACID replacement for InnoDB. Falcon could have been a reaction to Oracle's purchase of Innobase and development of the engine was killed off during the Oracle acquisition, possibly because it was no longer needed now that MySQL and Innobase were under the same parent company. MySQL 6.0's last alpha was 6.0.11 in May 2009; it was possibly too ambitious, so MySQL 5.5 was developed, which for the most part cherry-picked and stabilised several features of MySQL 6.0. This continued into MySQL 5.6, which has some features from 6.0, some that were planned and never developed and a few new things too.

MySQL 5.5 was already in late development at the time of the Oracle acquisition, so there are people who see MySQL 5.6 as Oracle's commitment to further develop MySQL.

Oracle has also maintained MySQL's own high availability fork of MySQL with the NDB engine called MySQL Cluster. Version 7.2 of MySQL Cluster was released under Oracle and 7.3 is currently in a development release.

Next page: The forks

1 2 next »