The at-large open-source community of MySQL users is panicking over Oracle's second buy of the database's two transactional storage engines, Berkeley DB, although enterprise users are far more sanguine.
"Goddamit"—or, in Slashdot forum speak, "God Damnit"—just about sums up the public reaction of the MySQL community to Oracle's purchase of both of the open-source database's 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, what's left, aside from some source code?" one Slashdot poster asked.
"First they bought Innobase, giving them the ability to cut MySQL's transaction nuts 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? I'd keep them out of atomic transaction space."
As it stands, MySQL AB is putting a brave face on Oracle's 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 it's important to remember that the open-source community "can't be bought or controlled by any vendor."
"As a vendor, you can certainly nurture and benefit from open source—but the community calls the shots," he wrote.
"This can't 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 that's not under Oracle's 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 there's 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."
That's the public fear, but enterprises or public agencies reliant on the MySQL database either don't fear that Oracle is up to no good or they've already figured out an escape plan.
One example is Tom Crimmins, a programmer analyst/database administrator for Pottawatamie County, in Iowa. Pottawatamie County uses both MySQL and SQL Server.
Crimmins said that he's not worried about Oracle's storage engine buys, in spite of the fact that the engines are "critical components right now."
"They're the only transactionalized storage engines MySQL has," he said. "I know the reason they haven't made the MyISAM engine transactional so far is it's so fast and they don't want to slow it down."
The only way Oracle's purchases would be a big deal if Oracle decided not to allow MySQL to use the InnoDB engine, Crimmins said, since it's the only way the MySQL database is ACID-compliant. InnoDB, as an ACID-compliant transactional storage engine, is designed for very high performance and scalability when processing large data volumes and under high concurrency.
But if push came to shove and Oracle changed its licensing, Crimmins said, his agency would probably move to SQL Server, in lieu of a replacement engine from MySQL. That runs contrary to Oracle's hopes that enterprises will use its newly acquired open-source databases and then upgrade to become paying customers.
"If there was no other choice as far as transactionalized engines, if they were going to start charging for that component, it wouldn't make sense for us to pay when we already have SQL Server," Crimmins said.
Another example of corporate comfort with Oracle's purchases is Dariush Zommorrodi, vice president of corporate development and technology for Yellow Online, Canada's leading alternative online directory.
Zommorrodi said he's sleeping well at night even though the company planned to migrate to the transactional version of MySQL, 5.0, "once it was debugged and ready."
"I don't think even if Oracle does this acquisition it would block the growth and the product," he said. "In the open-source community, you cannot prevent the enhancements and advancements of MySQL. I don't see it as a big threat, a big worry. The community will work to enhance this and over time it will prove it will become a very successful RDBMS."
As far as the planned migration goes, he's still considering migrating his Oracle 9i on Sun boxes setup to MySQL 5.0 running on cheaper Intel-based boxes with a Linux operating system, as soon as he's convinced the stability is there.
"We're using MySQL for the front-end search engine," he said. "That's where we've got the power of low cost, redundancy and scaling of MySQL servers. We can't afford multiple Oracle servers for the amount of traffic increasing on our site."
Another business user, Mike Welles, said that he understands the general angst over Oracle, "given that Oracle has a track record of being the death of every promising piece of technology they purchase," he said.
In the case of the InnoDB and Berkeley DB buys, he sees the "death" as being deliberate. "Even so, they can't cut water with a knife," he said, referring to the community's likelihood of forking the code if Oracle does anything fishy.
He's still made sure to keep his business' vendor dependence to a minimum, however, shielding his company from MySQL's reliance on a component now owned by Oracle—InnoDB—by reserving the use of InnoDB for only the most critical applications.
"I'd say the vast majority of the 'one-off' applications that are scattered around are using MyISAM," he said. "Even our 'mission-critical' applications that require these features have all been coded in a database-agnostic fashion as well—my group, at least, makes it a point to use technologies such as Hibernate that allow for seamless 'plugability' between different RDBMS systems."
At any rate, MySQL's April user conference is fast approaching—a time when the company has promised a full rollout of its product roadmap and storage engine architectures.
Until then, as Mickos has reportedly said, MySQL is sticking by the premise that trying to kill open-source products by buying companies that make open-source products is like trying to kill a dolphin by drinking the ocean.
"Should Oracle take their new toys and go home, we still can use what we have," said Welles. "We expect that even if [they do], the free forks of what we are using will thrive and supplant whatever Oracle does with their versions."
And after all, Welles pointed out, there's always Firebird or PostgreSQL. "Should we be wrong … we'll probably just switch to using PostgreSQL or Firebird or some other system that meets our needs at the same price point, and continue to invest our meager department budgets on more important things than Oracle licenses."