“Hybrid” Source, MySQL, and the Economics of Open Source

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

As is typical, I’m late with the news, but given that we’re still getting inquiries on the subject, it’s worth taking a look at the MySQL Workbench news. Particularly in light of the fact that it’s closely tied to another frequent line of questioning from our clients: hybrid source. In an effort to kill the proverbial two birds, then, let’s indulge in a quick Q&A on the subject.

Q: To open, how about the standard question: anything to disclose?
A: Indeed. MySQL, the vendor behind Workbench, is a RedMonk customer. As are several competitors of MySQL’s, including EnterpriseDB, IBM and Microsoft.

Q: Before we get to the question of hybrid source, can you quickly bring us up to speed on what’s important with respect to MySQL Workbench?
A: Sure. To begin with, MySQL Workbench is a database design tool. While that might not sound terribly sexy, it’s the kind of tool that DBAs live in so they’re geeked about the featureset. For the rest of us, however, the most interesting aspect to the Workbench news has little to do with the functionality, and more to do with what it says about MySQL’s business specifically and open source more generally.

Q: Why is that? If it’s just a database tool, why is it of such importance?
A: Because of the fact that it actively embraces a quote unquote hybrid source approach. While not unprecedented, in my opinion anyway, MySQL has traditionally been known as a “pure” open source vendor in that all of its source code was open and available. This will not be the case with Workbench, which will be release in two versions: a “Community” version that is open source, and a “Standard” version that is not but offers differentiating functionality. Given MySQL’s high visibility within the open source world, many are questioning what – if anything – this decision means for open source.

Q: So let’s talk “hybrid” source; can you be more specific in terms of what, precisely, that means?
A: Definitions vary, and while it’s certainly not a “precisely” understood term at the present time, it’s generally applied to projects or products that combine open and closed source software to produce an asset containing both. EnterpriseDB, for example, can be considered a hybrid source product, combining as it does an open source Postgres core with closed source extensions that provide, among other functions, performance improvements and Oracle compatibility.

Q: Is hybrid source a trend that you expect that we’ll see more of?
A: If commercial vendors have anything to say about it, and they will, probably. Very few commercial vendors at this point will be comfortable “burning the boats” as Matt Asay might put it. And when a high profile open source vendor like MySQL begins to embrace the model, it’s difficult to conclude that it’s not a trend.

That said there are exceptions to the rule. Asay’s Alfresco, as an example, is trending in the opposite direction, and while progress is slow in some quarters Sun has publicly committed to making the entirety of its software portfolio open source.

To judge by the chatter amongst our contacts, however, you’ll be hearing more rather than less about hybrid source.

Q: Is that good or bad?
A: Neither, I’d argue. Do I relish the task of explaining hybrid source to customers just getting their minds around open source? No. And would it be preferable from a user’s perspective if everything was free and open source? Certainly. I’ve spoken with more than a few would-be Zimbra customers, as an example, that decided against the software after they discovered that the features they wanted were locked behind the Network Edition pay wall, whose pricing was not flexible enough to suit them.

But whether hybrid source is a good or bad for Zimbra’s business is actually difficult to answer, dependent as it is on the metrics used to measure success. If ubiquity is the goal, for example, hybrid source is almost certainly a bad thing, as it can act as a throttle on adoption. If conversion percentage and revenue generation are the priority, however, it can be a good thing. Not always, but it can be. Is it better to have more users with a infinitely smaller percentage that pay, or an infinitely smaller user base far more likely to buy?

The answer is: it depends. Or no one knows. Take your pick.

Q: But surely that means that hybrid source is bad for open source?
A: If you’re among the crowd that believes that all software should be free and open source, and view hybrid source as something of a bastardized union, then yes, you’re probably going to think it’s bad. If you’re of a more pragmatic mindset, however, it’s probably a net positive. True, it’s possible that you’ll be forced to pay for certain features or pieces of functionality before the point of value as with traditional software, but on a net basis hybrid approaches are likely to free code that otherwise would have remained proprietary. As I tend to be a believer that a percentage of something is better than an entirety of nothing, I’m generally fairly understanding of at least the motives behind hybrid approaches. With certain exceptions, of course. Which is but one of the reasons free software purists occasionally get frustrated with me.

Q: So back to Workbench…is this the future of how open source firms will realize economic returns on software that traditionally has exceptionally poor customer conversion rates?
A: No. It’s a future, not the future. Personally, I think it far more likely that open source firms will grow their businesses on the backs of network services built on and around open source technologies than by monetizing strictly the bits themselves. It seems to have worked ok for Google, after all. But it will take time for many of the firms to retool and reorient their business to what is a fundamentally different model, and in the meantime hybrid source may offer a potential trigger to convert the customers that might pay you to the customers that will pay you.

Q: For those that might be considering hybrid source, then, what are the lessons they need to learn?
A: Absolute transparency is the key. Being absolutely up front about what is open source and what will require customers to write a check is critical for avoiding accusations of bait and switch, false advertising and the like. In the case of Workbench, I think MySQL’s done a pretty good job. They’ve explained the rationale behind the split in a blog entry here, they have a grid explaining the delta between the editions here, and they have that which is near and dear to my heart – a Q&A.

Q: It’s really that simple? Just being transparent?
A: If only. The real difficulty lies in determining which features are free and which are reserved for paid editions. While it’s true that you can’t please all the people all the time – witness the fact that even in software that’s completely free and open source you still have complaints – the trick to hybrid source is walking the fine line between giving enough away to keep people happy and preserving functionality that makes the software worth paying for. Unfortunately, having consulted on similar issues in the past, this issue is more art than science.

Q: So you believe that it’s simply a matter of holding a key feature or three back?
A: No. I believe it’s a matter of knowing what people want to pay for. And in many cases, they don’t want to pay for the bits, but they will pay for a service. Thus I agree with Matt when he says:

As noted, MySQL would have done better to brand Workbench Standard Edition as a service, perhaps as part of its Enterprise Network offering, much as Red Hat’s Network offering is proprietary.

If I was MySQL, I would attempt to differentiate the non-open source version on the basis of services provided rather than feature ticklists, as they have in the past with MySQL Community and MySQL Enterprise, but perhaps they’re not in a position to do so at the moment.

Q: So how do you think MySQL did with Workbench? Did they get the balance right in terms of features?
A: Honestly, I don’t know. There’s a saying in baseball that the hitters will tell you how a pitcher is throwing, more so than any radar gun or scout’s eye can, and that’s the case here.

I’ll have a better read on that after seeing the reactions of a greater number of users, because going off single datapoints will not give an accurate read. Ultimately, I think MySQL has done a better than average job communicating their intentions, and it’s now up to the users. Like the hitters, the users will tell me how MySQL did, and I expect MySQL to react accordingly.

Q: Anything else to add?
A: No, that should be about it. As always, feel free to ping me with questions, objections, corrections, whatever. If you have feedback for MySQL on their decision, feel free to let me know and I’ll be sure that they get it. Provided that it’s constructive, of course.