你可能从来没有听说已故的Jim Weirich或他开发的软件。但是你几乎肯定会使用过在他研究基础上开发出的各种应用程序。
Weirich为面向对象(面向对象程序设计)脚本语言Ruby创建了几个关键工具，Ruby是Hulu，Kickstarter，Twitter和其他无数主流网站代码的编程语言。Ruby的代码是开源的，这意味着任何人都可以使用它并对其进行修改。 Ruby开发人员兼软件公司Test Double联合创始人Justin Searls说：“Weirich是西方世界Ruby社区的创始人之一。
当Weirich于2014年去世时，Searls注意到没有人再去维护Weirich的一个软件测试工具。这意味着如果其他开发者再向Ruby社区提交关于Ruby语言的错误修复，安全补丁或其他改进，就不会有人批准更改。任何依赖该工具的测试最终都会失败，因为代码会随着时间推移变得过时，并且与新技术不再兼容。
事件凸显了开源软件社区日益关注的一个问题。当程序员过世后他们所编写的代码会怎么样？关于在用户死后其社交媒体账户会发生什么的文章已经写得很多了。但关于程序员过世这个问题没有那么多人关注。部分原因是因为大多数公司和政府所运行的都是商业软件，都有专人维护。但现暂，更多的程序依赖于像Weirich这样的程序员所开发的晦涩难懂但却重要的开源软件。
一些开源项目是众所周知的，如Linux操作系统或Google的人工智能框架TensorFlow。但是这些项目中都依赖于更小的开源代码库。而这些开源代码库又是基于另一个代码库。结果构成了一个复杂的，不为人知的相互依存的软件网络。
这可能会带来很大的问题，如2014年，在OpenSSL中发现了一个被称为“Heartbleed”的安全漏洞，几乎每个处理信用卡或借记卡支付过程的网站都会使用这个开放源代码程序。该软件与大多数Linux版本捆绑在一起，但由几个志愿者维护，他们没有时间或资源进行广泛的安全审计。
在Heartbleed安全漏洞被发现后不久，在另一个常见的开源应用程序Bash中也发现了一个同样的安全问题，这使得无数的Web服务器和其他设备很容易受到攻击。
肯定还有更多未发现的漏洞。 Libraries.io是一个分析软件项目之间关系的团队，其已经确定了超过2,400个开源代码库在其他1000个程序中使用，但是很少受到开源社区的关注。
安全问题只是这个问题的一部分。如果软件库无法及时更新，软件升级后也就无法运行。这意味着在用户在更新了相应软件之后，那些依赖于过期库的应用程序可能无法工作。当维护代码库的开发人员离世或放弃一个项目时，使用该软件的每个人都会受到影响。
去年，当程序员AzerKo ulu从互联网上删除了一个叫做Leftpad的代码库后时，它造成了涟漪效应，据说在Facebook，Netflix和其他很多地方都引起了令人头痛的问题。
巴士系数
一个开源软件的维护者越少，其被孤立的风险就越大。开发者甚至针对这种情况起了一个“病态”的名字：巴士系数，通俗地说即多少关键开发者被巴士撞了，会让项目停摆。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指出，这还有另外一个好处，那就是分配维护项目的工作，以防止开发人员产生倦怠。
原文：https://www.wired.com/story/giving-open-source-projects-life-after-a-developers-death/
译者：网易科技 - 晗冰
