One month after Oracle announced its takeover of Sun Microsystems, the future of MySQL remains up in the air. Can the leading lightweight open source database still thrive when it's controlled by the leading proprietary commercial database vendor? So far, the prognosis doesn't look good.
Even before the Oracle buyout, there were signs of strain within the MySQL community. Not long after Sun acquired MySQL in 2008, key MySQL employees began exiting the company, including CEO Mårten Mickos and cofounder Monty Widenius. Widenius, in particular, was vocally critical of the MySQL development process under Sun's stewardship, citing rushed release cycles and poor quality control. Another MySQL cofounder, David Axmark, left out of frustration with the bureaucracy and tedium of Sun's buttoned-down corporate culture.
In the wake of this exodus came another ominous development: Forks of the MySQL codebase began to appear, including Drizzle and MariaDB, offering users and contributors ways around Sun's control of the main branch. Drizzle is an attempt to shed some of the feature bloat that has crept into recent MySQL releases, in favor of a lightweight database server aimed at cloud computing and Web applications. MariaDB, on the other hand, aims to be feature-compatible with MySQL, but it uses a brand-new, transaction-capable storage engine by default. And perhaps even more significantly, MariaDB is spearheaded by none other than Widenius himself.
If that wasn't troubling enough for MySQL's new minders at Oracle, Widenius has since dropped the other shoe. Last week, he announced the formation of the Open Database Alliance, a "vendor-neutral consortium" whose stated aim is to become "the industry hub for the MySQL open source database, including MySQL and derivative code, binaries, training, support, and other enhancements for the MySQL community and partner ecosystem." Notably, no one from Oracle is listed among the Open Database Alliance's contacts.
If all this leaves you scratching your head, you're not alone. In March, former MySQL employee and Drizzle developer Patrick Galbraith wondered aloud just which branch of MySQL should be considered "official" these days. The ultimate answer to that question will determine the fate of the MySQL database.
Can Oracle keep the MySQL product relevant?
Of course, there can only be one real, official version of MySQL: It's the one that was originally developed by MySQL, was later bought by Sun, and was finally acquired by Oracle. Oracle now owns all the copyrights, trademarks, and other intellectual property associated with the MySQL name -- and that intellectual property has always been defended vigorously. MySQL had even been known to send trademark-violation notices to partners that had the temerity to call their service offerings "MySQL support" instead of "support for MySQL databases."
While that's all well and good, however, the MySQL brand alone isn't likely to comfort customers who worry that an open source database won't get the attention it needs from one of the world's largest commercial software companies. Already some customers must be questioning Oracle's commitment to a low-end product like MySQL, when it has a lucrative, proprietary database to sell. And as the MySQL community fragments and begins turning to alternatives, the economics of Oracle's MySQL business become steadily less attractive.
But if MySQL's approval ratings are slumping, all the more reason for Oracle to move decisively. Oracle must work to regain the trust and support of the MySQL community or risk losing mindshare to a fork, such as Drizzle or MariaDB. To do that, it has to avoid making the mistakes that Sun made when it acquired MySQL. In a sense, to succeed with MySQL, Oracle will have to stop acting like Oracle.
Open source customers are a notoriously fickle bunch. If one project doesn't deliver what users need, the users go elsewhere -- and the same goes for developers. Forks are a fact of life in the open source community, and arguably an entirely healthy one. Oracle just better hope it doesn't end up on the wrong side of the fork.
When projects fork, there are winners and losers
Coincidentally, a similar drama is playing out elsewhere in the open source world right now. This one concerns glibc, the Gnu standard C library that is used by practically every piece of software running on Linux systems. Earlier this month, the Debian Project opted to switch its entire distribution from using standard glibc to a fork called eglibc. Ostensibly the new fork works better for embedded systems programming, but the community scuttlebutt says the switch was really the result of ongoing problems with glibc's notoriously obstinate maintainer, Ulrich Drepper. (One contributor even went so far as to file a bug report describing the problem.)
The name eglibc is surely no accident. It echoes an earlier, contentious incident in which a group of developers working on gcc, the Gnu C compiler, frustrated by the project's restrictive contribution model, split off to form a new fork called egcs. Freed from excessive bureaucracy, the fork thrived, while development on the main gcc branch stagnated. Eventually it died off completely; all that was left was for egcs to formally change its name back to gcc. The fork became the main branch -- and according to some egcs developers, that had been their intention from the very beginning. It seems likely that the eglibc maintainers have something similar in mind.
There's a real lesson to be learned here for Oracle and other maintainers of open source projects. Creeping authoritarianism in the development and contribution processes is something that many users of open source software are simply unwilling to tolerate; quite naturally, the contributors with the most to offer are the most likely to become frustrated when they feel stymied by red tape (or simple pigheadedness). Projects that are maintained by commercial entities are particularly susceptible to this tendency. Twelve years after Eric S. Raymond published his landmark essay, "The Cathedral and the Bazaar," too many projects -- and companies in particular -- can't seem to let go of their cathedral mentalities.
That's why the best course of action for Oracle would be to join the Open Database Alliance and take an active role in the ongoing development of MySQL in an open, community-driven way. Oracle acquired MySQL as an asset of Sun, but Sun never knew what it had in the first place, nor how to manage it. If Oracle can't figure out how to do what Sun couldn't, it will still own the MySQL name; unfortunately, however, that name won't mean much.