开源项目死亡的愚蠢方式

Bernie’s 的周末表明，大部分最依赖的开源软件包已经死亡，并且项目有很多不同的方式会以这种方式结束。维护者离开了 Ghost 维护者。最简单和最常见的情况：几年前最后一次人类提交，问题累积而未得到答复，存储库未存档，因此它不会出现在任何标记它的过滤器中。通常，维护者只是转移到其他事情上，项目对他们来说还不够重要，无法正式移交或关闭，尽管同样的沉默掩盖了一切，包括维护者去世，注册表和存储库都无法代表这一点。从外面看，这与一个漫长的假期没有什么区别，直到有足够多的未解决问题堆积起来，使沉默变得明确，而伯尼死亡名单上排名第一的 npm 实用程序大多是这样的。企业孤儿。一家公司构建了它并开源了它，并有一个团队来运行它，然后一次转型或一轮裁员让该团队退出，没有人更新自述文件。 GitHub 组织坚持使用公司徽标，最后一批拥有管理员权限的人已经离开，所以通常公司里没有人知道该项目是他们的。谷歌的各种墓地是著名的案例，但每家超过一定规模的公司都有一些这样的墓地，而那些是基础设施而不是产品的墓地往往不会收到弃用通知。论文孤儿。由研究生为硕士项目或博士分会构建，他们已经毕业并继续前进。托管它的实验室名义上拥有该存储库，但那里没有人有继续它的背景，学术界也没有理由让他们尝试：维护别人的软件不会获得任何引用，并且在审查中与发布新内容相比毫无意义。研究软件充满了这些内容，通常在一篇论文描述的代码停止构建多年后仍然被引用。资金悬崖。该项目依靠赠款或定期赞助来运行，通常来自基金会或公共软件基金之一，并且资金如期结束。维护人员又回到了支付租金的地方，而一个已经发展到适合全职产能的项目现在却有了晚上和周末，对于这个范围来说，这一切都化为乌有。资助者的徽标通常在资助停止后很长时间内仍保留在自述文件中，这使得该项目很容易被误认为是一个健康的资助项目。被雇佣走了。维护人员是由一家公司雇用的，雇佣合同或新的工作量都意味着项目停止。偶尔，这是竞争对手消除了问题，但更常见的情况根本不是恶意的：苹果是雇主的典型例子，它根本不让大多数员工从事开源之外的工作，因此维护者的加入意味着他们的项目默认会安静下来。在开始之前移交是显而易见的解决办法，但几乎没有人及时这样做。继任僵局。原始维护者无法联系到，有人愿意接管，但注册中心的发布权与其他人无法访问的帐户绑定，并且 GitHub 存储库没有其他管理员，而注册中心的废弃包流程要么需要原始维护者的同意，要么需要长达数月的争议，没有人有明显的立场来开始。 PEP 541 流程和 npm 的争议政策都针对这种情况而存在，并且通常都比分叉和重命名花费更长的时间。维护者仍然处于倦怠期。根据您运行的任何指标仍然活跃。拼写错误修复和依赖项冲突会与偶尔出现的“谢谢，会看看这个”的问题合并在一起，但任何需要实际设计决策或调试会话的东西都会无限期地开放，因为这些需要维护者在很长一段时间内没有为项目投入精力。通常会有足够的回应，任何建议分叉的人都会被指出最近的活动，但还不足以实际发布，而且它可以保持这种状态多年，而不会死到让任何人觉得有理由接管。仁慈的僵尸。贡献图为纯绿色，每次提交都是机器人。 Dependabot 碰撞、自动合并规则、可能由碰撞触发的自动发布，以及现在预定的编码代理，可以无限期地保持灯亮着，而无需人工阅读任何内容。每个基于新近度的健康评分都将其评为良好，这或多或少是基于新近度的健康评分的全部问题。监护权之战。两个或多个共同维护者闹翻了，每个人都有足够的权限来阻止对方，但又没有足够的权限单独进行，项目就被冻结了。它可能会解决成分叉或以一方离开而结束，但很多人只是坐在那里，问题跟踪器充满了用户询问发生了什么并得到两个相互矛盾的答案。部落知识消失了。代码有效并且测试通过，但是理解原因的人已经离开，剩下的人没有足够的信心去