Steve: Developing on the Edge - Enterprise editions
Steve: Developing on the Edge
Thoughts on development, Web-services, technology and mountains.
22Oct
Sun2006
Enterprise editions

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.

Comments