什么是开放治理？为开源项目起草章程

构建一个健康的开源社区不仅仅是为项目选择一个开源许可证。它还包括创建贡献指南，采用行为准则，并建立一个开放的治理结构，允许所有成员积极参与并为项目做出贡献。

本文提供了一个关于如何为开源项目建立开放治理结构的实用指南。事实上，我目前正在提议修改ClearlyDefined 项目的现有章程，本文将重点介绍为使这一过程尽可能顺利而正在采取的步骤。

为了提供一些背景信息，ClearlyDefined 最初由微软 开发，大约 5 年前捐赠给了开源促进会。微软仍然在该项目中发挥着关键作用，但正在寻求外部贡献者。一些个人和公司已经表示有兴趣帮助 ClearlyDefined，但到目前为止，对于这些贡献者如何在项目治理中发挥作用，还没有明确的指导方针。ClearlyDefined 有兴趣接受来自其他组织的贡献，但今天的治理结构没有为组织贡献提供任何激励。

我最近加入 了 ClearlyDefined 项目，担任社区经理，我的首要步骤之一是联系几位社区成员，了解他们的需求和愿望。除了与这些成员在线安排通话外，我还 opportunity 参加了首届ORT 社区日。OSS Review Toolkit (ORT) 是一个 Linux 基金会项目，目前被多个组织用于管理开源供应链合规性和安全性，并且是目前使用和推广 ClearlyDefined 的关键项目之一。正是在与社区面对面的交谈中，我意识到了对开放治理模式的明确需求。

我的第二步是对开源项目的开放治理模式进行研究。我找到了一些很好的资源，其中最重要的可能是The Open Source Way 2.0，这是一本由红帽和几位著名的开源领导者创建的综合指南。同样值得一提的是GitHub 开源指南，它提供了开放治理的良好总结。CNCF 最近也发表了一篇文章，Outlining the structure of your Open Source software project，它很好地解释了如何根据开源项目的成熟度级别来构建项目。

我的下一步是研究与 ClearlyDefined 处于同一生态系统中的项目的不同章程和章程细则。我们不想从头开始创建一些东西，而是从已经存在的邻近项目中寻求灵感

最后，是时候开始对现有的ClearlyDefined 章程提出一些修改建议了。这是一个非常微妙的过程，因为一切都必须有充分的理由。让我们回顾一下章程的每个部分

使命

最初的使命非常笼统。使命没有“明确定义”

通过明确定义的项目数据，帮助 FOSS 项目更成功。

所以让我们使其更具体和更鼓舞人心

ClearlyDefined 的使命是为每个已发布的开源软件组件创建一个全球许可元数据数据库。

原则

最初的原则相当不错，所以我们保持不变

中立 – 项目不带有任何隶属关系或公司驱动的重点；

开放 – 数据、基础设施和流程对所有人开放；

事实 – 所有数据都是真实的。不做任何解释或评估；

上游 – 尽可能支持上游项目；

简单 – 在可能的情况下，项目将使用简单的解决方案。

社区要求更开放的数据，例如，这已经在本文中得到了解决。我们只需要遵循我们的原则。

范围

最初的范围过于雄心勃勃，旨在解决安全性、可访问性等问题

ClearlyDefined 将追求任何使 FOSS 项目更易于使用并因此更成功的数据。最初，这项工作将侧重于构成理解和满足与使用 FOSS 相关的法律义务核心的许可数据。这包括：许可证（声明的和观察到的）；版权所有者；源位置（包括修订版/提交）。

为什么？FOSS 许可和安全信息领域广阔而多样。没有明确元数据的项目更难采用，因此获得的贡献和参与度更低 – 它们的成功率较低。在消费者方面，需要付出巨大的努力来发现和遵守许可义务并跟踪安全问题。即使是组件源代码位置这样简单的事情也可能难以找到。这些歧义意味着 FOSS 不能被放心地使用。这影响了 FOSS 项目的成功。我们想要打破这个恶性循环。

什么？众包 FOSS 项目的许可、安全性、可访问性数据的管理。首先是明确的许可数据。稍后是明确的安全性、可访问性数据。

如何？收集项目中嵌入的数据，在开放和协作的过程中管理数据，将明确定义的项目数据贡献回 FOSS 项目，并使数据可以自由且轻松地访问。一个良性循环。

未来的工作将侧重于其他主题，例如：安全性– 促进项目中漏洞的报告和跟踪；可访问性– 项目对可访问性相关技术和问题的支持的特征和分析；项目数据 – 治理模型、原则、问题跟踪、讨论论坛，… 这项工作的顺序和应用的努力将完全取决于社区及其兴趣。

让我们缩小范围，专注于许可元数据。安全性、可访问性和项目数据当然也很重要，但是已经有其他倡议正在研究这些，所以让我们与他们合作。

这是提议的范围

ClearlyDefined 将专注于许可元数据，这些元数据构成了理解和满足与使用开源软件相关的法律义务和安全最佳实践的核心。这包括：许可证（声明的和观察到的）；版权所有者；源位置（包括修订版/提交）。

动机

在最初的章程中，动机（为什么？）是范围部分的一部分。让我们将动机分解成一个单独的部分，以使事情更清楚。此外，让我们重新措辞动机，使其更短更简洁

随着 SBOM（软件物料清单）因合规性和安全原因而无处不在，组织将面临巨大的挑战，需要在供应链的每个阶段、每次构建或发布时大规模生成这些清单。

此外，多个组织将不得不一遍又一遍地修复相同的缺失或错误识别的许可元数据。

这就是 ClearlyDefined 的用武之地，通过简单的 API 为每个组件提供许可元数据的缓存副本。

组织还可以贡献任何缺失或错误识别的许可元数据，帮助创建一个准确的数据库，造福所有人。

流程

在最初的章程中，在治理下，它描述了项目流程和社区角色。但是治理在更高层次上解决了系统如何工作的问题，而这在最初的章程中完全缺失。所以让我们创建这 3 个部分：流程、社区和治理。

流程部分基本保持不变

ClearlyDefined 的持续目标是帮助原始项目在其操作的本土部分中制定和维护围绕其范围数据的清晰度。在不可能的情况下，项目将维护相关数据。这被视为上游项目的一个分支，就像代码分支一样，应该尽量减少。无论哪种方式，该项目都充当范围数据的“一站式商店”，使消费者生活轻松。

该项目开展四项主要操作，以支持既定目标和范围：收集项目中嵌入的数据；在开放和协作的过程中管理数据；将明确定义的项目数据贡献回 FOSS 项目；以及使数据可以自由且轻松地访问。

这些过程在下面进一步描述。

收集

收集是从上游项目获取数据的行为。这可能就像从规范位置读取指定数据一样简单，也可能像使用各种开放工具对源代码进行全面分析一样复杂。发现的数据以其原始形式完整地存储在 ClearlyDefined 基础设施中，并按需提供给社区。收集工具本身始终完全开放，供社区审查和检查。该项目欢迎纳入新工具，但须经投票表决，如下所述。

收集可以由 ClearlyDefined 项目本身或由指定的各方（通常是管理者）运行。在任何情况下，只有来自约定的工具和配置的输出才会被系统接受。收集操作员可以自由地专注于最适合其专业知识和兴趣的给定项目领域。

管理

管理流程从根本上是开放和透明的。管理者（又名项目提交者或维护者）处理收集的数据、ClearlyDefined 社区贡献的数据以及原始项目工件和社区，以验证提供的信息。所有审议、发现和讨论都将被记录下来，并提供给社区检查。

最初，此工作流程将在一个或多个 GitHub 存储库中使用标准拉取请求工作流程处理人类可读且可区分的管理工件。该项目可能会开发其他工具来补充或取代此流程，但将始终确保完全透明。

与典型 FOSS 项目的提交者一样，管理者可以自由/期望专注于适合其兴趣和专业知识的特定领域。

至少在最初，所有管理的数据都必须由两位管理者签字认可。这更多是为了理清思路和机械流程，并对数据形成共同理解，并确定什么是可接受的。此要求可能会通过投票取消，如下所述。

贡献

在管理了关于项目的数据之后，ClearlyDefined 社区成员将寻求以上游项目最吸引人的形式贡献数据。考虑到这项工作的预期规模，将使用一些自动化，但要注意不要用拉取请求向项目发送垃圾邮件。这些贡献将包括支持纳入和持续维护管理数据的信息。

接受管理贡献的项目将被视为 ClearlyDefined（请参阅下面的徽章），并且不再需要管理。验证将继续进行，但通过选择加入此计划，项目正在努力有效地自我管理数据。

服务

无论项目是自我管理还是由 ClearlyDefined 外部管理，作为对消费社区的服务，ClearlyDefined 项目都通过编程（例如，REST）API 和可浏览的 Web 属性提供收集和管理的数据。原始收集的数据以及汇总和管理的数据都通过这两种访问方法提供。

社区

社区部分也基本保持不变

角色

数据管理者

数据管理者类似于典型开源项目中的项目维护者或提交者。管理者对管理存储库具有写入权限，并最终负责将数据添加到管理存储库中。管理者更像是图书管理员和数据科学家，而不是律师或开发人员。该角色需要足够的领域背景知识，才能识别和解决问题。该角色还需要运行用于检测和分析组件的各种工具的技术专业知识。每位管理者都必须是并且被视为供应商中立和公正的。这有助于他们在另一个关键角色中发挥作用 – 与上游项目合作，将管理的数据纳入原始项目。

与提交者和维护者一样，管理者由项目社区根据其优点和先前贡献提名和批准。管理者的角色与个人有关，而不是组织或组织中的职位。在任何情况下，管理者都不对合并到服务中的数据中的任何错误或其他缺陷负责。

数据贡献者

ClearlyDefined 数据贡献者就像任何其他开源项目的贡献者一样 – 他们识别错误或改进，fork 存储库并贡献包含其更改的拉取请求。对于数据贡献者来说，这可能是一个小的更改（例如，拼写更正）、一个实质性的更改（例如，识别组件的许可证）或批发数据定义（例如，为以前未知的组件提供数据）。与任何其他项目一样，贡献者应期望用背景信息和正确性证明来证实更改。

高质量数据的连续贡献者是成为管理者的候选人。

数据消费者

ClearlyDefined 数据消费者访问管理或收集的数据。他们理解数据按原样提供，不对数据的正确性或其对任何特定用途的适用性做出任何保证或担保。所有数据都完全限定了其来源和所做的任何澄清，是否使用数据由消费者自行决定。

代码提交者/维护者

虽然 ClearlyDefined 专注于数据，但该项目将开发少量代码。代码提交者身份独立于数据提交者身份。因此，代码提交者由现有代码提交者社区投票选出，如下所述。代码提交者对项目收集、管理和服务基础设施的运行具有完全控制权和责任。

角色移除

在不太可能发生的情况下，如果提交者或管理者变得具有破坏性或长时间不活跃，他们可能会通过剩余提交者或管理者的一致投票从角色中移除。

投票

项目内的大多数决策可以通过非正式协商一致达成，并记录在适当的公共记录中。当需要正式决策时，例如，当选举提交者/管理者时，将使用以下流程进行投票：管理者通过通知所有其他管理者来提出投票主题；主题提出后，管理者可以在持续不少于一个工作周的公开投票期内投票。投票将在约定的、相互方便的且开放的媒介（例如，电子邮件、GitHub 问题等）上进行；至少两个赞成 (+1) 票且没有反对 (-1) 票即可通过该主题。请注意，反对票必须有理由支持；弃权 (0) 票不影响结果。

认可和推广

项目可能会不时运行一些计划，以表彰和奖励项目为成为和保持 ClearlyDefined 所做的努力。例如，徽章计划将使符合条件的项目能够展示它们是 ClearlyDefined 的，从而提高消费者信心。此类认可可以相对于特定领域（例如许可或安全性）或与整体 ClearlyDefined 工作相关。

治理

最后，让我们描述一下治理模型。本节是全新的，其灵感来自同一生态系统中其他邻近项目的治理模型

理事会

理事会投票成员应包括：开源促进会执行董事、指导委员会主席和外联委员会主席。

理事会的职责包括

– 设定 ClearlyDefined 项目的总体战略方向，根据社区的反馈和意见，确立主要目标并确定关键优先事项；

– 以负责任和可持续的方式管理 ClearlyDefined 项目的资源，包括预算、基础设施和人力资源；

– 采用和维护 ClearlyDefined 项目的政策或规则和程序，例如行为准则和商标政策以及任何合规性或认证政策。

指导委员会

指导委员会应负责

– 设定 ClearlyDefined 项目的技术方向，确立主要目标并确定关键技术优先事项；

– 监督所有流程（收集、管理、贡献、服务），确保底层架构使这些流程能够顺利运行；

– 增强社区（数据管理者、数据贡献者、数据消费者和代码提交者/维护者）的能力，提供实现 ClearlyDefined 使命所需的所有技术支持；

– 与生态系统中相邻的项目建立开放协作。

外联委员会

外联委员会应负责

– 计划和执行工作，以向潜在用户和贡献者推广 ClearlyDefined 项目；

– 在全球范围内的虚拟和面对面活动中组织活动，以汇集现有社区成员并吸引新成员；

– 创建教育材料（文档、白皮书、网络研讨会、播客等），以帮助个人和公司了解如何使用 ClearlyDefined 项目并为其做出贡献；

– 管理跨不同渠道（网站、博客、社交媒体和新闻稿）的沟通。

成员和主席

指导委员会和外联委员会由长期持续贡献的社区成员组成，并被公认为对 ClearlyDefined 项目的长期健康感兴趣。指导委员会和外联委员会的成员推荐和任命新成员，并投票选出每个委员会的主席，任期一年。如果委员会成员辞职或在参与项目和做出贡献方面不活跃超过 6 个月，将被从委员会中除名。

会议

理事会会议将仅限于理事会成员。会议将是私密的，除非理事会另行决定，因为敏感事项可能不宜公开。理事会可以自行决定举行公开的社区会议。

指导委员会和外联委员会会议应定期（每月或每两周）举行，并打算向公众开放。会议可以通过电子方式、电话会议或面对面方式进行。每个委员会的主席应提前设置议程并主持会议。会议纪要应通过公共渠道发布并与社区共享。

投票

虽然 ClearlyDefined 项目的目标是以协商一致的社区方式运作，但如果任何决策需要投票才能向前推进，则理事会、指导委员会或外联委员会的成员（如适用）应在每位成员一票的基础上进行投票。

投票的决定将基于多数票，前提是至少百分之六十 (60%) 的理事会、指导委员会和外联委员会成员（如适用）在会议之前出席、以电子方式参与或通过电子投票（例如，通过电子邮件或以委员会材料中指定的形式）参与。

任何修改本章程的投票都需要三分之二多数票。修改将通过公共渠道传达给社区，并将立即生效。

明确定义的治理

现在，最后也是至关重要的一步是与所有利益相关者互动，并再次征求他们的反馈。最初的反馈是推动章程变更的首要因素，我们希望确保提出的变更解决了利益相关者的担忧。

我们希望避免在闭门造车的情况下讨论这些变更和做出决定。我们应该尽一切努力使这个过程从一开始就尽可能开放和透明。

通过建立清晰和开放的治理模式，我们希望 ClearlyDefined 将变得更加欢迎个人和组织的贡献，不仅在代码或数据贡献方面，而且在有助于治理项目本身的贡献方面。

如果您有兴趣了解更多关于 ClearlyDefined 以及如何参与的信息，请访问我们的网站 和discord。

图片来自 ktasimarr，通过 Canva.com