沒有開源，Google 不會(huì)有今天的成功。在本周舉行的北美 Linux 大會(huì)上，Google 工程師 Merlin 從一個(gè)第三方視角概括了 Google 是如何使用和為開源做出貢獻(xiàn)。自 2002 年以來，Marc Merlin 一直擔(dān)任 Google 的工程師，期間做過許多開源項(xiàng)目并為 Linux 項(xiàng)目貢獻(xiàn)過代碼的。

開源絕非易事

無論是個(gè)人還是公司，開放項(xiàng)目源碼的目的無非是：借助社區(qū)的力量幫助項(xiàng)目更好地成長和推動(dòng)社區(qū)的發(fā)展。但是，開源絕非易事。創(chuàng)始之初，由于資源非常緊缺，Google 在早期對(duì)開源的貢獻(xiàn)非常有限。Google 的第一代軟件都是為了內(nèi)部使用的需要，并非在開始就是為開源而設(shè)計(jì)。之后 Google 希望將這些軟件開源的時(shí)候，花費(fèi)了大量的精力專門為它們寫了技術(shù)文檔以及論文，以描述其中的方法和代碼，方便開源社區(qū)的其他開發(fā)者查閱和參與。開源并非僅僅是將源碼發(fā)布出去，同時(shí)還需要付出巨大的精力去進(jìn)行維護(hù)。

Google 的開源史

從經(jīng)驗(yàn)上看，Google過去在總體上雖然不怎么開源，但是卻發(fā)表了很多相關(guān)的論文，比如說對(duì)于業(yè)界很重要的MapReduce、BigTable論文。并不是說Google不愿意開源，否則它也不會(huì)去發(fā)表這類論文，問題是在于開源需要太多的人力和物力了。隨著 Google 的日益壯大，開始在開源社區(qū)擔(dān)負(fù)起一定的責(zé)任。從 Google 開源的發(fā)展中可以看出，Google 最早期的貢獻(xiàn)都是修復(fù)一些 bug。Google 總是最先發(fā)現(xiàn)和修復(fù)難以發(fā)現(xiàn)的 bug，因?yàn)檫@些 bug 只會(huì)在 Google 這樣的規(guī)模中才會(huì)出現(xiàn)。到目前為止，Google 已經(jīng)為 Linux 內(nèi)核貢獻(xiàn)了超過 5000 次補(bǔ)丁。其中有小的補(bǔ)丁也有大的子系統(tǒng)。當(dāng)談到 Google 自己的開源項(xiàng)目時(shí)，目前在 GitHub 中 Google 有超過 3000 個(gè)開源項(xiàng)目。隨著開源項(xiàng)目的驟增，為了方便集中地對(duì)需要開源的代碼進(jìn)行審查，Google 組建了一個(gè)包含 6 個(gè)人的審查團(tuán)隊(duì)，主要任務(wù)是從法律層面審查 Google 內(nèi)部使用開源項(xiàng)目和發(fā)布源碼的合規(guī)性。

如何保持代碼的合法性

為了保持整件事情的合法性，Google 將所有外部的開源代碼存儲(chǔ)在第三方。只有那些擁有 Google 能夠接受的許可證的項(xiàng)目，Google 才允許在內(nèi)部使用。一個(gè) Google 不能接受的許可證的例子是 AGPL（Affero 通用公共許可證），這是一個(gè)互惠許可證，要求那些使用了其中的代碼的項(xiàng)目需要提供一個(gè)項(xiàng)目源碼的鏈接。相比于在一個(gè)較少限制的許可證下自己去書寫代碼重新實(shí)現(xiàn)，或者使用其他的方式，比保證 Google 面向外部的產(chǎn)品中沒有任何 AGPL 代碼的代價(jià)要小得多。對(duì)于那些向 Google 項(xiàng)目貢獻(xiàn)代碼的開發(fā)者，Google 要求他們同意貢獻(xiàn)許可協(xié)議（CLA）。CLA 的主要目的是得 Google 能夠?qū)ω暙I(xiàn)的代碼重新頒布許可證，以及 Google 對(duì)貢獻(xiàn)的代碼有專利許可。即，仍然保留開發(fā)者的代碼的所有權(quán)，開發(fā)者只是另外給了 Google 一個(gè)許可證。