Yesterday Kaj Published changes to MySQL Community Release Policies. I knew about them a bit in advance but now they are public I can comment a bit.
In general I’m disappointed and think this is moving in the wrong direction, it also makes me to think hard if MySQL is out of more creative solutions to increase the sales revenue ?
The main issue for me is Change policy for MySQL Community version. We are patching MySQL with minor extension so this concerns us a lot – it would be much easier to make our customers to run Community version (at least temporary) compared compiling patched version for them. There was as hope MySQL Community version would allow to quickly make changes available but not it is gone.
Honestly I do not think it ever work. We have submitted our patches for microsecond resolution of slow queries over half a year ago. These patches had a good support from MySQL Professional Services Team and Monty himself but still the process just stalled.
It really looks like MySQL took Jeremy’s SHOW PROFILE patch and rushed integrating it in Community Release so they would not be criticized for having Community and Enterprise versions built from the same tree but as goal was reached process slowed down a lot.
Submitting patches to MySQL 5.2 now and hoping to see them in production release in a 2 years is not really motivating enough and not the option. Even if MySQL 5.2 is out sooner than that It unlikely will be actively migrated to. Many large MySQL Web customers become too large and careful for rush migrating to the new release next month it is released. As I’m aware Google is moving to MySQL 5.0 just right now and I’m aware about more big names which do the same but are less public about it.
May be there is a though having nice community features only in 5.2 now will make sure people will start testing it faster ? I do not think this makes much difference.
I guess community will have to cooperate on its own to build true community MySQL version for production ready version. There are great patches out where from us, Jeremy Cole, Mark Callaghan and few hours which are just tired to be just patches.
It is also very interesting to note 4 source releases for MySQL Community Version vs Monthly rapid updates for MySQL Enterprise version – to me this means a lot of changes have to go to Enterprise version before Community version which raises a question why MySQL Enterprise would be more “stable” than community if it is more bleeding edge, it is used by less people and MySQL does not too much testing internally ?
RedHat/Fedora split in my opinion is positioned much better in this regard. Fedora is bleeding edge and quick testing for new features for those which like it and there is RedHat Enterprise Linux which gets only stable features typically after community testing. It may not be perfect (ie with recent Fedora Legacy things) but I think gets much closer to balancing needs of Community vs Company needs.
There is also a good question of relationships with Linux Distributions. As Kaj writes 4 Yearly Source Released of Community Version is targeted to be used by distributions Vendors. Interesting – why would not these take Enterprise version from the source and name it differently ? If you build your distribution as Enterprise class why would not you use something MySQL considers Enterprise Quality ? What is really better for distribution users ? Does MySQL actively “recommends” you not to do so ?
I’m really interested what we’ll see in the distributions in 6 months or so, especially more community controlled ones such as Debian.
But again if all distributions ship MySQL Community version this makes it better tested than community – here is the conflict again. Not to mention people may get use to Community features and would be hard to migrate back to Enterprise version.
Now to the last point of removing source availability for Enterprise binaries. As Kaj mentions it is in line with GPL and FSF approves it, but in my opinion it is well against spirit of the Open Source. It also looks as pretty strange step to me.
As Kaj mentions MySQL Enterprise customers can distribute GPL builds if they want to, so I have no hesitations they will be available. Not to mention as Source Tree is available you can rebuild and rename binaries same as CentOS does for RedHat Enterprise Linux. Dorsal Source is the place where you can pick up the choice of binaries already.
There is always and argument MySQL is Commercial Company and has to make money, sure enough, and I’m not blaming MySQL for that. Microsoft and Oracle also make money. It is just a way of making money and how much is given back to community is different in each case. People get upset with MySQL because it starts to give back less, even though it has right to do so.
I would expect MySQL to fine it harder and harder to sit on two chairs and I fill there is a great fight inside the company between old fashined true Open Source ideals and new management for which is Open Source is new fashion and a vehicle for making money. Should we be surprised MySQL Does not get too warm welcome on OSCON any more ?
Its fun to see how its develops and nice to think MySQL availability under GPL and great community keeps us protected from whatever next steps MySQL will take.
Percona’s widely read Percona Data Performance blog highlights our expertise in enterprise-class software, support, consulting and managed services solutions for both MySQL® and MongoDB® across traditional and cloud-based platforms. The decades of experience represented by our consultants is found daily in numerous and relevant blog posts.
Besides specific database help, the blog also provides notices on upcoming events and webinars.
Want to get weekly updates listing the latest blog posts? Subscribe to our blog now! Submit your email address below and we’ll send you an update every Friday at 1pm ET.