实践者指南：开始淘汰开源项目

主要指标：

如果您还没有阅读 洞察指南：简介 - 解读指标时需要考虑的事项，请现在暂停并阅读该指南。

许多开源项目，即使是那些被广泛使用的项目，也会因为各种原因（例如，兴趣爱好变化、家庭状况、工作变动）而被放弃。但可以通过主动终止项目（Miller 等人，2025）以负责任的方式放弃项目。在企业环境中，终止项目是一项重要的考虑因素，因为很容易丢失那些后来离开项目的员工创建的项目。您肯定不希望那些存在安全漏洞的废弃开源项目堆积在组织的源代码库中，因为有些人可能仅仅因为信任您的组织就信任它们。找到不活跃的项目并以负责任的方式终止它们是一项明智的商业决策，也是许多开源团队/开源项目办公室 (OSPO) 定期进行的工作。

务必牢记，并非所有开源项目都能或应该永远存在：技术不断发展，企业优先级不断变化，人们的兴趣也随之变化。开源的魅力之一在于，我们在开放的环境下进行创新，其中一些创新项目将经受住时间的考验，而另一些则应通过落成流程负责任地弃用。开源项目的落成应考虑用户的需求，并在可能的情况下为用户提供迁移到替代技术的时间。至少，务必明确告知用户该项目将不再维护、更新或提供安全补丁，以便用户知道他们不应再使用该项目。

结束项目时最重要的一步就是保持每一步的透明。公开你的意图，确保未来开源工作的信任。

第 1 步：确定趋势

有几种指标可以帮助您确定项目是否有任何活动或用途，以便做出负责任地终止项目的决策。查看 变更请求 （又名拉取请求/合并请求）和 新问题 在考察是否仍有人使用和贡献某个项目时，这是一个很好的开始。另一个好的指标是 技术分叉，这往往表明了用途和潜在贡献。

变更请求

变更请求指标可以帮助您了解是否有人正在尝试为您的项目做出贡献，这表明是否有人对您的项目感兴趣。查看已关闭和未解决的变更请求会很有帮助，因为已关闭的变更请求表明项目可能仍在维护中，而未解决的未解决变更请求则可能表明项目可能已被放弃。如果没有最近合并的变更请求，那么很可能还没有进行任何安全更新。

废弃项目 - 变更请求

新问题

许多新问题都是由用户发现错误、提出疑问或想要新功能时产生的，因此新问题可能是因为有人正在使用您的项目或对您的项目感兴趣而提交的。如果一段时间内几乎没有或完全没有新问题产生，则可能表明该项目已被放弃。

废弃项目 - 新问题

技术分叉

这些是人们在使用您的项目或计划为其做出贡献时创建的分支，但除了分支数量之外，了解谁对您的项目进行了分支以及他们是否在继续更新他们的分支也大有裨益。最近更新的分支可以反映项目使用情况，通过收集谁对您的项目进行了分支的数据，您还可以在决定是否或如何停用该项目之前，联系其中一些人，询问他们是否仍在使用该项目。

第 2 步：诊断

如果您所在的组织正在审核其代码库以查找看似已被放弃的项目，那么您应该首先与参与该项目的人员沟通，以便更好地了解该项目是否真的被放弃，如果是，原因是什么。这可能需要查看最近的变更请求，以了解是谁对项目进行了最后几次更改，以便您可以联系他们。在某些情况下，项目可能不需要定期更新，并且可能看似已被放弃，但实际上它已经稳定下来并且可能仍在被广泛使用。例如，一个执行某些复杂数学函数的小型库可能在编写后无需更新，前提是它没有需要更新的依赖项。如果项目主要通过包管理器分发，则还应考虑来自这些来源的使用情况指标。

如果项目确实被放弃了，那么在决定停止之前，了解放弃的原因以及是否仍有人在使用它，会有所帮助。这时，技术分叉数据就非常有用了，它可以帮你查看是否有其他人分叉了你的项目，并且正在继续更新他们的分叉，这或许可以反映出你项目的使用情况。 关键性分数（OpenSSF 的一个项目）也可以显示使用情况，因为它还会计算依赖于你的项目的项目数量。有一个 Python脚本 它使用关键性分数和 GitHub API fork 数据来收集和分析这些数据。

第 3 步：根据需要收集其他数据

CHAOSS 有其他指标来了解项目活动和使用情况，这在决定是否终止项目时很有帮助。

附加指标：

此外，不要忽视代码库本身的内容。有时，组织会维护一些空白代码库，或者只包含一个 README 文件的代码库，而自己却浑然不知。如果未来没有积极开发的计划，这些空代码库应该考虑归档。您可以考虑删除这些代码库，但保留这些潜在代码库的记录仍然很有价值，因为它无需任何成本，能够体现决策过程，并保存项目历史记录。

为了帮助人们发现这些被忽视的代码库，GitHub OSPO 创建了 空仓库 GitHub Action。此操作会扫描您的组织，并识别出为空或仅包含 README 的存储库，以便在它们被忽略之前将其显示出来。

第四步：做出改变

完成诊断并决定终止项目后，您可以采取以下几项措施，确保以负责任的方式终止项目。按照以下步骤准备代码库以进行归档，有助于降低风险、简化维护，并在终止项目前将代码库置于清晰的最终状态。

外场通讯

应首先与所有现有贡献者沟通，确保他们同意此决定。在某些情况下，可能有些贡献者希望继续该项目，而不是将其弃用。

当您同意终止项目时，需要告知所有现有用户，包括可能正在使用该项目的其他内部团队。沟通应以透明的方式进行，并明确终止项目的原因。以下几个地方需要沟通并记录：

  • 自述文件：请在自述文件顶部明确说明该项目已弃用，并且将不再更新。如果可能，请推荐提供类似功能的替代项目。
  • 项目沟通渠道：这可能包括 Slack、邮件列表、论坛、社交媒体以及用于项目内部沟通的任何其他渠道。
  • 文档：项目文档也应更新。这可能包括维基、项目看板、网站和其他项目文档。
  • 包管理器/分发渠道：由于大多数项目都是通过包管理器（例如 npm、PyPI、RubyGems）分发的，因此也应该使用弃用警告进行更新，明确指出该项目不再维护或更新。
  • 其他渠道：如果这是企业项目，还应通知营销和其他内部团队。
  • 用户：还应通知项目的已知用户。

代码与安全审查

至少要检查存储库中是否存在机密信息、密钥和个人身份信息 (PII)。务必删除或编辑任何发现的敏感信息。

对于大型项目，值得对代码及其提交历史进行全面审查。解决通过 Dependabot、CodeQL 和其他代码分析工具发现的任何代码扫描和安全警报。如果代码库包含变更日志 (CHANGELOG) 和/或发布版本/标签，请确保其反映了所有已完成的工作和项目的最终状态。

问题

审查所有未解决的问题，关闭已修复的问题，并为未解决的问题添加背景信息。应用适当的标签并关闭问题。 won't fix 适用时。

变更请求

审核所有变更请求，合并无冲突且通过测试的请求。Dependabot 的 PR 也应进行测试并合并，以确保安全漏洞得到解决。对剩余的未完成变更请求添加注释，说明其当前状态，并关闭变更请求。 won't fix 适用时。

存储库元数据

如果您的项目包含元数据文件（例如 code.json, publiccode.yml 或 codemeta），更新它们以反映存档状态，并确保所有字段都是最新的。

如果您的项目不包含此类文件，请考虑将其添加到存储库中。添加元数据文件可以提高项目的可发现性，帮助用户和内部团队了解项目状态，并随着时间的推移，简化组织软件资产的生命周期和合规性跟踪。

家政

对所有拥有代码仓库提交者权限的用户进行审核。移除不再需要访问权限的用户的权限。同时，清理代码仓库，删除过时/不活跃的分支和不必要的文件/构件。

清单和工具

以下清单总结了上述任务：

有多种工具可以帮助完成档案整理工作。例如， repo-sunsetter GitHub Action 通过生成审查清单（如上所示）作为存储库问题并自动更新文档，为存储库的归档做好准备。

档案

项目应该使用类似 GitHub 的归档方法进行正式归档。将这些项目保存在单独的位置也是一个好主意，这样可以清楚地表明这些项目已经走到了生命的尽头。例如，VMware 有一个单独的“vmware-archive”组织，Apache 也有一个类似的组织，叫做“Apache Attic”。

采取额外步骤将您的代码添加到 遗产软件 存档可以帮助代码长期保存。如果您自行托管源代码存储库，这一点尤其重要，它还能帮助存档代码在平台变更后依然保持活力，并方便人们日后查找。

请记住，如果您以后改变主意，项目可以随时取消归档。强调这一点通常能更容易地让人们同意日落流程。

特殊情况：停止进行中的项目

不幸的是，即使是活跃的项目也可能需要停用，这可能会更加困难。当一个项目完全由一家公司维护，而该公司战略发生转变，决定不再为一个被广泛使用的项目配备人员或维护该项目时，就会发生这种情况。在这种情况下，在项目归档之前，还需要考虑一些其他事项：

  • 公共关系 (PR)：归档正在进行的项目可能是一个棘手的情况，一旦您开始与人们谈论您希望终止该项目，可能会导致负面报道，因此在与公司外部的任何人交谈之前，您需要让您的公关团队参与进来，以便他们准备好处理任何疑问。
  • 在新的所有权下继续的选项：确定是否有其他贡献者或其他组织愿意并能够接管项目的新开发和/或维护。
  • 日落计划：它可以帮助创建一个详细的计划，概述需要采取的所有步骤以及项目日落的时间表。
  • 时间：负责任的日落计划将为用户提供时间在停止进行安全更新和发布之前迁移到另一个解决方案。6 个月是一个很好的起点。
  • 客户、用户和沟通：需要仔细沟通，将此决定以及时间安排传达给任何现有客户和用户。

注意事项和注意事项

  • 在决定终止某个项目之前，值得花一些额外的时间与贡献者交谈，并确保这个决定是正确的。
  • 尽可能透明地说明终止项目的决定以及做出该决定的原因。
  • 项目落成并不意味着失败，也不应该被这样看待。项目有生命周期；只要需要，它们就会一直存在；当它们不再需要时，就应该负责任地弃用。
  • 考虑提供过渡细节，如果可能的话，提供工具来帮助现有用户过渡到替代解决方案（如果有合理的解决方案）。
  • 与所有 CHAOSS 从业者入门指南一样，这些材料旨在帮助您在结束项目时开始工作，但它并不是一份包含您在每种情况下可能需要了解的所有内容的综合指南。

延伸阅读

合作者

以下人员为本指南做出了贡献：

  • 黎明福斯特
  • 里亚·斯查纳特
  • 达米安·维奇诺
  • 马特·杰蒙普雷斯
  • 伊丽莎白巴伦
  • 塔拉·塔拉基耶
  • 娜塔莉亚·卢祖里亚加
  • 艾萨克·米拉尔斯基
  • 萨钦·帕纳伊尔
  • 迪恩·科佩列维奇
  • 雷米·迪考梅克

案例

CHAOSS 从业者指南是 MIT 授权的动态文档，我们欢迎您的反馈和意见。您可以在以下位置建议对本文档进行修改 https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/sunset.md