MySQL Community Version

Jul 28, 2008 / By Sheeri Cabral

Tags: ,

The MySQL Community version is different in theory from the Enterprise version in relation to the following points:

0) It’s free
1) It has community patches
2) It is released less often
3) It is tested less strictly

In reality, the first two differences are not applicable — the binaries and source code for Enterprise can be freely and legally downloaded at http://mirror.provenscaling.com/mysql/enterprise/. The process for adding community patches to the MySQL source code has not been changed sufficiently to be able to actually add community patches and encourage more community development.

I understand that MySQL (and now Sun) needs to make money. I also understand that development takes a lot of effort, and seeing an ROI is important. The Community/Enterprise split was designed to have tradeoffs on both sides. However, currently there is no benefit to running the Community version.

While I would love to magically make community contributions easy to put into a Community version of MySQL, logistically that’s not possible right now. I do have a solution that is possible right now, that takes very few additional resources, and is something I think will be acceptable to the MySQL community and to Sun — assuming the MySQL executives can admit that the Community version has not been working out.

I propose to make the Community release an older version of an Enterprise release. In this way, Enterprise users still get value in having bugs fixed and features added first, and Community users can choose to upgrade if they want the latest features. There is very little overhead in having Community releases, with no overhead in having to manage two trees/branches/whatever from both a code and build standpoint. Maintaining the promise of immediate security releases, 4 code releases per year and 2 binary releases per year becomes trivial.

The question is, of course, how far back the Community version should go. And should there be a delay (ie, release the January Enterprise version as the June Community version) or not?

I recommend that security releases be immediate (as they currently are) and for all other releases there should be a delay of at least 6 months, perhaps 1 year. Certainly that’s enough of an incentive to get customers to upgrade without having folks feel like the Community ersion is crippleware.

What do folks think of this as a solution to the Enterprise/Community split dilemma?

5 Responses to “MySQL Community Version”

  • Sheeri,
    Although the official position of my company is different, I am with Baron in thinking that the current split is bad for customers.
    (http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/)

    IMO, but this is my personal view, we should remove the binary differentiation, and release to the community first, and after some weeks of testing we should recommend the release to paying customers. This is what I was doing as a consultant before joining MySQL, and thus my recommendation to the decision makers is to remove the differentiation at all.

    Giuseppe

  • Marten Mickos says:

    Sheeri,

    Thx! We are certainly open to suggestions, and we are not denying that the model isn’t perfect yet. (But it also isn’t entirely wrong, judging from the rapidly growing numbers of subscription customers we have)

    Your proposal has been discussed before. Some people say it won’t work because they feel that the Community edition should be *newer* than the Enterprise one, so that paying customers of Enterprise would receive something that the community has already tested.

    Every model has its pros and cons, of course. Will be great to see what other comments you get on this blog posting. And thanks again for helping us perfect the model.

    Marten

  • Lukas says:

    3) should be clarified. There should not necessary be less releases, just less binary releases.

    Anyways your proposal makes no sense. Sun/MySQL should get back to doing open source. Right now they do not use the community to find bugs for their Enterprise users, they do not use the community for development (Drizzle is the new path for this I guess). They solely use the community to write apps for them to grow the market opportunities. How this makes business sense is beyond me, especially since MySQL has a serious quality issue, I would be happy to get as many testers for the binaries I ship to my Enterprise customers.

  • Xaprb says:

    I think your idea is actually the reverse of what I’d want to see. Enterprise should be an older, less bleeding-edge version of Community. That’s not the only change I’d like to see of course.

  • Nicklas Westerlund says:

    For what it’s worth, it’s a bit of a double-edged sword.

    If I’m a paying customer, I want bug fixes quickly obviously.
    But, I don’t want that on the cost of having to “test” the software for the community users, so I would prefer to see a model where new functionality goes into community first, and when properly verified and tested by the mass, goes into enterprise. Whereas bugfixes go into the enterprise release first. (Security fixes should go to both)

Leave a Reply

  • (will not be published)

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>