On MySQL’s Commitment to Open Source
Mike Kruckenberg, well-respected community member recently blogged about MySQL taking another step (away from open source, and I’d like to refute some of his worries. In fact, this is really more to drive away from what some within the community think is not kosher, i.e. change #5 in Kaj’s blog entry.
The sources are always available. Its just gone one step further, in that you need to use the Bitkeeper free client, and pull the correct revision, tags of which are always at http://mysql.bkbits.net/. From there, you are welcome to compile it yourself, and even make a binary distribution, all with fair ease thanks to the excellent build scripts. As MySQL’s CEO Marten Mickos has in a regular slide deck of his: people use the Community Server to save money and spend time, while people use the Enterprise Server to save time and spend money (ref. slide 14 [html][pdf]).
Mike says, “And I can only guess, but somewhere in the MySQL master plan there must be another blog post planned to ease folks along about closing off the enterprise source in Bitkeeper.” They say talk is cheap, so I’m not going to promise this will not ever happen in this lifetime, but I implore you to think about who makes up the MySQL development team — they are largely, very opinionated, open source types, whom will refuse to work on a code-base that they know isn’t open source. And going by Kaj’s change #1, which clearly states that there will be no new features applied to the current GA release, why are we really bothered about differing source trees?
The only real benefit in terms of sources and binaries is that if you’ve got Enterprise, you’re going to get your bug fixes every month, and a quarterly service pack to boot. If you’re on the Community tree, you’re just getting fixes once every 3 months, in a source release, that is sure to be built by the large and varied community MySQL have, for even more platforms than MySQL supports.
While Mike mentions the marketing message is currently stating that the Community edition is experimental and not ready for production, we all know that in technical reality, this is so untrue. MySQL maintains the same high quality assurance standards to any given tree, and I think this is why MySQL realised that putting community contributions into a current GA release was just not sensible — we all know that Jeremy’s famous SHOW PROFILE patch (the epitome of Community Contributions) introduced some server instability till 5.0.41. This is why the sensible decision has been made to push changes into the current development tree — to ensure high quality and standards are maintained in the current GA releases.
So let me reiterate: the Community server will never get unreliable with Community Contributions.
Note: Title has since changed… Hat tip to Marten :-)
Technorati Tags: mysql, community, enterprise, differentiation
Well .. they say the same thing about that as they do for the tarballs, they will make it available to their customers.
That is for people with logins … presumably to people who pay them for that access too. At least that is how I read it.
Tarballs (enterprise) are only available to customers, that is correct. Source trees (with appropriate tags, to generate your own tarball) is and always will be available at mysql.bkbits.net. But you do need a login to enterprise.mysql.com to get enterprise tarballs (sources, binaries, multiple platforms, etc.)
Tarballs (community) are available to all and sundry