关于Android项目和内核主分支开发社区的关系，已经谈论得够多了。在LinuxCon大会日本站，詹姆斯·博顿利（译者注：James Bottomley，Linux SCSI子系统的维护者）又深入探讨了这个问题。他说，从Android和内核主分支分道扬镳这件事上，我们可以吸取一些有趣的教训。如果内核开发社区能关注到Android在干什么，那么我们以后处理这些问题可能会更得心应手。
詹姆斯首先给Android下了个定义，很简单，它是有史以来最成功的Linux发行版。它的市场占有率是其他桌面和服务器发行版所望尘莫及的。Android的成功很惊人，但总结起来归结于：
- 自立门户，和官方内核走不同的路
- 重写了工具链和C库
- 开发了一套自己的Java应用框架，并且
- 极度不喜欢GPL
詹姆斯说，换句话说，Android为“如何跟开源社区对着干”树立了榜样 。我们让他们别做的事情，他们都做了，并且做得很好。我们一直想让Android开发人员回到正道上来时，但他们的成功似乎证明了，需要改变的，不只是他们。也许内核开发社区也应该重新评估，我们在代码质量和市场成功两者之间到底如何权衡取舍。他问道，我们是否需要一套更面向商业的制度？
这场讨论的一个重大假设是，自立门户是一件坏事。Android一开始就自己单搞了一套内核，然后另起炉灶开发了自己的用户空间代码。内核社区适时地谴责了这种做法。但我们还是有必要去理解当时Android开发人员想干什么。他们一开始先要找到想采用Android的人，然后才会真正动手去实现这个系统。这个时候，时间压力就会很大。他们需要尽快搞定。对于内核社区走查和接受补丁代码的流程，有很多话可以说，但这个流程确实还有可以改进的地方。谷歌显然等不到他们的补丁被接受，因他们要发布Android，所以除了单干以外别无选择。
自立门户有错吗？詹姆斯说，从某种意义上来说，没错：毕竟GPL保障了这种权利。因为自己搞自己的，有时候还是有必要的，所以这种权利必须被保证。没有实践机会的权利是毫无意义的。在这个事情上，如果Android跟着官方内核走，那他们很难在短时间内达到商用目标（指的是电源管理和其他一些东西）。如果那样，结果将会是Android延迟发布，它获得市场成功的可能性就小了，甚至完全错过市场的档期，成为一个失败的产品。所以，自立门户有时候是好事，能使开发团队更快地做出产品，而你要走内核社区的审核流程，就慢了。
自立门户就意味着分裂吗？他问道。这是一个很重要的问题。分裂扼杀了90年代的UNIX市场。詹姆斯声称，如果自立门户失败了，它就消亡了，不会导致分裂。自立门户后，又把开发出来的代码合并回原来的项目，那也不会产生分裂，他们会带着他们的代码和开发人员回归到最初的项目中。只有这样的自立门户是有害的：他们取得了一些成功，部分的社区力量转而成为他们的拥趸，这些人再也不会回到原来的项目中。此时，开发社区要帮助这些自立门户的人把他们的代码合并回原来的项目，这显得非常重要。
Android开发人员，不止是自立门户，而且抱这样一种态度：GPL对商用是有害无益的。Android起初的计划是完全不使用GPL授权的代码，他们准备写一个新的内核。但后来很多原因迫使他们采用了Linux内核，还有其他一些GPL授权的组件。詹姆斯说，所以我们应该感谢安迪·鲁宾（译者注：Android之父）——对GPL的憎恨就来自他——他向世人展示了采用GPL授权代码的手机也能获得市场的成功。看起来下游厂商根本不关心他们设备里面运行的代码的授权许可证是什么，只要这个许可证清晰并能遵守就行了。
Anroid特殊的应用框架如何？詹姆斯说，基于Java的应用框架是Android最创新的部分之一。它抽象了平台的细节，使应用层尽量远离内核。这个框架限制了应用程序能使用的API，对应用进行了更多的控制。鉴于这个系统的结构，重写C库似乎是完全没必要的。框架层之上的应用不可能直接使用它。
所以，Android不是什么都错，但确实有一些错误。从詹姆斯的观点来看，最大的错误就是它的日历程序不支持SyncML（译者注：一种平台无关的信息同步标准协议集，可以在不同手机间同步数据）。这使得Android手机对于商务用户来说没什么用。黑莓（Blackberry）成功的关键之一就是它的日历做得非常好。摩托罗拉（Motorola）就意识到了这个问题，并且为他们的Droid手机自主开发了支持SyncML的应用。但这使事情变得更糟，因为这会使用户误以为Android手机都支持SyncML。当他们拿到一台非Droid的手机时，他们会很失望，并且最终去买一部iPhone。Android直到2.1才支持SyncML，是完全从头去实现的。这个错误的代价就是一年内没什么公司愿意用Android。
当然，Android的另一个问题是开发门槛。Android看起来是个开源项目，但是谷歌完全掌握着基线版本的控制权。没人能看到代码，直到谷歌把代码放出来为止。没有任何合作伙伴贡献的修改，所以根本没什么开发社区，没什么共享制度可言。举个例子，如果Android愿意接受外部帮助的话，它原本可以更快地解决它的日历问题。谷歌对Android的完全控制是为了更好地专注于市场。如果想统治市场，这是必要的先决条件，但对于内核开发社区来说，这不是好事，这也使谷歌被迫去做“重复发明轮子”的事情。
还有一个错误，正在被甲骨文（Oracle）起诉。这个案子的起因是Android重写了Java，并且接下来和GPL唱反调。如果Android是建立在甲骨文的GPL授权的Java之上的话，就不会有这桩诉讼了，而谷歌也会受到GPL的默示专利许可（implied patent license）的保护。如果甲骨文赢了，那么为绕开许可证而重写Java将是一次非常昂贵的尝试。更可悲的是，许可证其实是无关紧要的，因为Java运行环境把上层应用隔开了，上层应用无需遵守GPL。
教训
从中我们可以学到什么教训？詹姆斯重申了自立门户可以变成一件好事，只要开发成果能够回归。尽管做了很多努力，Android内核的开发成果没有回归到官方内核。而且我们也不清楚内核社区提出的方案时，Android开发人员有没有参与其中。他说，也许我们应该使合并代码变得更简单。内核社区应该找到更好的办法来处理这个流程。目前的流程很容易卡在代码走查这个环节，尤其是当代码量很大的时候。
自立门户的项目也需要思考他们的流程。自立门户容易产生“非我发明”的心态（译者注：not-invented-here，指拒绝使用非自己创造的技术），导致他们不愿意公示自己的开发成果。因为发布代码去找骂，谁也不愿意。自立门户时间越长，情况就越糟，因为改正基本的设计错误（内核社区的观点：wakelocks机制就是一个错误）会更难。为防止这种错误发生，需要这些项目变得更包容，经常发布他们的代码，并向内核社区咨询意见——即使他们不打算采纳。打破壁垒，使思想能够相互交流，这很重要。
詹姆斯又谈了一点关于“许可证恐惧”，他指出GPL就是我们的惧、惑、疑（译者注：即FUD，Fear，Uncertainty，Doubt，这是一个专用名词，指向客户灌输其他竞争公司产品的负面观念）。内核社区对许可证的讨论，看起来很吓人。他们对这个问题也需要降降温。对GPL的恐惧往往是受外部利益驱使，但我们也在尽可能使他们能受益。内核社区应该主动出击，帮助大家消除这种恐惧。比如，可以帮助Android看看能不能换用GPL授权的代码。Linux基金会曾经做过一些工作，但詹姆斯认为内核社区应该提供帮助。他说，其实相较于大多数商业许可证协议，遵守GPL更容易。这一点我们必须要澄清。
在遵守GPL的问题上，我们必须澄清一些界线。比如，用户空间的代码，不算是起源于内核（译者注：这样就不需要遵守GPL）。明白了这些界线，可以帮助大家消除对GPL的恐惧。
内核社区应该更好地培养和拥抱多样化，鼓励别人单干（这可能带来重大的进步）并帮助他们回归。詹姆斯说，在这个问题上，内核社区只能说是勉强及格，还有很大改进空间。我们接受的代码，只来自于和我们有一样价值观的人。这造成的结果就是，把Android内核合并回来的难度越来越大。
公司如果想掌握项目的控制权，应该以赞成或反对的方式，而不是独自占有项目的所有权。李纳斯·托瓦兹（译者注：Linus Torvalds，Linux创始人）是一个很好的例子，他有很大的控制权，但这只是因为内核社区相信他能做出正确的判断。也就是说，社区如果信任你，那么他们很高兴交出大量控制权。这就是为什么“善良的独裁者”模式能大行其道。另一方面，如果公司通过拒人门外的手段来昭示它的控制权，或者逼贡献代码者交出版权，这必然会与开源社区交恶。
詹姆斯说，总之，对于所有牵涉其中的人来说，Android是一个两败俱伤的结果。我们所有人都必须好好想想，如何才能做得更好。我们需要找到更好的办法来鼓励和管理自立门户的项目，并消除对许可证的恐惧。自立门户的项目也应该想着要合并回去。这样，项目（比如Android）既能取得商业成功，也能在社区中取得成功。
原文地址：http://select.yeeyan.org/view/234039/204194
【编辑推荐】
