开源软件认证的挑战

开源取得了胜利，在过去五年左右的时间里，我们一直看到新一波开源项目的加速发展，这些项目最初在公司中启动。这带来了一系列新的挑战，因为新的企业参与者正在努力应对一些现实。人们普遍理解基金会在某种程度上提供了中立性，但不一定知道如何将竞争性讨论从会议室中驱除。这种混乱更令人不安的症状之一是围绕“认证”以及获得特定项目认证意味着什么的讨论。什么是认证的优秀软件^TM？ [1]

我相信推动这些认证讨论的很大一部分是对 20 世纪 80 年代末、90 年代以及 21 世纪初“开放系统”美好时光的回忆。我们看到了互联网的兴起，IETF 交付了通信协议标准，随后万维网和万维网联盟 (W3C) 交付了与网络相关的标准。UNIX 操作系统 API 和命令的变体由 IEEE（以及后来的 ISO）标准化为 POSIX。我们看到了 X/Open（现在的 Opengroup）在 POSIX 标准之上叠加的 Single UNIX Specification。UNIX 是早期 Web 的驱动引擎，后来随着 Linux 的成熟和发展，被 Linux 取代。

这就是在讨论中需要考虑差异的地方。

成功的开源社区（例如，Linux）

• 在单个快速发展的代码库上构建唯一真正的实现
• 通过贡献进行协作，以及
• 精英影响力由代码、基础设施和项目中的努力贡献驱动。

另一方面，标准组织（例如，POSIX 和 UNIX）

• 协作制定接口规范，以支持构建和衡量多个竞争性实现
• 通过在参与者之间协商折衷立场，以及
• 民主影响力通过外交和参与标准开发组织的官僚机构获得。

另一种说法是，良好运行且所有权中立的开源项目可能会发展成为包含产品的生态系统，但标准往往发生在竞争产品已经存在的成熟市场中。

标准和认证

标准的存在是为了鼓励多种不同的实现，并衡量它们如何互操作。这适用于标准是否用于

• 允许在两个不同实现之间传递信息的通信协议，
• 一种编程语言，允许程序在由不同实现编译或解释时表现一致，
• 一个系统 API，允许在一个系统上开发的程序在不同的系统上（构建和）执行。

为此，人们通常希望存在某种形式的认证或测试，以便实现可以证明它们符合标准。但是这些人是谁？这是一个非常重要的问题，因为测试和认证从来都不是容易的，也从来都不是便宜的。我将回到我在 POSIX 和 C 语言标准方面的主要经验，从不同的角度举两个例子。

供应商在标准制定工作中进行协作，无论场所规则是否规定参与者是个人专家（例如，IETF、IEEE）还是联盟成员的雇员（例如，X/Open、W3C）还是代表其国家的代表（ISO）。

在 20 世纪 80 年代末到 90 年代初，美国政府是地球上最大的 IT 采购组织。他们关心 IEEE POSIX 标准，以支持跨不同供应商的不同系统的应用程序可移植性，他们与开发 POSIX 的个人工程师一起参与了 IEEE 工作组，以定义 UNIX 操作系统接口的最小子集。然后，美国国家标准与技术研究院 (NIST) 制定了基于 POSIX 的政府采购联邦信息处理标准 (FIPS)。它有测试要求，政府制定了一个测试套件和一个计划，以认证测试实验室运行测试套件，以便拥有产品的供应商能够证明其符合标准。

IEEE 标准本身对标准的一致性做出了相当简单的声明——本质上，它们定义了“符合标准的应用程序”的概念，符合标准的实现必须运行该应用程序。（符合标准的应用程序在现实世界中是一个可怕的想法，但我们将把这场辩论留到以后再说。）NIST FIPS 计划通过定义必须通过的大量测试用例，使标准的符合性声明成为现实，以允许供应商声明他们拥有 POSIX FIPS 证书。由于 POSIX 标准的复杂性以及测试的难度和成本，FIPS 并没有走得那么远，以至于仅仅因为实现通过了测试套件就保证了符合性，但这仍然是一个非常有力的指标。

本质上，美国政府将其资金（认证计划）投入到其口头承诺（我们想要 POSIX 系统）中，并支付了证明符合性的成本。IEEE 无力为其个人专业会员制定的标准构建昂贵的测试计划。

在那个时期，围绕核心 POSIX 标准正在开发一个更广泛的规范，用于现代 UNIX 系统。如果 POSIX 是最小子集，则 Single UNIX Specification 是超集。这里的标准化工作由供应商作为 X/Open（一个行业供应商联盟）的参与者领导。这项工作是 POSIX 标准的适当超集。（没有供应商希望排除美国政府客户。）X/Open 采用了略有不同的方法来解决符合性问题。X/Open 希望在供应商成员之间创造一个公平的竞争环境，因此“UNIX”品牌的使用与通过扩展的测试套件挂钩。为了规避认证保证的困难，X/Open 认证被声明为保证。如果任何人发现经过认证的供应商实现与 Single UNIX Specification 之间存在矛盾，则供应商保证他们将在非常短的时间内修复问题并符合标准，否则他们将面临公开失去 UNIX 品牌的风险。

同样，关心证明其符合性的小组（UNIX 供应商）将其资金投入到他们在联盟中的集体口头承诺中，以支付 X/Open 会员计划的费用以测试符合性。

互联网工程任务组的结构类似于 IEEE，参与者是个人贡献专家。他们针对其网络规范的聪明“技巧”是声明，如果没有来自不同代码库的两个实现证明它们可以完全通信，则标准永远无法从草案状态转变为完全使用状态。

开源软件认证？

到目前为止，所有这些讨论都关于认证标准。为什么在过去几十年中，我们没有听说过开源世界的认证？

标准规范的演变时间线与开源项目不同。它们通常需要支持市场中复杂的外部驱动采购需求，并经过仔细和慎重的开发，以确保供应商参与者能够满足这些需求。一旦达成一致，标准的变化相对谨慎（即，缓慢且具有正确的保守流程）。考虑 HTML：IETF Internet 草案 (1993) 变为 HTML 2.0 (1994) 变为 W3C HTML 4.01 (1999) 变为 HTML5 (2014)。

虽然基于开源的产品可以更改以满足客户需求，但当产品必须互操作（例如，网络产品）或必须证明合规性（操作系统接口）时，认证是一种证明产品符合标准公差的方法。

成功的开源项目，从小型公共社区或单一供应商项目发展到多供应商生态系统，是通过定义中立的竞争环境、共享或非营利性知识产权以及围绕协作的明确界限来消除协作本身的竞争性讨论来实现的。工作和演变实时发生。如果项目成功并发展到市场上的产品和服务，那么提供这些产品和服务的商业实体已经确定了其客户的最佳差异化方法，以及如何平衡对项目的贡献与服务和产品的开发。

没有 Perl 语言标准，因为归根结底，只有一个 Perl。它以各种形式由供应商作为其平台或 IDE 的一部分交付。存在多个其他可执行版本（有些是免费的），可以在不同的平台上运行，并且具有不同的质量和支持级别。但是没有 Perl 认证测试，因为所有版本最终都源自唯一真正的社区项目源代码。用 Perl（在特定语言版本）编写的应用程序可以在各种实现上运行，除非有人正在处理明显的平台特定扩展或实验。

C 和 Fortran 语言确实有标准。来自多个来源和供应商的多个编译器实现存在并且正在分化。需要有一个标准来衡量不同的实现，专业人士在 X3 委员会的主持下齐聚一堂，创建了 ANSI 标准。美国政府再次将其资金投入到其作为采购组织的口头承诺中，并针对其自身采购的标准制定了认证流程。其他人信任认证以用于他们自己的采购这一事实对这些组织有利，但不是 NIST 的要求。它支持标准，但与标准是分开的。

Linux 项目是另一个很好的例子。Linux 发行版来来往往。一些发行版被打包为产品，为客户提供此类产品以赚钱的公司有无数种竞争方式。但是 Linux 内核社区仍然是核心工作发生的地方，即 Linux 操作系统。一些公司对其支持的 Linux 变体采取了细致入微的方法。例如，Red Hat 是内核项目的主要贡献者。Fedora 发行版是一个 Red Hat 支持的社区项目，Red Hat Enterprise Linux 是从 Fedora 社区开发的。CentOS 发行版是 Red Hat Enterprise Linux 源代码的免费发布社区重建版本，它提供了类似的执行环境。

Linux 在这里提供了一个更有趣的例子。尽管 Linux 具有明显的血统，并且尽管随着 Linux 服务器的企业采用率不断提高并取代了昂贵的 UNIX 服务器，UNIX ISV 世界在没有此类认证的情况下转向了 Linux 的几个关键企业发行版，但 Linux 从未获得 UNIX 操作系统的认证。我认为，由于 Linux 与 UNIX 非常接近，因此 ISV 迁移了他们的应用程序，并受到 Linux 供应商 ISV 计划的鼓励，并且再也没有回头。

行为与位

因此，退后一步，获得开源项目认证意味着什么？如果这意味着该项目体现了某些特定规范（例如，Apache httpd 实现 RFC 2616），那么规范（而不是开源项目）可能是将精力集中在认证上的地方。开源项目可能只是一个单一的（可能正在分化的）实现，并且标准充当市场中的衡量标准，以确保分化在标准利益相关者社区的可接受公差范围内。这对于 NGINX 也是如此。

我们已经在 Linux 标准库中看到了这一点。该标准是一个应用程序二进制标准，旨在支持 ISV 尝试使用其应用程序定位市场中的多个 Linux 发行版产品。但是 LSB 是 Linux 部分的 ABI 标准，而不是 Linux 代码库本身的 ABI 标准。

当供应商在新开源协作中努力解决这些想法时（例如，新成立的开放容器倡议），他们将需要关注容器的规范和容器上的操作，而不是任何测试和认证的开源许可代码，而不是开源许可代码。（也许他们可以借鉴 IETF 笔记本电脑的一页，并演示运行相同测试容器的多个不同实现。）标准世界的另一个现实是，“认证”产品在现实世界中会发生分化，并且需要重新与衡量标准对齐。我敢打赌，一旦该小组确定规范，他们就会事后发现代码和规范已经分化。

希望开源认证永远不会普遍意味着某种程度上唯一真正的代码库是衡量标准。在交付丰富的产品和服务生态系统方面取得成功的开源项目支持广泛的需求和要求。构建产品和提供服务的公司围绕其中一些需求和要求为客户开发了无数市场。最简单地说，一家公司可能会在将组件塑造成产品时发现开源项目软件中的错误。他们可能会正确地将这些更改贡献回项目，这样他们就不会承担生活在代码库分支上的工程经济成本。但这意味着项目对源代码的看法与公司产品看法之间现在存在差异。如果项目接受了错误报告，但修改了修复程序，则产品可能会在一段时间内与项目的源代码对齐状态不一致。

最终，想要获得认证的人员必须清楚地了解到底要针对什么衡量标准进行认证，并且选择该特定衡量标准的好处必须明确。因为归根结底，接受这些好处的人需要愿意承担认证的成本。

[1] 特别鸣谢 Tom Christiansen