Refining MySQL Community Server

MySQL AB has announced some changes in the way it handles the Community and Enterprise releases of MySQL. From the post:

The changes are in the areas of release policy and stability of MySQL Community Server and in the availability of MySQL Enterprise Server.

The changes start from the question: “How can we better target MySQL Community Server to the community and MySQL Enterprise Server to the paying customers?“. Many of them originate from our ongoing discussions with the Linux Distributions, some of whom have been distributing MySQL Enterprise Server to their user base, since MySQL Community Server hasn’t conformed to their needs of feature stability and release schedule.

Our intention is for MySQL Community Server to be very good, and for MySQL Enterprise Server to provide further value on top of that. The five changes, in short, are:

1. New features and community contributions will go into the next development tree. The new features will not be applied to a current GA release, ensuring stability for the Community Server. At the time of writing, the development tree is MySQL 5.2.
2. There will be at least two yearly “mature GA” (currently MySQL 5.0) binary builds. They aren’t scheduled, but usually triggered by grave security vulnerabilities.
3. When a version of MySQL initially goes GA (as 5.1 soon will), the company will release binary builds of the new GA product every month for a period of several months until it reaches a point of suitable stability/maturity to be considered a “mature GA” release — as described above.
4. There will be four yearly “mature GA” (currently MySQL 5.0) source releases, predictably scheduled, to be released once every quarter. These will be ideal for use by distributions shipping MySQL.
5. The current Enterprise source tarballs will be removed from ftp.mysql.com. These will move to enterprise.mysql.com, and will be available for our paying subscribers only.

This has sparked quite a few responses in the community, most of them negative. For one, it’s an extremely confusing setup that builds on what was already a confusing system. Second, it appears to go against what they are attempting to accomplish. Why would supposedly stable “Enterprise” builds be released more often and be tested by less people?

To me, that’s not the worst of it however. At least on the face of it, it seems like a bad business decision. Let me make one thing clear: I really like both MySQL the product and MySQL AB the company. They have done a ton for Open Source and I’d like nothing more than to see them make boat loads of money. The way I see it though, their adoption process is usually something along the lines of: technical person installs MySQL, something critical ends up getting implemented using it, managers insist on a support contract. Maybe what I’ve seen it not representative of the average MySQL sale, but if it is this move should prove quite bad for the bottom line. By making the Enterprise product harder to implement, it makes a support contract less likely in my mind. I thought they were trying to sell on value adds, such as support and monitoring. Is it possible that isn’t working and they are seeking other alternatives? If so, that’s worrisome. I trust that MySQL AB is watching the responses on this closely and really think in the end they’ll do the right thing, but I have to admit this is a little troubling. It’s a trend I’ve seen at a broader scale bubbling beneath the scenes and some interesting times could be ahead for “Enterprise Open Source”.