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

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

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

這就引出了一個話題，如果開源項目的作者去世了，代碼由誰來繼承？這實際上是兩個問題。一是，版權(quán)由誰來繼承；二是，代碼由誰來維護？

通常來說，繼承版權(quán)和維護代碼的不會是同一個人。畢竟，不是每個開源大佬都像 Simon一樣，有個會寫代碼的弟弟。

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

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

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

所以問題就集中在，項目維護。其實很早就有人想要答案。

未雨綢繆的假設(shè)

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

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

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

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

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

Debian 社區(qū)在 2005 年就認識到，在任何關(guān)鍵職位上，至少應(yīng)該有兩個活躍的人?！岸嗌偃吮还卉囎驳讲艜?dǎo)致項目停止，我稱之為公交車指數(shù)。指數(shù)≤1 是非常糟糕的?！遍_發(fā)人員 Petter Reinholdtsen 表示，對 Debian 來說，確保特權(quán)職位有良好的冗余非常重要。

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

可見，對于貢獻者眾多，還有基金會、委員會等組織護航的開源項目來說，核心人員的離去并不會帶來太大的打擊。沒有某個特定人物長期把持決策，也就沒有人能在社區(qū)引起動蕩。

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

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

小眾項目續(xù)命難

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

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

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

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

還有更多少為人知的開源項目，湮沒在時間的長河之中。

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

而沒有人維護，那就意味著，如果其他開發(fā)人員提交錯誤修復(fù)、安全補丁或其他改進，將沒有人批準更改，這個項目很快就會因為代碼過時，或者與新技術(shù)不兼容而被用戶放棄。

一位 web.py 用戶說，將不會在新項目使用 web.py，因為它沒有得到積極維護。Flask/Werkzeug、Bottle 和 Tornado 基本上填補了相同的“微框架”細分市場，它們明顯更好、更現(xiàn)代。

繼任者是必要的

有人認為，應(yīng)該任其自生自滅，因為如果一個開源項目有價值，那么它自然有人繼承。但事情并沒有這么簡單。

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

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

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

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

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

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

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

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

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

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

關(guān)鍵詞：