但是，如果 MySQL的支持率正在下降，Oracle更应该快点做出决断。Oracle必须努力恢复MySQL社区的信任和支持，否则就可能眼睁睁的看着它变成一把叉子长出Drizzle、MariaDB或者其它分支。为了做到这一点，Oracle必须要避免Sun在收购MySQL时犯的错误。从某种意义上说，想要MySQL成功，Oracle要表现得不像Oracle一点。

  开源项目的客户是出了名的挑剔。如果一个项目不能提供用户需要，用户可以立刻去找其他的开发者也一样。有许多开源项目都出现了叉子的状况，也有观点认为这样的竞争是健康的。而对于Oracle来说，最好希望自己不要走错了路口。

  如果MySQL变成叉子，谁会输，谁会赢？

  巧合的是，在开源世界的另一个领地正在上演类似的情节。这个主角是glibcGnu standardClibrary（GNU标准C库）Linux上运行的几乎所有软件都在用它。本月初，Debian项目决定用 eglibc（ddedglibc），也就是glibc的一个分支来替换掉它。表面上看新的分支可以更好地为嵌入式系统编程服务，但社区里却可以听到些闲话说替换glibc的真正原因在于glibc主要维护者UlrichDrepper的顽固不化。

  eglibc的出现肯定不是偶然的。它与很久以前的一次争议事件遥相呼应，当时有一群从事Gnu Ccompiler（GCC，GnuC编译器）的开发者由于受不了项目贡献模式的严格限制，分离出去形成了一个称为egcs的新分支。摆脱了官僚主义之后，egcs分支繁荣发展，而gcc的主分支依旧停滞不前，最后以gcc的死去而其后egcs正式改名为gcc而告终，分支最终变成了主干。根据一些 egcs开发者所说，他们从一开始就有这样的打算。很难讲这次eglibc的维护者们是不是也有类似的想法。

  Oracle和其他开源项目的维护者都应该在这里好好的上一课。缓慢的专制管理是许多开源软件的用户和贡献者所不愿意容忍的，而被企业等商业实体维护的项目特别容易受到这种影响。在EricS.Raymond发表了他那篇论文大作大教堂和集市的12年之后，我们看到仍有太多的项目尤其是企业还是无法放掉自己的大教堂心态。

  因此Oracle最好的行动方针应该是立即加入开放数据库联盟，并以积极的态度参与MySQL的开发，而且要全力保护由社区推动的开放的方式。Oracle将MySQL作为Sun的一项资产买下来，但是Sun一直没有抓住MySQL的重点，也不知道如何管理。如果Oracle想不出怎样比Sun做的更好，那么它仍将拥有MySQL的名号，然而不幸的是，这个名号很快就会没有多大意义了。