The Open Database Alliance and the Future of MySQL

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Stated more simply: as long as MySQL remains committed to the dual licensing model, it will be unable to accept the same patch set that open source only versions of the code can, because they do not share the same licensing concerns. Which is why we’ve seen these spring up.” – MySQL: Now and Then

Given that I wrote the above back in December, I obviously could not have known that the Open Database Alliance would launch this week. But if by some miracle you’d had a vision of the future and relayed it to me, I confess that I would not have been terribly surprised.

The simplistic analysis is that the Open Database Alliance is strictly a reaction to the Oracle acquisition of Sun, and by extension, MySQL, which has introduced uncertainty into that ecosystem. The truth, however, is that the consortium, or something very much like it, was inevitable given the increasing delta between the versions of MySQL being shipped by MySQL and those being distributed by third parties with no dual license interests to protect.

To recap, for those of you unfamiliar with the intricasies of the dual licensing practice, here’s a quick description. In dual licensing,

…a single entity such as MySQL is responsible for the overwhelming majority of all development on a given codebase. Anything they don’t produce themselves, they license. Very often this is practiced in conjunction with the dual-license model; because MySQL is responsible for virtually all of the development of the core code, they own or have licensed appropriately all of the involved IP. As such, they’re free to issue commercial licenses to those who would cannot or choose not to comply with the terms of the open source license – the GPL, in this case.

Sounds too good to be true, open source alongside proprietary licenses (and revenues)? Looking for the catch?

In part, it’s that the burden of development is born almost entirely by the MySQL staff, but the more relevant concern here is the inability to consume external contributions – even if they’re excellent – without licensing them.

Unlike, notably, Monty Program AB and Percona, which can consume whatever patches they deem acceptable because without the need to adhere to a dual licensing model, they are free from its restrictions.

What’s happening here, then, is this: the MySQL forks that have been propagating through the community for sometime – not to mention competing with the parent distribution – are beginning to coalesce and become a more centralized alternative.

The near term market impacts should be minimal: just as the MySQL organization spent years building its enterprise credibility, so too must those that would compete with it, technical superiority or no. The longer term implications, however, are far less clear. Already we’re seeing substantial community interest in the innovations to the codebase occurring externally, and this week’s news could potentially accelerate enterprise interest in the forked codebases by coordinating development to a greater degree.

If nothing else, then, we live in interesting times.

Thanks to Lisa Sheeran of Sheeran/Jager Communication, I was able to put a few questions to Monty Widenius via email, so herewith the rare Q&A that’s with someone other than myself.

SOG: While it will have an obvious technical advantage in its ability to consume patches and fixes that MySQL itself cannot, how does the Open Database Alliance anticipate competing with the enterprise heft of Sun in the short term and Oracle in the long term? Or does the Alliance anticipate pursuing a different customer segment?
Monty: Our aim is to make MariaDB the main and most used open source database. If we succeed, then the user and customers will come to us, the Open Database Alliance, for their MariaDB and MySQL business.

We plan to grow the same way that MySQL initially grew — by working closely with the community and the MariaDB users. This means that Monty Program Ab’s first customers are heavy database users who need changes done in the server code to be able to satisfy their business needs.

Sun/Oracle will be better equipped to handle big companies that are used to deal with companies of the same size. The Alliance is targeting customers that need more personalized services than Sun/Oracle provides.

SOG: What storage engines, besides Maria, will be supported, if any?
Monty: We aim to support by default all open source storage engines. In our current tree we already have PBXT. Within a couple of weeks we will also have XtraDB and FederatedX. We are talking with some other storage engine vendors to include their engines too.

SOG: What restrictions are imposed on the business by the ownership of the MySQL trademark by Sun, and potentially Oracle?
Monty: The main restriction is that we can’t call our branch of MySQL “MySQL”. Instead we have chosen to call it MariaDB, after my youngest daughter.

SOG: How many full-time development resources are available to the Alliance, both for development and support?
Monty: The Alliance is growing by the day, so this is an increasing number.

Percona is about 20 people.
Monty Program Ab will be around 15 by end of May.
Openquery is about 3 persons.

From how things looks now, I would not be surprised if we have more than 10 companies in the alliance by the end of the month.

SOG: Are there any Open Database Alliance customers available for comment?
Monty: Each of the current Alliance members have a lot of customers. I can of course only speak for Monty Program AB; We are talking with several
really big, well known companies regarding server work so things looks good!

Disclosure: MySQL and Sun are RedMonk customers, while Oracle and the Open Database Alliance are not.


  1. […] some reason, the identical comments have also appeared one by one on a Stephen O’Grady blog post, with links back to the original thread. I did not actually post the comments attributed to me, so […]

  2. […] 26, 2009 @ 10:58 am ET Following the launch of the Open Database Alliance a number of interesting reports were published that examined its role in establishing MariaDB as an alternative development branch […]

  3. […] ovviamente sulle relazioni che potrebbero intercorrere tra Oracle e la Open Database Alliance, e c’è chi analizza la nascita di quest’ultima non soltanto dal punto di vista della…, una licenza che è al contempo sia open source che commerciale: per effetto di tale licenza […]

  4. […] Blog: http://monty-says.blogspot.com Download: MariaDB Download Page MySQL Performance-Blog & Redmonk Tags dieses Artikels: Datenbank, MariaDB, MySQL Verwandte […]

  5. […] exclusivity with respect to the license. Trademark protects the name, logo and so on, and as Monty told me in an interview, means in practical terms that forks cannot call themselves […]

  6. […] Consider that the available forks of MySQL are, for reasons that have been apparent for some time, not only technically differentiated, but regarded by many in the community as superior to the builds available from MySQL itself. In spite of this, they are, as Mårten argues above, individually weak. Forks cannot use the MySQL brand, and they cannot hope to match MySQL’s distribution in the near term through conventional distribution mechanism. But Amazon wouldn’t necessarily need the brand (in the context of EC2, which is stronger – Linux or EC2?), and its cloud offers massive advantages over conventional distribution. What if, compelled by market conditions and Oracle pricing, Amazon eventually stopped talking about its MySQL databases in favor of a compatibility story that would permit it host your MySQL databases. And what if, for whatever the reason, MySQL developers were unhappy with the state of affairs and chose to leave, making them available to Amazon? Or Amazon shifted its partnership to the Open Database Alliance? […]

Leave a Reply

Your email address will not be published. Required fields are marked *