本文来自Savio Rodrigues，他是IBM的的产品经理。他期望有一天开源软件和传统软件可以和平共存。但是这个也只是Savio Rodrigues本人的愿望，IBM大概不太希望这样的事情发生。
由于甲骨文迟迟不发布最新版本的OpenSolaris，关于OpenSolaris何去何从的问题有了很多讨论，同时，在OpenSolaris社区也有了很多关于fork的话题。本文中，博主对开源fork进行分析并提出自己的看法和解决方法。
源代码的开放是建立开源社区可信度的核心因素。我们都知道，开源的开放可以消除人们对某些特定开源项目和产品未来的担忧。但是这样的信任常常是被夸大了的。
几周前，当我写Solaris10的许可变化时，我尽量避免讨论OpenSolaris。那时，甲骨文依然在设法消化它们对Sun的收购，我认为给甲骨文时间设计OpenSolaris是一个明智的做法。尽管我的想法没有变，但是从目前的消息来看，关于OpenSolaris的问题还是引起了很多的讨论。
早些时候，OpenSolaris的进度表中因为缺少进度的信息和开源操作系统整体的发展模式信息而受到诟病。Sun帮助成立了OGB（OpenSolaris Governing Board）。就这点而论，围绕OpenSolaris的发布和技术路线图的决定大部分还在Sun控制的范围内。由于甲骨文对他们自己关于OpenSolaris的计划相对比较沉默，所以至少有一名评论者建议OGB表明立场并要求甲骨文公司发布澄清OpenSolaris的未来或者和甲骨文断绝关系，对于这样的要求我们就不会感到奇怪了。
OpenSolaris社区的成员Ben Rockwood给了如下回应：
这里就是我要小心的地方。我认为，在这个时候请求自治是非常愚蠢的。如果他们给了这个自治的权力，他们会期望我们去fork，并重新建立一个没有Sun或者Oracle资源的社区。这也就意味着网站将被关闭，联系也将被切断。我觉得情况会变得很糟糕，基本上我们的行为将有助于结束社区。
目前，该社区的规模相对还是比较小的，而且相对不是很活跃。对于Nexenta, Belenix等的支持相对影响力会较小一点。这些项目是很有建设性和积极性的，但是与官方社区相比数量还是太小了。把这些所有的因素都考虑进去，我想我们就没有理由认为一个自治的社区真的会得到什么实际的支持了，除非我们可以得到突然得到大量的开发者。所以说，恕我直言，这个并不是首发。
另一个会员Martin Bochnig同样建议要谨慎地对待fork，他问道：
你们用什么来取代Sun内核这些经验丰富的工程师？
但是，OpenSolaris社区的另一名会员Damian Wojslaw写道：
我们确实有一个社区。目前它是存在的并且运行良好的。这是一个用户和管理员社区。我们没有开发者社区。这就是为什么我们不愿意付钱重新建一个新的。
这些话都是意味深长的。关于开源程序和产品的社区没有支持fork的资源也一样会充满活力的。实事上，几乎没有人可以胜任在fork发生时开发更深层次的源代码程序，更糟的是，甚至都没有人会对这个感兴趣。
当fork不可行时的对策
对企业来讲，对于fork失效的最好的保证是采用多供应商社区的开源产品。这保证了多方利益相关者的存在，每一个都可以合理地预期引导开源项目向前发展。
不幸的是，多厂商的社区是很少见的。更多的时候，你会发现开源产品大都是由社区的一个单一厂商控制的。在这种情况下，一个组织可以合理地支持一个fork的可能性是很高的，如果围绕这个开源项目有一个很强的合作伙伴或者是一个有机、整合的系统。对fork失效的另外一个故障安全将是对开源项目实现收费。对供应商所作的工作付费将是一个很好的方法来确保供应商的动机，但是这会大大损坏用户的利益。
但是，最好的建议可能是忽视它，或者至少不要这么重视这个问题。否则，更多的时候，你将会在很多其他重要的时刻难以抉择，更何况要维护一个fork的源代码是很困难的。
