谷歌开源之道

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

开源绝非易事

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

Google 的开源史

从经验上看,Google过去在总体上虽然不怎么开源,但是却发表了很多相关的论文,比如说对于业界很重要的MapReduceBigTable论文。并不是说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 一个许可证。

 

本文固定链接:http://www.oxox.work/web/news/google-opensource/ | 虚幻大学

发表评论

电子邮件地址不会被公开。