认证识别 开源

开源赢得了胜利，并且在过去的五年左右的时间里，我们一直在看到一波新的开源项目的加速发展，这些新项目开始于公司。 随着新的公司参与者在某些现实中挣扎，这带来了一系列新的挑战。 人们通常都知道基金会以某种形式提供中立性，但不一定知道如何从会议室推动竞争性讨论。 这种混乱的更令人不安的症状之一是围绕“认证”开始的讨论，以及对特定项目进行认证意味着什么。 什么是合格软件认证^TM ？ [1]

我认为，推动这些认证讨论的许多因素都使人们回想起1980年代和1990年代末以及2000年代中期的“开放系统”的美好时光。 我们看到了互联网和IETF提供通信协议标准的兴起，随后是万维网和万维网联盟（W3C）提出了与Web相关的标准。 UNIX操作系统API和命令的变体已由IEEE（及后来的ISO）标准化为POSIX。 我们在POSIX标准之上看到了来自X / Open（现在是Opengroup）的Single UNIX规范的叠加。 UNIX是推动早期Web发展的引擎，随着Linux的成熟和发展，Linux被Linux取代。

这就是讨论中需要考虑差异之处。

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

• 在单个快速发展的代码库上构建一个真实的实现
• 通过贡献合作，以及
• 精英的影响力是由项目中的代码，基础架构和工作的贡献所驱动。

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

• 在接口规范上进行协作，以构建和评估多个相互竞争的实现
• 通过协商参与者之间的折衷立场，以及
• 通过外交和参与标准制定组织的官僚机构，可以获得民主影响。

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

标准和认证

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

• 一种通信协议，允许在两种不同的实现方式之间传递信息，
• 一种编程语言，允许程序在通过不同的实现进行编译或解释时能够始终如一地运行，
• 系统API，允许在一个系统上开发的程序可以在另一个系统上（构建和执行）。

为此， 人们经常希望存在某种形式的认证或测试，以便实现可以证明自己可以衡量并符合标准。 但是这些人是谁？ 这是一个非常重要的问题，因为测试和认证绝非易事，也不便宜。 我将从两个角度从两个角度回到有关POSIX和C语言标准的主要经验。

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

在1980年代末至1990年代初，美国政府是地球上最大的IT采购组织。 他们关心IEEE POSIX标准，以支持来自不同供应商的不同系统之间的应用程序可移植性，并且他们与开发POSIX的个人工程师一起参加IEEE工作组，以定义UNIX操作系统接口的最小子集。 然后，美国国家标准技术研究院（NIST）为基于POSIX的政府采购制定了联邦信息处理标准（FIPS）。 它有测试要求，政府建立了一个测试套件和一个程序来认证测试实验室来运行该测试套件，以使带有产品的供应商能够证明其符合标准。

IEEE标准本身就遵守该标准做出了相当简单的声明-本质上，他们将“符合应用程序”的概念定义为符合标准的实现必须运行的理想对象。 （在现实世界中，合格的应用程序是可怕的想法，但我们可以避免争论。）NIST FIPS程序通过定义必须通过的大量测试用例，使供应商能够声明，从而使标准的合格性声明成为现实。他们拥有POSIX FIPS证书。 由于POSIX标准的复杂性以及测试它的难度和费用，FIPS不能仅仅因为实现通过了测试套件就保证了一致性，但这是一个非常有力的指标。

本质上，美国政府把钱（一项认证计划）放在其口中（我们想要POSIX系统），并支付了证明符合性的费用。 IEEE无法为他们的专业成员开发的标准建立昂贵的测试程序。

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

再次，关心证明自己的一致性的小组（UNIX供应商）将他们的钱花在联盟的集体口中，以支付X / Open成员资格计划来测试一致性。

互联网工程任务组的结构与IEEE相似，因为参与者是个人贡献专家。 他们对于网络规范的巧妙“破解”是指出，如果没有来自不同代码库的两个实现来证明它们可以完全通信，那么标准永远不可能从“ 草稿”状态转变为“ 完全使用”状态。

开源软件认证？

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

标准规范在不同的时间轴上演变为开源项目。 他们通常需要支持市场中复杂的，由外部驱动的采购需求，并经过精心设计，以确保供应商参与者可以满足这些需求。 一旦达成协议，标准就会相对谨慎地进行更改（即缓慢而正确地进行保守的过程）。 考虑HTML：IETF Internet草案（1993）变成HTML 2.0（1994）成为W3C HTML 4.01（1999）变成HTML5（2014）。

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

成功的开源项目已经从小型公共社区或单一供应商项目转移到多供应商生态系统，其方法是定义一个中立的竞争环境，共享或非营利IP所有权，以及围绕协作的明确路线，以消除协作中的竞争性讨论本身。 工作和发展是实时发生的。 如果项目成功并发展到市场上的产品和服务，那么提供这些产品和服务的企业实体将确定针对其客户的最佳差异化方法，以及如何在对项目的贡献与服务开发之间取得平衡。产品。

没有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有明显的血统，但从未被认证为UNIX操作系统，尽管事实上随着企业对Linux服务器的采用不断增长并取代了昂贵的UNIX服务器，UNIX ISV领域转移到了几个没有此认证的企业级Linux发行版中。 我相信，由于Linux与UNIX足够接近，因此ISV在Linux供应商ISV程序的鼓励下移动了他们的应用程序，并且再也没有回头。

行为与位

那么退一步，获得开源项目认证意味着什么？ 如果这意味着该项目体现了某些特定的规范（例如，实施RFC 2616的Apache httpd），则该规范（而不是开源项目）可能是致力于认证的地方。 开源项目可能只是一个单一的（可能是不同的）实施，并且该标准充当了市场上的量尺，以确保该差异在该标准的关注社区的可接受范围内。 NGINX也是如此。

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

当供应商在新的开源协作（例如，新成立的“开放容器计划”）中努力争取这些想法时，他们将需要专注于容器的规范和对容器的操作，而不是针对任何容器的开源许可代码测试和认证，而不是开放源代码的代码。 （也许他们可以从IETF笔记本中抽出一页，并演示运行同一测试容器的多种不同实现。）标准世界的另一个现实之一是，“认证”产品将在现实世界中出现分歧，因此需要使它与量尺对齐。 我敢打赌，一旦小组决定了规范，他们就会在代码和规范已经脱离事实之后发现。

认证开源希望通常永远不会意味着什么，一个真正的代码库就是一个准绳。 成功交付丰富的产品和服务生态系统的开源项目支持广泛的需求。 围绕这些需求和要求中的一些，制造产品和提供服务的公司为客户开发了无数的市场。 最简单的是，一家公司可能会发现开源项目软件中的错误，因为它们会将组件塑造成产品。 他们可以将这些更改正确地归还给项目，这样他们就不会吃掉代码库中分叉的工程经济成本。 但这意味着项目的源视图和公司产品视图现在有所不同。 并且，如果项目接受错误报告，但修改了修复程序，则该产品可能会在一段时间内与该项目的源代码不一致。

最终，想要获得认证的人必须清楚地知道对哪种量尺进行了认证，选择特定量尺的好处也必须明确。 因为最终，获得这些利益的人们需要愿意承担认证费用。

[1]给汤姆·克里斯蒂安森 （ Tom Christiansen）戴帽子

翻译自: https://opensource.com/business/16/2/certified-good-software

认证识别 开源