沒有開源，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 一個許可證。
京公網安備 11010502049343號