Although the open-source community of MySQL users is panicking over Oracle's buys of the database's transactional storage engines, enterprise users are far more sanguine, taking steps to ensure that they're protected if Oracle tries anything fishy.
The at-large open-source community of MySQL users is panicking over Oracles second buy of the databases two transactional storage engines, Berkeley DB, although enterprise users are far more sanguine.
"God*it"thats a polite rendering of the very first public reaction of the MySQL community to Oracles purchase of both of the open-source databases crucial transactional back-end engines, InnoDB in October and Berkeley DB from Sleepycat Software
on Feb. 14.
The fear is based on the vision of Oracle forcing its tiny competitor out of business, thus leaving the MySQL user community in the lurch, forced to fork the source code.
"The reason MySQL DB users are concerned, even though the source is GPL, is because MySQL DB is heavily dependent on MySQL AB. If MySQL is forced out by Oracle, whats left, aside from some source code?" one Slashdot poster asked.
"First they bought Innobase, giving them the ability to cut MySQLs transaction [capabilities] off, then they buy another open-source-friendly DBMS which has transaction capability," another Slashdot reader posted.
"Now, if you were the largest commercial DBMS vendor in the world and you were worried about the OSS people moving into your space, what would you buy in order to stop them cold? Me? Id keep them out of atomic transaction space."
As it stands, MySQL AB is putting a brave face on Oracles moves. The company already shrugged off interest from Oracle CEO Larry Ellison, as MySQL CEO Marten Mickos told CNET
at the recent Open Source Business Conference.
Zack Urlocker, vice president of marketing for MySQL, said in an e-mail exchange that its important to remember that the open-source community "cant be bought or controlled by any vendor."
"As a vendor, you can certainly nurture and benefit from open sourcebut the community calls the shots," he wrote.
"This cant be underestimated. If the community is not happy with the direction a vendor takes, they can fork the code and continue on. There is no lock-in with open source, and that is the true freedom it provides."
But how easy is forking the code to create a separate transactional engine thats not under Oracles thumb?
"Building a community to support an RDBMS takes more than just a few good programmers," pointed out a Slashdot poster. "It takes years to build the kind of community that works like the PostgreSQL Global Development Group (PGDG). It takes programmers, organizers, advocates, managers, advocates, support channels, channels for accepting new developers (for instance, if a company wants to pay for a feature), decision makers, and arbitrators (to prevent too much forking). And it takes a lot of time to figure out who does what, and when they do it, and how to reconcile conflicts or scheduling difficulties, how to work as a team so that work is integrated properly and time is not wasted."
In other words, it takes something similar to a company, where theres a chain of command to determine what feature proposals are heard, who should step up to program, who will coordinate programmers working in similar areas and the like, the poster pointed out.
"It really takes a long time to build those conventions and organize people into a functional development group," he or she wrote.
"MySQL DB users can only hope that MySQL AB is still around for a while. If MySQL AB goes the way of Great Bridge, MySQL DB may be left in chaos. In the meantime, start forming a community that can operate outside of MySQL AB. The monolithic development/business model seems to be in question right now."
An escape plan.