你可能從來沒有聽說已故的 Jim Weirich 或他開發的軟體。但是你幾乎肯定會使用過在他研究基礎上開發出的各種應用程式。

Weirich 為 Ruby 建立了幾個關鍵工具，Ruby 是 Hulu、Kickstarter、Twitter和其他無數主流網站程式碼的程式語言。Ruby 的程式碼是開源的，這意味著任何人都可以使用它並對其進行修改。 Ruby 開發者兼軟體公司 Test Double 聯合創始人 Justin Searls 說：“Weirich 是西方世界 Ruby 社群的創始人之一。

當 Weirich 於 2014 年去世時，Searls 注意到沒有人再去維護 Weirich 的一個軟體測試工具。這意味著如果其他開發者再向 Ruby 社群提交關於 Ruby 語言的錯誤修復，安全補丁或其他改進，就不會有人批准更改。任何依賴該工具的測試最終都會失敗，因為程式碼會隨著時間推移變得過時，並且與新技術不再相容。

伯樂線上轉載補充：Jim Weirich 出生於 1956 年 11 月 18 日，他的 GitHub 活動記錄停止於 2014 年 2 月 19 日。

前文提到他給 Ruby 做了一些的關鍵工具，包括了他給 Ruby 開發的 build 工具 Rake。在 Weirich 離世後，Rake 已移交到 Ruby 官方。

事件凸顯了開源軟體社群日益關注的一個問題。當程式設計師過世後他們所編寫的程式碼會怎麼樣？關於在使用者死後其社交媒體賬戶會發生什麼的文章已經寫得很多了。但關於程式設計師過世這個問題沒有那麼多人關注。部分原因是因為大多數公司和政府所執行的都是商業軟體，都有專人維護。但現在，更多的程式依賴於像 Weirich 這樣的程式設計師所開發的晦澀難懂但卻重要的開源軟體。

一些開源專案是眾所周知的，如 Linux 作業系統或 Google 的人工智慧框架 TensorFlow。但是這些專案中都依賴於更小的開原始碼庫。而這些開原始碼庫又是基於另一個程式碼庫。結果構成了一個複雜的，不為人知的相互依存的軟體網路。

這可能會帶來很大的問題，如 2014 年在 OpenSSL 中發現了一個被稱為“Heartbleed”的安全漏洞，幾乎每個處理信用卡或借記卡支付過程的網站都會使用這個開放原始碼程式。該軟體與大多數Linux版本捆綁在一起，但由幾個志願者維護，他們沒有時間或資源進行廣泛的安全審查。在 Heartbleed 安全漏洞被發現後不久，在另一個常見的開源應用程式 Bash 中也發現了一個同樣的安全問題，這使得無數的 Web 伺服器和其他裝置很容易受到攻擊。

肯定還有更多未發現的漏洞。 Libraries.io 是一個分析軟體專案之間關係的團隊，其已經確定了超過 2,400 個開原始碼庫在其他 1000 個程式中使用，但是很少受到開源社群的關注。

安全問題只是這個問題的一部分。如果軟體庫無法及時更新，軟體升級後也就無法執行。這意味著在使用者在更新了相應軟體之後，那些依賴於過期庫的應用程式可能無法工作。當維護程式碼庫的開發人員離世或放棄一個專案時，使用該軟體的每個人都會受到影響。去年，當程式設計師 Azer Koçulu 從網際網路上刪除了一個叫做 Leftpad 的程式碼庫後時，它造成了漣漪效應，據說在 Facebook、Netflix和其他很多地方都引起了令人頭痛的問題。

伯樂線上轉載補充：2016 年 3 月 23 日凌晨，NPM 社群的貢獻者 Azer Koçulu 出於對 NPM 管理層的不滿，默默地刪除了自己所有模組，其中就包含只有 11 行程式碼的“Left-pad”。這個 Leftpad 被其他庫高度依賴，所以它被廣泛引用。這一刪除，導致導致Babel、ReactNative、Ember等大量工具構建失敗，整個 Nodejs 社群都炸開鍋了。

巴士係數

一個開源軟體的維護者越少，其被孤立的風險就越大。開發者甚至針對這種情況起了一個“病態”的名字：巴士係數，通俗地說即多少關鍵開發者被巴士撞了，會讓專案停擺。Libraries.io 已經確定了大約 3000 個開源庫，在許多其他程式中使用，但只有極少數的人在默默貢獻。

巴士係數：一個專案至少失去若干關鍵成員的參與（“被巴士撞了”，指代職業和生活方式變動、婚育、意外傷亡等任意導致缺席的緣由）即導致專案陷入混亂、癱瘓而無法存續時，這些成員的數量即為巴士係數。

伯樂線上轉註：巴士係數是指一個專案在失去多少關鍵開發者後會癱瘓，失去關鍵開發者的最少數量就是卡車/巴士係數。係數越高，意味著一個專案在發生嚴重事故後仍然有足夠的人能帶領專案繼續前進。開發者退出有一個短語形容——被卡車/巴士撞了，意思是職業和生活方式變動、婚育、意外傷亡等導致他們停止參與一個開源專案。

專案孤立是使用開源軟體的風險，但商業軟體製造商也可能會停止支援或更新舊程式，從而給使用者帶來同樣的麻煩。在某些情況下，別有用心的程式設計師會採用孤立的開原始碼。

這就是 Searls 在處理 Weirich 開源專案中遇到的一個問題。 Weirich 最受歡迎的專案在他去世的時候有共同管理者。但是 Searls 注意到一個測試工具 Rspec-Given 沒有被移交出去，他有意負責更新，但一路上遇到了不少麻煩。

Rspec-Given 的程式碼託管在程式碼託管和協作站點 GitHub 上，後者目前擁有 6700 萬個程式碼庫。 Weirich 在 GitHub 上的 Rspec-Given 頁面是其他 Ruby 使用者報告錯誤或自願幫助改進程式碼的主要地方。但 GitHub 不會讓 Searls 控制這個頁面，因為 Weirich 在他去世之前還沒有進行命名。所以 Searls 必須建立一個新的程式碼副本，並將其轉移到其他地方。他還必須說服分發程式碼的“包管理系統”Ruby Gems運營商使用他的 Rspec-Given 版本，而不再是 Weirich 的版本，以便使所有使用者都能訪問的變更。 GitHub 拒絕討論其關於轉移專案控制的政策。

相關方法能夠解決與Rspec-Given有關的潛在問題，但是它也讓Searls看到了許多可能出潛在問題。 Searls說：“我們很容易將開源看作一種純粹的技術現象。但是，一旦有些事情產生，並且被其他人所依賴，這也是一種社會現象。”

大多數軟體包管理系統的維護人員至少有一個專門的流程來轉移對庫的控制權，但是這個過程通常取決於是否有人能夠注意到專案已經被孤立，然後自願接管它。 Ruby Gems專案的Evan Phoenix說：“我們沒有官方政策，主要是因為它不會經常出現。 “我們有一個顧問委員會，用來逐個處理這種型別的事情。”

現在，一些軟體包管理人員會監視他們的庫執行狀態，並標記那些很久沒有更新且使用頻繁的專案。協助維護程式語言Perl軟體包管理器的Neil Bowers說，他有時候會尋找志願者接管孤立專案。鮑爾斯說，他的小組時常會指出，一個專案已經被開發者放棄，並推薦接管人。

一個“去世開關”

Searls接管Rspec-Given時只有30歲，他為自己的開源專案制定了遺囑和繼任計劃。除此之外，開發人員還可以針對未來做出其他努力。例如，他們可以將版權轉讓給諸如Apache基金會等其他組織。但是許多開源專案本質上是以業餘愛好開始的，所以程式設計師可能不會想到轉移所有權，想到時已經為時已晚。

Searls認為，GitHub和Gems等軟體包管理者可以在他們的平臺上新增一個類似於“去世開關”的東西，如果建立者沒有登入或者長時間沒有更新，程式可以自動將專案或者帳戶的所有權轉讓給其他人。

而過渡計劃不僅僅是讓人們能夠訪問程式碼。Matplotlib 是一個 Python 編寫的 2D 數字繪相簿，在創始人約翰·亨特（John Hunter）於 2012 年去世後，Michael Droettboom 進行了接管。他指出，繼任者也需要了解這些程式碼。他說：“有時候只有一個人可以理解部分程式碼。知識只存在於一個人的頭腦中。”

這意味著理想情況是，一旦專案被原始開發人員以外的人使用，就需要讓其他人儘早參與一個專案。 Searls指出，這還有另外一個好處，那就是分配維護專案的工作，以防止開發人員產生倦怠。