Many sites online have reported that new features will appear in MySQL Enterprise as opposed to the community version. Slashdot is now suggesting that Sun is going to begin closing the MySQL source, and that "Sun has had a very poor history of actually open sourcing anything."

From Jeremy Cole's blog, submitted by reader Vic Cekvinich:

MySQL will start offering some features (specifically ones related to online backups) only in MySQL Enterprise. This represents a substantive change to their development model — previously they have been developing features in both MySQL Community and MySQL Enterprise. However, with a shift to offering some features only in MySQL Enterprise, this means a shift to development of those features occurring (and thus code being tested) only in MySQL Enterprise.

As I’ve discussed before, the size of the user base for MySQL Enterprise is much smaller than for MySQL Community. That means these critical features will be tested by only a few of their customers. So, in effect, they will be giving their paying customers real, true, untested code. How is this supposed to work? In addition, this means that they are changing their internal development model, splitting the relationship between the two trees, and overall going even further down the path of getting the RHEL/Fedora model backwards.

Slashdot's post on it is utterly confusing. Here it is, in its entirety:

"From the MySQL User's Conference, Sun has announced, and former CEO Marten Mickos has confirmed, that Sun will be close sourcing sections of the MySQL code base. Sun will begin with close sourcing the backup solutions to MySQL, and will continue with more advanced features. With Oracle owning Innodb, and it being GPL, does this mean that MySQL will be removing it to introduce these features? Sun has had a very poor history of actually open sourcing anything."

The post is tagged as "flamebait" and "wrong."

Marten Mickos, previously CEO of MySQL, posted a response to the /. post, saying:

Let me clarify some facts:

* The business decision on this was made by MySQL AB (by me as the then CEO) prior to the acquisition by Sun, so this has nothing to do with Sun. On the contrary, Sun is more likely to influence this decision the other way.

* It is not a quesiton of close sourcing any existing code, nor anything in the core server. Everything we have released under GPL continues to be under GPL, and the core server will always be under GPL (or some other FOSS licence).

* We will introduce backup functionality for all users (Community and Enterprise) under GPL in version 6.0.

* Additionally we will develop high-end add-ons (such as encryption, native storage engine-specific drivers) that we will deliver to customers in the MySQL Enterprise product only. We have not yet decided under what licence we will release those add-ons (GPL, some other FOSS licence, and/or commercial).

* At all times, because the main backup functionality goes into the core server under GPL, anyone can of course use the api and build their own add-ons or other modifications.

Those are the facts on this. The interesting topic is of course the one of the business model and what the best business model for FOSS software is. I hope to cover that in a separate posting.

In all of this, you have our undivided continued commitment to providing a fantastic and complete MySQL server under GPL for anyone to download and use. If we for whatever reason would not do that, we would risk losing users to other open source databases or risk seeing a fork of our own product. This is the power of open source.

It's also odd that the Slashdot poster says that Sun has a poor record of open source. It's almost like the poster (and slashdot?) consider "open source" to be GPL and nothing else - availability of source and the right to commit changes are the only measures of whether something can be considered open or not.

This may be a slight exaggeration on my part, but seriously! Sun's separate licenses have their encumbrances, to be sure, but by and large, for the average developer, accessibility to the original source is enough.

Before you start flaming me: I'm very aware of the license issues in the JCP, and I'm also aware of the Apache/Sun license arguments. These all have merit on both sides. As soon as you have a solution that fits all requirements - really fits them, instead of deciding that a requirement isn't important after all - send them my way and I'll forward them.

So what about it, TSS readers? Does the possibility of two versions of MySQL having slightly separate and separately funded features really worry you?

It's superior anyway.

That Slashdot article has nearly no facts, it's just nonsense.

Sun doesn't have a cool brand to some people, but who cares?

I don't see any negative changes or problems with licensing or property rights related to MySQL. That being said, PostgreSQL is also nice and I'd love to try Google's denormalized GQL.

Slashdot is now suggesting that [..] "Sun has had a very poor history of actually open sourcing anything."

This coming from Slashdot, which was so kind as to open source the pile of pooh that runs their own little web site.

What a bunch of B.S.

I think Sun does all sorts of moronic things (i.e. they may not have a viable business model), but they've open sourced just about everything they have, whether it has any value or not.

Peace,

Cameron Purdy
Oracle Coherence: Data Grid for Java and .NET

It really depends on what features they going to leave out.

As long as they deliver equal, or more (stable) features than their competitors, I don't see a big problem (I use MySQL only as a backend, most of the time… maybe that’s why I’m not so shocked). That is, when SUN/MySQL are capable of fixing severe bugs in good pace, of course.

However, I do think the timing is not quite right (showing us the features of 6.0 and then changing course). Some basic RDBMS-features like foreign keys aren't there yet and some competitive enterprise features are just (or not fully) implemented in the last release (5/5.1). Maybe the source code of these features aren't going to be closed or left out for the community edition, but still the support of open source developers can decrease, if they aren't satisfied with the roadmap of (future )features presented to the community. Leaving features out at the current state of the product, will seriously leave a gap where competitors can get their advantage. Plus MySQL is an icon to the Open Source-community so people can get very touchy over this.

People are always going to compare it to other (commercial) enterprise products(for e.g. Oracle, M$SQL), no matter how much difference the $$$$$$ is, especially when they must pay for it. So do ‘concern your separations’, SUN.

Then again, Most of the time people's choices are going to be based on what the business demands, from their Information System/Architecture/DBMS. For e.g., the ones who are claiming that they are moving to PostgreSQL, 'cause of this, must consider that some enterprise features, like clustering are not directly available in Postgres either (out-of-scope). Question yourself… will the effort of switching be worth the time/money/features? (Before acting like a 'FOSS-extremist', of course ;))

Personally, I think this is a storm in a teacup. The features mentioned are in the area of database backups. Sun now supports PostgreSQL, JavaDB, and MySQL, and I'm fairly certain there are others of less note to the open source community. So what if MySQL doesn't have feature X? Chances are that Derby (AKA JavaDB) or PostgreSQL do.

Personally, I think this is a storm in a teacup. The features mentioned are in the area of database backups. Sun now supports PostgreSQL, JavaDB, and MySQL, and I'm fairly certain there are others of less note to the open source community. So what if MySQL doesn't have feature X? Chances are that Derby (AKA JavaDB) or PostgreSQL do.

Wouldnt you typically want to have all the features in the one and same database manager? Or do we run 3 database servers and replicate between them to be able to use all the features needed?

I dont know if this thread is correct or not, but online backups were mentioned, and thats a pretty vital feature if you try to run a 24/7 business.

Personally, I think this is a storm in a teacup. The features mentioned are in the area of database backups. Sun now supports PostgreSQL, JavaDB, and MySQL, and I'm fairly certain there are others of less note to the open source community. So what if MySQL doesn't have feature X? Chances are that Derby (AKA JavaDB) or PostgreSQL do.

Wouldnt you typically want to have all the features in the one and same database manager? Or do we run 3 database servers and replicate between them to be able to use all the features needed?

I dont know if this thread is correct or not, but online backups were mentioned, and thats a pretty vital feature if you try to run a 24/7 business.

Sure. But they're not saying that online backups aren't supported by MySQL - they're saying that new features in the online backups will be put into MySQL Enterprise.

Besides, if it's mission-critical, you should be using the supported (commercial, Enterprise) version anyway, right?

Chime-in the requisite punter or 2 that claims to run Open source software in 'mission critical, 24/7' operation/environment, and still refuses to pay for support...

Googling forums is no excuse for bantering against charging 4 support...i know, i know, there are the majority of Red Hat, JBoss, MySQL, and on and on OSS projects where the users don't pay for support, alright 95%....but if you're going to run a business on one or more of these vendors, certainly u would want their expertise, let alone their viability in the marketplace...

wouldn't that $10K for MySQL/annum leave many a less sleepless nights?

Besides, if it's mission-critical, you should be using the supported (commercial, Enterprise) version anyway, right?

Well, I have never deployed anything mission-critical on MySQL, so I wouldnt know.

But I somehow thought that it would be "a good thing" if there was a full open-source stack on which you could run mission-critical systems, without being forced to buy support from any particular vendor.