More MySQL keynote videos
Thanks Everyone!

Two Markets in Unison

One of the greatest things about MySQL is the amount of passion that exists inside the company and among our customers and users. People are vocal in the things they love and sometimes hate about MySQL. But it's all good; we love getting input; it helps us refine our products and offerings.

At our users conference this week, Robin Schumacher presented our roadmap going beyond the latest 5.1 release. There's been discussion about the new backup capabilities planned for MySQL 6.0, so let me put all the cards on the table to explain what we're doing and why.

First of all, MySQL 6.0 is currently in alpha and is targeted for GA release at the end of the year if things go well. Online backup has been a long requested item from our customers and we know that the more business-critical the application, the greater the need for better backup facilities that can operate faster and with less disruption. There are some solutions today in the form of MySQLdump (free), InnoDB Hotbackup (commercial), Zmanda (subscription), but ultimately backup is a capability that everyone needs. And technically, to do a good job with backup, certain core capabilities need to be in the server.

One thing that we didn't explicitly state in the roadmap presentation was that these core capabilities will be published as part of the MySQL server under GPL. Why? Because everyone needs them and we want to continue to be competitive and improve our product both for community users and for our paying customers. You will be able to download the new backup facilities in MySQL 6.05 alpha which should be available in the coming weeks. And this week Chuck Bell, Robin Schumacher and other folks have been describing in more detail how the backup works and some of the enhancements coming in subsequent releases. The new backup facilities will include a SQL-command driven interface for online, non-blocking DML for all transactional engines and point-in-time recovery. Compared to MySQLdump it's faster, easier to use and integrated into the server. Again, all of this is open source, under GPL and available to all our users. And as Marten Mickos has said, the core MySQL DBMS server will always be open source.

In addition, we also look for ways to add further value to our paying customers. In so doing, my rule of thumb is we should never take things away from the community or cripple our community offerings. But if there are capabilities that can deliver more value to paying customers and grow that part of the market, that's a good thing. After all, revenues help us hire more developers, and build more open source software. So in the MySQL 6.0 roadmap our plan is to develop plug-ins to the server that provide additional compression, encryption and so on. Since the server will have a pluggable API for these facilities, this is also an area where the community and our partners can create their own plug-ins, perhaps coming up with their own enhancements that further strengthen the ecosystem.

Since MySQL 6.0 is still many months away, there are plenty of details that are not yet finalized. We have not yet determined how the encryption or compression plug-ins will be licensed, but the intent is to make them available to paying customers. And in our view, many or perhaps most community users will not need these capabilities. But we hope that some commercial customers will find that they can save time with these features and so that's an added value delivered as part of our subscription offering. And so just to be clear:

  1. MySQL 6.0 backup capabilities are open source
  2. Add-on modules will be for paying customers

Backup and recovery are hugely critical functions and our goal is to make sure that all of these capabilities are rock solid and high quality, no matter whether it's the core capabilities in the server or the subscription add-ons. So we have committed substantial QA resources in this area to make sure we do it right.

Getting to Lagom

One of the lessons I've learned over the years at MySQL is that we serve two distinct markets. Like normal commercial companies, we have customers who pay us. And like many rapidly growing open source products we have rabid users who love our product, but don't necessarily pay us. Marten characterizes our customers as those who pay money to save time, and our open source community as those who spend time to save money. I think the model is a good one. We may never be FOSSy enough to please the most ardent open source proponents --nor will we ever be as commercially-focused as our profit-driven salesforce would like. But we do try to make decisions to keep things in balance. Or as they say in Sweden: lagom, meaning "in balance." That balance keeps us honest and focused. 

Our goal at MySQL is to serve both markets equally well, even though they have different characteristics. And we recognize that both markets are extremely competitive. While it would be easy to optimize our operations for a single variable (say, paying customers) at the expense of the other (in this case, the community) I think that's a mistake.

Why? Because open source is not only a development model, it's also a distribution model. While the number of customers who pay us is much smaller than the number of community users who do not, most of our paying customers first used MySQL because it is available freely under the GPL open source license. And in many cases, we know that MySQL is popular because of the work of the community who are out there using it, blogging about it, creating add-on tools, products or services. MySQL has always had this "dual" nature, since the very beginning when David, Monty and Alan founded the company as a commercial enterprise.

There is a natural tendency to view the relationship between the needs of our paying customers and our non-paying community as a zero-sum game. That is, we can easily consider that the gains of one group come at the expense of the other. Personally, I think that logic is very limiting. Perhaps it is true in some cases, but it need not be that way. Instead, I think the right thing to do is to find ways to benefit both markets at the same time. After all, the two markets are joined at the hip in many ways.

How so? MySQL customers benefit directly from the large scale of the community which has helped create a thriving ecosystem. For example there are many third party tools, books, training courses, consultants created by the open source community and our many commercial partners. And obviously, by having many very advanced community users, there is a lot of sophisticated know-how about MySQL. We are always blown away by the kind of innovation that comes out of our users, the contributions that are made (directly or indirectly), the way they push the limits of our software, test it, make suggestions, write innovative applications for it, the bugs they report and so on.

And the community benefits from the growing revenues contributed by the paying customers. I was speaking to MySQL guru Frank Mash over at Fotolog and he said one of the benefits of commercial focus is that it makes MySQL more legitimate in companies. Perhaps that's not true for everyone, but I suspect it's true for some people. Since there's growing commercial demand, it means that there are more jobs available, which leads to more opportunities for developers and DBAs, which means the community continues to grow.

There's a "virtuous circle" that links the community and the commercial users of MySQL. And MySQL is in the middle trying to make sure we are balanced in our actions and not neglecting the interests of either market. It's not always obvious how to benefit both groups and there are few successful models to guide us at this point. So we are constantly forging new territory, experimenting, trying new things, and listening for input. As we do so, we try to be true to the mission we have declared for many years: "make superior database management available and affordable to all." That mission continues on in 2008 even as we are part of Sun Microsystems.

Feedback, Input Welcome

Going back to the original premise, I think our plans for backup in MySQL 6.0 meet the needs of both our markets by having core capabilities in the community server and additional convenience features for commercial customers. And there's no limitations here to prevent anyone in the community from creating their own plug-ins.

Let me know what you think of the ideas here. Would you use the new backup capabilities in MySQL 6.0? Would you want the add-on modules for compression or encryption? Is this the right balance between the needs of Community and Customers? What suggestions do you have for us?


As an Enterprise customer, I can say that that at least for me closed features in mysqld are not what we are looking for. We are of course willing to pay for quality software but personally I am wary of the vendor lock-in associated with proprietary software -- that is much of the reason people such as myself enjoy using free and open software like MySQL.

I am less wary of proprietary software when it comes in the form of add-on software like Workbench, MySQL Load Balancer or the monitoring portions of Enterprise monitor -- or the insight driven software such as the advisors in Enterprise monitor and the new Query Analyzer. These give me value without providing the lock-in I fear from proprietary vendors.

What I would really worry about is the alienation of the next generation of customers, preventing them from trying MySQL from a (wrongly) perceived notion that the community edition is crippleware. Miscommunication like what you saw on Slashdot will surely not be the last.

Thanks for taking time to clarify the specifics. It helps a lot to know that the core server will continue to be GPL, and that the parts of online backup being developed inside the core will be available to the community.

I agree with Ryan, am much less concerned with proprietary development in the form of add-on services.

The only difficulty with this line of reasoning, Zack, is that "lagom" will invariably swing toward the profit side of the equation. You're a public company now. You will be under tremendous pressure to deliver the numbers, and the numbers are never long-term. They're always this quarter.

I don't think it's necessary that you adopt Red Hat's model, though it works very well for Red Hat and for those of us who have espoused it. Rather, I'm suggesting that you would do well to separate - *clearly* - your community product from your enterprise product. Instead, what you appear to be doing is making your community and customers forever guess where the line will be drawn. You've emphasized how critical backup is...and you're only making it available to paying customers. Does this mean the more critical, the more likely it will be closed?

I'm not criticizing. It's a difficult road. Alfresco had the same decision to make and we scrapped our proprietary extensions. It was too much work and bother always having to decide what would be open source versus proprietary, with "important for customers" generally translating into "proprietary." Perhaps you'll be better at it than we were. Or perhaps you'll discover a new licensing model along the way that we'll all follow. I'll be a fan, regardless.

Thanks for these comments. We are still gathering input, so its much appreciated.

I'm not sure that the Red Hat / Fedora model makes sense for us. It has been successful for them, but there are differences between an OS and a DBMS.


The thing about open source is that the community can verify the code as being well-written, secure, and efficient. If you don't release all of it as open-source, you will put some customers off using it, particularly those who require verifiable security and to KNOW that there is no spyware. But that still shouldn't preclude Sun from offering a paid-for support agreement for those who feel they would prefer the warm feeling of having someone they can call on if they need to.

In addition to the security/spyware point thae Peter brings up, by releasing certain features in the enterprise version of the product, you implicitly state that your (mysql/sun as a company) can test those features (along with your paid customers) at least as well as the community at large can.

This seems like a very cathedral approach to me and against one of the fundamental strengths of the open source development model.

This should trouble your open source savvy enterprise customers.

Hi Zack

Thanks for a good summary. In fact, even being a MySQL employee myself, there were parts of this that I had not previously been aware of. (In particular, I had understood the "online" part of the backup would also be closed source, which I'm happy to see is not the case now.)

First observation: We probably could have done a better job communicating this proactively up front, it shouldn't be a surprise to anyone that this would go on Slashdot. Now MÃ¥rten and you have a hard time catching up with all of the disinformation up there.

Second: For Ryan in the first comment, and other paying customers. Make sure your MySQL account manager is aware of your feelings. The opinions of paying customers is obviously at the highest importance for the MySQL organisation and the input from the sales organisation is given a lot of weight since they are the ones who spend a lot of time with our customers. Unfortunately, many account managers don't read blogs! So make sure whoever in your organisation talks to a MySQL account manager mentions this, if this is in fact how you feel. (That being said, Zack is also a very good person to funnel opinions through!)

Third: We all like Open Source, both as users and programmers. Finding out how to transfer the money from users to programmers is not that easy though. (Since Open Source software is so useful to it's users, by modern capitalist logic it is only right that such a transfer happens. As Zack says, it allows us to produce even more Open Source software.) Matt from Alfresco, I wouldn't be surprised if after a couple of years [email protected] arrives at the same conclusion you did. Any good hints at what business models MySQL could try next? In particular, how did you do it?

Finally: Some very nice and subtle spam from Jenny up there, this is probably the best written spam I've ever seen. I had to read several times to be certain that it is not at all on topic for this article.


From my perspective, MySQL is taking the right approach with regard to added value plug-ins. Yes, some of them will be closed source, but the API to incorporate them into the mainline product will be open, thereby leveling the playing field. The kinds of organizations that most need these features are also the types that will pay for such innovation.

If it turns out that there's significant market interest in these add-ons, MySQL will have competitors (including, perhaps, some open source projects) for these new plug-ins. This means that market forces will be in play, likely keeping costs under control for that subset of the market that requires these capabilities. All in all, this is probably the only way that MySQL can remain true to its open source roots while funding leading edge innovation for highly specialized functionality.

As someone who has been doing relational db's since before SQL was the, er, standard, I must say, the Oracle people have it right: a DBA can screw up anything, except restores. Having a proper, transaction-aware solid-as-a-rock, backup and restore capability is what differentiates professional databases from toys. And professionals from little boys.

Some of those high profile screwups, like losing all posts of popular blogs, ought to be an object lesson.

thanks for the news

The comments to this entry are closed.