What is an enterprise edition of an OSS application? Is it
something that works better?
Ian holsman
has some worries about MySQL's announcement of separate community
and enterprise editions.
Its a complex issue. On the one hand, we need some of the
OSS-based software vendors, as they provide great software, or
stable packagings of third party applicatons. And MySQL AB are the
core team behind MySQL; they've put in a lot of work to make a very
good database, that is widely used.
Even so, every app that puts a split between 'community' and
'enterprise' is saying to the community 'we don't value you', or
'you are the people who profit from from the paying customers',
rather than 'you are the people who build the OS, the tools, the
ecosystem in which you live.
And where do you stop? Does RedHat enterprise come with extfs
'enterprise', apache 2.x 'enterprise', Gnu autoconf 'enterprise',
and even grub 'enterprise edition'? It is a community, and if some
groups try to imply they are above the others, it falls apart.
You can only push people to premium enterprise editions if you
can justify the money, not just compared to commercial offerings
(Windows, Unix, Oracle, MSSQL. ...), but against the community
versions. RedHat managed to pull this off by making fedora
desperately unstable, but by doing so they have managed to make
Ubuntu the community deskop distro of choice. You dont have to
choose between RHEL (good) and fedora (unstable), but between RHEL
(good, with money and licensing complications) and Ubuntu (pretty
slick, IMO).
I don't see MySQL having such strong competition, but Derby is
certainly IBM backed -and it wouldnt hurt IBMs sales of DB2 if
MySQL suffered. Then there is Oracle and Berkeley DB. And finally,
postgres. There is a lot of competition in the OSS database land,
and if MySQL community edition gets worse, then its value and use
will decrease. If MySQL community remains as good as it always is,
and the added value 'automated DBA' stuff delivers ease of
use/tangible cost savings of DBA headcount/time, then the split may
work out. For now, I will wait and see.
Incidentally, there are some
incomplete SmartFrog components for JDBC-based database work,
which currently hosts a
transaction component that is derived from Ant's sql task. As a
deployment descriptor can already pull down the MySQL JDBC driver
from the M2 repository, you can do a deploy-time binding to MySQL
without any hard coding in your source, just a deployment
descriptor. The new Transaction component will (once I write the
tests, obviously) let you set up the database afterwards.