Spoon full of Sugar, Oracle and the Open Core Model
(Reposted from blog.krow.net)
From the 451 Group:
“MySQL flirted with the open core licensing model in early 2008 with plans to introduce new features into Enterprise Edition that would not be available under an open source license.”
MySQL didn’t flirt with, it was going to do it.
Why? Because we were asking the question, “how do we pull in customers to make more money”.
MySQL was going to put the new backup API, which never materialized, into an Enterprise branch.
It was a lousy idea for the following reasons:
1) There was no internal API in the server for this, so the engineering was going to be messy and expensive.
2) We didn’t own the technology that was needed to even do this (Oracle owned Hot Backup)
3) Percona has an awesome tool for doing this, that is Open Source (http://www.percona.com/software/percona-xtrabackup/)
4) Backup is a core feature everyone needs, and some of those “everyones” are the folks who manufacture tools that you want to have work with your product.
5) When we were going to announce it, we hadn’t even written it/completed it. It was vaporware.
It would have been a horrible move, and would have caused Chaos for no particular reason. It was dead on arrival, and when it was to be announced as a strategy since it didn’t even exist.
Lets look at Oracle’s move. Both the authentication module, and the Thread Pool come into the MySQL server as plugins. If the engineering of the MySQL server continues in the current direction (which is somewhat flattering to Drizzle I might add), then they are on a good path (if I can find my blog entry where I talked about this as a good strategy, I’ll link back to it here).
Much of the hubbub around Open Source, Community, etc, in regards to this are a bit inflated I feel. They haven’t touched the core product, and they are creating API. Are they possibly hurting themselves in regards to ubiquity?
Doubtful.
Would I pick those two pieces? No, but they aren’t the last two I would pick either. If Sun had continued as a company?
Something similar to this would have been done as well.
From an engineering and usage stand point?
The first person who sniffs at the authentication mechanism who knows anything about security is going to freak.
The Thread Pool can only be used by a very limited number of users (and there are some restrictions on what can be done in the server while it is in use). MySQL’s IO was never designed for the Thread Pool, and there is a lot of engineering work that would need to be done to make it work.
Still? People will use both, and I am betting some customers will want them badly enough to pay.
If they are really badly needed? Well then someone will write an open source version of both.
I have no great love of Oracle, but this is really not a big deal at all. The original GPL’ing of the Public Domain/LGPL clients was a much bigger deal.
From the 451 Group:
“MySQL flirted with the open core licensing model in early 2008 with plans to introduce new features into Enterprise Edition that would not be available under an open source license.”
MySQL didn’t flirt with, it was going to do it.
Why? Because we were asking the question, “how do we pull in customers to make more money”.
MySQL was going to put the new backup API, which never materialized, into an Enterprise branch.
It was a lousy idea for the following reasons:
1) There was no internal API in the server for this, so the engineering was going to be messy and expensive.
2) We didn’t own the technology that was needed to even do this (Oracle owned Hot Backup)
3) Percona has an awesome tool for doing this, that is Open Source (http://www.percona.com/software/percona-xtrabackup/)
4) Backup is a core feature everyone needs, and some of those “everyones” are the folks who manufacture tools that you want to have work with your product.
5) When we were going to announce it, we hadn’t even written it/completed it. It was vaporware.
It would have been a horrible move, and would have caused Chaos for no particular reason. It was dead on arrival, and when it was to be announced as a strategy since it didn’t even exist.
Lets look at Oracle’s move. Both the authentication module, and the Thread Pool come into the MySQL server as plugins. If the engineering of the MySQL server continues in the current direction (which is somewhat flattering to Drizzle I might add), then they are on a good path (if I can find my blog entry where I talked about this as a good strategy, I’ll link back to it here).
Much of the hubbub around Open Source, Community, etc, in regards to this are a bit inflated I feel. They haven’t touched the core product, and they are creating API. Are they possibly hurting themselves in regards to ubiquity?
Doubtful.
Would I pick those two pieces? No, but they aren’t the last two I would pick either. If Sun had continued as a company?
Something similar to this would have been done as well.
From an engineering and usage stand point?
The first person who sniffs at the authentication mechanism who knows anything about security is going to freak.
The Thread Pool can only be used by a very limited number of users (and there are some restrictions on what can be done in the server while it is in use). MySQL’s IO was never designed for the Thread Pool, and there is a lot of engineering work that would need to be done to make it work.
Still? People will use both, and I am betting some customers will want them badly enough to pay.
If they are really badly needed? Well then someone will write an open source version of both.
I have no great love of Oracle, but this is really not a big deal at all. The original GPL’ing of the Public Domain/LGPL clients was a much bigger deal.