(363) With the my blog entry yesterday on Refining MySQL Community Server, did anything really change? If so, was it for the better or for worse for the community?

(364) My answer is “not much”, and “for the better”, but feel free to disagree.

(365) Judging from some reactions in the community, a lot changed, and for the worse.

• (367) Mike Kruckenberg feels that MySQL takes another step away from Open Source, through no longer publishing the sources for the Enterprise incarnation of the MySQL Server.
• (368) Jeremy Cole claims that the MySQL Community split is officially a failure, and that MySQL fundamentally misunderstands their community.

(370) Strong words.

(371) So let me expand on the “not much” part:

(372) The negative reactions that I experienced on the #mysql-dev channel in the Freenode IRC chat stem (like Mike Kruckenberg’s blog) from the removal of the source code of MySQL Enterprise Server from ftp.mysql.com. I argue that while this may feel or appear like a step away from Open Source, the real effect on the core MySQL community member is minuscule. And this is by design. We don’t intend for the change to adversely affect core MySQL community members’ usage. What we do intend is related to positioning: MySQL Community Server is for our users, MySQL Enterprise Server is for our paying customers. We want people to associate MySQL Enterprise Server with a commercial relationship to MySQL as a company.

(373) Hence, we thought about what we could do to encourage the use of MySQL Community Server, in particular by the Linux distributions. Part of that is discouraging the use of MySQL Enterprise Server, and that’s why we set a signal by removing the source code of the Enterprise incarnation of the MySQL Server code.

(374) But I want to underline that we also took a number of positive measures — carrots, if you will — which brings me to the “for the better” part.

(375) First and foremost: We stopped adding new features to a GA release. No more new patches to 5.0. Adding new features to 5.0 is the “that” that I was above all referring to in IRC when saying (as now quoted by Jeremy)

(376) <kaj> JeremyC: Our past 10 months since Oct has been a struggle to make that work, and we’ve failed

(377) Having a stable release which gets new features is like squaring the circle. It’s not doable in Euclidean geometry. This is also where I feel Jeremy’s pain. There are plenty of reasons to want to have new functionality into a stable release, without the burden of the destabilisation introduced by other new functionality.

(378) As I understand Jeremy’s non-Euclidean solution (and there are other geometries than that of Euclid), he wants to pick and choose individual patches, and build an abundance of binaries with a free combination of those patches. While that may be technically feasible, it gives MySQL Community Server a different role from the one intended by MySQL AB. MySQL AB gave two mandates to MySQL Community Server: being experimental, and being the main one used by the MySQL user base. The mandate of MySQL Enterprise Server was the opposite: being stable, and being the one used by customers entering a commercial relationship with MySQL. That equation is the other “that” which hasn’t worked in the past ten months at MySQL AB.

(379) Now, yesterday’s announcement recognised that these requirements are conflicting. That’s where we failed. The community doesn’t want to merely experiment, it wants to use a stable version. And the changes announced yesterday are about making Community Server stable. On top of that, we increase the predictability and planned frequency of Source releases (which we do to encourage Distributions to use MySQL Community Server). Jeremy correctly points out that the frequency doesn’t change much compared to our actual track record on release frequency during the last 6-7-8 months. Personally, I wouldn’t necessarily count it to our disadvantage that we’ve released more frequently than planned (which was twice a year). The more-frequent-than-planned releases is another indicator of the failure of the double mandate (”experimental” plus “main version”), that yesterday’s announcements are supposed to improve.

(380) Another solution, which I suppose would have pleased Jeremy, is to fix the situation by removing the mandate of MySQL Enterprise Server to be associated with a commercial relationship with MySQL. Then we would have one stable and one experimental variety of MySQL Server, regardless of the dimension of paying vs. non-paying. That would dissociate the brand of “MySQL Enterprise Server” with paying-only. And different branding of servers, in turn, is one of the basic current assumptions of Community versus Enterprise. I do understand that this distinction is not one that the Community particularly cares about. However, indirectly, a successful commercial company behind MySQL fuels the virtuous circle from which the community benefits in the form of new GPL features developed by MySQL AB.

(381) Speaking of GPL: I want to make it perfectly clear that we have no intentions of moving MySQL Enterprise Server to another license. Yes, we are evaluating GPLv3 instead of GPLv2, but our plan is for both Community Server and Enterprise Server to remain GPL.

(382) So in summary, I do say “not much” has changed. We have recognised some impossible requirements on the Community Server, and made the difference between Enterprise Server and Community Server consist mainly of the packaging (release schedule and availability). Same features, same bug fixes, different schedule, different branding.

(383) I hope to now focus on making the best out of both Enterprise and Community server, feeding the virtuous circle of open source software.

(386) This entry was posted on Thursday, August 9th, 2007 at 15:36 and is filed under MySQL, MySQL Server, Release Policy. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.