软件开发者死后，他的开源项目会有人继续维护吗？

　　你可能从来没有听说已故的 软件开发者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指出，这还有另外一个好处，那就是分配维护项目的工作，以防止开发人员产生倦怠。