文 | 肖滢
出品 | OSC开源社区（ID：oschina2013)
2008 年初，澳大利亚一对兄弟 Simon Zerner 和 Toby Zerner 开始了 esoTalk 的开发。不幸的是， esoTalk 尚处于 Alpha 阶段，主力开发人员哥哥 Simon 就在 2009 年年中去世。 接替 Simon 维护和更新 esoTalk 的，是他弟弟 Toby。在 README.md 文件，写着这么一句话：“esoTalk 是 Toby Zerner 为纪念他的兄弟 Simon 而开发的。”最终，两兄弟留下了一个采用 PHP+MySQL 开发的，具有非常简单、快速、现代特性的开源论坛系统。 这就引出了一个话题，如果开源项目的作者去世了，代码由谁来继承？这实际上是两个问题。一是，版权由谁来继承；二是，代码由谁来维护？ 通常来说，继承版权和维护代码的不会是同一个人。毕竟，不是每个开源大佬都像 Simon一样，有个会写代码的弟弟。 版权问题其实并不那么棘手。如果开源软件只有一个作者，那么版权完全归他所有。如果有多个作者，那么每个代码部分的作者，都拥有该部分的版权。 有遗嘱就按遗嘱执行，没有遗嘱还有著作权法、继承法这样的法律来管。不管由谁继承，都不会过多影响用户使用开源软件。因为开源本身就具有特殊性，项目作者已经通过开源许可证，许可他人任意使用、复制、修改、分发代码，这已经包含了大部分版权所涉及到的权利。 所以问题就集中在，项目维护。其实很早就有人想要答案。 “如果 Guido 被公交车撞了？”1994 年 6 月，有人在新闻组提出了一个假设。Guido van Rossum 是 Python 语言的发明者，同时也是 Python 社区的领导者。而这里的“公交车”，是许多可能的意外场景之一。 之所以会有这么一个问题，是因为 Python 对 Guido 过于依赖。对于想要使用 Python 的企业来说，就不得不考虑这样一个风险：如果 Guido 消失了，Python 还能活下来吗？商业产品有供应商基于利益继续支持，因此风险较低，但像 Python 这样的学术研究项目，如果开发人员的兴趣发生变化，或者开始了新工作，不久之后该项目可能会消失。 这个问题不仅让企业用户担心，同时也在 Python 社区引起了讨论和重视。之后，虽然 Guido 仍然扮演核心角色，但社区一步步地通过成立基金会、指导委员会等方式来监督 Python 的未来。 这一讨论影响范围甚广。几年后，有人在 Ruby 社区提出了一样的问题，“如果创始人 Matz 被公交车撞了该怎么办”。 Matz 表示：“因为 Ruby 是我的快乐之源(至少在计算机领域是这样)，只要我活着，我就不会放弃对 Ruby 的控制。” 并且他还进行了“提名” ：“如果我发生了什么事，欢迎开源。所有的源代码都在那里，我希望 Shugo Maeda、Guy Decoux 和其他人会继续开发这个解释器。我相信，Dave Thomas 会告诉社区该走向何方。他和我一样理解 Ruby 哲学。” Debian 社区在 2005 年就认识到，在任何关键职位上，至少应该有两个活跃的人。“多少人被公交车撞到才会导致项目停止，我称之为公交车指数。指数≤1 是非常糟糕的。”开发人员 Petter Reinholdtsen 表示，对 Debian 来说，确保特权职位有良好的冗余非常重要。 此外，Debian 还主张将权力分散，而不是集中于领导者一人身上。比如，Debian 负责人可在特定的领域做出决定，但是须将之交付给另外的技术负责人；民主程序可以罢免项目负责人和推翻负责人的任何决定等等。（详情可查看：开源长老 Debian 就是这么硬气！）因此当 Debian 的创始人 Ian Murdock 去世时，社区实现了平稳过渡。 可见，对于贡献者众多，还有基金会、委员会等组织护航的开源项目来说，核心人员的离去并不会带来太大的打击。没有某个特定人物长期把持决策，也就没有人能在社区引起动荡。 这个问题最终被延伸为，如果社区中某一个人拥有的特权过多，在他出现意外之前，应该做些什么来保证项目正常运转。 鉴于 Linus 在 Linux 社区的独裁统治，所以大家关心的问题也就变成了：如果 Linus 被公交车撞了？ 不是所有项目都像 Python、Ruby 一样这么幸运。对于较为小众的开源项目来说，创始人去世后，想要续命并不容易。web.py 是一个用于 Python 的轻量级 web 框架，2013 年初，创始人 Aaron Swartz 自杀身亡。在此后的三年间，该项目几乎陷入了停滞。GitHub 上的 web.py 仓库虽然有少量的代码提交记录，但再也没有发布新版本。 之后几年，虽有开发者相继接棒进行维护，但 web.py 的前景也难掩颓意。web.py 的命运，会迎来转机吗？或许很难。不论是 GitHub 上最新的提交记录，还是社区网站上最新的邮件讨论，都停留在 2020 年。一年多了，它们仍然静悄悄。 像 web.py 这样由于主要开发者去世而导致项目搁浅的事情并不鲜见。就连在 Ruby 社区颇有名望的贡献者 Jim Weirich 去世后，他创建的两个最受欢迎的项目—— Rake 和 Builder，在两年之内都没有新版本发布记录。不过好在最终被人注意到了，Weirich 开发的多个开源工具都有了继任者。 还有更多少为人知的开源项目，湮没在时间的长河之中。 这其实跟创始人主动抛弃一个项目面临着一样的问题：代码给交给谁。但又有很大不同，主动意味着有的是时间讨论或计划给它找个好下家。 而没有人维护，那就意味着，如果其他开发人员提交错误修复、安全补丁或其他改进，将没有人批准更改，这个项目很快就会因为代码过时，或者与新技术不兼容而被用户放弃。 一位 web.py 用户说，将不会在新项目使用 web.py，因为它没有得到积极维护。Flask/Werkzeug、Bottle 和 Tornado 基本上填补了相同的“微框架”细分市场，它们明显更好、更现代。 有人认为，应该任其自生自灭，因为如果一个开源项目有价值，那么它自然有人继承。但事情并没有这么简单。 一个项目被放弃，尤其是一些被高度使用的底层关键库被放弃，可能会导致数十万个软件应用程序受影响。像 Linux 或深度学习框架 TensorFlow 等著名的大项目，都依赖于较小的开源代码库，而这些库又依赖于其他库，从而形成了一个复杂、庞大的软件依赖网络。Libraries.io 的分析显示，用于超过 1000 个其他程序的开源库多达 2400 多个，但它们很少受到开源社区的关注。 Debian 10 buster 服务器软件包依赖关系 因此，为那些因开发者突遭变故而被抛弃的开源项目找到继任者是很有必要的。在接手 Weirich 遗留的 Rspec-Given 项目之后， Justin Searls 就为自己的开源项目制定了遗嘱和继任计划。WIRED 杂志的撰稿人 Klint Finley 认为，将版权转让给开源组织，比如 Apache 基金会，也是一个明智的选择。 即使有能力有意愿维护开源项目，但在实际操作中可能会遇到不少麻烦。Klint Finley 记录了 Searls 在这个过程中有多难。“GitHub 拒绝让 Searls 控制 Rspec-Given，因为 Weirich 没有为他提供权限。所以 Searls 不得不创建一个新的代码副本，并将其托管在其他地方。他还必须说服 Ruby Gems（一个用于分发代码的“包管理系统”）的运营商使用他的 Rspec-Given 版本，而不是 Weirich 的版本，以便所有用户都可以访问 Searls 的更改。GitHub 拒绝讨论关于转移项目控制权的政策。” 无独有偶，Luacheck 的继承也因为所有权转移的问题，拉锯了两三年。Luacheck 是一个用于对 Lua 代码进行 linting 和静态分析的工具，创建者 Peter Melnichenko 去世之后，GitHub 上的仓库就一直处于悬而未决的状态。之后，尽管社区创建了分支，但在 Google 搜索“luacheck”，Peter 创建的仓库仍然是第一个结果，直到今天，人们仍在向旧的仓库发布 issue。 几年前，Searls 曾建议 GitHub 和 Gems 等包管理器可以在他们的平台上添加类似“亡者开关”的东西，万一创建者长时间没有登录或者修改，系统可以自动将项目或帐户的所有权转移给其他人。 “亡者开关”没有在 GitHub 实现。不过， GitHub 在 2020 年 5月新增了一项功能：添加账户的继任者。它允许仓库所有者在无法管理的情况下，邀请同平台的其他用户作为继任者。继任者虽然不能直接登录原帐户，但他们可以将公共仓库进行存档以及转移。 GitLab 也正在讨论账户继承这一事项。GitLab 表示，这主要是为了应对账户所有者去世的情况。尽管初衷是为了解决由于账户长期不使用可能出现的身份盗用或其他与安全相关的问题，不过同时也明确了开源仓库官方继承的流程。如果能够提前指定继任者，Searls 曾经面临的问题不会再出现。 “添加继任者”这一功能不过是扫清了些许障碍，但会让开发者或者开源社区更早地认识到，未雨绸缪是很有必要的。 话说回来，最难的还是找到合适的继任者。倒也不必灰心，不妨把更多的视线拉回到开源这件事情上来。代码开源之后，它就有了无限续命的可能。假以时日，会出现有能力有意愿的开发者将它们捡起来并变成自己的。正如 WhiteSource 的首席执行官兼联合创始人 Rami Sass 所言：“它不属于任何人，它属于每个人。”