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.
