2008 年初，澳大利亞一對兄弟 Simon Zerner 和 Toby Zerner 開始了 esoTalk 的開發(fā)。不幸的是， esoTalk 尚處于 Alpha 階段，主力開發(fā)人員哥哥 Simon 就在 2009 年年中去世。
接替 Simon 維護(hù)和更新 esoTalk 的，是他弟弟 Toby。在 README.md 文件，寫著這么一句話：“esoTalk 是 Toby Zerner 為紀(jì)念他的兄弟 Simon 而開發(fā)的?！弊罱K，兩兄弟留下了一個(gè)采用 PHP+MySQL 開發(fā)的，具有非常簡單、快速、現(xiàn)代特性的開源論壇系統(tǒng)。
esoTalk 的延續(xù)是那么地順其自然。
這就引出了一個(gè)話題，如果開源項(xiàng)目的作者去世了，代碼由誰來繼承？這實(shí)際上是兩個(gè)問題。一是，版權(quán)由誰來繼承；二是，代碼由誰來維護(hù)？
通常來說，繼承版權(quán)和維護(hù)代碼的不會是同一個(gè)人。畢竟，不是每個(gè)開源大佬都像 Simon一樣，有個(gè)會寫代碼的弟弟。
版權(quán)問題其實(shí)并不那么棘手。如果開源軟件只有一個(gè)作者，那么版權(quán)完全歸他所有。如果有多個(gè)作者，那么每個(gè)代碼部分的作者，都擁有該部分的版權(quán)。
有遺囑就按遺囑執(zhí)行，沒有遺囑還有著作權(quán)法、繼承法這樣的法律來管。不管由誰繼承，都不會過多影響用戶使用開源軟件。因?yàn)殚_源本身就具有特殊性，項(xiàng)目作者已經(jīng)通過開源許可證，許可他人任意使用、復(fù)制、修改、分發(fā)代碼，這已經(jīng)包含了大部分版權(quán)所涉及到的權(quán)利。
一般來說，作者在貢獻(xiàn)之前會已經(jīng)與項(xiàng)目維護(hù)的法律實(shí)體，比如基金會、企業(yè)，簽訂貢獻(xiàn)者許可協(xié)議，將版權(quán)分配出去。簽了這類協(xié)議，別說作者去世了，就是還活著，對交出去的代碼，想做些什么也做不了。（詳情可查看：貢獻(xiàn)者許可協(xié)議（CLA），是開源開發(fā)者的保護(hù)傘還是枷鎖？）
所以問題就集中在，項(xiàng)目維護(hù)。其實(shí)很早就有人想要答案。
“如果 Guido 被公交車撞了？”1994 年 6 月，有人在新聞組提出了一個(gè)假設(shè)。Guido van Rossum 是 Python 語言的發(fā)明者，同時(shí)也是 Python 社區(qū)的領(lǐng)導(dǎo)者。而這里的“公交車”，是許多可能的意外場景之一。
之所以會有這么一個(gè)問題，是因?yàn)?Python 對 Guido 過于依賴。對于想要使用 Python 的企業(yè)來說，就不得不考慮這樣一個(gè)風(fēng)險(xiǎn)：如果 Guido 消失了，Python 還能活下來嗎？商業(yè)產(chǎn)品有供應(yīng)商基于利益繼續(xù)支持，因此風(fēng)險(xiǎn)較低，但像 Python 這樣的學(xué)術(shù)研究項(xiàng)目，如果開發(fā)人員的興趣發(fā)生變化，或者開始了新工作，不久之后該項(xiàng)目可能會消失。
這個(gè)問題不僅讓企業(yè)用戶擔(dān)心，同時(shí)也在 Python 社區(qū)引起了討論和重視。之后，雖然 Guido 仍然扮演核心角色，但社區(qū)一步步地通過成立基金會、指導(dǎo)委員會等方式來監(jiān)督 Python 的未來。
這一討論影響范圍甚廣。幾年后，有人在 Ruby 社區(qū)提出了一樣的問題，“如果創(chuàng)始人 Matz 被公交車撞了該怎么辦”。
Matz 表示：“因?yàn)?Ruby 是我的快樂之源(至少在計(jì)算機(jī)領(lǐng)域是這樣)，只要我活著，我就不會放棄對 Ruby 的控制?！辈⑶宜€進(jìn)行了“提名”：“如果我發(fā)生了什么事，歡迎開源。所有的源代碼都在那里，我希望 Shugo Maeda、Guy Decoux 和其他人會繼續(xù)開發(fā)這個(gè)解釋器。我相信，Dave Thomas 會告訴社區(qū)該走向何方。他和我一樣理解 Ruby 哲學(xué)?！?/p>
Debian 社區(qū)在 2005 年就認(rèn)識到，在任何關(guān)鍵職位上，至少應(yīng)該有兩個(gè)活躍的人?！岸嗌偃吮还卉囎驳讲艜?dǎo)致項(xiàng)目停止，我稱之為公交車指數(shù)。指數(shù)≤1 是非常糟糕的。”開發(fā)人員 Petter Reinholdtsen 表示，對 Debian 來說，確保特權(quán)職位有良好的冗余非常重要。
此外，Debian 還主張將權(quán)力分散，而不是集中于領(lǐng)導(dǎo)者一人身上。比如，Debian 負(fù)責(zé)人可在特定的領(lǐng)域做出決定，但是須將之交付給另外的技術(shù)負(fù)責(zé)人；民主程序可以罷免項(xiàng)目負(fù)責(zé)人和推翻負(fù)責(zé)人的任何決定等等。（詳情可查看：開源長老 Debian 就是這么硬氣?。┮虼水?dāng) Debian 的創(chuàng)始人 Ian Murdock 去世時(shí)，社區(qū)實(shí)現(xiàn)了平穩(wěn)過渡。
可見，對于貢獻(xiàn)者眾多，還有基金會、委員會等組織護(hù)航的開源項(xiàng)目來說，核心人員的離去并不會帶來太大的打擊。沒有某個(gè)特定人物長期把持決策，也就沒有人能在社區(qū)引起動蕩。
這個(gè)問題最終被延伸為，如果社區(qū)中某一個(gè)人擁有的特權(quán)過多，在他出現(xiàn)意外之前，應(yīng)該做些什么來保證項(xiàng)目正常運(yùn)轉(zhuǎn)。
鑒于 Linus 在 Linux 社區(qū)的獨(dú)裁統(tǒng)治，所以大家關(guān)心的問題也就變成了：如果 Linus 被公交車撞了？
不是所有項(xiàng)目都像 Python、Ruby 一樣這么幸運(yùn)。對于較為小眾的開源項(xiàng)目來說，創(chuàng)始人去世后，想要續(xù)命并不容易。
web.py 是一個(gè)用于 Python 的輕量級 web 框架，2013 年初，創(chuàng)始人 Aaron Swartz 自殺身亡。在此后的三年間，該項(xiàng)目幾乎陷入了停滯。GitHub 上的 web.py 倉庫雖然有少量的代碼提交記錄，但再也沒有發(fā)布新版本。
之后幾年，雖有開發(fā)者相繼接棒進(jìn)行維護(hù)，但 web.py 的前景也難掩頹意。web.py 的命運(yùn)，會迎來轉(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í)間的長河之中。
這其實(shí)跟創(chuàng)始人主動拋棄一個(gè)項(xiàng)目面臨著一樣的問題：代碼給交給誰。但又有很大不同，主動意味著有的是時(shí)間討論或計(jì)劃給它找個(gè)好下家。
而沒有人維護(hù)，那就意味著，如果其他開發(fā)人員提交錯誤修復(fù)、安全補(bǔ)丁或其他改進(jìn)，將沒有人批準(zhǔn)更改，這個(gè)項(xiàng)目很快就會因?yàn)榇a過時(shí)，或者與新技術(shù)不兼容而被用戶放棄。
一位 web.py 用戶說，將不會在新項(xiàng)目使用 web.py，因?yàn)樗鼪]有得到積極維護(hù)。Flask/Werkzeug、Bottle 和 Tornado 基本上填補(bǔ)了相同的“微框架”細(xì)分市場，它們明顯更好、更現(xiàn)代。
有人認(rèn)為，應(yīng)該任其自生自滅，因?yàn)槿绻粋€(gè)開源項(xiàng)目有價(jià)值，那么它自然有人繼承。但事情并沒有這么簡單。
一個(gè)項(xiàng)目被放棄，尤其是一些被高度使用的底層關(guān)鍵庫被放棄，可能會導(dǎo)致數(shù)十萬個(gè)軟件應(yīng)用程序受影響。像Linux 或深度學(xué)習(xí)框架 TensorFlow 等著名的大項(xiàng)目，都依賴于較小的開源代碼庫，而這些庫又依賴于其他庫，從而形成了一個(gè)復(fù)雜、龐大的軟件依賴網(wǎng)絡(luò)。Libraries.io 的分析顯示，用于超過 1000 個(gè)其他程序的開源庫多達(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 基金會，也是一個(gè)明智的選擇。
即使有能力有意愿維護(hù)開源項(xiàng)目，但在實(shí)際操作中可能會遇到不少麻煩。Klint Finley 記錄了 Searls 在這個(gè)過程中有多難?！癎itHub 拒絕讓 Searls 控制 Rspec-Given，因?yàn)?Weirich 沒有為他提供權(quán)限。所以 Searls 不得不創(chuàng)建一個(gè)新的代碼副本，并將其托管在其他地方。他還必須說服 Ruby Gems（一個(gè)用于分發(fā)代碼的“包管理系統(tǒng)”）的運(yùn)營商使用他的 Rspec-Given 版本，而不是 Weirich 的版本，以便所有用戶都可以訪問 Searls 的更改。GitHub 拒絕討論關(guān)于轉(zhuǎn)移項(xiàng)目控制權(quán)的政策?！?/p>
無獨(dú)有偶，Luacheck 的繼承也因?yàn)樗袡?quán)轉(zhuǎn)移的問題，拉鋸了兩三年。Luacheck 是一個(gè)用于對 Lua 代碼進(jìn)行 linting 和靜態(tài)分析的工具，創(chuàng)建者 Peter Melnichenko 去世之后，GitHub 上的倉庫就一直處于懸而未決的狀態(tài)。之后，盡管社區(qū)創(chuàng)建了分支，但在 Google 搜索“l(fā)uacheck”，Peter 創(chuàng)建的倉庫仍然是第一個(gè)結(jié)果，直到今天，人們?nèi)栽谙蚺f的倉庫發(fā)布 issue。
幾年前，Searls 曾建議 GitHub 和 Gems 等包管理器可以在他們的平臺上添加類似“亡者開關(guān)”的東西，萬一創(chuàng)建者長時(shí)間沒有登錄或者修改，系統(tǒng)可以自動將項(xiàng)目或帳戶的所有權(quán)轉(zhuǎn)移給其他人。
“亡者開關(guān)”沒有在 GitHub 實(shí)現(xiàn)。不過， GitHub 在 2020 年 5月新增了一項(xiàng)功能：添加賬戶的繼任者。它允許倉庫所有者在無法管理的情況下，邀請同平臺的其他用戶作為繼任者。繼任者雖然不能直接登錄原帳戶，但他們可以將公共倉庫進(jìn)行存檔以及轉(zhuǎn)移。
GitLab 也正在討論賬戶繼承這一事項(xiàng)。GitLab 表示，這主要是為了應(yīng)對賬戶所有者去世的情況。盡管初衷是為了解決由于賬戶長期不使用可能出現(xiàn)的身份盜用或其他與安全相關(guān)的問題，不過同時(shí)也明確了開源倉庫官方繼承的流程。如果能夠提前指定繼任者，Searls 曾經(jīng)面臨的問題不會再出現(xiàn)。
“添加繼任者”這一功能不過是掃清了些許障礙，但會讓開發(fā)者或者開源社區(qū)更早地認(rèn)識到，未雨綢繆是很有必要的。
話說回來，最難的還是找到合適的繼任者。倒也不必灰心，不妨把更多的視線拉回到開源這件事情上來。代碼開源之后，它就有了無限續(xù)命的可能。假以時(shí)日，會出現(xiàn)有能力有意愿的開發(fā)者將它們撿起來并變成自己的。正如 WhiteSource 的首席執(zhí)行官兼聯(lián)合創(chuàng)始人 Rami Sass 所言：“它不屬于任何人，它屬于每個(gè)人?！?/p>
