Can Sun Make MySQL Pay?
AlexGr submitted a nice followup to last weeks billion dollar Sun buyout of MySQL. He notes that "Jeff Gould presents an interesting analysis in Interop News:
How can an open source software company with $70 million or so in revenue and no profits to speak of be worth $1 billion? That's the question Sun CEO Jonathan Schwartz has been trying to answer since he bought MySQL last week.
Like most commercial open source companies, MySQL makes money by enticing well-heeled customers to pay for an enterprise version of its product that comes with more bells and whistles than the community version it gives away for free.
It appears though that the additional features of the Enterprise version are not enough to compensate for the revenue-destroying effects of the free Community alternative. What else could explain the surprising fact that MySQL has quietly filled out its open source portfolio with a closed source proprietary management software tool known as Enterprise Software Monitor?"
A DBA is not necessarily a database programmer and vice versa. I am a database programmer. I am *NOT* a DBA. I can write SQL statements, procedures, triggers, etc. better than most people who touch a database and yet, don't ask me to configure an Oracle database or set up replication in SQL Server (SQL Server being the pointy-clicky-draggy-droppy approach to administration, I could probably do it, but it isn't what I do and isn't what I profess to be able to do). An MCDBA is certified to do the pointy-clicky-draggy-droppy stuff, not to write database applications.
Granted, I think a DBA needs some understanding of what is done in the database (code wise), I don't expect him to be an expert in it.....that's my job.
Layne
*Disclaimer, I work in a large company where they can afford to have this division of labor. In a small company, people have to wear many hats and usually the person who wears the database programmer hat also has to wear the DBA hat (and probably the network engineer hat and a couple of others).
So yeah, he's got an idea for the answer, but the author of the TFA knew he didn't have a story if he had read the entire blog entry
I think the idea that people will go "hey, that sun mysql worked out pretty well for us. let's go over to sun.com and see what else they have." isn't a bad one. I think the real kicker will be support. Have some random problem in mysql that's killing you? Pay for an incident with Sun support, and the customer could be well satisfied with what they get back. They like the idea of having a vendor that will actually fix things for you, and suddenly you look at other stuff sun sells that you could get support for.
To put it in perspective, I've got a sun desktop machine (nothing fancy, an amd box that was a lot cheaper than my macbook pro) and it was getting a harmless error message. I put in a support call to sun. Until the issue's fixed (they want me to upgrade the firmware), they've been stalking me to track the ticket. E-mails and voicemail messages ("Did you get a chance to upgrade that firmware yet?") more often than you'd get from a real-life stalker. These kids don't screw around with support. I'm kind of afraid of them for that.
But I'm sure that if you have a problem that's important, you'll appreciate the dedication.
I'm sure there's a lot to be said about companies trusting mysql more now that a big company like sun's behind them, but I'm still in academia, so I donno how much of a factor that is. Probably lots.
Care about electronic freedom? Consider donating to the EFF!
Excellent comments about MySQL. You've summarized my thoughts exactly. However, you've really dropped the ball by not moving to PostgreSQL. It's really a shame that such a gem gets left in the dust because people simply don't know any better. It's either MySQL on low end or some proprietary DB on high-end. But the truth is that PostgreSQL can do anything that MSSQL can, and it actually does a few things better. For example:
* If you start a transaction in PostgreSQL and one of the SQL statements causes an error, the transaction is aborted immediately, and all resources are immediately released. The server still expects the client to send "ROLLBACK", but that is merely an acknowledgment. Not so with MSSQL. It allows you to continue writing to the database, AND issue a COMMIT statement at the end, thus committing a partially-failed transaction! This is from the WTF??? department.
* For whatever reason, the default collation is not case-sensitive. This caused some interesting bugs when we least expected.
* Client libraries are just pathetic, especially on non-windows platforms. JDBC driver is usable, but C client library is essentially reverse-engineered and not supported by microsoft (http://www.freetds.org/). It is a small miracle we can access MSSQL at all from Linux.
Anyway, I've used PostgreSQL in my past few projects and currently using MSSQL (not my choice). It is a decent database (other than the annoyances I mentioned), but I still prefer PostgreSQL. Feature-wise, I can't think of anything that MSSQL has and PostgreSQL doesn't. It's really a shame it doesn't get used more.
___
If you think big enough, you'll never have to do it.