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?

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

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

• 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.
• Jeremy Cole claims that the MySQL Community split is officially a failure, and that MySQL fundamentally misunderstands their community.

Strong words.

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

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.

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.

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.

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)

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

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.

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.

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.

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.

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.

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.

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

Back in October 2006, we introduced MySQL Community Server. Since then, we’ve learnt a thing or two, spent many man hours discussing how to improve our processes, and are now refining the concept. We feel that we’ve come up with some good middle-ground that fulfils not only our company interests but fosters community use and growth as well.

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.

Let me expand upon the first and the last items.

Community contributions: As I know this is a topic important to our contributors and potential contributors, let me provide an example. I confess: We’ve been bad at incorporating new features. We haven’t entered much more significant than SHOW PROFILE, and it took many months and several builds to mature. And we cannot continue with this practice of applying patches to a stable release, because new features will destabilise the release. That’s what we’ve been hearing from both distributions and contributors. We’re listening, and we’re learning. By no longer going for the impossible (adding features to a feature frozen release), we hope to change this dynamic for the better.

Enterprise source code availability: I expect three questions, “Why?“, “Does this conform with the GPL?” and “What keeps a paying customer from building and posting Enterprise binaries?“. The rationale is to underline the positioning goal of “Community Server for community users, Enterprise Server for paying users”. And the GPL requires us (like anybody else) to hand out the code to those whom we give the binaries, which in the case of MySQL Enterprise Server is just the customers. So it does conform to the GPL, something that we’ve verified with the FSF to eliminate any doubt. And as for the third expected question, the answer is “Nothing”. Still, we feel that most business users will see the value of a MySQL Enterprise subscription that offers regularly-reliable software updates directly from the ’source’, along with premium 24×7 technical support and proactive monitoring/advisory tools.

To finish off, let me repeat a number of basic facts which stay unchanged:

1. both the Enterprise Server and the Community Server remain licensed under the GPLv2
2. MySQL Enterprise Server has Monthly Rapid Updates (MRUs) and Quarterly Service Packs (QSPs), i.e. binaries delivered to our customers; building these binaries is a service for paying customers only
3. bugs are first fixed in MySQL Enterprise Server builds, and while updates are delivered quicker and more frequently to paying customers, bug fixes are also added to the next source and binary builds of MySQL Community Server as stated above
4. when scheduled, we build Community binaries for all platforms
5. community binaries and sources are still available for download at dev.mysql.com/downloads
6. all source trees are still available via BitKeeper
7. the Enterprise Server is close to a full subset of the Community Server

With these changes that are intended to simplify life for the Linux Distributions that distribute MySQL, we hope to better serve the MySQL user base, while continuing to provide additional value to our paying customers in the form of more frequent, scheduled binary bug fix releases.

If you have any questions with regards to this, please do not hesitate to reply via email to community@mysql.com.