对外开源指南

人们也可从这里下载 1.0 版本指南的 PDF。

TODO 社区对通过这个仓库收到用于改进的修正和建议表示感谢，它包含有 TODO 指南的最新版本的文档。

简介

目标与受众

本指南旨在指导公司如何为开源项目做出贡献或者发起一个开源项目（也叫做“对外开源”)。它旨在描述一个完整且精简的流程，该流程能够被任何规模（包括大型、小型或者中型）实施。公司可以根据自己的需求调整所提议的程序。例如，根据公司的规模和情况，并非所有的步骤都需要实施。

成熟度级别

开源软件（OSS）的企业采纳情况通常可以根据成熟度模型进行分类。这些层级描述了 OSS 是如何以一种越来越有效地方式创造价值和满足业务需求。区分不同成熟度层级的一个显著因素是组织如何处理外向型开源软件。一个关键的认知是，对开源生态系统的影响主要是通过参与和贡献开源项目来实现的。

公司开源采纳的一个典型的成熟度模型如下（例如，参见 Haddad：开源项目办公室）:

  1. 拒绝-没有或者没有使用开源软件的意识
  2. 消费-被动的使用开源软件
  3. 参与-加入开源社区
  4. 贡献-务实的为开源项目做贡献
  5. 领导层-战略性参与开源以推动业务价值

要想从一个级别提升到另一个级别，需要采取一定的措施，并具备相应的结构和组织要素。

从单纯的使用转变为积极参与的过程需要循序渐进。初期可以从非正式的、投入较少的活动开始，例如报告上游项目的漏洞。这类活动往往出于解决技术需求的考虑。在这个阶段，有关开源软件贡献的决策通常是临时性的，仅针对个别情况做出。

确立专门的决策流程和正式的贡献政策将引领开源迈向下一个层级。这一级别的一个典型的步骤是建立开源项目办公室 (Open Source Program Office)，以支持开源参与并维护开源战略和流程。

在领导层级别，开源贡献的流程已经成熟且具备可扩展性。相应的工具链也已经到位。如果有必要且合适，将启动旨在创建新的开源社区的自有项目。这通常会伴随着利用开源基金会来推动跨公司协作，并战略性地利用开源来加速创造商业价值。

公司可能决定不升级到基于更多贡献的级别，当然，即使不贡献，也可以建立成熟的流程来使用开源软件。然而，大多数情况下，公司都会感受到一些回馈压力。这种压力可能来源于实际的技术需求（例如，缺少功能或者需要漏洞修复是向开源项目贡献的典型原因），或来自于在开源生态系统中承担责任的期望，或来自于从开原模型中获益的渴望。

公司如何管理开源：开源项目办公室

随着参与开源软件的程度加深，越来越多的组织意识到企业内部开源管理以及开源生态系统固有复杂关系带来的挑战。因此，有许多组织开始成立开源项目办公室（Open Source Program Offices，OSPOs），或者叫一些其他名称，例如开源技术中心，开源社区发展团队等。OSPOs 是组织内部专门负责支持、培育、分享、解释和推动开源发展的地方。有了这样的办公室，企业可以以明确地条款和职责来制定和执行其开源战略，为领导者、开发人员、营销人员和其他员工提供所需的流程和工具，帮助他们在运营中成功运用开源。

针对如何启动开源项目办公室（OSPO），TODO Group 提供了一系列指南。对于刚接触该主题的公司而言，可以优先查看如何创建一个开源项目指南。

开源贡献的动机

投身开源项目或者发起新项目的动机多种多样。这里，我们仅列举部分示例.

高效和高质量的构建软件

使用开源软件通常可以加快开发的速度并降低开发的成本，因为您可以利用现有的经过功能测试的代码进行构建。然而，一个存在的风险是社区可能无法迅速地提供所需的功能或者漏洞修复。为了缓解这一风险，培养必要的技能并自行创建这些漏洞修复和/或功能可能是有意义的。将它们回馈给上游项目具有重要的好处：

实施战略影响

除了上面提到的开源软件在开发速度和质量的优势外，为开源项目做贡献在战略层面也很重要。在开源世界中，声誉和影响力通常是通过参与社区和贡献来建立的。因此，对开源项目的贡献有助于…

有时，公司倾向于使用金钱来施加影响。但在开源项目中这并不是最有效的方法。影响力的“货币”是贡献，因为开源项目通常更多地由个人的工作驱动，而不是委员会的决策。因此，与单纯成为某个组织的成员或者支付支持费或其他服务相比，贡献代码更加直接、更有效。

开源社区（尤其是那些由大的开源基金会运营的）为公司和其他组织之间的合作提供了一个中立的场所。因此，开源方式可以为公司提供与供应商、客户、合作伙伴甚至竞争对手合作的新途径，仅举一些行业或领域特定的项目为例，如 Linux Foundation Energy 或 Eclipse Tractus-X。建立开源社区也是创建和维护生态系统以及建立事实标准的有力手段。

吸引，培养并留住人才

软件（因此也包括开源软件）在许多的产品和领域变得越来越普遍。因此，对于许多公司来说，拥有一个技术成熟且积极进取的软件开发团队至关重要。这不仅适用于软件或者云计算公司，也适用于其他行业的公司，例如将软件越来越多地集成到产品中的传统硬件制造商，或者因数字化转型而越来越依赖软件的其他公司。一项包含开源贡献和社区参与的开源战略可以起到一下支持作用：

回馈并维持开源的可持续性

开源软件的发展依赖于其社区。如上所述，开源软件的使用有助于降低成本并且加速开发，但这唯一的可能是因为项目背后拥有维护软件的社区。为了保持开源软件开发模式的可持续性，每个开源软件的使用者都有责任思考如何支持这些项目。以下是一些参与和支持的方式：

需要理解的是，虽然使用开源软件无需支付许可费用，但它并非免费可用。为保持这些项目对用户的吸引力，需要稳定的参与和支持。因此，制定适宜的开源贡献战略至关重要。

如何为开源软件(OSS)做贡献

与开源软件生态系统构建良好的关系具有其自身的一系列挑战，但是如果你有一个清晰地计划可供遵循，这会变得更容易。这里给出一些组织可以采纳的多种实践指南。

明确你的开源目标和战略

你的开源战略将管理、参与和创建开源软件的计划与这些计划服务的业务目标相结合。这可以带来许多机会并促进创新。TODO Group 提供了一份关于制定开源战略 的专门指南。

建立开源指导原则与流程

指导原则

以下描述的流程旨在确保公司利益及其员工得到保护。我们还需要确保所做的贡献符合版权法、出口规定、数据保护规定和开源开发的最佳实践。另一方面，对于所有涉及的利益相关者来说，流程负担应尽可能低，审批流程也不应该花费太多时间。

责任：决策权在于部门

流程的一般结构和范围

精简流程

边界条件

公司审批贡献流程

为何需要审批流程？

为何需要遵循特定的程序？

首先，版权发有明确规定。

例如，《德国版权法》第 69b 条规定：受雇于某人或为某人服务的作者（1）若计算机程序是雇员在其职责范围内或按照雇主的指示创作的，则雇主应独家享有对该计算机程序的所有经济权利，另有约定的除外。

来源：《德国版权法》

这意味着，在此背景下开发的所有软件均属于雇主的财产，即开发人员工作的公司所有。《德国版权法》至少没有将所有权限定于工作时间或公司IT基础设施内开发的代码，它只界定了背景范围。

其次，需要遵循一定的程序来确保公司的商业利益以及保护员工。最后，公开代码既是公司的商业名片，也是编写该代码的开发者的名片。

对外贡献者许可协议（CLA）

一些开源软件项目以及开源软件基金会，在接受贡献之前，会要求签署贡献者许可协议（CLA）。我们至少知道两种不同类型的 CLA：

项目是否不需要，或者需要其中一种或两种 CLA，通常会在项目仓库中的 CONTRIBUTING.md 等文件中说明。APache 基金会制定的 CCLA 和 ICLA 是 CLA 的实际标准，许多开源软件项目已经采用其中的一种或者两种。

贡献者协议（CLA）的目的是给开源软件（OSS）项目提供信心，即贡献者有权提交其贡献。开发者原创证书（DCO）是一种替代方法，与CLA相比更加轻量级。

一些贡献者协议（CLA）还会要求将额外的权利转移给项目，例如以额外的、通常是专有许可证发布代码的权利。这是一种不对等的设置，不利于贡献者。因此大多数公司将不会向此类项目贡献代码。

开源软件项目提升信心的代价是贡献者所在的组织需要承担更多的额外工作。尤其是在拥有多家附属公司的大型企业中，评估、签署和维护企业贡献者许可协议（CCLA）所需的工作量不容小觑。

为什么大型组织使用企业贡献者协议（CCLA）会带来额外的工作量？让我们以 Apache 基金会的 CCLA 为例来简单的看一下为什么造成这种情况:

一些 CCLA 要求将贡献的版权转让给 OSS 项目/基金会。版权转让是一个需要付出更多努力的话题，并且可能根本不会被接受。

除了上面提及的额外工作，CCLA 还给组织增加了额外的“维护工作”，因为它要求组织提名所有有资格的贡献者的姓名给 CCLA 要求方。

您有责任在需要变更代表公司提交贡献的指定员工名单或公司与基金会之间的联系人时，及时通知基金会。

这些额外的努力可能阻止组织向上游的开源软件（OSS）贡献小的漏洞修复、补丁甚至是新的功能，从而使他们面临私有分叉的风险，最终在长远来看带来大量额外的开发工作。因此，关于是否进行贡献的决策需要非常谨慎地做出。

与 CLA 相比，DCO 是一个更轻量级的过程。它被引入是为了增强人们对 Linux 内核贡献者所做贡献是“合法正确”的信心。许多开源项目都使用 DCO 1.1 版本。

DCO 与 CLA 相比主要的区别在于，DCA 不是一份合同，而是一种来自特定贡献者的证明，表明他们有权提交具体的贡献代码。因此，签署和维护 CLA 所花费的精力在 DCO 中是不需要的。需要执行的任务仅有：

因为 DCO 1.1 版本是“标准”，因此“法务部门”和“知识产权部门”仅需要花费很少的精力。

向现有项目贡献的流程

发布已开发的代码所处的业务环境越复杂，涉及的利益相关者就越多。下图展示了一个涉及所有职能的程序，即使在复杂的情况下也能适用。

contributions

使用的缩写

上述过程不适合频繁贡献者和/或在日常工作中“上游”工作的贡献者。对于这些开发者，需要建立不同的流程，以避免给他们承担“非生产性”工作负担。组织中可以建立不同的共享模型，以满足不同的需求。

贡献模式

以下方法适合这类开发者：

small-contributions

小型贡献模式或者微贡献模式

小型或者微型贡献是指对现有开源软件进行一些较小且简单的改动。这类贡献的典型例子包括漏洞修复，但这些漏洞的知识产权价值通常较低或者没有。

以下情况不属于微型更改：

该程序适用于小贡献。在首次向特定开源开源软件项目或组件贡献代码后，可以对小贡献或微型贡献采用该程序。首次贡献必须经过完整流程（如上所述），因为该项目可能需要检查并签署贡献者协议（CLA）/开发者证书（DCO）等文件。在首次贡献代码后，所有后续的小型贡献都可以直接提交给该开源软件项目，无需再遵循既定程序，也不管该项目处于哪个版本。

主要版本到主要版本的发布模式

该过程规定了向开源软件项目提交贡献的发布周期。它与其他任何贡献具有相同的“起点”——首次贡献必须遵循完整流程，以便确认贡献者协议（CLA）/开发者证书（DCO）等事宜，并获得对特定项目的贡献许可。在首次贡献之后，在新主要版本的开发期间，所有后续贡献都可以直接贡献给开源软件项目，而无需经过审批流程。对贡献的大小没有限制。贡献可以是从简单的错误修复到添加新功能、更改接口、重构等。在项目主要版本发布后，针对主要版本发布后的首次贡献，必须启动新的审批程序。

完全信任模式

完全信任模式适用于已经成功遵循主要版本到主要版本发布模式的开发者。这是一种对员工的激励以及雇主对员工信任的表现。基本上，它是允许开发者在没有任何审批程序的情况下“上游”工作的许可。由于该模式仅在开发人员已经成功遵循主要版本到主要版本发布的模式后才会应用，因此无需再进行包含完整审批程序的“初始”贡献，尽管处于文档记录的目的进行初始贡献仍然是合理的。

主要版本到主要版本的发布模式以及完全信任模式应当只能由高级开发者来实施，他们应当接受过专门的版权原则培训，对他们所工作的公司的商业利益有深入的了解，践行“主人翁文化”，并在开源生态系统中拥有丰富经验。

为了追踪所有贡献，开发者们应当使用其官方电子邮件地址进行贡献。

批准项目贡献

另一种模式是为具体的项目提供审批。这些项目已经被例如 OSPO 进行检查，如果一切就绪，允许员工贡献代码，则项目会被批准接受贡献。然后，对于每个具体的贡献就不再需要进行单独审批。但是，如果项目的总体条件发生改变，例如许可证或者引入 CLA 等，项目需要由 OSPO 重新进行批准。

这种模式的前提条件是贡献者们具备自主进行贡献的资格。这可以通过确保贡献者们已经受到培训和/或追踪和批准哪些人可以向哪些仓库贡献代码来实现。

业余时间贡献——也称为“兼职”

当员工们想要在业余时间为不属于公司范畴的开源软件（OSS）项目做贡献时，应该怎么做？

在这种情况下，版权所有权将归开发人员所有（假设他们不是为其他实体开发软件）。为了清楚起见，可以实施以下程序：

开发者告知他或她的经理打算为某个项目（不属于德国版权法的第 69b 中的范围）做出贡献的意向。如果经理没有异议，他/她可以起草一份简短的说明，至少包括以下内容：

可以将这份说明发送给人力资源（HR）部门，并将其保存在员工的人事档案中。

该程序提供了透明性，尤其是在那些涉及多个软件技术领域的大型企业情况下。

下面的例子将阐述为什么这样的程序是有意义的：

例如，根据职责，开发者可能是实现 Linux 内核驱动。开发者另一个感兴趣的领域比如是人工智能（AI），其想要在业余时间为 AI 项目做贡献。由于 AI 项目与 Linux 内核驱动开发没有关系，因此开发者对自己贡献的代码拥有版权以及版权所有权不用转移给雇主。开发者在贡献代码时不需要经过雇主批准。

但是，当开发者决定转到公司内部另一个开发 AI 的部门时会怎么样？突然之间，以前被视为“兼职”的工作现在就属于著作拳法第 69b 条的规定，著作权的所有者也变成了雇主。

上述程序在整个过程中提供了关于版权所有权及其变更的透明度。

培训

开源项目贡献者需要一定程度的自主性才能发挥作用。对一些公司软件开发者来说，参与开源社区也是一个新兴事物。出于这些原因，支持企业贡献者并为他们提供培训或其他类似手段，帮助他们发展理解和技能，以代表公司成为开源世界的好公民，这一点至关重要。

这些可以通过指导，良好的实践指南，或者培训来实现，其包括以下主题：

启动开源项目

动机

有许多好的理由启动自己的开源项目。请查看介绍中描述的如此做的动机。

启动一个新的开源项目与产品发布类似，它首先是一个软件开发项目——在规划、预算、人员配备和测试等方面，它与内部软件项目开发没有区别——唯一的区别是，所有工作都在公共领域进行。请注意，公开可用的源代码是组织在软件生态系统中的“名片”，也是其维护者的“名片”。

当考虑启动自己的开源项目时，这里有几个阶段你应当考虑：

oss-project-process

项目生命周期

开源项目的生命周期描述了项目从构思到退役或者生命周期结束阶段的演变过程。通常，一个项目是为了解决某个特定的问题而产生的。它可能会因为问题不在存在或因为其他项目更适合解决该问题而变得过时。下面的图展示了开源软件项目可能经历的不同阶段。

Typical lifecycle of an open source project

规划或者构思阶段

这是每个开源项目的开始。它也可以被称为“初始化阶段”。通常，在该阶段，只有一个想法存在或者一个特定的已经明确的问题需要解决方案。在这个阶段，开源项目具有以下的典型特征。

在启动一个项目之前，合理的做法是获得以下关键问题的答案：

（来源：Linux 基金会）

另外，在规划阶段还应考虑以下几个方面：

活跃或开发阶段

项目一旦获得开源批准，并且代码已经发布可用，项目就进入了活跃开发阶段。在这个阶段，开源项目通常具有以下特点：

在活跃阶段，应当考虑以下方面：

成熟或者维护阶段

在某个时间点，开源项目变得成熟。这也可以称为“维护阶段”，意味着只进行错误修正，通常不再开发新功能。以下是这个阶段的特点：

废弃或者生命周期结束阶段

开源项目处在这个阶段具备以下特征：

当选择许可证时，以下的问题需要考虑：

回答这些问题可能具有挑战，并且观点会因人而异。一个简单的起点可以是使用choosealicense.com这个网站。此外，从各种来源都可以找到大量综合材料，例如Open source licenses: What, which, and why（开源许可证：是什么、选哪种以及为什么）。

建议制定许可证选择策略，以便在启动新项目时简化决策过程。

贡献者许可证协议（CLA)，开发者原创证书 （DCO）

当运营一个开源向目时，你需要决定如何检查代码的来源，以及是否需要从贡献者那里获取许可证未授予的额外权利。主要有三种方式来处理这些问题：

你应当制定一个策略，明确在何种情况下使用哪种方式。“Inbound=Outbound”是一种务实的方法，适用于大多数项目。DCO 是一种使贡献过程更加明确的好方法，尤其适用于具有众多贡献者的较大项目。CLA 使得贡献变得更加困难，并且需要额外的管理工作和工具。要了解大型企业面临的额外工作量和困难的详细信息，您可以查看关于向现有项目贡献的部分。

项目治理

开源项目成功的关键因素之一是其治理结构。这包含了协作的规则、策略、习惯和文化。 它决定了诸如如何做出决策、谁控制项目以及谁可以加入项目等因素。

在现有项目中，治理通常随着时间的推移而逐渐形成，从由项目创始人的实践所驱动的非正式程序，发展为在贡献指南中更为正式定义的治理结构，或者最终通过一个托管项目的正式组织基金会来制定。

当启动一个新的开源项目时，你应当决定治理结构是什么样的。这不仅仅是选择许可证的问题。你还需要决定商标或域名等资产的所有权，以及它们的使用规则。此外，您还需要决定人员如何成为提交者或维护者、版本发布和路线图的制定方式，以及决策过程的透明度等方面的政策。

对于旨在吸引大量贡献者的项目，重要的是建立一个能够提供中立平台、对不同参与者开放参与并且决策过程透明的治理结构。这可以称为开放治理。实现这一目标的一种方法是加入现有的开源基金会之一。杰出的例子包括由 CNCF（云原生计算基金会）托管的 Kubernetes 项目,以及隶属于 Eclipse 基金会的 Eclipse IDE 项目。

在其他情况下，公司可能想要保留对项目更多的控制权。这将限制其他人的贡献，但也给了公司更多的自由引导项目发展的方向。这要求分配足够多的资源来维护项目。尽管如此，实施开放治理的某些元素仍然是有帮助的，例如提高项目规划的透明度或实施宽容的商标政策以增加项目的采用率。这方面的例子包括由 Google 运营的 TensorFlow 和由 Microsoft 运营的 Visual Studio Code。

对于规模较小的项目，例如从其他项目工作中衍生出来的技术工具，也可以采用简单且不太正式的治理方式。在这种情况下，主要目标不是广泛采用或建立大型社区，而是保持透明度和与感兴趣的个人进行临时写作。这类项目往往更多地有技术需要和开发者动力驱动，而不是有总体业务需求驱动。如果这样的项目不断发展壮大，其治理方式也可以逐步演进。例如，项目可能会转移到某个基金会。在 GitHub 上可以找到无数这样的例子。

您可以从最小可行治理框架或面向开源和自由软件项目的法律问题入门找到有关开源项目治理的更详细信息和可能的入门指南。

不同的项目级别

对新开源项目设置不同的级别（“沙箱”，“孵化器”，“毕业”）是有意义的。 例如CNCF 的项目级别就是这样划分的。这是一种根据采纳度、成熟度和质量标准对项目进行分类的方法。基本思路是，新项目在一个专用空间内开始（CNCF 称之为“沙箱”，在 Meta 则为“孵化器”项目，如 “Incubator”）。在这个空间里，项目可以不断发展，并检查是否达到了在采纳和质量方面设定的目标。如果达到了，项目就可以晋升到下一个级别；如果没有，则可能会决定停止项目。这种分级制度有助于确保项目的质量和可持续性，同时也为项目提供了成长和发展的空间。

社区管理

对于大部分开源项目，围绕项目建立社区并接收贡献是一个重要目标，甚至可以说是首要目标（不过也有一些项目开源的主要目的并不是建立活跃的社区，例如通过公开源代码来建立信任，在这种情况下，获得贡献的优先级可能会较低）。这样的社区并不是自然而然形成的。启动和维持它需要计划、预算和资源。初始和持续的活动包括：

建议为项目分配一名社区经理，负责这些任务。TODO Group 指南启动开源项目中“构建社区”的章节包含更多信息。如需进一步阅读，我们推荐 TODO Group 指南中的“构建包容性开源社区”和“在开源社区中培养领导力”。

行为准则

营造一个安全友好的环境，让人员免受他人有害行为的侵害，是维护健康社区的重要组成部分。尤其重要的是支持多元化的社区，避免对少数群体的歧视，解决显性和隐性的偏见问题。

维护健康社区环境的一个常见要素是行为准则，它明确规定了可接受和不可接受的行为规则，并定义如何处理不可接受的行为。有许多示例和模板可以作为您行为准则的基础。一个广受欢迎的、可重复使用的行为准则是贡献者公约 (Contributor Covenant)，它被诸如 Kubernetes、git、Node.js 等许多项目所采用。

作为一家公司，你需要提供一个用于举报违反行为准则情况的电子邮件地址。您需要确保该地址由能够及时响应、具备处理此类问题的能力的人员负责控制。

技术考量、工具与最佳实践

合适的工具能够节约大量时间，并显著帮助自动化流程。开源项目管理工具精选列表包含了经过验证和推荐的工具的综合列表。

用户管理

通常，Git 提供商（GitHub、GitLab、Bitbucket 等）提供定义由单个用户组成的团队以及设置团队和个人级别（访问）权限的方法。为了使用 Git 提供商的服务，工程师需创建相应的账户。此账号与工程师在公司的内部账户无关。这会带来一些挑战，因为工程师对外部仓库的访问权限可能依赖于他们在公司内的角色或者他们是否仍然在公司工作（假设工程师在为贵公司工作期间获得外部仓库的全面权限，而现在他们已经离职——您可能想要调整访问权限）。但是如何做到这一点，因为工程师在 Git 提供商的外部账户独立于其公司内部用户账户？需要某种方式在两个账号之间建立映射。对于 GitHub，可以使用开源工具 opensource-portal 来帮助创建这样的映射。它还可用于实现加入 GitHub 组织的自助服务。作为该过程的一部分，该工具会建立了 GitHub.com 账号与其对应公司内部用户账号之间的映射。映射存储在数据库中。在此基础上，可以轻松创建一些工具，定期检查数据库中包含的所有用户是否仍在贵公司任职，并在情况不成立时出发某些活动。

设置仓库

在代码仓库包含一定的文件集合（健康文件）是一个良好的做法。这些文件包含仓库的基本信息，例如描述、行为规范、许可证、贡献指南等。这些文件通常以 markdown 格式，但根据Git提供商的不同，也可以采用其他格式，例如 AsciiDoc。在这里，我们假设默认格式为 markdown，因此使用文件后缀名.md.

对所有仓库来说，都应当包含 README.md 和许可证的文本文件。其余的文件可以被视为可选的，只在需要时才创建（例如，如果不接受任何贡献，则可以将此信息放入 README.md 中，这样就不用需要创建 CONTRIBUTING.md 文件）

为了确保始终创建某个特定健康文件集，我们可以采用以下几种方法：

提供许可证和版权信息

开源软件项目的许可证和版权信息必须正确的声明。这对于项目的使用者和贡献者都是非常重要的。此外，源代码经常从一个项目复制到另一个项目，因此，强制所有文件都必须携带许可证和版权信息是必不可少的。

请注意，像有关许可条件，请查看 LICENSE.txt 这样的声明是不合适的。

来自欧洲自由软件基金会 (Free Software Foundation Europe)的 REUSE 工具支持您项目的许可和版权信息的正确声明：

CLA/DCO 管理

如果贡献者在可以提交贡献代码之前，必须要接受 CLA 或者 DCO，那么尽可能的自动化该过程是有益的。TODO Group 提供了一份工具列表，支持 DCOs 或 CLA 文档的管理和签署。作为例子，我们将更详细地描述 CLA Assistant。

CLA 助手 （CLA Assistant）实现了一个工作流程，要求贡献者在向 GitHub.com 上的特定仓库提交首个拉取请求时接受/签署一份文档。尽管该工具的名称为 “CLA 助手”，但它可以用于公司要求贡献者在提交拉取之前接受的任何类型的文档，包括 CLA 和 DCO。文档文本必须作为 GitHub.com 上的 gist 提供。要使用的文档/gist 可以在组织和仓库级别进行配置。CLA 助手使用默认逻辑：如果某个代码仓库没有配置特定文档，则会使用组织级别配置的文档。当贡献者首次向仓库提交拉取请求时，CLA 助手会显示文档文本，并且只有贡献者接受该文档内容后才能提交请求。接下来，当统一为贡献者提交拉取请求，他们可以直接提交，无需再次接受该文档。贡献者接受仓库文档的信息会存储在 CLA 助手的数据库中，以后可以检索。CLA 助手可以在https://cla-assistant.io/上作为托管服务提供，也可以自行托管。

凭据扫描

尽管开源政策和指南明确的要求，在公开代码之前必须移除密码、访问令牌或者其他敏感信息，但有时还是会无意中将此类重要和敏感数据推送到公共仓库。为了尽快发现此类情况（从而能够撤销已发布的敏感信息并从公共仓库中删除该数据），建议定期对此类仓库进行凭据扫描。幸运的是，所有知名的代码托管平台（如 GitHub.com、GitLab.com 等）都提供此类扫描服务作为其服务的一部分。我们强烈建议使用这些服务。

质量标准/CII最佳实践徽章计划

核心基础设施倡议（CII）创立了CII 最佳实践徽章计划，该计划现在由开源安全基金会继续推进。作为该计划的一部分，它定义了开源软件的最佳实践，并实施了徽章系统。项目可以通过网络应用程序自我认证是否符合标准，并在其网站上展示相应的徽章。截至今天（2022 年 5 月），已有超过 4724 个项目完成了评估。

CII 系统分为三个等级（通过、银级 和 金级 ）。这些等级是层层递进的（即 银级包含了通过等级的所有标准以及额外的标准）。这些标准被划分为不同的类别，包括基础、变更控制、报告、质量、安全和分析。

CII 最佳实践徽章社区开放贡献（例如，提出额外的标准）。

总体而言，CII 最佳实践徽章计划是验证项目是否遵循公认最佳实践的一种好方法。通过徽章，项目可以证明其符合这些标准。

代码仓库审查

代码仓库审查器是一种自动化工具，用来检查代码仓库是否遵循公司为其公开开源仓库定义的指南。TODO Group 提供了可用于此目的工具列表。代码仓库审查器通常会检查以下方面的标准：

然而，它们检查的标准因公司而异，因此，它们通常提供配置规则的可能性（例如，作为 JSON 文件，正如 TODO Group 的 repolinter所做的那样）。为了获取执行这些检查所需的数据，会使用 Git 提供商（如 GitHub.com、GitLab.com、Bitbucket.org 等）的 API。检查结果通常会在用户界面上提供。如果检查失败，另一种选择是在相应的仓库中自动创建问题。此类审查器的典型使用场景包括：

在发布开源项目时构建开源指标策略

一旦为公司对外开源计划制定了目标，流程和工具，随着公司参与的开源项目不断发展和成熟，持续监测和追踪这些项目的整体健康状况变得非常重要。

在考虑使用哪些巩工具来追踪项目的健康状况之前，一个更好地替代方案是遵循目标——问题——指标（goal-question-metrics）方法来建立完整的指标策略。这种方法常用于关注社区健康分析指标标准和软件的社区，例如 Linux 基金会旗下的 CHAOSS 项目。

定义社区健康目标

有时候，最好从小处着手，先定义两个或三个主要目标，避免被指标淹没。如果你不知道从哪里开始，CHAOSS 提供了一套基于不同关注领域和目标的项目健康衡量指标，可以帮助您开始衡量对您组织至关重要的开源项目的健康状况：

创建问题和构建相关指标

指标应当回答与先前设定的目标相一致的具体问题。

例如，如果你的公司的目标之一是了解项目内的社区足迹，那么一个很好的问题可以是：“在开源生态系统中，组织的存在和影响力如何？”为了解答这个问题，一个有用的指标是“大象因子”，即员工贡献了总贡献量 50% 所需的最少组织数。

有很多优秀的工具可以帮助你度量不同的社区健康分析指标，例如 GrimoireLab、LFX 或 Augur。

如需更多关于跟踪项目健康状况的工具的信息，请查阅 TODO Guides 中的专门部分。

参考文献与缩写

缩写

参考文献

附录

在 git 中管理工作与个人电子邮件

在开源领域，人们可能拥有一个早于其加入我们当前组织的线上身份。同时，组织可能希望代表他们进行的贡献使用公司电子邮件进行。

解决这一问题的一种方法是，在每个仓库的基础上对其提交电子邮件进行编码，例如：

git config user.email "simba@special-email.example.com"

如果你管理多个仓库，这将会变得难以管理且容易忘记。相反，我们可以利用 git 的一个功能，该功能允许我们根据不同的目录结构进行不同的配置。

我们的 ~/.gitconfig 文件可能类似于：

[user]
	name = Simba Lion
	email = simba@personal-email.example.org

[includeIf "gitdir:~/my-company/"]
    path = ~/my-company/.gitconfig

这设置了我们的默认电子邮件（在这种情况下，是个人账户的电子邮件）。如果我们在 ~/my-company 目录下有仓库，我们将会加载一个额外的 git 配置文件，该文件位于 ~/my-company/.gitconfig。该文件可能看起来像这样：

[user]
	email = simba@very-corporate-email.example.com

现在，当用户提交更改时，它将默认使用期个人电子邮件，或者对于 ~/my-company 文件夹内的任何仓库，它将使用其公司电子邮件。请注意，name 属性是从基础配置中继承的，因此我们不需要重复指定它。