MySQL Ends Enterprise Server Source Tarballs
vboulytchev writes "The folks at MySQL has quietly announced that it will
no longer be distributing the MySQL Enterprise Server source as a tarball. It's been about a year since the split between the paid and free versions of the database project. The Enterprise Server code is still under the GNU General Public License (GPL), and as a result MySQL appears to be making it harder for non-customers to access the source code. 'One of the things that many users worry about is whether they're getting an inferior version of MySQL by using the Community version. Urlocker says that MySQL "wants to make sure the Community version is rock solid," but admitted that the company has introduced features into the Community edition of the software that "[weren't] as robust as we thought, and created some instabilities." Because of that, the company is revising its policies about when features go into the Community releases.'" Update: 08/10 04:56 GMT by CN :While it is slightly harder to get, the source isn't closed by any means, so I updated the title to reflect that.
Oh well, there is always PostgreSQL... Hopefully some development can move to there.
I don't suppose this is an attempt to get more money?
http://www.beanleafpress.com
I wonder how many other projects will start pulling this -- get the world hooked on your product, and then close the source after you reach a critical mass of commercial users who are likely to pay versus those who would be prone to forking and taking over open development. I think it's ignorant to assume people will just take the last open version and fork it to continue being free - there are commercial users who will likely be quite happy to deal with the closed version they trust. Hell - look at sourceforge -- they closed off their source, and do you see companies installing the GNU fork of the code internally? No - they buy the commercial sourceforge. It'll be interesting to see how many companies follow this trend.
My take: while MySQL has improved technically in leaps and bounds over the last couple of years, stuff like this (or having its transactional backends bought out from under it by Oracle) makes it increasingly difficult for me to recommend it as a business proposition to my clients. Meanwhile PostgreSQL continues to get the job done for the majority of my projects; I have a network of professionals who support it competently; and having followed the project since 2001 or so, I'm confident it's not going anywhere but forwards.
Wow...
The same guys who lied about the suitability of their code for various purposes from day one
The same guys who maintained that ACID was unimportant until the very moment they had it
The same guys who have been setting this up for years with their Project Mayo/DivX Networks style licensing/contribution scheme
You mean they actually went ahead and tried to use shady shenanigans to force developers who have no need for anything from their organization whatsoever beyond a copy of the community developed codebase to pay for access to the codebase?
Wow. What a surprise.
I made a decision to give preference to PostgreSQL over MySQL in my developments... not because of the technical merits involved, but because of the repeatedly demonstrated lack of trustworthiness of the MySQL team.
I didn't expect to see my decision validated in such a rapid and undeniable fashion though.
Just goes to show... technical skill is no substitute for good character or lack thereof.
-1 Uncomfortable Truth
I think this is caused by people and companies not supporting open source with their wallets, but instead just paying lip service to it.
I work for an open source company and the number of calls we get from people demanding support for something they just downloaded from SourceForge has caused us to provide our paying customers with a different "priority" telephone number.
When we politely tell these people that we require they purchase a support package to receive telephone support, they usually get pissed off and hang up. Some try to convince you that they will buy support if we would *just* help them with this one little problem first, heh.
Don't get me wrong, the business model works, but if you have investors I can understand how they would want to close the source if they feel it would convert some of these non-paying customers into paying ones.
If only companies would look at the long-term and realize that if this free software saved us X-thousands of dollars, its well worth it to spend even 1/10th of the money they saved to support it and ensure its longevity. Unfortunately it doesn't work that way though.
PostgreSQL 8.2.4. :)
Thank goodness I did my homework and selected PostgreSQL and not, as one consultant suggested, MySQL back when we selected the database for our application. I've never had it crash and on the few occasions where it was unceremoniously shutdown (accidental powerdown and such), it's always come right back up with no data loss. And it's just been getting better by leaps and bounds.
~~~~~~~
"You are not remembered for doing what is expected of you." - Atul Chitnis
no, I've had enough of your bullshit! take this goddamn article down right fucking now and change the title you worthless fucking excuse for a yellow journalist! For fucksake you READ the goddamn article before you post it, I HOPE.
Fucking immune from moderation troll-assed motherfucker, I will sacrifice my "excellent" karma to bring you down! Anyone want to clue me in on what's going on there? And what all the yelling is about?
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
By discouraging people from getting and using the Enterprise version, I feel less and less safe deploying it myself. Less users = less chances to catch problems. Less code = less review = less security.
I'm about to deploy 4 MySQL servers for some serious volume and was strongly considering buying into an enterprise package, largely on the strength of their monitoring tool, but now I'm seriously thinking it's time to try Postgres.
Wow, thats irritating. Hopefully someone decides to follow their releases and package tarballs themselves, in spite of MySQL. Unless of course MySQL are just doing it to be lazy, which is entirely possible.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
"This is because any party who receives the binary is entitled to the source even if they didn't get it directly from MySQL AB."
And you, Sir, are not entirely correct. I cannot bend over MySQL AB by giving people binaries of MySQL. If you get binaries from me, then *I* must offer the source code *not* MySQL. If MySQL AB no longer offers source to all comers, then it's *my* problem, not theirs.
From GPL V2 (which is what MySQL is using currently)
"b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,"
If I'm distributing version 2 GPLed MySQL, that clause is talking to _me_ and not MySQL AB. The "c" clause gives me an out if I'm noncommercial and I can point to SourceForge or a public server offering MySQL source.
--
BMO
It's interesting to see how the community often openly promotes and vehemently defends an "open" piece of software but if the software starts to "close" then all the problems start coming out and suddenly it's a piece of @#$! The robustness of software doesn't change with a philosophy. It's all the in marketing. I mean if MySql were still open then we'd see posts comparing it against Microsoft's software. Now for "some reason" they're equivalent in the garbage bin. I will remember this indeed.
Did you verify that 5.0.45 contains the two bugs you listed before claiming that it does? I tested them here and both of them appear to have been fixed.
I'm not saying MySQL quality control is as good as I'd like (I'm pretty grumbly about it lately, actually), but both bugs have "Can't Repeat" status, and indeed I can't repeat them with 5.0.45. Both bug reports have received feedback from developers, which is more than I can say for a lot of bugs I have reported in other open source programs.
> I mean, even the most basic test suite would have easily caught these.
No, a test suite that tested for these exact things would have caught them. From what I have seen, MySQL is pretty good about adding test cases to their suite when they fix bugs or add new features.
I'm sure you can list troublesome bugs in 5.0.45, but those aren't two of them.
So extra few bytes are so expensive compared to downtime and data corruption? I did not know that RAM and storage prices were going up?
There are many options available to you with PostgreSQL. Either,
* use the next largest data type (8 bytes) - cheap and fast solution, or
* add support for native unsigned ints - labour intensive solution ($$$). Just use the code for native signed ints and add unsigned support. Should not be too difficult!, or
* use another DB like DB2 or Oracle or even MSSQL - propriatory solution ($$$), or
* use MySQL and pray - lazzy solution
MySQL is an OK storage engine, but it is not a real database. Now that they have started to move to supporting standard database features, they are shutting out the "community" in favour of good old cash. But then against we all saw this when 3.53.x => 4.0 transition switched from LGPL to GPL client libraries?? Right?
Now I have to put on a fire suit and watch karma burn.
Wow, someone has some anger issues. How about a prozac or real database to solve your issues?
"It ain't a war against drugs.it's a war against personal freedom" --Bill Hicks
Something else.
Specifically, encoded network traffic data collected in a packed form of unsigned 16, 32 and 64 bit integers. While its possible to shift the numbers to be signed, it makes the supporting code substantially more complicated, since ultimatly most of these numbers are not counters, they represent identifiers, which means all queries and output would need to do these calculations as well. Certainly not impossible, but its a huge increase in code complexity.
Agreed. I'm currently building a *huge* international, multi-lingual web site for a very large corporation, who happen to host their own servers and mandate the use of the community version of MySQL. The project is more than large and complicated enough to convince me that if you *need* the enterprise version for whatever reason, you can most definitely afford it.
Hey, it works for me -- all of it. I started with MySQL 3.23 a bunch of years ago. From nothing, I learned enough to build large simple systems and complex small systems. Now, I build complex large systems; you better believe I'm sticking with MySQL for the long haul -- and I have no problem paying for it. I'm a business making money, I expect to pay suppliers for suppliers -- it's that simple. And for the record, I still dislike transactions and referential integrity being handled at the database level. It's handy, but it's unnecessary and rarely beneficial. It usually amounts to a limitation when everything's great, and then you want that trigger to do something complicated. And then you want that stored procedure to do something that your application does in one line of code, but requires a web-server, and your entire application, to do it.
Over the years, I've loved the simplicity of MySQL; I've loved the ease of installation; I've loved the low price -- sometimes no price; I've loved the upgrade pace. And like any good business, I stay one step behind.
I've built a successful business with MySQL as a backbone. They deserve my loyalty.
Agreed. There's nothing especially difficult about using Postgres or even administering it. Performance is great and there are connections with PHP, Perl, etc. that are drop in replacements.
The only thing is that there are a few web apps that have MySQL support, but not Postgres - I believe vBulletin is one, but I don't know for sure. An engine is an engine. Installation is easy - in fact, compiling Postgres from source is much easier than MySQL.
Frankly, I don't know why I haven't made the switch for all my webapps. I don't use it much, but when I have, I have run into exactly zero problems. n00b problems are a myth.
Raven737,
I am sorry if we are losing the trust you have in us at MySQL AB.
We have a simple ambition of building a commercially successful business that is built on top of great GPL software. We have a community edition for those who are ready to spend time to save money, and a commercial edition (MySQL Enterprise) for those who are ready to spend money to save time. Both are GPL and live up to all requirements of that licence.
We continually finetune this model and make changes, and as doing so we may at times upset our users or make a mistake. I don't think the change we now made was a mistake, but I am very keen to hear your opinion and also your suggestion on how we can best serve the two groups we have (users and customers). Feel free to send me an email (it's easy to guess what my email address is) so we can engage in a discussion.
Obviously I am a big believer in our model, but wouldn't you also agree that we have brought some great innovations (whether created by the community or by us) to the FOSS world in recent years? I am thinking of MySQL Cluster and the storage engine architecture in general, and more recently MySQL Proxy, etc. Without a functioning business model we would not be able to run such projects or do the QA or other work that is required in addition to the design and coding.
Looking forward to your comments and hoping we can rebuild the trust.
Marten Mickos, CEO, MySQL AB