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.
Good post by Jeremy Cole regarding this topic:
http://jcole.us/blog/archives/2007/08/09/mysql-community-split-officially-a-failure/
Peter, my dear friend,
I read your columns 3 or 4 times so far, and all were written so well and so accurate. I am so sorry that I can’t tell the same for the above article.
Here are my criticisms. First of all, Community version will continue, but with some changes. Second, microsecond resolution for slow queries is in 5.1 already and should come out soon.
Regarding SHOW PROFILE, it turns out it has te be implemented as an option, and not as it is implemented now. I do agree partially with what you wrote on the speed with which MySQL accepts patches. But, believe it or not, new procedures are in place and even patches from us, the insiders, are going through a long, elaborate process and quality control testing.
I totally disagree with your comparison of community versus enterprise. Same holds true for comparison between Red Hat and Fedora. Red Hat is dealing mostly with software they don’t make and don’t know much about. Enterprise binaries are ones where all bugs are fixed. Enterprise binaries are NOT the ones that get any bleeding edge features. Enterprise binaries contain all fixes for the bugs made up to that moment. That is the main difference. It is actually Community binaries that have few bleeding edge features, not tested thoroughly, like SHOW PROFILE.
I also hope that you agree that there has to be a differentiation. In that way a paying customer gets more then community user. But community still gets a free software, which is also VERY important.
Sinisa, For some reason I expected you to commit on this even though you do not commit that often.
Now regarding your criticism as usually you critique something I did not write 🙂
1) I’m not saying Community version will not continue. Of course MySQL is free to have some version which they call Community. I’m just saying it is pointless for my needs as I need production versions with community patches (including mine) not some version which my clients will be ready to use 2 years from now.
2) Regarding microsecond patch – 5.1 is not 5.0 (still beta). It is still taking way too much time from original submission and as I understand it is not normal community contribution process which worked well in this case but me talking to Monty at OSCON and him agreeing to personally add it.
3) I’m not showing SHOW PROFILE is implemented as it should be I’m simply stating it is only significant feature accepted for last 10 months or so. I had customers having problem with this patch, even though Jeremy tells me they are typically because of Chad’s code not his, but again this is not the point.
4) The fact your patches take too long to be merged so what ? Community tree specially had as one of its goals fast path for community patches so you could still use your new slow processes for Enterprise version. As you correctly outline it did not happen and this is exactly to the point
5) Let me clarify my point about bleeding edge. You update Community source releases 4 times per year and binaries 2 times a year (per new promise) while Enterprise binaries get Monthly rapid update packs. This means some fixes go to Enterprise version before Community version so bug fixes are first tested by Enterprise customers.
These are of course all “safe” bug fixes but as you should know from years of working in support bug fixes are never safe and there is always significant probability of fixes breaking something either directly or by side effects.
Community of course expected to get some big “bleeding edge” features.
6) Regarding your last question you put question wrong. There does not have to be differentiation in terms of software MySQL had significant revenues before these Community vs Enterprise spilt, but differentiation does typically allow you to get more sales. The problem is how MySQL does differentiation which is in many cases of “We’ll take back what we previously were giving away” rather than providing newly created extra value for enterprise customers (Merlin being exception) . May be MySQL was giving away too much ? If so why not to say so ?why to use these lame excuses “We’re doing it to better serve you”.
7) I do not deny community version remains free software I’m simply pointing out it does not matches goals of community, even those goals which were outlined by Kaj himself less than a year ago.
I see there is another great post on this topic by Mike Kruckenberg
http://mike.kruckenberg.com/archives/2007/08/mysql-takes-another-step-away-from-open-source.html
Kaj responses to Mike and Jeremy posts
http://www.planetmysql.org/kaj/?p=124
Pjotr,
You show once again that you are very capable of getting out of the tight spots !!! During our enjoyable and interesting work in MySQL, I was wrong two or three times in five years, but you NEVER. That is OK, since you had such a great teacher. who once said: “I think I was wrong once in 1978, but I am not sure ….”. You know who said that ????
Here are my answers to your answers to my answers to your answers to ………
1) Actually, most of criticisms that we got on Community version (so I am told) is on having those bleeding edge community patches. I will say no more as I am not in direct touch with Community.
2) Microsecond patch finished to be VERY different from the original submission. It also was amended with some very nice improvements not directly related to slow query log.
3) No comment. Who introduced latency can be found scientifically, right ???? That is, aftar all, your speciality , not mine …
4) loop to point 1. (I don’t like goto);
5) You would have had a point here if 50 % of bug fixes produce new bugs. Luckily, this is not true, hence you are wrong ……. ;o) Also, Community gets last bug fixes at that point in time, so if our QA is that bad (and it is not), both versions would suffer.
6) I did not bring this point of “taking back away” in my comment, but I will will still say something. The only thing that I see that is taken away is a frequency of Community binary releases. Previous policy, in my opinion, was simply not perfect. I thought then, and I think now, that paying customers should be the ones that should get the fix sooner. Isn’t that logical ????
7) loop to point 1. (no goto’s)
Reading all these comments, it seems to me that nobody seems to understand the simplicity of a stable branches being truly stable, and development branches being fast moving.
It’s the basis of open source.
If someone wants to patch a stable branch, you push back unless it’s a security or data loss bug or serious. Once 5.0 went STABLE, it should have seen no more work done on it that was not security or bug fixes. And this: http://bugs.mysql.com/bug.php?id=28591 does not count as a “BUG”. It was a performance enhancement. Those go into the next development version (5.1? 6.0?) No way should such a change be applied to 5.0, which is a stable branch. And if you read the release notes for each 5.0 version since it went stable, many many many of those changes are NOT Security or true bug fixes. This causes people to not trust the community versions of MySQL because they can’t be sure a simple update won’t scram their whole db server.
In using pgSQL a lot, I’ve had exactly one point release on a stable branch that introduced a bug that could affect data, and there was a point release the next week to fix it. It came and went so fast I didn’t get a chance to get bitten by it.
MySQL AB needs to stop trying to differentiate their commercial and community code right now. It’s a bad idea. When I’ve been bitten by problems in the community version, my very very last response was to think I should switch to the commercial version. My first response was to migrate off of MySQL. And there are a lot of people I know who’ve now done the same.
The sloppy approach to patching stable versions, and the idea that you can only make money selling code is gonna kill MySQL AB in the long run. I truly hope a vibrant Open Source community takes the whole thing GPL and adopts a reliable, responsible Open Source / Free development methodology around it.
The current method of upselling commercial versions feels like a protection racket or a bait and switch. yeah, that community version is ok, except for these horrible bugs. We can fix those for you for a small fee.
Sinisia, you mention that bug fixes are going through a long and elaborate process. Does this apply to all bug fixes, or just those to stable versions? I can totally understand a more involved and careful QA and reviewing process for patches to stable versions. But dev versions don’t need so much time and should be made pretty quickly, assuming they’re coming from a trusted source.
Anyway, I’ve kvetched enough. I don’t use MySQL as much as I used to, and I doubt anything MySQL AB can do will win me back. Their current course seems to be actively driving people away.
Scott,
Securty are not only bug fixes which deserve to be fixed, there are others such as crash bugs or wrong query results for common queries. The bug you mentioned had Severity 5 so it of course should not go in stable release, neither Innodb performance improvements in 5.0.30
On the other hand the bug you’re mentioned went only in the enterprise version as far as I remember and was quickly pulled off with customers who downloaded it notified not to use this version.
The problem with very conservative approach is – way too long delays between version releases. For example many paying customers could not wait for 5.1 to get scaling fixes so MySQL had to go ahead.
If MySQL 5.1 would be released 6 months after 5.0 (containing say only row level replication or no new big features at all) it could be the one to contain larger bug fixes and improvements.
inserted value as ‘1/15-16’ in column1, i need out only out put as 1 as uppart part of slash
,