Android, forking, and control

翻译：马少兵/刘晓佳/李潇

关于 Android 和 Linux 主线开发的关系已经被谈论很久了。在日本的 LinuxCon，James Bottomley 又就此阐述了很多观点。他说，从两个项目之间缺乏联系和交流可以学到很多教训，如果社区能关注这些往事，未来我们应该能做得更好

• Forking the kernel

• 重写了 C 库和工具链

• 开发了一个 Java 应用框架（JVM定制）

• 项目启动的时候，对 GPL 极为排斥

换句话说，Android 是一个不同社区合作的典型代表。它们做了无数社区觉得不该做的事情，但是最后成功。尽管我们觉得 Android 的开发团队需要有所改变，但它的成功也说明，社区也需要有所改变。也许社区需要重新权衡代码质量以及市场成功，社区是否需要更加面向商业一些？？

一个最大的争论就是 forking，不仅仅是 kernel，Android 从零编写了整套用户空间，社区对此特别愤怒。但我们得理解这个事情的历史过程。最开始 Android 是期望它的变更能被主线采纳的，但在开始实现系统的过程中，时间压力很大，不得不尽早往前赶进度。我们都知道关于内核社区的补丁复查和接纳过程有很多议论，总之Google 无法等待社区接受后再发行它的 Android。但也许，除了 forking 内核外我们还能有其它选择

“难道内核分支是一种错误吗？”，在某种意义上来说，James说，那不是错误：毕竟有 GPL 担保。分支有时候是必须的，如果android系统不能被应用，原来那种正确也是无意义的。在此特殊情况下，如果不采用分支，android系统的商业的开发与应用将会处于一个艰难的时刻,很难实现其目标（关于电源管理以及其他）。最终将会导致android代码被推迟，而这一切，会使目前市场缺少很多产品，或许因为错过市场时机项目就悲剧了。分支，换句话来说，也是一个好的事情——相比较于内核社区的固定流程，不同的团队可以做更多的事情

James问到，分支化等同于分裂化吗？这是个很重要的问题：上世纪九十年代分裂化几乎杀死了Unix的市场。他声称失败的分支化并不会分裂Linux社团；相反，他们只是简简单单的消失而已。那些合并后回到父工程的分支化并不代表着分裂化；他们将代码和开发者带回了原始的工程。真正有害的分支化，是那些取得成功并带走了一部分社团的分支，它们不会再回到父工程了。从这个角度讲，很有必要让社团帮助分支合并回来。

除了分支化了内核，Android的开发者，曾经认为GPL对于商业化并无益处。该工程最初避免任何GPL-licenced的代码；本来计划是写一个全新的内核。最后，由于某些原因，采用了GPL-licenced的Linux内核；同时还保留一些其他GPL-licenced的组件。所以，James说，我们应该谢谢Andy Rubin – 是他最初讨厌从GPL来的代码 – 最后决定性的证明了一款含有GPL-licensed代码的手机在市场上是可以成功的。结果就是下游销售商不用关心他们设备里代码的许可证；只需要关注清晰一致即可。

关于Android特别应用框架呢？James说基于Java的应用程序框架是Android系统最大的创新；它将平台细节抽离出来，使得应用层尽可能地远离了内核。该框架限制了应用程序可用的API，对应用所能做的以更强的控制。给定该结构后，貌似重写C库是一件完全没必要的事情；在该框架下没有人会尝试直接使用C库的。

所以，Android并没有做错一切。但是还是犯了一些错误：从James角度看，最大的错误就在于一开始它缺乏支持SyncML的日历应用。这使得Android很难吸引商业人士。黑莓成功的关键之处就是它优秀的日历。摩托罗拉看到了该问题，并为Droid系列手机实现了它自己专有的SyncML日历系统；这实际上使得事情更糟了，因为商业人士购买Android手机的出发点就变成了它能够支持日历系统。如果除了Droid之外别无他选，就会非常令人失望，最终转投iPhone平台。直到一年后，2.1版本，Android才支持SyncML，也是从零开始重头编写。

Android的另外一个问题是它的“walled garden”开发手段。Android本来是个开源工程，但是谷歌却对基本的发行维持总控制；在谷歌把代码扔出墙外前没有别人可以看到代码。没有一个变化是来自第三方提供的，所以没有社团来维护该代码，没有共享的创新。举个例子，如果愿意接受来自外界的帮助的话也许早就解决了日历的问题了。谷歌对代码的总控制是因为需要给工程以市场焦点。这是达到市场统治的先决条件，但是对社团来说并无益处，并且迫使谷歌重复了许多已有的创新。

另一个大问题是来自甲骨文的起诉。该控告基于Android对Java语言的重写，这完全是因为 Android 害怕GPL所至。要是Android建立在甲骨文的GPL-licensed的Java代码基础上，应该不会有法律问题；按照GPL暗示的专利许可，Google本该被保护。如果甲骨文赢得这场官司，重写Java将意味着在许可证逃避方面极其昂贵的实践。令人悲痛的是该license是完全无关紧要的：Java runtime API 将应用同 GPL 隔离

学习到的教训

我们能从这些里面学到什么？James重申，只有最终合并回去，创建分支才是一件好事。虽然做出了大量的努力，但Android分支还未合并回去。也不清楚Android开发者是否已经开始实施内核社区提出的解决方案。他说，也说我们需要想出一种方法让合并更容易。尤其是在创建的分支壮大的情况下，社区应该有一种更好的方法来处理当前这个有可能在审查中陷入困境的过程。

创建分支的项目还要考虑一下这些过程。子分支开发团队容易产生“非我发明”的心态（指反感或拒绝使用不是自己发明的技术），这反而会导致他们不愿意展示自己的最终代码。把自己都知道贴出来就要被社区严厉批评的代码贴出来一点都不有趣。子分支发展越久，这种状况越糟糕；修正基础的设计错误（正如社区眼里wakelocks的作用）就会越困难。要防止这个问题就要求分支团队更加包容，更频繁的贴出他们的代码，并寻求社区的建议—即使他们并不打算接受这些建议。打开围墙并让双方交流各自的想法是很重要的。

James谈到了“授权恐惧”，说GPL是我们特别感到FUD的地方。我们在社区里的一些关于“授权”的讨论在行业界人士看来就像是一个令人害怕的问题。而社区里关于这个话题的讨论不像那样激烈，这反而大有好处。对GPL的恐惧是由外界的兴趣驱动的，但我们趋向于让事情简单。社区应当更加前瞻性的去缓和这种恐惧；将Android看作在GPL授权下如何运转的一个范例，这是缓和恐惧的一种可能性。Linux基金会做过一些这样的工作，但是James觉得社区该出手帮助。他说，GPL比起那些最具商业性的授权，遵守起来容易得多，这是我们需要更加明白的一点。

我们应该设计更加“bright line”的系统，这会让GPL问题变得更加明确。内核用户空间ABI就是这样的一个系统；开发者知道用户空间代码被认为不会被内核的 GPL 所污染。让这个界限更容易的理解，会有助于减少对GPL的恐惧。

社区应该在提倡和发展多样性，鼓励创建分支（这会创造更多显著地成就）并帮助他们合并回去。James说，如今内核最多能得一个“C”的成绩。我们只从看起来跟我们相似的人那里接受代码，Android的合并尝试比原本想象的更加痛苦。

企业们应当靠获得社区拥护而不是绝对所有权来控制代码。Linus Torvalds就是一个例子；他有许多控制权，但那是因为社区信任他能做正确的决定。一般来说，如果社区信任你，它就会交出大量的控制权；那就是为什么仁慈的独裁者模型如此平常的原因了。另一方面，那些试图通过设置开发壁垒或者通过要求贡献者转让版权来声明控制权的企业们与社区相处得更加困难。

James说，总之，Android对任何参与进来的人而言都是一个惨败；我们都需要想清楚怎么去做的更好。我们需要找出更好的鼓励和管理分支并减轻授权恐惧的方法。创建分支的项目从一开始就应该仔细考虑合并回去的事情。这样，那些商业成功的项目（如Android）能同样是社区的成功