News that MySQL was to bring out a closed-source addon has provoked a storm of protest across the Internet. This has prompted an interesting reaction from the company, which has responded in a very direct manner to that wave of negative comment. For example, shortly after I posted my story on the subject, I received an email from Marten Mickos, formerly CEO of MySQL, and now head of Sun's database group, offering to explain what exactly was going on.
Whatever you think of Mickos's reasoning behind the move, explained below, the company deserves full marks for responding so quickly to a situation that it admits was caused by its own slightly maladroit handling of an announcement, which in retrospect was bound to be controversial. In particular, Mickos seems genuinely to welcome this kind of criticism because he recognises that rapid and honest feedback – whether good or bad – is one of the key advantages of the open source way.
GM: There seems to be a lot of confusion surrounding MySQL's future plans; could you please explain what exactly you have announced?
MM: We're talking about something for version 6 [of MySQL], which is coming out in nearly a year from now. So it's nothing imminent, and there was some misunderstanding by some that it would relate to existing code - that's not true. So for 6.0 we're adding an online backup module to the core product, and this backup will be available for all and anyone. It will be under GPL - it will be open source as we have always produced. And this backup function in the core product will have an API of its own that allows you to build pluggable addons to the backup. So when we introduce it, you can do your basic backups using the features, and everybody's happy with that, but if you like you can build your advanced features on top of it, thanks to the API.
GM: What might that be?
MM: People can do anything they like, so in that sense it's not my mind governing it, but theirs. But if you ask what we are doing, we are planning to add encryption and compression as pluggable features and those we plan to ship to paying customers, to subscription customers.
GM: Does that also mean that it will be closed source, or will you be giving them the source when they pay?
MM: So there we haven't made a decision yet, we are contemplating a number of scenarios. And one is that it would be closed source and nobody other than us could see the source code; another is that we give the customers the source code if they like to see it, which we certainly can do; the third one is that it is GPL, we just don't ship it to other than paying customers. So there's a number of alternatives. Because we didn't have to decide yet, we didn't, that's something we'll do when the features start to get ready and we start shipping them to customers.
GM: Why did you decide to take that particular route?
MM: An important part of this is our and perhaps personally my belief that in terms of open source businesses it's such a new industry that we just must continue to experiment. And this is a serious experiment, but it's an experiment nevertheless. And some people say, Marten, why don't you just go back to selling support, that's the business model for open source? And I just refuse to think that that's the only way to build a business and that that's what we all should settle on, because I don't think that's a useful thing for either the customer or the vendor.
So that's a major reason for us doing this, and we are trying to figure out ways that we can win in two markets. The one market is the market for non-paying users, open source users, who just love your product and use your product and help you with various things, but they don't really pay you money. So you've got to win there, that's why we'll make sure that the GPL product is very, very competitive and is a great product on its own.
And then we also want to win in the commercial market. And this is where we differ from open source projects in that open source projects have no specific ambition to win in the commercial market, but we do. So we are trying to figure out ways of making it very simple for our paying customers to know what it is they get when they pay, and what they are paying for.
We specifically have customers who say: Hey Marten, give me just something that I can show to my boss that I got for the money. I'm very happy paying you the money, but we need something tangible because my boss is otherwise asking me why the heck we are paying. It's not an unwillingness - our contact person usually is somebody who will be happy to pay, but this needs to be a no-brainer in the corporation, and then they can look at this and say, OK, this makes sense, this is what we are paying [for].
So as we do this, of course, we meet exactly the crossfire that we are now in, meaning the same solution seems to upset one market and please the other one. So then the question is: How do we ensure that we are not completely upsetting our open source users when we do something commercially, or vice versa. And this is why it's vital when I describe this backup functionality that there's an open API. What we have done is we've said here's an API anybody can build an addon feature [with], and we will be building ours. We are at the same time opening up the playing field for anybody else to do so - a customer, a partner, a competitor - they can all build their addons. If somebody would like to get access to that functionality without us, then they are free to develop it and they can do it on the same basis as we can, we're not using any hidden hooks in the software.
GM: One issue is that you seem to be throwing away an advantage of open source in the sense that if it is closed then obviously people can't help you make it better.
MM: That's true – absolutely, it's true. That's why for any such code we will have to hire more QA people, and do more work because we don't get that help from the community.