为开源维护者设定新期望

图片来自

Melissa Hogan, CC BY-SA 4.0, via Wikimedia Commons

长期以来，发布开源软件有两个基本测试：“它是否能满足我的需求？”和“它是否能编译？”

当然，如果它能为其他人做些什么就更好了，但最重要的是，它至少需要对开发者来说有趣，并且对其他人来说可以运行。然后，随着包管理的兴起，情况有所改善：“它是否打包了？” 此后不久，测试驱动开发的日益普及增加了一个新要求：“测试是否通过？”

这些新要求都给开源维护者带来了更多的工作，但（总的来说）维护者并没有对此抱怨太多。我认为发生这种情况有两个原因：首先，这项工作通常与开发人员需要为工作学习的技能相一致，其次，它们被广泛认为对软件的所有用户都有益，而不仅仅是企业开发人员。

但这种情况正在发生变化——而且可能会对开源和企业产生不利影响。

新的企业负担

在2021年，很明显，一套新的开源标准正在凝聚。这些标准带来了新的劳动，可以由开源开发人员完成，也可以作为元数据覆盖的一部分。这些新标准包括：

安全信息和审计：传统上，开源软件包的安全评估由第三方进行，要么通过内部安全团队，要么通过 MITRE 通用漏洞披露数据库协调的分布式流程。随着Linux 基金会的 CII 徽章和 OpenSSF 以及 Google 的 SLSA 等新安全培训的出现，新的流行语是“端到端”——这意味着维护者和项目必须使自己成为安全专家并创建安全控制。虽然这几乎可以肯定对整个行业都有好处，但这又增加了更多的工作期望，而且没有立即获得补偿的前景。
法律元数据：传统上，GNU、Debian 和 Fedora 等开源社区（有充分的理由）认为，强制性许可元数据的默认级别是在包级别，每个文件的许可信息充其量往往不受欢迎，最坏的情况下是无法表示。 SPDX，以及最近的 clearlydefined.io，已经确定许可信息必须完整、机器可读且准确地存在于每个文件中。这对于所有用户来说显然是正确的，但实际上绝大多数的利益都归于资金最雄厚的企业。与此同时，如果我们想要准确的全球覆盖，绝大多数负担将落在维护者身上，并且需要复杂的法律评估。（将这些添加到 Linux 内核实际上花了数年时间。）
采购信息：业界最新的要求是提供贯穿整个软件堆栈的软件物料清单 (SBOM)——这不可避免地包括大量的开源软件。同样，这并非完全不合理，事实上，开源长期以来一直通过开源语言社区首创的包管理技术在这方面处于领先地位。但是，对覆盖范围的完整性和信息深度的要求（包括在某些提案中，有关开发人员身份的信息）是所需内容的一个阶梯式变化——主要是为了使政府和大型企业能够负担得起对软件出处的详细的、逐个软件包的分析。

这项新的工作可能与先前开源开发人员面临的新义务浪潮截然不同——我们应该思考为什么会这样以及我们可以对此做些什么。

这项工作会成功吗？

正如我在本文开头所建议的那样，开源的持续成熟定期地给维护者带来了新的负担。（在 Mozilla，我们过去称这些为“入场券”——一种扑克术语，表示你必须做的事情才能坐在扑克牌桌旁，或者用技术术语来说，才能被考虑用于企业用途。）因此，从某种意义上说，这新一轮的义务并不新鲜。但我确实想指出，在两个重要方面，这些新的授权是有问题的。

首先，这项工作越来越高度专业化，因此对个人维护者学习的帮助越来越少。最强大的开源开发人员一直拥有多样化的技能（不仅是编码，还有营销、人员管理等）。这一直是开源的吸引力的一部分——你可以在这个过程中学到这些东西，让你成为一名更好的开发人员。但是，当我们开始添加越来越多的专家（例如，法律团队或安全团队）将在企业环境中涵盖的要求时，我们就会降低参与开源的开发人员的附加价值。

换句话说：开发人员通过学习基本的编程和人际交往技能来为自己的利益服务，这一点很明确。他们通过成为在日常工作中可能委派给专家的采购、法律和安全等问题方面的专家来为自己的利益服务，这一点不太明确。这在大到拥有大型、复杂团队的开源项目中效果很好，但这些项目很少见（即使它们获得了大部分的媒体和关注）。

其次，这些新的且日益专业化的要求主要使特定类别的开源用户——大型企业——受益。这不一定是坏事——大型企业在很多方面都是必不可少的，事实上，它们的风险确实应该认真对待。

但是，在一个由开源创造了数千亿美元企业价值的世界里，小型教育/爱好项目（甚至许多小型公司）实际上并没有从这些新的无资金支持的任务中受益，开发人员可能会专注于其他事情，因为他们很少有人主要为了让财富 500 强受益而进入开源领域。

换句话说，许多开源开发人员喜欢构建使他们自己和他们的朋友受益的东西，甚至愿意为此放弃夜晚和周末。如果满足这些新要求主要使没有面孔的公司受益，我们可能需要找到其他激励措施来鼓励开发人员创建和维护新的开源项目。