Many words have been said about the relationship between the Android project and the mainline kernel development community. At LinuxCon Japan, James Bottomley took the stage to say a few more. There are,
he said, some interesting lessons to be learned from that disconnect. If the development community pays attention to what has been going on, we may be better placed to deal well with such situations in the future.

关于Android项目和内核主分支开发社区的关系，已经谈论得够多了。在LinuxCon大会日本站，詹姆斯·博顿利（译者注：James Bottomley，Linux SCSI子系统的维护者）又深入探讨了这个问题。他说，从Android和内核主分支分道扬镳这件事上，我们可以吸取一些有趣的教训。如果内核开发社区能关注到Android在干什么，那么我们以后处理这些问题可能会更得心应手。

James started with the statement that Android is, hands down, the most successful Linux distribution ever produced. Its adoption dwarfs that of Linux on the desktop - and on the server too. Android's success is spectacular, but it
was achieved by:

詹姆斯上来先给Android下了个定义，很简单，它是有史以来最成功的Linux发行版。它的市场占有率是其他桌面和服务器发行版所望尘莫及的。Android的成功很惊人，但总结起来归结于：

Forking the kernel,

自立门户，走不同的路

Rewriting the toolchain and C library,

重写了工具链和C库

Developing a custom Java-based application framework, and

开发了一套自己的Java应用框架，并且

Working from an extreme dislike of the GPL

极度不喜欢GPL

In other words, James said, Android is a poster child for how one should not work in the open source community. They did everything we told them not to, and won big. While we would like the Android developers to change and do some
things differently, their success suggests that, perhaps, Android is not the only group in need of change. Maybe the community needs to reevaluate how it weighs code quality against market success; do we, he asked, need a more commercially-oriented metric?

詹姆斯说，换句话说，Android为“如何跟开源社区对着干”树立了榜样 。我们让他们别做的事情，他们都做了，并且做得很好。我们一直想让Android开发人员回到正道上来时，但他们的成功似乎证明了，需要改变的，不只是他们。也许内核开发社区也应该重新评估，我们在代码质量和市场成功两者之间到底如何权衡取舍。他问道，我们是否需要一套更面向商业的制度？

One of the big assumptions brought into this debate is that forking is a bad thing. Android started by forking the kernel and writing its own user space mostly from scratch, and the community has duly condemned（正式谴责）these moves.
But it is worth understanding what the Android developers were trying to do; Android started by finding adopters first; only then did they get around to actually implementing their system. At that point, the time pressures were severe; they had to have something
ready as soon as possible. There is a lot to be said for the development community's patch review and acceptance processes, but they do tend to be somewhat open-ended. Google couldn't wait for that process to run its course before it shipped Android, so there
was little choice other than forking the kernel.

这场讨论的一个重大假设是，自立门户是一件坏事。Android一开始就自己单搞了一套内核，然后另起炉灶开发了自己的用户空间代码。内核社区适时地谴责了这种做法。但我们还是有必要去理解当时Android开发人员想干什么。他们一开始先要找到想采用Android的人，然后才会真正动手去实现这个系统。这个时候，时间压力就会很大。他们需要尽快搞定。对于内核社区走查和接受补丁代码的流程，有很多话可以说，但这个流程确实还有可以改进的地方。谷歌显然等不到他们的补丁被接受，因他们要发布Android，所以除了单干以外别无选择。

Was forking the kernel wrong? In a sense, James said, it cannot be wrong: the GPL guarantees that right, after all. The right is guaranteed because forking is sometimes necessary, and rights are meaningless if they are not exercised.
In this specific case, without a fork, the Android project would have had a hard time achieving its goals (with regard to power management and more) in a commercially useful time. The result would have been a delayed Android release which would have led to
less success in the market or, perhaps, missing the market window entirely and failing to take off. Forks, in other words, can be good things - they can enable groups to get things done more quickly than going through the community process.

自立门户有错吗？詹姆斯说，从某种意义上来说，没错：毕竟GPL保障了这种权利。因为自己搞自己的，有时候还是有必要的，所以这种权利必须被保证。没有实践机会的权利是毫无意义的。在这个事情上，如果Android跟着官方内核走，那他们很难在短时间内达到商用目标（指的是电源管理和其他一些东西）。如果那样，结果将会是Android延迟发布，它获得市场成功的可能性就小了，甚至完全错过市场的档期，成为一个失败的产品。所以，自立门户有时候是好事，能使开发团队更快地做出产品，而你要走内核社区的审核流程，就慢了。

Is forking equal to fragmentation, he asked? It is an important question; fragmentation killed the Unix market back in the 1990's. James claimed that forks which fail do not fragment the community; they simply disappear. Forks which
are merged back into their parent project also do not represent fragmentation; they bring their code and their developers back to the original project. The forks which are harmful are those which achieve some success, carrying part of the community with them,
and which do not return to the parent project. From that, James said, it follows that it is important for the community to help forks merge back.

自立门户就意味着分裂吗？他问道。这是一个很重要的问题。分裂扼杀了90年代的UNIX市场。詹姆斯声称，如果自立门户失败了，它就消亡了，不会导致分裂。自立门户后，又把开发出来的代码合并回原来的项目，那也不会产生分裂，他们会带着他们的代码和开发人员回归到最初的项目中。只有这样的自立门户是有害的：他们取得了一些成功，部分的社区力量转而成为他们的拥趸，这些人再也不会回到原来的项目中。此时，开发社区要帮助这些自立门户的人把他们的代码合并回原来的项目，这显得非常重要。

The Android developers, beyond forking the kernel, also took the position that the GPL is bad for business. The project's original goal was to avoid GPL-licensed code altogether; the plan was to write a new kernel as well. In the
end, a certain amount of reason prevailed, and the (GPL-licensed) Linux kernel was adopted; there are a few other GPL-licensed components as well. So, James said, we can thank Andy Rubin - from whom the dislike of the GPL originates - for conclusively（确凿）
demonstrating that a handset containing GPL-licensed code can be successful in the market. It turns out that downstream vendors really don't care about the licensing of the code in their devices; they only care that it's clear and compliant.

Android开发人员，不止是自立门户，而且抱这样一种态度：GPL对商用是有害无益的。Android起初的计划是完全不使用GPL授权的代码，他们准备写一个新的内核。但后来很多原因迫使他们采用了Linux内核，还有其他一些GPL授权的组件。詹姆斯说，所以我们应该感谢安迪·鲁宾（译者注：Android之父）——对GPL的憎恨就来自他——他向世人展示了采用GPL授权代码的手机也能获得市场的成功。看起来下游厂商根本不关心他们设备里面运行的代码的授权许可证是什么，只要这个许可证清晰并能遵守就行了。

What about Android's special application framework? James said that the Java-based framework is one of the most innovative things about Android; it abstracts away platform details and moves the application layer
as far away from the kernel as possible. The framework restricts the API available to applications, giving more control over what those applications do. Given the structure of the system, it seems that rewriting the C library was entirely unnecessary; nobody
above the framework makes any sort of direct use of it anyway.

Anroid特殊的应用框架如何？詹姆斯说，基于Java的应用框架是Android最创新的部分之一。它抽象了平台的细节，使应用层尽量远离内核。这个框架限制了应用程序能使用的API，对应用进行了更多的控制。鉴于这个系统的结构，重写C库似乎是完全没必要的。框架层之上的应用不可能直接使用它。

So maybe Android didn't do everything wrong. But there were some mistakes made; the biggest, from James's point of view, was the lack of a calendar which can handle SyncML. That made Android handsets relatively useless for business
users. One of the keys to the Blackberry's success was its nice calendaring. Motorola had seen this problem and implemented its own proprietary SyncML calendaring application for the Droid; that actually made things worse, as business users would get an Android
handset with the idea that it would work with their calendars. If they ended up with something other than the Droid, they would be disappointed and, eventually, just buy an iPhone instead. Android had no SyncML support until 2.1, when a new, written-from-scratch
implementation was added. The cost of this mistake was one year of poor corporate uptake.

所以，Android不是什么都错，但确实有一些错误。从詹姆斯的观点来看，最大的错误就是它的日历程序不支持SyncML（译者注：一种平台无关的信息同步标准协议集，可以在不同手机间同步数据）。这使得Android手机对于商务用户来说没什么用。黑莓（Blackberry）成功的关键之一就是它的日历做得非常好。摩托罗拉（Motorola）就意识到了这个问题，并且为他们的Droid手机自主开发了支持SyncML的应用。但这使事情变得更糟，因为这会使用户误以为Android手机都支持SyncML。当他们拿到一台非Droid的手机时，他们会很失望，并且最终去买一部iPhone。Android直到2.1才支持SyncML，是完全从头去实现的。这个错误的代价就是一年内没什么公司愿意用Android。

The other problem with Android, of course, is its "walled garden" approach to development. Android may be an open-source project, but Google maintains total control over the base release; nobody else even sees the code until Google
throws it over the wall. No changes from partners get in, so there is no community around the code, no shared innovation. As an example, Android could have solved its calendar problem much sooner had it been willing to accept help from outside. Google's total
control over Android was needed to give the project its market focus. It was a necessary precondition for market dominance（霸主地位）, but it is bad for community and has forced Google to reinvent a lot of wheels.

当然，Android的另一个问题是开发门槛。Android看起来是个开源项目，但是谷歌完全掌握着基线版本的控制权。没人能看到代码，直到谷歌把代码放出来为止。没有任何合作伙伴贡献的修改，所以根本没什么开发社区，没什么共享制度可言。举个例子，如果Android愿意接受外部帮助的话，它原本可以更快地解决它的日历问题。谷歌对Android的完全控制是为了更好地专注于市场。如果想统治市场，这是必要的先决条件，但对于内核开发社区来说，这不是好事，这也使谷歌被迫去做“重复发明轮子”的事情。

Another big mistake was being sued by Oracle. That suit is based on Android's rewrite of Java which, in turn, was entirely motivated by fear of the GPL. Had Android been built on Oracle's GPL-licensed Java code base, there would
have been no suit; Google would have been protected by the GPL's implied patent license. If Oracle wins, rewriting Java will turn out to be a hugely expensive exercise in license avoidance. And the sad fact is that the license is entirely irrelevant: the Java
runtime's API constitutes a "bright line" isolating applications from the GPL.

还有一个错误，正在被甲骨文（Oracle）起诉。这个案子的起因是Android重写了Java，并且接下来和GPL唱反调。如果Android是建立在甲骨文的GPL授权的Java之上的话，就不会有这桩诉讼了，而谷歌也会受到GPL的默示专利许可（implied patent license）的保护。如果甲骨文赢了，那么为绕开许可证而重写Java将是一次非常昂贵的尝试。更可悲的是，许可证其实是无关紧要的，因为Java运行环境把上层应用隔开了，上层应用无需遵守GPL。

Lessons learned

教训

So what can be learned from all of this? James reiterated that forking can be a good thing, but only if the results are merged back. The Android fork has not been merged back despite a great deal of effort; it's also not clear that the Android developers have
bought into the solutions that the kernel community has come up with. Maybe, he said, we need to come up with a way to make merging easier. The community should have a better way of handling this process, which currently tends to get bogged（陷入沼泽） down in review,
especially if the fork is large.

从中我们可以学到什么教训？詹姆斯重申了自立门户可以变成一件好事，只要开发成果能够回归。尽管做了很多努力，Android内核的开发成果没有回归到官方内核。而且我们也不清楚内核社区提出的方案时，Android开发人员有没有参与其中。他说，也许我们应该使合并代码变得更简单。内核社区应该找到更好的办法来处理这个流程。目前的流程很容易卡在代码走查这个环节，尤其是当代码量很大的时候。

Projects which create forks also need to think about their processes. Forks tend to create not-invented-here mentalities which, in turn, lead to a reluctance （不愿）to show the resulting code. It's no fun to post code that you know is going to be panned by the
community. The longer a fork goes, the worse the situation gets; fixing of fundamental design mistakes (which is what wakelocks are in the community's view) gets harder. Preventing this problem requires forks to be more inclusive, post their code more often,
and ask the community's advice - even if they do not plan to take that advice. It's important to open the wall and let ideas pass through in both directions.

自立门户的项目也需要思考他们的流程。自立门户容易产生“非我发明”的心态（译者注：not-invented-here，指拒绝使用非自己创造的技术），导致他们不愿意公示自己的开发成果。因为发布代码去找骂，谁也不愿意。自立门户时间越长，情况就越糟，因为改正基本的设计错误（内核社区的观点：wakelocks机制就是一个错误）会更难。为防止这种错误发生，需要这些项目变得更包容，经常发布他们的代码，并向内核社区咨询意见——即使他们不打算采纳。打破壁垒，使思想能够相互交流，这很重要。

James talked a bit about "licensing fears," stating that the GPL is our particular version of FUD. The discussions we have in the community about licensing tend to look like scary problems to people in industry; less heat from the community on this subject
would do a lot of good. The fear of the GPL is driven by outside interests, but we tend to make it easy for them. The community should be more proactive（主动） on this front to allay（缓和） fears; pointing to Android as an example of how GPL-licensed code can work
is one possibility. The Linux Foundation does some of this work, but James thinks that the community needs to help. The GPL, he said, is far easier to comply with than most commercial licensing arrangements; that's a point we need to be making much more clearly.

詹姆斯又谈了一点关于“许可证恐惧”，他指出GPL就是我们的惧、惑、疑（译者注：即FUD，Fear，Uncertainty，Doubt，这是一个专用名词，指向客户灌输其他竞争公司产品的负面观念）。内核社区对许可证的讨论，看起来很吓人。他们对这个问题也需要降降温。对GPL的恐惧往往是受外部利益驱使，但我们也在尽可能使他们能受益。内核社区应该主动出击，帮助大家消除这种恐惧。比如，可以帮助Android看看能不能换用GPL授权的代码。Linux基金会曾经做过一些工作，但詹姆斯认为内核社区应该提供帮助。他说，其实相较于大多数商业许可证协议，遵守GPL更容易。这一点我们必须要澄清。

We should also design more "bright line" systems which make the question of GPL compliance clear. The kernel's user-space ABI is one such system; developers know that user-space code is not considered to be derived from the kernel. Making the boundary easy
to understand helps to make the GPL less scary.

在遵守GPL的问题上，我们必须澄清一些界线。比如，用户空间的代码，不算是起源于内核（译者注：这样就不需要遵守GPL）。明白了这些界线，可以帮助大家消除对GPL的恐惧。

The community should do better at fostering and embracing diversity, encouraging forks (which can create significant progress) and helping them to merge back. Currently, James said, the kernel gets a "C - must do better" grade at best here. We only take code
from people who look like us; as a result, the Android merge attempt was more painful than it needed to be.

内核社区应该更好地培养和拥抱多样化，鼓励别人单干（这可能带来重大的进步）并帮助他们回归。詹姆斯说，在这个问题上，内核社区只能说是勉强及格，还有很大改进空间。我们接受的代码，只来自于和我们有一样价值观的人。这造成的结果就是，把Android内核合并回来的难度越来越大。

Companies, in turn, should aim for "control by acclamation（以鼓掌的方式）" rather than control by total ownership. Linus Torvalds was given as an example; he has a lot of control, but only because the community trusts him to do the right thing. In general, if the
community trusts you, it will happily hand over a lot of control; that's why the benevolent dictator model is as common as it is. On the other hand, companies which try to assert control through walled garden development or by demanding copyright assignment
from contributors have a much harder time with the community.

公司如果想掌握项目的控制权，应该以赞成或反对的方式，而不是独自占有项目的所有权。李纳斯·托瓦兹（译者注：Linus Torvalds，Linux创始人）是一个很好的例子，他有很大的控制权，但这只是因为内核社区相信他能做出正确的判断。也就是说，社区如果信任你，那么他们很高兴交出大量控制权。这就是为什么“善良的独裁者”模式能大行其道。另一方面，如果公司通过拒人门外的手段来昭示它的控制权，或者逼贡献代码者交出版权，这必然会与开源社区交恶。

In summary, James said, Android was a fiasco（惨败） for everybody involved; we all need to figure out how to do better. We need to find better ways of encouraging and managing forks and allaying licensing fears. Projects which create forks should be thinking about
merging back from the outset. Then projects which (like Android) are a commercial success can also be a community success.

詹姆斯说，总之，对于所有牵涉其中的人来说，Android是一个两败俱伤的结果我们所有人都必须好好想想，如何才能做得更好。我们需要找到更好的办法来鼓励和管理自立门户的项目，并消除对许可证的恐惧。自立门户的项目也应该想着要合并回去。这样，项目（比如Android）既能取得商业成功，也能在社区中取得成功。