MySQL: Now and Then

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

MySQL has never shied from being controversial, from being the iconoclast of the open source world. From working with SCO to embedding non-open source assets to the dual licensing strategy, the vendor has ever been willing to push the envelope and experiment.

And while it’s taken a beating in some quarters for a decision here and there, it remains the de facto open source standard for a relational store. In spite of the fact that there are database people that would vehemently claim that it is anything but a relational store. Even its competitors, however, will generally allow that it is as close to ubiquitous as you get in the database world.

As Jeremy says, however, the times, They Are A-Changin.’ For better or worse, we don’t yet know, but it’s a whole new world.

To explore some of these questions, let’s turn to our old friend the Q&A, as we haven’t done one in a while.

Q: Before we begin, anything to disclose?
A: Yes. MySQL, and MySQL’s parent company Sun are both RedMonk customers, as are market competitors such as EnterpriseDB, IBM and Microsoft.

Q: So what’s been happening with MySQL lately?
A: Quite a bit. In case you haven’t been keeping up with current events, the company got acquired, and since then, a few things have happened. They lost a co-founder, their new parent’s financial fortunes took a tumble (prompting advice), and they (finally) kicked 5.1 out the door. Which Monty wasn’t exactly fired up about.

And those are just a few of the obvious items of note.

Q: We’ll get to the non-obvious in just a bit; for now, what’s changed with MySQL as a business?
A: A lot, and a little. Among other things.

In terms of how business is done, what you hear from acquired MySQL employees is what you’d hear from any other small company acquired by a big company: grumblings about the crush of process, death by meetings and so on balancing praise for the advantages of (even) wider distribution and greater resource availability. Ultimately, little has changed externally. I’ve even spoken to a few users who were unaware that MySQL had been acquired, shocking as that might be to those of us spend our time covering such things. Predictions of a decommitment from Linux, for example, have proven groundless, and clearly the MySQL employees still feel empowered to speak their mind without fear of retribution.

From a business perspective, then, it would seem that the aquisition and the subsequent dip in Sun’s fortunes haven’t had much impact. And also, that the more things change, the more they stay the same.

Q: Has being acquired by Sun changed the business model?
A: That question presumes that there was a fixed, static business model in place – an assertion that I would dispute. While some MySQL revenue models – dual licensing profits and traditional support/service – have been consistent, the firm has historically demonstrated a willingness to adjust and tweak various dials on their business model to try to find an optimal (for the vendor) and fair (for the community) balance between revenue generation and community relations. That has continued, as we see with the MySQL Query Analyzer. So no, I would argue: the acquisition by Sun has not materially changed the business model.

Q: So what has changed with MySQL?
A: The community around the product. It’s come a long way, and there are some interesting questions looming.

Q: Well, let’s start with the progress: how has the MySQL community come a long way?
A: As Jeremy says, “Nowadays MySQL is sort of a universe onto itself.” It’s the closest thing the database has to a ubiquitous platform, and that ubiquity has – predictably – incented a variety of behaviors and developments. Some that offer a potential commercial benefit Sun/MySQL, and some that raise certain questions.

Q: Which are potentially good for Sun/MySQL?
A: Well, the creation of appliance and datawarehousing lines of business for MySQL in Kickfire and Infobright expand the addressable market for the product, introduce it to new audiences and potentially help drive its development by posing new technical challenges in workload and performance requirements.

Q: And how about those that “raise questions?”
A: Well, let’s remember what the dual license mechanism is and how it works. Here’s a basic description I wrote a while back:

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.

Generally, this model has served MySQL fairly well. By controlling the intellectual property, they retain the rights to relicense the code, thus protecting a revenue stream. They also were afforded a slightly greater protection from forks versus more collaboratively developed projects like Linux, in that they – theoretically – employed the majority of the people qualified and paid to work on the codebase at the lowest levels. But let’s come back to that.

What’s the catch to the model? 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.

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, and possibly why the MySQL-derived Drizzle project has taken a different approach from its parent.

Q: Where are these patches being accumulated?
A: In external binaries from the likes of Percona and OurDelta, who add patches aimed at improving performance and so on and release versions of MySQL that MySQL itself cannot. In a manner of speaking, Jeremy is exactly right when he says “you can get a “better” MySQL than the one Sun/MySQL gives you today. For free.” I’d argue it’s more complicated than that, particularly for enterprises that might prioritize support and service over the latest and greatest features, but his argument is certainly reasonable for certain market segments.

Q: Is that legal?
A: Sure. As long as the patches and original source are released under the GPL (and to be applied and distributed, they have to be), it’s all perfectly legal. MySQL itself could even consume the patches if it wished, but it would forfeit, assuming they couldn’t license it all, the ability to exclusively license the database. So it’s a tradeoff: revenue from exclusive database licensing rights vs a more collaboratively developed product.

It will be interesting to see how MySQL evolves its model going forward, because the trend to me seems clear: more and better patches for MySQL are emerging from the community all the time. Which on the one hand is great for the product, but on the other raises questions for the firm.

It’ll be interesting to see MySQL evolve and adapt its models to a changing ecosystem; certainly they’ve shown no hesistancy to experiment in the past.

Q: You mentioned Drizzle; where does it fit in?
A: Well, Drizzle is a very different project from MySQL aimed at a very different audience, though some would say it’s the original MySQL audience. So in spite of the fact that Drizzle is derived from MySQL, it’s being built using a fundamentally different model and has almost entirely different design goals. More on that project here and here, but while it’s early days, it’s definitely one to watch.

Q: Given Drizzle’s MySQL heritage, is it sharing changes and patchsets with its parent, and vice versa?
A: I wondered about that myself after reading Ian’s entry here, but Brian was kind enough to drop by and comment on that, describing the current state thusly:

In general though? There is no bug flow from Drizzle to MySQL. So all of the bug fixes we have made to turn Drizzle into an ACID compliant/OLTP type system? I don’t see those going back (and there are hundreds). On the same token their bug fixes? Other then the bug fixes for the optimizer we just do not see them.

Both projects get fed Innodb, so as far as that goes we are similar (though we have community pushing for Google/Percona patches).

Apples to oranges, then, even on a bug level. Note especially the comment on the Google/Percona patches; that would be possible in Drizzle where it is not in MySQL precisely because of the difference taking in the licensing and development model.

Q: What do you think the future holds for MySQL, generally?
A: MySQL is in good shape, in my view, because they have achieved volume: something that will be increasingly difficult to do, I believe, because of the trend towards diversification. The primary task ahead for them, as it has ever been, is using that volume for better monetization; that would ease any and all of the challenges mentioned above, I believe. As for how they do that, I remain convinced that the clearest path to increased monetization lies with leveraging telemetry. MySQL users are generating petabytes of useful data every day without lifting a finger, but to date, no one is leveraging that. Query Analyzer can provide interesting insights on a customer by customer basis, but what if it had access to telemetry from MySQL users all over the world? A different value altogether. That data would have massive value in aggregate, to a variety of audiences: MySQL, MySQL customers, MySQL partners, and – potentially – hardware designers.

That’s where my focus would be, if I was in their shoes.


  1. We found within our FLOSSMETRICS research that in general dual licensing tends to results in lower external contributions to the core source code, and more or less no difference in “peripheral” contributions (in terms of external packages or supporting tools as an example). This was found to be consistent with network-like models of contribution in OSS (for a small summary look http://guide.conecta.it/index.php/6._FLOSS-based_business_models#Assessment_of_FLOSS_business_models_usage)
    I believe that dual licensing can be a reasonable business models for companies that are not reusing a large number of external OSS libraries and for which external contributions are not relevant. As soon as the desire to reduce engineering costs arise, however, there is a strong pressure to move to alternative monetization schemes.

  2. Interesting that you mentioned “telemetry” as what ought to be MySQL’s primary focus. I think that Sun is both “missing the boat” AND “banging the drum too hard” about telemetry, in general.

    As far as “missing the boat” goes, they have an EXCELLENT tool in DTRACE, that allows metrics to be collected in a way that is almost transparent to the application itself. As you mentioned in your comments on Amber Road, this is what really sets their use of [Open]Solaris apart from Linux-based and BSD-based NAS implementations. If Sun were so bold as to build a true MySQL appliance with DTRACE underneath (or to provide MySQL as an add-on to Amber Road, with the associated DTRACE goodies plugging-into the provided web interface) then they have some interesting ways to show some data.

    On the other hand, Sun is “banging the drum too hard” with respect to metrics/telemetry, because that seems to be pretty much all they have to offer above Linux right now. If it weren’t for ZFS and DTRACE, I’d argue that Sun’s relevance would be EVEN LOWER than it is now. As it stands OpenSolaris seems to be an interesting direction for the company. However, it isone that is playing catch-up with Linux distributions, in terms of features and usability. It’s one redeeming aspect is the inclusion Sun’s technological bits, like the aforementioned ZFS and DTRACE. What is troublesome to me is the still murky relationship of OpenSolaris to Solaris proper. It is still woefully undefined and (I feel purposefully) obfuscated.

    I think that if Sun REALLY wants to put its money where its mouth is, they should go with a release process similar to that of Ubuntu — have only ONE OS, and that should be OpenSolaris, and choose to define certain releases for LTS, so that their traditional customers can still consume technology as they are accustomed to.

    I did not mean to make this into a rant on [Open]Solaris and Sun, but I think that MySQL is a case of a company/project that has been succeeding in spite of itself, and that the legacy Sun folks as well as the new MySQL Sun folks need to both take a step back and re-evaluate what will make them both a successful company as well as successful developers of OSS.

  3. Steve,
    good posting. We’ve never been great at handling external contributions. In the early days, the founders were too busy to put together a good contributors agreement and in more recent years we did not have the manpower to review all the contributions.

    The good news is, it’s something that we will be staffing more in 2009. We’ve got MySQL 5.1 out the door, it appears to be working well, and we will assign some resources on this issue to make it easier. We’ll also benefit from some of the experts at Sun who have done a good job in this area. Look for some news in the new year and thanks for all the good input.

    Merry Christmas, happy new year everyone…

  4. […] O’Grady recently posted a Q&A pertaining to the past, present, and future of MySQL. There’s been quite a bit […]

  5. […] MySQL: Now and Then Stephen O’Grady, Redmonk […]

  6. […] O’Grady was keeping one eye on the road and one on the rear-view mirror, to get his view on MySQL: Now and Then. Stephen cites Jeremy Zawodny’s item The New MySQL Landscape, which I mentioned in […]

  7. […] also some discussion of this over the Christmas period, sparked by Stephen O’Grady’s Q&A on whether MySQL’s dual-licensing strategy impacts its ability to generate contributions from […]

  8. […] project in immediate jeopardy of being forked and coopted. First, because the risk of forking was present already, and needed no help from Mårten, Monty and co. Second, because with all due respect to the […]

  9. […] “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 […]

  10. […] “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 […]

  11. Seems like Mysql has come along way since this post was published – great work y’all.

Leave a Reply

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