没有开源，Google 不会有今天的成功。在本周举行的北美 Linux 大会上，Google 工程师 Merlin 从一个第三方视角概括了 Google 是如何使用和为开源做出贡献。自 2002 年以来，Marc Merlin 一直担任 Google 的工程师，期间做过许多开源项目并为 Linux 项目贡献过代码的。

开源绝非易事

无论是个人还是公司，开放项目源码的目的无非是：借助社区的力量帮助项目更好地成长和推动社区的发展。但是，开源绝非易事。创始之初，由于资源非常紧缺，Google 在早期对开源的贡献非常有限。Google 的第一代软件都是为了内部使用的需要，并非在开始就是为开源而设计。之后 Google 希望将这些软件开源的时候，花费了大量的精力专门为它们写了技术文档以及论文，以描述其中的方法和代码，方便开源社区的其他开发者查阅和参与。开源并非仅仅是将源码发布出去，同时还需要付出巨大的精力去进行维护。

Google 的开源史

从经验上看，Google过去在总体上虽然不怎么开源，但是却发表了很多相关的论文，比如说对于业界很重要的MapReduce、BigTable论文。并不是说Google不愿意开源，否则它也不会去发表这类论文，问题是在于开源需要太多的人力和物力了。随着 Google 的日益壮大，开始在开源社区担负起一定的责任。从 Google 开源的发展中可以看出，Google 最早期的贡献都是修复一些 bug。Google 总是最先发现和修复难以发现的 bug，因为这些 bug 只会在 Google 这样的规模中才会出现。到目前为止，Google 已经为 Linux 内核贡献了超过 5000 次补丁。其中有小的补丁也有大的子系统。当谈到 Google 自己的开源项目时，目前在 GitHub 中 Google 有超过 3000 个开源项目。随着开源项目的骤增，为了方便集中地对需要开源的代码进行审查，Google 组建了一个包含 6 个人的审查团队，主要任务是从法律层面审查 Google 内部使用开源项目和发布源码的合规性。

如何保持代码的合法性

为了保持整件事情的合法性，Google 将所有外部的开源代码存储在第三方。只有那些拥有 Google 能够接受的许可证的项目，Google 才允许在内部使用。一个 Google 不能接受的许可证的例子是 AGPL（Affero 通用公共许可证），这是一个互惠许可证，要求那些使用了其中的代码的项目需要提供一个项目源码的链接。相比于在一个较少限制的许可证下自己去书写代码重新实现，或者使用其他的方式，比保证 Google 面向外部的产品中没有任何 AGPL 代码的代价要小得多。对于那些向 Google 项目贡献代码的开发者，Google 要求他们同意贡献许可协议（CLA）。CLA 的主要目的是得 Google 能够对贡献的代码重新颁布许可证，以及 Google 对贡献的代码有专利许可。即，仍然保留开发者的代码的所有权，开发者只是另外给了 Google 一个许可证。