In the past few days, MySQL Community 5.0.41 was released. While reading through the changelog, I noticed the following entry:
The patches for Bug #19370 and Bug #21789 were reverted.
Upon looking at Bug #21789, I noted that it was originally committed in MySQL Enterprise 5.0.32, released December 20th, 2006. The next community release which would have contained the patch is MySQL Community 5.0.33, released January 9th, 2007. This means that not only was the patch not vetted by the community, but there was a full 20 days between the enterprise release with the patch, and the next community release which contained it. According to MySQL’s release process, it could have been a full 5 months, given the right timing…
The patches were rolled back in MySQL Enterprise 5.0.40, released April 17th, 2007. Yes, the patch was committed without much vetting, and then had to be rolled back, 118 days later, in the “enterprise” version of MySQL. Why?
Back when MySQL first polled me about the community/enterprise split, I told them that this would happen. The reason it happened, of course, is that MySQL willingly shut down its only avenue for vetting these sorts of patches. They made a similar split to RedHat Enterprise Linux (RHEL) vs. Fedora Core Linux, but for some reason broke the process at the same time: they produce releases of community much less often than enterprise. That means that nobody in the community is testing the features that they stick in enterprise. They just get pushed out with no public vetting.
The way that RHEL and Fedora work is that all the shiny new stuff is pushed into Fedora first. After it has been deemed that the Fedora process, plus plenty of internal vetting, has been successful, those patches or new versions are merged into RHEL either for the next patchset, or the next full release. This, of course, means that Fedora is always ahead of RHEL. That’s exactly the idea. RedHat is betting that enterprise users (whatever that really means, these days) want a stable slowly-moving release that is “guaranteed” to work, and easy to keep up with.
On the flip side, Fedora is great for users who want the latest and greatest all the time—primarily desktop users and developers—people who are willing to work through the quirks and contribute a bit back in the way of feedback. People that like to run yum update a couple times a week. What do they get in return? A (usually) good product that is completely free.
Why did MySQL reverse the process and make it (in my opinion) useless? I suspect their sales team thinks it would look bad if the community users “get more” than the enterprise ones. But, take a look at the MySQL releases themselves, discounting any other “features”—which are debatable—that you receive with MySQL Enterprise. Why would I pay to get a release with the same unvetted, broken, may-be-rolled-back patches as everyone else gets? Why would I suggest that our customers pay?
Jeremy Cole 
Good point Jeremy.
In fact I also raised this concern to Kaj when we had a call with him on Enterprise/Community issues.
I see MySQL Enterprise is kind of copying what big brothers like RedHat has done but without deep though to make it well to the technical side.
There are other confirmations you can see this was mainly done as Marketing only split – for many months Enterprise and Community were built from practically the same tree while sold as different things already.
I think part of the issue here is that you end up with paying customers who want a fix *now*, and because they are paying, they feel entitled to get those fixes and aren’t willing to wait for people who don’t pay to recieve them first. Yes, this does overlook the value of the vetting process, but this is not anything new; usually commercial vendors and thier customers “dont get it” as they say, so I’m not sure why people expect different from MySQL.
Hi Robert,
I can certainly see your point, but at the same time, if there is so little difference in the vetting process, why not just stick with a single release? The entire idea behind the split was that the enterprise version would somehow be better for the “enterprise” customer. I would argue that it’s actually *worse*.
Regards,
Jeremy
Yeah, I looked at the `enterprise’ price tag when the split was made and came to the immediate conclusion it was a scam. That’s like $50/month for the basic level of service, and what do you get? More binaries and a token amount of feel-good support. Big deal; we build from source anyway because the non-rpm binaries lack libmysqlclient, and we try to avoid the bleeding edge of releases too. Upgrading isn’t free in terms of admin time or the risk of breakage.
In short, the enterprise version is clearly aimed at companies with more money than sense.
The other problem is the license agreement says that if you buy one Enterprise license, you have to buy an Enterprise license for EVERY mysql server, anywhere in your company.
So, if I buy 1 Enterprise license for my single production server, I also have to buy 2 for my report servers, an 12 for the qa and staging systems, and 8 for the development workstations!!!!!!!!!!!!
Enterprise:
more features + less vetting = more breaking
Community:
fewer features + more vetting = more stability
This is the scenario we have today. However, back when the announcement was made, the community kvetched, saying:
We do the vetting, why can’t we get more features?
“You don’t care about us, you give us old crufty feature-starved software, and expect us to make it better or give you $$ to do so.”
You’re selling out!
If something’s broken I still have to pay to fix it.
On the other hand, what if the roles WERE reversed, as you suggest?
The Community customers would complain that they have something that’s “broken” or “has too many features implemented poorly” and yes, STILL has to pay to get it fixed. “You don’t care about us, you give us broken software, and expect us to fix it or give you $$ to do so.”
Then Enterprise customers would then ask why they’re getting *less* product, even though you could argue that a truly “enterprise” product is stable. MySQL Cluster is an excellent instantiation of this — very few people want MySQL Cluster for what it was designed for: an in-memory database. An enterprise level product for specialized needs, such as telecom companies. I’m imagining true horror when the disk-based clustering is a hard and fast reality — it’s not what Cluster was DESIGNED for, but because so many folks are whinging, they’re going to take cluster and add on “write to disk every now and then.”
I would say the problem isn’t that MySQL went the wrong way. I think successful models occur either way.
The problem is that patches got into a release without enough vetting. That’s bad for any customer, paying or not. Yes, you can argue that the Community is MySQL’s testing ground, but that makes Community members whinge (“we’re you’re guinea pigs, and you give us software that may or may not work, and then want us to pay when it doesn’t?”)
So, yeah. Forget about which way to go in the split. How about “vet the code”?
jcole’s weblog: Jeremy Cole’s take on life. » Blog Archive » MySQL Community split officially a failure
jcole’s weblog: Jeremy Cole’s take on life. » Blog Archive » On Sun's acquisition of MySQL AB
451 CAOS Theory » Balancing community and enterprise needs