MySQL and "commercial extensions:" Core, complements, and semantics

MySQL has made a short-term public relations error in calling out its proprietary extensions, but one that is easily fixed. It simply needs to reassure its user community that it is not taking anything away, now or in the future.

MySQL has placed itself in the middle of a rising furor over its allegedly diminished commitment to open source. To be fair, it has only itself to blame.

It all started with a disgruntled ex-MySQL employee, Jeremy Cole. Cole declared that MySQL's sky was falling because it was to be releasing certain parts of the next version of its database as closed-source software. Marten Mickos responded that he had misunderstood (when, in fact, he had understood very well), it went to Slashdot (where it was of course misconstrued even further), and we're left with a somewhat tepid defense by Marten in the comments section of Slashdot to the self-addressed question, "Why is MySQL now producing some proprietary software?":

The reason is that we have an ambition not only to produce FOSS [free and open-source] code, but also to be a profitable business that can exist for a long time. Each time we make more money, we hire more developers to develop GPL code.

If the world were perfect, we would only produce GPL code and we would have a great business that can fund the software development. But we have found that the world is not perfect. We have been experimenting with a variety of business models around FOSS (dual licensing, support only, simple subscriptions, different binaries for community and enterprise, non-open source features) to find the best one. And we will continue to experiment until we are satisfied. We need to find a model that allows us to produce a ton of great code under GPL while having the financial strength to do all this.

To get to this goal of ours, we believe we have to be more pragmatic than dogmatic. Call it a necessary evil if you like. Having production add-ons that we provide only to paying customers currently seems to use to be a useful model. Our partners and customers think it is great. Many users think it is great. But not all do (as evident from this thread on /.). I would hope we could please all, but I am afraid we cannot.

It's a fine defense, and one that SugarCRM has used for years (and one which Zimbra never had to, for some reason, quietly churning out tons of cash in the background while others took the arrows. Perhaps Satish was on to something :-). But it's unclear to me why MySQL had to get to this point.

Perhaps it's just a matter of semantics ( Marc Fleury certainly believes it is ), but I think MySQL would have been wiser (at least as an interim step) to adopt Red Hat's model rather than don the hairshirt over commercial extensions, without clearly defining what this means.

What would MySQL Enterprise look like if it truly followed Red Hat Enterprise Linux?

  • MySQL would make Enterprise available only to paid subscribers, which subscription would include 100 percent of its core database software as GPL (or some other open source-licensed) code, along with proprietary services (support, MySQL Network (Red Hat's Network was proprietary), up-to-date bug fixes, etc.);

  • MySQL, like Red Hat, could block "first sale" access to the Enterprise bits to paid subscribers by placing the availability of the bits behind a support contract (This would ensure a steady stream of paying customers but wouldn't stop a CentOS, as seen below);

  • These subscribers would have the option to redistribute the core software because, after all, it's open source. (They would not be able to distribute Network and the patches/services distributed through this mechanism.) However, as with CentOS and other RHEL clones, they're more of a minor nuisance than a serious threat to Red Hat, and I can't imagine that MySQL would suffer much at the hands of the clones, either (including from Oracle - I heard from one of its Unbreakable Linux salespeople that things aren't going too swimmingly there);

  • MySQL is spared having to make distinctions between proprietary code and instead can focus on a very clear distinction between core (100 percent open source) and complement (some percentage of which is closed).

The sound and fury around MySQL's moves is because people (wrongly, for the most part) perceive that MySQL is closing off the core of its product to them. It is not. MySQL is considering holding back future add-ons to its core product, either as proprietary software or as proprietary services (in the fashion that I've described). But by not taking a bold, RHEL-esque move, MySQL's position looks shakier than it actually is.

Of course, MySQL is a business that needs to please shareholders. I believe, however, that it can do this without sacrificing the community that contributes much to its success, even if it doesn't contribute much to its code base.

The key, again, is to separate the core from the complement. MySQL, the database, is the core. That should be open source. It's good for MySQL that it be such. It leads to greater distribution.

As for monetization, in open source you do it exactly the opposite as in proprietary software, which jealously guards the core and throws trifles to the crowd as free complements. In open source, you charge for the complements while giving away "the crown jewels."

The services around MySQL, including Workbench (around which MySQL did a better job of explaining the difference between the open-source core and the "proprietary" periphery), Network, and other add-on services that make the MySQL experience more pleasant but not necessarily more capable are fine to close off to paid subscribers, as Red Hat has long done.

As Michael Tiemann of Red Hat expresses it:

The bits are free; the service is not.

A very simple principle that can help MySQL and every other open-source company intelligently make decisions about how it licenses its software.

Ultimately, MySQL has made a short-term public relations error, but one that is easily fixed. It simply needs to reassure its user community that it is not taking anything away, now or in the future. Instead, it is offering additional services to subscribers, services that augment the MySQL experience but don't imply a degraded MySQL experience for those who opt for the free download of Community.

One way to further improve such a strategy is to make the short-term difficult step of clearly separating out a separately trademarked/branded community product as Red Hat did with Fedora. Clearly brand it as the community/labs product and foster its growth on its own merits, then focus the bulk of MySQL, the company, on MySQL Enterprise. Fedora is a vibrant community in its own right. There's no reason that Dolphora (MySQL Community ;-) couldn't be the same.

Tags:
Tech Culture
About the author

    Matt Asay is chief operating officer at Canonical, the company behind the Ubuntu Linux operating system. Prior to Canonical, Matt was general manager of the Americas division and vice president of business development at Alfresco, an open-source applications company. Matt brings a decade of in-the-trenches open-source business and legal experience to The Open Road, with an emphasis on emerging open-source business strategies and opportunities. He is a member of the CNET Blog Network and is not an employee of CNET. You can follow Matt on Twitter @mjasay.

     

    Join the discussion

    Conversation powered by Livefyre

    Show Comments Hide Comments
    Latest Galleries from CNET
    Best iPhone 6 and iPhone 6 Plus cases
    Make your own 'Star Wars' snowflakes (pictures)
    Bento boxes and gear for hungry geeks (pictures)
    The best tech products of 2014
    Does this Wi-Fi-enabled doorbell Ring true? (pictures)
    Seven tips for securing your Facebook account