出品
开源中国
文
肖滢
年初，澳大利亚一对兄弟SimonZerner和TobyZerner开始了esoTalk的开发。不幸的是，esoTalk尚处于Alpha阶段，主力开发人员哥哥Simon就在年年中去世。
接替Simon维护和更新esoTalk的，是他弟弟Toby。在README.md文件，写着这么一句话：“esoTalk是TobyZerner为纪念他的兄弟Simon而开发的。”最终，两兄弟留下了一个采用PHP+MySQL开发的，具有非常简单、快速、现代特性的开源论坛系统。
esoTalk的延续是那么地顺其自然。
这就引出了一个话题，如果开源项目的作者去世了，代码由谁来继承？这实际上是两个问题。一是，版权由谁来继承；二是，代码由谁来维护？
通常来说，继承版权和维护代码的不会是同一个人。毕竟，不是每个开源大佬都像Simon一样，有个会写代码的弟弟。
版权问题其实并不那么棘手。如果开源软件只有一个作者，那么版权完全归他所有。如果有多个作者，那么每个代码部分的作者，都拥有该部分的版权。
有遗嘱就按遗嘱执行，没有遗嘱还有著作权法、继承法这样的法律来管。不管由谁继承，都不会过多影响用户使用开源软件。因为开源本身就具有特殊性，项目作者已经通过开源许可证，许可他人任意使用、复制、修改、分发代码，这已经包含了大部分版权所涉及到的权利。
一般来说，作者在贡献之前会已经与项目维护的法律实体，比如基金会、企业，签订贡献者许可协议，将版权分配出去。签了这类协议，别说作者去世了，就是还活着，对交出去的代码，想做些什么也做不了。
所以问题就集中在，项目维护。其实很早就有人想要答案。
未雨绸缪的假设
“如果Guido被公交车撞了？”年6月，有人在新闻组提出了一个假设。GuidovanRossum是Python语言的发明者，同时也是Python社区的领导者。而这里的“公交车”，是许多可能的意外场景之一。
之所以会有这么一个问题，是因为Python对Guido过于依赖。对于想要使用Python的企业来说，就不得不考虑这样一个风险：如果Guido消失了，Python还能活下来吗？商业产品有供应商基于利益继续支持，因此风险较低，但像Python这样的学术研究项目，如果开发人员的兴趣发生变化，或者开始了新工作，不久之后该项目可能会消失。
这个问题不仅让企业用户担心，同时也在Python社区引起了讨论和重视。之后，虽然Guido仍然扮演核心角色，但社区一步步地通过成立基金会、指导委员会等方式来监督Python的未来。
这一讨论影响范围甚广。几年后，有人在Ruby社区提出了一样的问题，“如果创始人Matz被公交车撞了该怎么办”。
Matz表示：“因为Ruby是我的快乐之源(至少在计算机领域是这样)，只要我活着，我就不会放弃对Ruby的控制。”并且他还进行了“提名”：“如果我发生了什么事，欢迎开源。所有的源代码都在那里，我希望ShugoMaeda、GuyDecoux和其他人会继续开发这个解释器。我相信，DaveThomas会告诉社区该走向何方。他和我一样理解Ruby哲学。”
Debian社区在年就认识到，在任何关键职位上，至少应该有两个活跃的人。“多少人被公交车撞到才会导致项目停止，我称之为公交车指数。指数≤是非常糟糕的。”开发人员PetterReinholdtsen表示，对Debian来说，确保特权职位有良好的冗余非常重要。
此外，Debian还主张将权力分散，而不是集中于领导者一人身上。比如，Debian负责人可在特定的领域做出决定，但是须将之交付给另外的技术负责人；民主程序可以罢免项目负责人和推翻负责人的任何决定等等。（详情可查看：开源长老Debian就是这么硬气！）因此当Debian的创始人IanMurdock去世时，社区实现了平稳过渡。
可见，对于贡献者众多，还有基金会、委员会等组织护航的开源项目来说，核心人员的离去并不会带来太大的打击。没有某个特定人物长期把持决策，也就没有人能在社区引起动荡。
这个问题最终被延伸为，如果社区中某一个人拥有的特权过多，在他出现意外之前，应该做些什么来保证项目正常运转。
鉴于Linus在Linux社区的独裁统治，所以大家关心的问题也就变成了：如果Linus被公交车撞了？
小众项目续命难
不是所有项目都像Python、Ruby一样这么幸运。对于较为小众的开源项目来说，创始人去世后，想要续命并不容易。
web.py是一个用于Python的轻量级web框架，年初，创始人AaronSwartz自杀身亡。在此后的三年间，该项目几乎陷入了停滞。GitHub上的web.py仓库虽然有少量的代码提交记录，但再也没有发布新版本。
之后几年，虽有开发者相继接棒进行维护，但web.py的前景也难掩颓意。web.py的命运，会迎来转机吗？或许很难。不论是GitHub上最新的提交记录，还是社区网站上最新的邮件讨论，都停留在年。一年多了，它们仍然静悄悄。
像web.py这样由于主要开发者去世而导致项目搁浅的事情并不鲜见。就连在Ruby社区颇有名望的贡献者JimWeirich去世后，他创建的两个最受欢迎的项目——Rake和Builder，在两年之内都没有新版本发布记录。不过好在最终被人注意到了，Weirich开发的多个开源工具都有了继任者。
还有更多少为人知的开源项目，湮没在时间的长河之中。
这其实跟创始人主动抛弃一个项目面临着一样的问题：代码给交给谁。但又有很大不同，主动意味着有的是时间讨论或计划给它找个好下家。
而没有人维护，那就意味着，如果其他开发人员提交错误修复、安全补丁或其他改进，将没有人批准更改，这个项目很快就会因为代码过时，或者与新技术不兼容而被用户放弃。
一位web.py用户说，将不会在新项目使用web.py，因为它没有得到积极维护。Flask/Werkzeug、Bottle和Tornado基本上填补了相同的“微框架”细分市场，它们明显更好、更现代。
继任者是必要的
有人认为，应该任其自生自灭，因为如果一个开源项目有价值，那么它自然有人继承。但事情并没有这么简单。
一个项目被放弃，尤其是一些被高度使用的底层关键库被放弃，可能会导致数十万个软件应用程序受影响。像Linux或深度学习框架TensorFlow等著名的大项目，都依赖于较小的开源代码库，而这些库又依赖于其他库，从而形成了一个复杂、庞大的软件依赖网络。Libraries.io的分析显示，用于超过个其他程序的开源库多达多个，但它们很少受到开源社区的