沒有開源,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è)許可證。