网站自主制作平台,用网上的文章做网站行吗,浙江省龙泉市建设局网站,大学专业分类目录文 | 肖滢出品 | OSC开源社区#xff08;ID#xff1a;oschina2013)2008 年初#xff0c;澳大利亚一对兄弟 Simon Zerner 和 Toby Zerner 开始了 esoTalk 的开发。不幸的是#xff0c; esoTalk 尚处于 Alpha 阶段#xff0c;主力开发人员哥哥 Simon 就在 2009 年年中去世。… 文 | 肖滢出品 | OSC开源社区IDoschina2013)2008 年初澳大利亚一对兄弟 Simon Zerner 和 Toby Zerner 开始了 esoTalk 的开发。不幸的是 esoTalk 尚处于 Alpha 阶段主力开发人员哥哥 Simon 就在 2009 年年中去世。 接替 Simon 维护和更新 esoTalk 的是他弟弟 Toby。在 README.md 文件写着这么一句话“esoTalk 是 Toby Zerner 为纪念他的兄弟 Simon 而开发的。”最终两兄弟留下了一个采用 PHPMySQL 开发的具有非常简单、快速、现代特性的开源论坛系统。 esoTalk 的延续是那么地顺其自然。 这就引出了一个话题如果开源项目的作者去世了代码由谁来继承这实际上是两个问题。一是版权由谁来继承二是代码由谁来维护 通常来说继承版权和维护代码的不会是同一个人。毕竟不是每个开源大佬都像 Simon一样有个会写代码的弟弟。 版权问题其实并不那么棘手。如果开源软件只有一个作者那么版权完全归他所有。如果有多个作者那么每个代码部分的作者都拥有该部分的版权。 有遗嘱就按遗嘱执行没有遗嘱还有著作权法、继承法这样的法律来管。不管由谁继承都不会过多影响用户使用开源软件。因为开源本身就具有特殊性项目作者已经通过开源许可证许可他人任意使用、复制、修改、分发代码这已经包含了大部分版权所涉及到的权利。 一般来说作者在贡献之前会已经与项目维护的法律实体比如基金会、企业签订贡献者许可协议将版权分配出去。签了这类协议别说作者去世了就是还活着对交出去的代码想做些什么也做不了。详情可查看贡献者许可协议CLA是开源开发者的保护伞还是枷锁 所以问题就集中在项目维护。其实很早就有人想要答案。 未雨绸缪的假设 “如果 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 所言“它不属于任何人它属于每个人。”END觉得不错请点个在看呀
