文?| 肖瀅

出品 | OSC開源社區(qū)（ID：oschina2013)

2008 年初，澳大利亞一對(duì)兄弟 Simon Zerner 和 Toby Zerner 開始了 esoTalk 的開發(fā)。不幸的是， esoTalk 尚處于 Alpha 階段，主力開發(fā)人員哥哥 Simon 就在 2009 年年中去世。?

接替 Simon 維護(hù)和更新 esoTalk 的，是他弟弟 Toby。在 README.md 文件，寫著這么一句話：“esoTalk 是 Toby Zerner 為紀(jì)念他的兄弟 Simon 而開發(fā)的。”最終，兩兄弟留下了一個(gè)采用 PHP+MySQL 開發(fā)的，具有非常簡(jiǎn)單、快速、現(xiàn)代特性的開源論壇系統(tǒng)。?

esoTalk 的延續(xù)是那么地順其自然。?

這就引出了一個(gè)話題，如果開源項(xiàng)目的作者去世了，代碼由誰(shuí)來(lái)繼承？這實(shí)際上是兩個(gè)問題。一是，版權(quán)由誰(shuí)來(lái)繼承；二是，代碼由誰(shuí)來(lái)維護(hù)？?

通常來(lái)說(shuō)，繼承版權(quán)和維護(hù)代碼的不會(huì)是同一個(gè)人。畢竟，不是每個(gè)開源大佬都像 Simon一樣，有個(gè)會(huì)寫代碼的弟弟。?

版權(quán)問題其實(shí)并不那么棘手。如果開源軟件只有一個(gè)作者，那么版權(quán)完全歸他所有。如果有多個(gè)作者，那么每個(gè)代碼部分的作者，都擁有該部分的版權(quán)。?

有遺囑就按遺囑執(zhí)行，沒有遺囑還有著作權(quán)法、繼承法這樣的法律來(lái)管。不管由誰(shuí)繼承，都不會(huì)過多影響用戶使用開源軟件。因?yàn)殚_源本身就具有特殊性，項(xiàng)目作者已經(jīng)通過開源許可證，許可他人任意使用、復(fù)制、修改、分發(fā)代碼，這已經(jīng)包含了大部分版權(quán)所涉及到的權(quán)利。?

一般來(lái)說(shuō)，作者在貢獻(xiàn)之前會(huì)已經(jīng)與項(xiàng)目維護(hù)的法律實(shí)體，比如基金會(huì)、企業(yè)，簽訂貢獻(xiàn)者許可協(xié)議，將版權(quán)分配出去。簽了這類協(xié)議，別說(shuō)作者去世了，就是還活著，對(duì)交出去的代碼，想做些什么也做不了。（詳情可查看：貢獻(xiàn)者許可協(xié)議（CLA），是開源開發(fā)者的保護(hù)傘還是枷鎖？）?

所以問題就集中在，項(xiàng)目維護(hù)。其實(shí)很早就有人想要答案。?

未雨綢繆的假設(shè)?

“如果 Guido 被公交車撞了？”1994 年 6 月，有人在新聞組提出了一個(gè)假設(shè)。Guido van Rossum 是 Python 語(yǔ)言的發(fā)明者，同時(shí)也是 Python 社區(qū)的領(lǐng)導(dǎo)者。而這里的“公交車”，是許多可能的意外場(chǎng)景之一。?

?

之所以會(huì)有這么一個(gè)問題，是因?yàn)?Python 對(duì) Guido 過于依賴。對(duì)于想要使用 Python 的企業(yè)來(lái)說(shuō)，就不得不考慮這樣一個(gè)風(fēng)險(xiǎn)：如果 Guido 消失了，Python 還能活下來(lái)嗎？商業(yè)產(chǎn)品有供應(yīng)商基于利益繼續(xù)支持，因此風(fēng)險(xiǎn)較低，但像 Python 這樣的學(xué)術(shù)研究項(xiàng)目，如果開發(fā)人員的興趣發(fā)生變化，或者開始了新工作，不久之后該項(xiàng)目可能會(huì)消失。?

這個(gè)問題不僅讓企業(yè)用戶擔(dān)心，同時(shí)也在 Python 社區(qū)引起了討論和重視。之后，雖然 Guido 仍然扮演核心角色，但社區(qū)一步步地通過成立基金會(huì)、指導(dǎo)委員會(huì)等方式來(lái)監(jiān)督 Python 的未來(lái)。?

這一討論影響范圍甚廣。幾年后，有人在 Ruby 社區(qū)提出了一樣的問題，“如果創(chuàng)始人 Matz 被公交車撞了該怎么辦”。?

Matz 表示：“因?yàn)?Ruby 是我的快樂之源(至少在計(jì)算機(jī)領(lǐng)域是這樣)，只要我活著，我就不會(huì)放棄對(duì) Ruby 的控制。”?并且他還進(jìn)行了“提名”?：“如果我發(fā)生了什么事，歡迎開源。所有的源代碼都在那里，我希望 Shugo Maeda、Guy Decoux 和其他人會(huì)繼續(xù)開發(fā)這個(gè)解釋器。我相信，Dave Thomas 會(huì)告訴社區(qū)該走向何方。他和我一樣理解 Ruby 哲學(xué)。”?

Debian 社區(qū)在 2005 年就認(rèn)識(shí)到，在任何關(guān)鍵職位上，至少應(yīng)該有兩個(gè)活躍的人。“多少人被公交車撞到才會(huì)導(dǎo)致項(xiàng)目停止，我稱之為公交車指數(shù)。指數(shù)≤1 是非常糟糕的。”開發(fā)人員 Petter Reinholdtsen 表示，對(duì) Debian 來(lái)說(shuō)，確保特權(quán)職位有良好的冗余非常重要。?

此外，Debian 還主張將權(quán)力分散，而不是集中于領(lǐng)導(dǎo)者一人身上。比如，Debian 負(fù)責(zé)人可在特定的領(lǐng)域做出決定，但是須將之交付給另外的技術(shù)負(fù)責(zé)人；民主程序可以罷免項(xiàng)目負(fù)責(zé)人和推翻負(fù)責(zé)人的任何決定等等。（詳情可查看：開源長(zhǎng)老 Debian 就是這么硬氣！）因此當(dāng) Debian 的創(chuàng)始人 Ian Murdock 去世時(shí)，社區(qū)實(shí)現(xiàn)了平穩(wěn)過渡。?

可見，對(duì)于貢獻(xiàn)者眾多，還有基金會(huì)、委員會(huì)等組織護(hù)航的開源項(xiàng)目來(lái)說(shuō)，核心人員的離去并不會(huì)帶來(lái)太大的打擊。沒有某個(gè)特定人物長(zhǎng)期把持決策，也就沒有人能在社區(qū)引起動(dòng)蕩。?

這個(gè)問題最終被延伸為，如果社區(qū)中某一個(gè)人擁有的特權(quán)過多，在他出現(xiàn)意外之前，應(yīng)該做些什么來(lái)保證項(xiàng)目正常運(yùn)轉(zhuǎn)。?

鑒于 Linus 在 Linux 社區(qū)的獨(dú)裁統(tǒng)治，所以大家關(guān)心的問題也就變成了：如果 Linus 被公交車撞了？?

小眾項(xiàng)目續(xù)命難?

不是所有項(xiàng)目都像 Python、Ruby 一樣這么幸運(yùn)。對(duì)于較為小眾的開源項(xiàng)目來(lái)說(shuō)，創(chuàng)始人去世后，想要續(xù)命并不容易。

web.py 是一個(gè)用于 Python 的輕量級(jí) web 框架，2013 年初，創(chuàng)始人 Aaron Swartz 自殺身亡。在此后的三年間，該項(xiàng)目幾乎陷入了停滯。GitHub 上的 web.py 倉(cāng)庫(kù)雖然有少量的代碼提交記錄，但再也沒有發(fā)布新版本。?

之后幾年，雖有開發(fā)者相繼接棒進(jìn)行維護(hù)，但 web.py 的前景也難掩頹意。web.py 的命運(yùn)，會(huì)迎來(lái)轉(zhuǎn)機(jī)嗎？或許很難。不論是 GitHub 上最新的提交記錄，還是社區(qū)網(wǎng)站上最新的郵件討論，都停留在 2020 年。一年多了，它們?nèi)匀混o悄悄。?

像 web.py 這樣由于主要開發(fā)者去世而導(dǎo)致項(xiàng)目擱淺的事情并不鮮見。就連在 Ruby 社區(qū)頗有名望的貢獻(xiàn)者?Jim Weirich 去世后，他創(chuàng)建的兩個(gè)最受歡迎的項(xiàng)目—— Rake 和 Builder，在兩年之內(nèi)都沒有新版本發(fā)布記錄。不過好在最終被人注意到了，Weirich 開發(fā)的多個(gè)開源工具都有了繼任者。?

還有更多少為人知的開源項(xiàng)目，湮沒在時(shí)間的長(zhǎng)河之中。?

這其實(shí)跟創(chuàng)始人主動(dòng)拋棄一個(gè)項(xiàng)目面臨著一樣的問題：代碼給交給誰(shuí)。但又有很大不同，主動(dòng)意味著有的是時(shí)間討論或計(jì)劃給它找個(gè)好下家。?

而沒有人維護(hù)，那就意味著，如果其他開發(fā)人員提交錯(cuò)誤修復(fù)、安全補(bǔ)丁或其他改進(jìn)，將沒有人批準(zhǔn)更改，這個(gè)項(xiàng)目很快就會(huì)因?yàn)榇a過時(shí)，或者與新技術(shù)不兼容而被用戶放棄。?

一位 web.py 用戶說(shuō)，將不會(huì)在新項(xiàng)目使用 web.py，因?yàn)樗鼪]有得到積極維護(hù)。Flask/Werkzeug、Bottle 和 Tornado 基本上填補(bǔ)了相同的“微框架”細(xì)分市場(chǎng)，它們明顯更好、更現(xiàn)代。?

繼任者是必要的?

有人認(rèn)為，應(yīng)該任其自生自滅，因?yàn)槿绻粋€(gè)開源項(xiàng)目有價(jià)值，那么它自然有人繼承。但事情并沒有這么簡(jiǎn)單。?

一個(gè)項(xiàng)目被放棄，尤其是一些被高度使用的底層關(guān)鍵庫(kù)被放棄，可能會(huì)導(dǎo)致數(shù)十萬(wàn)個(gè)軟件應(yīng)用程序受影響。像?Linux 或深度學(xué)習(xí)框架 TensorFlow 等著名的大項(xiàng)目，都依賴于較小的開源代碼庫(kù)，而這些庫(kù)又依賴于其他庫(kù)，從而形成了一個(gè)復(fù)雜、龐大的軟件依賴網(wǎng)絡(luò)。Libraries.io 的分析顯示，用于超過 1000 個(gè)其他程序的開源庫(kù)多達(dá) 2400 多個(gè)，但它們很少受到開源社區(qū)的關(guān)注。?

Debian 10 buster 服務(wù)器軟件包依賴關(guān)系?

因此，為那些因開發(fā)者突遭變故而被拋棄的開源項(xiàng)目找到繼任者是很有必要的。在接手 Weirich 遺留的 Rspec-Given 項(xiàng)目之后， Justin Searls 就為自己的開源項(xiàng)目制定了遺囑和繼任計(jì)劃。WIRED?雜志的撰稿人 Klint Finley 認(rèn)為，將版權(quán)轉(zhuǎn)讓給開源組織，比如 Apache 基金會(huì)，也是一個(gè)明智的選擇。?

即使有能力有意愿維護(hù)開源項(xiàng)目，但在實(shí)際操作中可能會(huì)遇到不少麻煩。Klint Finley 記錄了 Searls 在這個(gè)過程中有多難。“GitHub 拒絕讓 Searls 控制 Rspec-Given，因?yàn)?Weirich 沒有為他提供權(quán)限。所以 Searls 不得不創(chuàng)建一個(gè)新的代碼副本，并將其托管在其他地方。他還必須說(shuō)服 Ruby Gems（一個(gè)用于分發(fā)代碼的“包管理系統(tǒng)”）的運(yùn)營(yíng)商使用他的 Rspec-Given 版本，而不是 Weirich 的版本，以便所有用戶都可以訪問 Searls 的更改。GitHub 拒絕討論關(guān)于轉(zhuǎn)移項(xiàng)目控制權(quán)的政策。”?

無(wú)獨(dú)有偶，Luacheck 的繼承也因?yàn)樗袡?quán)轉(zhuǎn)移的問題，拉鋸了兩三年。Luacheck 是一個(gè)用于對(duì) Lua 代碼進(jìn)行 linting 和靜態(tài)分析的工具，創(chuàng)建者 Peter Melnichenko 去世之后，GitHub 上的倉(cāng)庫(kù)就一直處于懸而未決的狀態(tài)。之后，盡管社區(qū)創(chuàng)建了分支，但在 Google 搜索“l(fā)uacheck”，Peter 創(chuàng)建的倉(cāng)庫(kù)仍然是第一個(gè)結(jié)果，直到今天，人們?nèi)栽谙蚺f的倉(cāng)庫(kù)發(fā)布 issue。?

?

幾年前，Searls 曾建議 GitHub 和 Gems 等包管理器可以在他們的平臺(tái)上添加類似“亡者開關(guān)”的東西，萬(wàn)一創(chuàng)建者長(zhǎng)時(shí)間沒有登錄或者修改，系統(tǒng)可以自動(dòng)將項(xiàng)目或帳戶的所有權(quán)轉(zhuǎn)移給其他人。?

“亡者開關(guān)”沒有在 GitHub 實(shí)現(xiàn)。不過， GitHub 在 2020 年 5月新增了一項(xiàng)功能：添加賬戶的繼任者。它允許倉(cāng)庫(kù)所有者在無(wú)法管理的情況下，邀請(qǐng)同平臺(tái)的其他用戶作為繼任者。繼任者雖然不能直接登錄原帳戶，但他們可以將公共倉(cāng)庫(kù)進(jìn)行存檔以及轉(zhuǎn)移。?

GitLab 也正在討論賬戶繼承這一事項(xiàng)。GitLab 表示，這主要是為了應(yīng)對(duì)賬戶所有者去世的情況。盡管初衷是為了解決由于賬戶長(zhǎng)期不使用可能出現(xiàn)的身份盜用或其他與安全相關(guān)的問題，不過同時(shí)也明確了開源倉(cāng)庫(kù)官方繼承的流程。如果能夠提前指定繼任者，Searls 曾經(jīng)面臨的問題不會(huì)再出現(xiàn)。?

“添加繼任者”這一功能不過是掃清了些許障礙，但會(huì)讓開發(fā)者或者開源社區(qū)更早地認(rèn)識(shí)到，未雨綢繆是很有必要的。?

話說(shuō)回來(lái)，最難的還是找到合適的繼任者。倒也不必灰心，不妨把更多的視線拉回到開源這件事情上來(lái)。代碼開源之后，它就有了無(wú)限續(xù)命的可能。假以時(shí)日，會(huì)出現(xiàn)有能力有意愿的開發(fā)者將它們撿起來(lái)并變成自己的。正如 WhiteSource 的首席執(zhí)行官兼聯(lián)合創(chuàng)始人 Rami Sass 所言：“它不屬于任何人，它屬于每個(gè)人。”

END

覺得不錯(cuò)，請(qǐng)點(diǎn)個(gè)在看呀

總結(jié)

以上是生活随笔為你收集整理的开源作者去世后，代码谁来继承？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。