“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.
