越来越多的模式是由InnerSource Commons社区贡献给本书的。这真是太棒了!

现在，如何让读者更容易发现那些能在特定情况下帮助他们的模式？

为此，我们提供了这个思维导图。它根据内源项目的不同阶段对模式进行了分类，以及在各个阶段可能出现的挑战。

改进这个思维导图

如果你注意到这个思维导图中的任何问题，请打开一个问题，描述这个问题以及应该做的修正。

此外，如果你有其他想法来提高这些模式的可发现性，或者想让这个思维导图变得更好，请查看我们的模式归类方法的文档，也可以查看如何为本书做贡献。

参考文献

像这样对模式进行分类的想法大致是基于Tim Yao、Bob Hanmer和Padma Sudarsan（2018）在有关内源模式语言的思考中的描述。具体内容见该幻灯片中的第15张幻灯片。

翻译校对

• 2022-12-21 翻译姜宁

• 2022-12-28 校对龙文选

Title

以实验的方式开始

Patlet

将内源实践倡议作为一个有时间限制的实验开始，使不熟悉内源的管理人员更容易认可和支持该倡议。

问题

一项内源倡议被考虑但没有开始实施，因为管理层对其结果没有把握，因此不愿意承诺投资。

背景

该公司正在考虑采用内源来提高软件项目开发的协作效率。然而，大多数管理人员并不熟悉开放源码的工作模式，而是习惯于等级制度、自上而下的控制式管理。内源的想法在该公司的软件开发人员中非常流行，这主要是因为许多开发人员使用或正在积极开发开源软件。

约束

• 在进行长期投资之前，管理人员希望验证通过内源改善协作的说法。这通常涉及到对协作改进的测量。

• 如果内源计划在开发者中可能有巨大的接受度，如果许多项目可能依赖它，那么关闭它的决定将非常不受欢迎，因此也很难做出。由此产生的控制权的丧失可能会使一些管理人员甚至不敢开始推行内源。

• 实施内源风格的工作模式往往与以前的工作模式截然不同。因此，现有的、强制性的流程很可能不再适用，并且缺少适当的管理流程。其结果可能是，人们不得不在有时是法律上的无主之地监管运作。例如，在多个国家拥有多个法律实体的大公司的税收和出口控制相关法规。

解决方案

宣布内源计划是一个有时间限制的实验。界定并宣传加入内源实验的项目标准。选择能够最大限度地提高建立一个健康社群的实施标准。如果一套标准在实验中积累的洞察指标能够直观地应用于涉及其他潜在内源项目的环境中，那么这就是一个好的标准。

这种标准的例子有：

• 开发者有足够的地理分布

• 足够的开发人员的部门参与

• 社群内交流的开放性

• 社群内基于功绩的职业道路

• 社群内的民主决策

考虑将实验结束时指定为_支点_、_变化_或_暂停_点，以重新评估。还可以考虑建立一个评审委员会，通过参与增加管理层认同的机会。根据公司文化，在实验中加入适当的指标，设置指标的第一步可能会有帮助。如果实验中的项目没有对公司的收入产生直接影响，可以考虑引入跨团队的项目评估来强调其价值贡献。

结果

管理人员能够启动内源的原因如下：

• 实验性的设置减轻了管理人员对内源项目数字的审查需要，就像他们对典型项目的审查一样。

• 实验失败的可能性被理解和接受。管理人员支持内源的个人风险被降至最低。

• 即使在失败的情况下，这种设置也能确保公司将从实验中学习。

• 在成功的情况下，实验期间收集的数据将使管理人员能够对内源做出更长期的承诺。

内源实验的参与者现在意识到，他们必须向管理层证明内源产生了承诺的效益。因此，这将有助于将工作重点放在那些能提供最明显价值的活动上，从而增加成功的机会。

最后，作为一个实验开始，它更容易避开可能会减少成功机会的法规和约束，如工具和流程政策。

相关模式

• Trial Run(摘自[无畏的改变]一书)(https://fearlesschangepatterns.com/)

已知实例

• Robert Bosch GmbH (全球分布式软件开发)

状态

• 结构化

作者

• Georg Grütter (Robert Bosch GmbH)

致谢

• Jason Zink (Robert Bosch GmbH)

• Diogo Fregonese (Robert Bosch GmbH)

• Robert Hansel (Robert Bosch GmbH)

• Hans Malte Kern (Robert Bosch GmbH)

• Russ Rutledge (Nike)

• Tim Yao (Nokia)

• Clint Cain (Optum)

翻译校对

• 2022-12-06 翻译姜宁

• 2022-12-21 校对龙文选

• 2023-06-18 最后更新日期

Title

代码仓活跃度评分

Patlet

潜在的贡献者希望找到需要他们帮助的活跃的内源项目。通过计算每个项目的代码库活跃度评分，可以创建一个项目的排名列表（例如在内源门户网站上），这样潜在的贡献者可以更容易地确定他们想要贡献的项目。

问题

内源项目应以何种顺序呈现？典型的排名指标，如GitHub星数、复刻（fork）数、提交数、代码行、最后更新，都不足以简明地表明项目的活动。

活跃的项目有很多吸引力，但也有相当新的和热情的项目，需要新的贡献者，应该比活动很少或处于维护模式的成熟项目排名更高。

为了给项目的活动水平定义一个可靠的、通用的分数，我们需要一个从几个KPI中得出的新指标。 它可以被用来根据项目的活动水平进行分类排序。

故事

当内源实践了很长时间，或者规模超过了一定数量的项目（比方说50个，给一个有意义的门槛），就很难找到目前最流行和最活跃的内源项目。存在了很长时间的项目是众所周知的，但可能不再是非常活跃的。另一方面，相当新的项目还没有声誉或活跃的社区。

内源项目列表不应该被认为是一个静态资源，而是一个发现和探索新的和活跃的项目的令人兴奋的地方，就像一个新闻页面首先列出当天最有趣的话题一样。因此，当项目的顺序定期更新，并根据项目的受欢迎程度和活动情况而改变时，这是很有好处的。

这些考虑导致了第一个计算代码库活跃度评分的原型，它的效果出乎意料地好，并根据项目的活动提供不断变化的排名顺序。

背景

发现内源项目可以通过内源门户网站和零工市场模式，或者通过在其他交流渠道和平台上推广项目来实现。活跃度评分定义了项目被展示给社区的默认顺序。

约束

通过查询GitHub的API可以自动获取到和代码开发相关的关键绩效指标。那么如何评价，代码质量、良好文档的可用性，或者使项目成为一个有趣的贡献场所的活跃和互助的社区呢？

这些 "软"的关键绩效指标必须手动或半自动地添加到计算中，并得出分数。如果有工具可以为代码库提供更多的背景，如代码覆盖率报告，它们可以很容易地被加入。

素描

一个集中的方法来计算和应用代码仓活跃度评分。更多细节，见结果

解决方案

代码仓活跃评分是一个数值，代表内源项目的（GitHub）活跃度。它是由GitHub星数、关注和复刻等代码仓库统计数据自动得出的，并可以用其他工具或人工评估的KPI来进行补充。

此外，它还考虑了活动参数，如 repo 的最后更新和创建日期，以便为具有大量吸引力的年轻项目提供助力。 拥有贡献指南、积极参与的统计数据和问题（公共backlog）的项目也会获得更高的排名。

所有这些都可以通过GitHub搜索API和GitHub统计API的结果集来自动获取和计算。如果有类似的API，其他代码版本系统如BitBucket、Gitlab、Gerrit也可以被整合。

下面的代码假设变量repo包含一个从GitHubsearchAPI获取的实体，participation对象包含一个来自GitHubstats/participationAPI的实体。

如果需要，可以根据软的关键绩效指标（见约束）在上面进行手动调整。

// 从标星、关注、提交和问题中计算出一个虚拟的内源分数
function calculateScore(repo) {
    // 初始分值为50分，作为GitHub KPI（复刻、观察者、标星）较低的活跃仓库一个的起点
    let iScore = 50;
    // 权重：复刻和关注最多，然后是星标，对没有关闭的问题也加一些小分
    iScore += repo.forks_count * 5;
    iScore += (repo.subscribers_count ? repo.subscribers_count : 0);
    iScore += repo.stargazers_count / 3;
    iScore += repo.open_issues_count / 5;

    // 在过去3个月内更新：给总分增加一个0...1的奖励乘数（1=今天更新，0=100天以前更新）
    let iDaysSinceLastUpdate = (new Date().getTime() - new Date(repo.updated_at).getTime()) / 1000 / 86400;
    iScore = iScore * ((1 + (100 - Math.min(iDaysSinceLastUpdate, 100))) / 100);

    // 评估过去3个月的参与统计
    repo._InnerSourceMetadata = repo._InnerSourceMetadata || {};
    if (repo._InnerSourceMetadata.participation) {
        // 平均提交量：为总分增加一个0...1的奖励乘数（1=每周提交量大于10，0=每周提交量小于3）
        let iAverageCommitsPerWeek = repo._InnerSourceMetadata.participation.slice(-13).reduce((a, b) => a + b) / 13;
        iScore = iScore * ((1 + (Math.min(Math.max(iAverageCommitsPerWeek - 3, 0), 7))) / 7);
    }

    // 加分计算
    // 所有在前一年更新的资源库都将获得最大1000的加分，并按上次更新后的天数递减
    let iBoost = (1000 - Math.min(iDaysSinceLastUpdate, 365) * 2.74);
    // 根据资源库的创建日期，逐步缩小加分的规模，与 "真实 "的参与统计相混合
    let iDaysSinceCreation = (new Date().getTime() - new Date(repo.created_at).getTime()) / 1000 / 86400;
    iBoost *= (365 - Math.min(iDaysSinceCreation, 365)) / 365;
    // 在总评分中加分
    iScore += iBoost;
    // 给予有意义的描述的项目以50的静态加分
    iScore += (repo.description?.length > 30 || repo._InnerSourceMetadata.motivation?.length > 30 ? 50 : 0);
    // 给予有贡献指南（CONTRIBUTING.md）文件的项目以100的静态加分
    iScore += (repo._InnerSourceMetadata.guidelines ? 100 : 0);
    // 为非常活跃的项目建立一个对数表（不限，但稳定在5000左右）
    if (iScore > 3000) {
        iScore = 3000 + Math.log(iScore) * 100;
    }
    // 最终得分是一个从0开始的四舍五入值（减去初始值）
    iScore = Math.round(iScore - 50);
    // 为元数据添加分数
    repo._InnerSourceMetadata.score = iScore;

    return iScore;
}

结果

贡献者可以自由地将他们的一部分时间投入到内源项目中。他们可以选择为一个他们在常规团队中依赖的项目做出贡献。然而，他们也可以根据自己的兴趣和个人发展目标，选择为一些完全不同的项目做贡献。

项目可以按照资源库活动得分进行分类和展示，在向潜在的新贡献者展示项目的门户中给出一个有意义的顺序。分数可以即时计算，也可以在后台工作中计算，定期评估所有项目并存储结果列表。

一个定期搜索所有内源仓库的爬虫（例如在GitHub中被标记为某个主题）也可以是一个有用的补充。它提供了一个经过排序的项目列表，可以作为内源门户、搜索引擎或互动聊天机器人等工具的输入。

原理

仓库活跃评分是一个基于GitHub API的简单计算。它可以完全自动化，并容易适应新的需求。

已知实例

• 在SAP的内源项目门户中使用，用于定义内源项目的默认展示顺序。它首次创建于2020年7月，此后经常进行微调和更新。在2020年7月向 InnerSource Commons 提出时，出现了这种模式。另见Michael Graf & Harish B (SAP) at ISC.S11 - 不知不觉实现了一个内源模式。

状态

• 结构化

作者

Michael Graf (SAP)

致谢

感谢 InnerSource Commons社区光速提供的建议，以及大量有益的意见，不断完善这个模式。特别感谢：

• Johannes Tigges

• Sebastian Spier

• Maximilian Capraro

• Tim Yao

翻译校对

• 2022-12-08 翻译姜宁

• 2022-12-16 校对龙文选

• 2023-06-18 最后更新日期

Title

30天保修

Patlet

当接受来自自己团队以外的贡献时，人们自然不愿意为非本团队自己编写的代码负责。通过30天保证，贡献团队同意向接受团队提供错误修复，这将增加两个团队之间的信任度，使贡献更有可能被接受。

问题

一个团队开发了一个在整个组织中使用的组件。 这个团队抵制接受或直接拒绝贡献（功能请求）。 这种行为阻碍了正常的项目研发，并导致了事态升级使得项目开发受到影响。

上下文

• 团队依赖另一个团队接受他们的贡献，以便接收团队生产的组件能够被贡献团队使用。

• 接收团队没有资源、知识、许可和/或倾向于自己编写贡献的组件/功能。

约束

• 由于过去的作弊历史，人们对贡献存在不信任：团队提交了半成品的贡献之后，通过提出后续的修复请求，使其可以在生产中使用。

• 如果代码是由团队以外的人贡献的，团队自然会怀疑其他团队不知道如何编写符合接收团队期望的代码。

• 每个团队首要考虑的是帮助自己的领导实现自己的目标。这样忠诚度会使这个问题的解决变得复杂。

• 人们对承担非自己编写的代码的责任有一种自然的厌恶。

• 贡献的代码在被代码库接纳之前需要进行大量的重写。

• 人们担心贡献者在贡献被接纳之后无法提供修复错误的支持。

• 团队担心贡献的代码会导致高额的维护成本，并担心如何控制这些维护成本。

• 接收团队可能会担心，教别人如何贡献代码会暴露他们系统中的技术债务，并引发其他的伤害。

• 接收团队可能不相信，无论他们提供何种程度的指导，都能得到可接受的代码。

• 大家对衡量风险或证明风险在贡献中得到缓解缺乏信心；系统本身的脆弱性（可能没有办法完全测试和捕捉所有问题）。

解决方案

通过建立一个30天的保证期来解决接收团队和贡献团队的担忧，保证期从贡献的代码投入生产时开始计算。在这个保证期内，贡献团队承诺向接收团队提供问题修复。

请注意，保证期也可以是45、60或100天。持续时间可以根据项目的限制、项目的软件生命周期、对客户的承诺和其他因素而变化。

此外，提供明确的贡献指南，阐明接收团队和贡献团队的期望，也是有帮助的。

结果

• 接收团队愿意接受贡献，并能分担初步改编/修复的工作量。

• 增加透明度和公平性。

• 使得维护工作不至于变得过于沉重。

已知实例

• 这在 PayPal 得到了成功的尝试和证明。

• GitHub 内部使用这种模式，修改后的保证时间线为6周。

• 微软推荐这种模式作为一个内部原则--团队设定自己的具体时间目标，与他们的需求和信心相匹配。

作者

• Cedric Williams

致谢

• Dirk-Willem van Gulik

• Padma Sudarsan

• Klaas-Jan Stol

• Georg Grütter

状态

• 结构化

• 在2017年春季内源峰会上起草；2017年7月18日审查。

变体

• 确保相互由依赖关系团队的合作，让他们成为一个社区，由一个以上的、以择优任命的"trusted-committer"（TCs）负责。

翻译校对

• 2022-12-01 翻译姜宁

• 2022-12-09 校对龙文选

• 2023-06-18 最后更新日期

欢迎来到内源模式。

这本书包含了内源的最佳实践，并以特定的格式进行编纂，以便于理解、评估和在你的环境中应用它们。我们称这种格式为模式。

InnerSource Commons多年来收集了这些模式，在本书中发布了最成熟的模式，社区成员对每个模式进行了评审，至少有一个已知的模式使用实例。

在这篇介绍中，我们解释了内源是什么，内源模式是什么，以及如何在你的组织中使用这些模式 。

如果你已经在你的公司使用内源，并想把你的经验贡献给本书，我们很乐意欢迎你的贡献!

内源是什么?

我们将内源定义为。

在一个组织的范围内使用开源的原则和实践进行软件开发。

内源从开发开源软件中吸取经验教训，并将其应用于企业内部开发软件的方式。由于开发人员已经习惯于在世界级的开源软件上工作，人们强烈希望将这些实践带回防火墙内，并将其应用于公司可能不愿意公开发布的软件。

对于那些主要构建闭源软件的公司来说，内源可以成为一个很好的工具，帮助打破孤岛，鼓励和扩大内部协作，加速新工程师的入职成长，并找到机会将软件贡献给开源世界。

内源模式是什么?

模式是一种描述在某一背景下对某一问题的可重复的、经过验证的解决方案的方式。模式遵循一种简单的形式，在实施解决方案的过程中，协助你了解问题的限制，了解你需要平衡的限制条件，以及由此产生的结果--应用解决方案所创造的情况。

模式可以为InnerSource Commons的参与者提供一种简明的信息分享方式，改善内源的实践。模式分为标题、问题陈述、背景、约束和解决方案，作为其主要部分。

• "什么是模式？"Youtube视频 - 观看一组2-5分钟的Youtube视频，解释内源模式。

• 模式讨论网络研讨会 - 我们在2017-03-16举行了一次网络研讨会，现场讨论一个甜甜圈模式(进入24:30的讨论)。这是对我们所遵循的评审过程的说明。也可参见2017年6月1日O'Reilly网络研讨会上的内源模式 。

• 模式模板 --查看一个内源模式的骨架，了解新模式的内容!

• 内源模式介绍（2016年秋季峰会演讲） - Tim Yao和Padma Sudarsan (PDF)。详细的模式背景和例子 -- 详细了解为什么以及如何与我们的模式互动。也可参见内源模式介绍(2017年秋季峰会) Tim Yao和Bob Hanmer (PDF)。

如何使用这些模式?

模式的使用必须经过深思熟虑。它们不能被不加区分地应用。在大多数情况下，你需要根据你的情况来调整给定的解决方案；但模式中给出的信息，定义了背景（不可移动的约束）和力量（可以改变和相互平衡的约束），应该有助于你应用这些模式。请注意，你还需要确定是否有额外的约束（公司背景和公司力量）适用于你的特定公司/组织，必须添加到模式中（作为一种过滤器）。这些额外的制约因素可能需要额外的解决步骤来应用。

模式的形式对于描述成熟的解决方案是很有用的，但它也可以用于脑力激荡的新解决方案，创建哪些尚未建立的模式。这是因为模式的解剖提供了一个以结构化方式思考问题的框架。你也可以创建一个甜甜圈模式（填写问题、背景、约束和结果等字段，但在解决方案留空），作为向InnerSource Commons社区寻求帮助的一种方式（找到一个成熟的解决方案或做一次集思广益的尝试）。

如何贡献?

请参考: 为这本书做贡献

致谢

本书是世界各地无数开源贡献者多年工作的成果。他们愿意公开分享他们在公司所面临的挑战，以及内源如何帮助他们解决这些挑战，使本书成为其他人在内源旅程中的宝贵资源。

我们要特别提到内源模式工作组。他们孕育了内源模式的质量，并帮助其他人作出贡献。最后，他们还将一些可用的模式汇编成了这本书。

本书的标题图片由Sebastian Spier创作，并改编自Tony Hisgett - Alhambra 6的图片，可根据CC BY 2.0获得。

感谢所有的贡献者! 并祝内源日快乐 :)

Licensing

InnerSourcePatterns by InnerSourceCommons.org is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

翻译校对

• 2022-12-21 翻译姜宁

• 2022-12-28 校对龙文选

你想让这本书变得更好？那真是太棒了!

《内源模式》这本书本身就是一个开源项目，欢迎任何形式的贡献。没有什么是微不足道的!

不管你是想帮助我们修正语法/拼写，改进设计，还是根据你在工作场所的内源经验贡献全新的模式。我们喜欢所有这些（贡献）! :)

如果你以前从未为一个开源项目做出过贡献，请知道内源模式社区是一个由友好的人组成的团体，并且有一个安全的地方可以尝试这些贡献。

在你开始之前

内源模式和本书的源代码都保存在GitHub上的一个仓库中。因此，你需要一个GitHub用户账户来对本书进行编辑和提交建议。如果你还没有，请前往github.com，免费创建一个账户。

贡献的不同方式

这里有几种你可以做出贡献的方式。

1. 修复你在本书中发现的拼写、格式或其他小问题

2. 改进现有模式的内容（例如，通过添加一个简短的描述，说明你是如何使用一个模式作为_已知实例的）。

3. 贡献一个新的模式，描述你如何在你的组织中克服内源相关的挑战。

对于上述（1）和（2），你可以简单地点击本书每页顶部的Edit on GitHub链接。这将使你直接进入我们GitHub仓库中的相应文件，在那里你可以提出你的修改意见。

对于（3），你需要克隆内源模式资源库，并将你建议的模式添加到一个新文件中。当对本书做出这种较大的贡献时，请查看我们的CONTRIBUTING.md和我们的贡献者手册。

贡献的许可

本资源库的内容以CC-BY-SA-4.0授权。通过向这个资源库贡献，你授予我们（以及其他所有人）根据该许可使用你的贡献的权利。

翻译校对

• 2022-12-21 翻译姜宁

• 2022-12-28 校对龙文选

Title

交流工具

Patlet

一个内源项目正在原始开发团队之外使用，但用户在寻求帮助和与项目团队联系时遇到困难。 我们的想法是建立和记录标准的通信工具，使讨论变得可见、存档和可搜索。

上下文

一个团队依赖于另一个团队的组件。它希望对该组件做出贡献。 即使是书面形式的沟通，也是1对1的方式进行的。

问题

一个团队愿意接受来来自于下游的他们的组件用户的贡献。 由于协调和沟通是以一种点对点的方式进行的，导致了信息共享的不连贯性，收到答复的延迟，贡献者于是在收到明确的答复前会呼叫多个东道主团队成员。

约束

• 东道主团队有兴趣接受贡献，并愿意指导贡献者。

• 团队有很强的口头沟通文化，在建立项目特定的异步沟通渠道方面缺乏经验。

• 沟通渠道可能与应该接触到的特定群体使用习惯相一致，但不是以沟通目标进行选择的。

解决方案

东道主团队需要明确提供公司公开的、存档的、可搜索的、可链接的沟通渠道的好处，公司内部的任何人都可以免费订阅信息。

在精简内源项目的沟通渠道时，目标应该是围绕主题进行沟通，而不是围绕某些人。

• 项目应该有自己的问题跟踪器，东道主团队成员采用公开透明的方式进行结构化的沟通、决策和进度跟踪需求，同时也鼓励下游的用户和贡献者遵循同样的原则进行沟通。

• 该项目应该有一个或多个结构不太严格的讨论渠道。通常情况下，这将是邮件列表、在线论坛甚至是存档的聊天频道。通常情况下，项目开始时只有一个频道就足够了，如果流量增加太多，把关于项目使用的讨论和关于项目开发的讨论分开是有帮助的。

• 此外，项目应该有一个私人频道，可以在 Trusted Committer 之间进行敏感的交流--例如，将更多的 Trusted Committer 加入到东道主团队中。这个渠道的使用应该非常谨慎，因为沟通默认为公开的，只有在非常罕见的情况下才会保持私密。

虽然沟通可以发生在书面渠道之外，但尽可能多的信息应该被带回异步渠道。

所有的通信渠道都应该在项目的README.md中进行记录。东道主团队成员需要努力将他们个人收到的问题带回官方沟通渠道。

结果上下文

建立并持续使用官方的异步交流渠道，有助于建立一个基础的被动文档，当类似的问题再次出现时可以再次参考。

随着交流的公开化，其他人可以很容易地关注项目的进展，并积极做出贡献。其他人的聆听和阅读降低了参与的门槛，提高了获得贡献的可能性。

随着问题被公开回答，更多的人可以加入他们的观点，从而形成一个完整的画面--这不仅包括东道主团队成员，也包括项目的用户。

在异步渠道中保持交流，可以让不同时间段的参与者--无论是由于不同时区，还是由于不同的作息时间、会议时间、团队作息时间--对项目做出有意义的贡献。

在这些渠道中回答问题，不仅意味着其他团队成员可以倾听并提供额外的信息，也意味着有相同问题的其他用户可以看到（或后来找到）之前的答案，从而降低重复解释的需要。

已知实例

• Europace AG

• Paypal Inc.

• Mercado Libre

作者

Isabel Drost-Fromm

状态

• 结构化

• 于2019年12月起草。

翻译校对

• 2022-12-06 翻译姜宁

• 2022-12-09 校对龙文选

Title

专职的社群领导

Patlet

选择同时具备沟通和技术能力的人领导社群，以确保成功推动内源倡议。

问题

你如何确保一个新的内源倡议有合适的社群领导来扩大其影响？

如果选择了错误的人和/或没有为他们提供足够的能力，就有可能浪费精力，最终导致新的内源倡议的失败。

故事

考虑一下下面的故事。一家公司想启动一个内源计划，以促进跨越组织边界的合作。他们已经决定从一个范围有限的实验阶段开始。管理层已经为第一个内源社区选择了一个合适的试点主题，并期望来自整个组织的许多业务部门的贡献。公司已经提名了一位新员工来用他工作时间占50%领导社群，因为他还没有打算100%投入其中。6个月后，社群只收到了一些贡献，其中大部分是来自一个业务部门。公司用一个在公司有较长历史的人替换了社群负责人，这次只用了他30%的时间。又过了6个月，贡献的数量仅有小幅回升。该公司不再相信内源能帮助他们实现增加跨部门合作的目标，于是放弃了内源。

背景

• 该公司是一家大型的老公司。它以前没有开源或其他基于社群的工作经验。公司文化的典型特点是自上而下的经典管理风格--它通常与社群文化相抵触。

• 虽然在高层管理中有支持者和赞助者，但公司的中层管理人员还没有接受内源。

• 管理层没有被说服，只能提供有限的预算来资助一个兼职的社群领导。

• 最初选定的社区领袖在开源工作模式方面几乎没有经验。

• 最初选定的开发者社区领袖在公司内部没有广泛的社交网络。

约束

如果一个公司没有在预算和能力方面对最初的内源社群进行大量投资，那么它对内源的承诺的可信度可能会被认为是有问题的。一个具有传统管理文化的公司，如果项目或倡议的表现不尽如人意，其常见的冲动就是更换领导人。在没有社区参与和遵循任人唯贤原则的情况下这样做，将进一步破坏公司对内源的承诺，因为它突出了当前公司文化和目标文化--社区文化之间的摩擦。

内源项目的价值贡献对于许多沉浸在传统项目管理方法中的管理者来说并不明显。这些经理人不太可能把他们的高级人员（通常非内源项目对他们的工作时间优先级要求很高）分配到内源项目中去，来占用他们相当大的工作时间。

沟通在社群领导的日常工作中占了很大比例。同时，他或她很可能也要带头进行初步开发。在能力有限的情况下，没有经验的领导人会倾向于专注于发展，而忽略了沟通。如果社群领导人很难联系上，或者因为没有时间而对反馈和问题反应迟钝，那么潜在的贡献者做出第一次贡献和对社群做出承诺的障碍就会大增。此外，技术上没有经验的领导者很可能比在公司内有很高知名度的顶尖人才更难吸引和保留经验丰富的贡献者。

如果一个社群不能快速成长，不能加速发展，很可能他们就不能令人信服地展示内源的潜力。

如果公司选择一位经验丰富的项目或部门经理来担任社区领导人，他或她很可能会关注传统的管理主题，如资源分配、提供结构和报告渠道，而不是通过任人唯贤的原则以身作则。这将破坏内源项目在开发者眼中的可信度。

解决方案

选择一个社群领导，他：

• 对开源工作模式或类似的社群工作模式有经验。

• 具备必要的软技能，可以作为一个自然的领导者。

• 以身作则，从而证明他在社群中的地位是合理的。

• 是一个优秀的社会网络工作者。

• 激励社群成员。

• 能够有效地与执行管理层和开发人员沟通，并且

• 能够处理社群工作的管理问题。

授权社群领导将其100%的时间用于社群工作，包括沟通和开发。告知管理层，在对社群管理进行改革时，需要对社群的意见保持敏感。理想情况下，授权社群自己提名社群领导。

结果

一个具有上述属性的社群领导将为公司带来面子，体现出公司对内源的承诺。这将使他社交网络中的其他同事更有可能跟随他的步伐，为内源做出贡献。随着时间的推移，他或她将能够建立一个稳定的核心开发人员团队，从而增加内源项目的成功机会。通过说服公司内部足够多的人相信内源的潜力，他或她将为公司文化向社区文化的转变做出重要贡献。

拥有优秀而敬业的社群领导是内源项目成功的先决条件。然而，这并不是银弹。内源有许多挑战，超出了社群领导可以解决的范围，如预算、法律、财政或其他组织挑战。

已知实例

BIOS at Robert Bosch GmbH. 请注意，博世的内源在大多数情况下是为了增加创新，并在很大程度上处理面向内部的产品。由于缺乏资金，这种模式目前在博世没有使用。

别名

专职社群经理

状态

• 结构化

作者

• Georg Grütter (Robert Bosch GmbH)

• Diogo Fregonese (Robert Bosch GmbH)

致谢

• Tim Yao

• Padma Sudarsan

• Nigel Green

• Nick Yeates

• Erin Bank

• Daniel Izquierdo

修改记录

• 2016-11-06 - 第一次评审

• 2017-04-06 - 第二次评审

翻译校对

• 2022-12-06 翻译姜宁

• 2022-12-11 校对龙文选

• 2023-06-18 最后更新日期

Title

不要吝啬对参与者的夸奖

Patlet

及时感谢贡献者对内源项目贡献的时间和付出是很重要的。 这种模式不仅提供了有效地承认了贡献的指导，而且还吸引贡献者和其他人的进一步参与。

问题

我们怎样才能正确地表达我们对贡献者对项目的内源贡献的感谢？ 我们很容易忘记这样做，或者不知道该用什么样的语言或方式来达到足够的效果和诚意。 赞扬和感谢是简单的、低成本的方法，可以激励贡献者和他们的经理保持持续贡献动力。 这方面的模式使赞扬很容易做到，并确保信息能清晰和真诚地传达出来。

背景

• 你是 Trusted Committer 或内源项目的维护者。

• 你重视贡献者的社群，并希望维护和发展它。

约束

• 你很忙，这使得你很容易忘记一些柔软的能触动人心的表达，例如赞美和感谢。

• 你可能不是一个在社交牛人或善于言辞的人。

• 同行的认可对工作满意度和职业发展非常重要。

解决方案

对任何人来说，被他人认可的感觉都很好。 在职业环境中，增加认可也是增加影响力和成长的途径。 任何时候，当有人为你的内源项目做出贡献时，请用一句真诚的、沉甸甸的 "谢谢 "来认可他们。

对于有价值的贡献（所有的代码贡献和重要的时间贡献），通过以下机制说谢谢。

(1) 在你组织项目活动的任何聊天地点（例如 Slack），叫出这个人的名字。 让大家知道他们做了什么并公开感谢他们。

示例：

每个人都@这里给@andrew.clegg击掌，因为他把 rcs-viewer 更新到 hebo-client 的最新版本（https://github.com/rcs/rcs-viewer/pull/81）。 谢谢你帮助更新这个库，Andy!

(2) 给他们和他们的经理（抄送）发邮件，感谢他们的贡献。 对于代码贡献，很多时候你可以直接转发合并通知邮件。

示例：

嗨，安迪，我想再次感谢你的这次更新。 这可能只是一小部分时间，但正是每个人这样的关注才使得RCS项目为我们所有人工作。 感谢你解决了自己的问题，同时也使 rcs-viewer 更加好用。

结果

这样的反馈让贡献者有一种奇妙的感觉，并准备回来继续努力。 同时结合两种形式的感谢，让他们在同行面前（广度）和在直接经理面前（深度）得到认可。 在聊天中，有一种微妙的鼓励，让那些同行考虑自己做出贡献，也让那个经理寻找适当的环境，鼓励他们的直接报告下属也这样做。 此外，不知道团队已经开始的使用和参与内源项目的经理也会了解到内源项目的进展。

有一点需要注意的是--保持真实。 确保你的话来自于你内心对他们所做的事情的真诚感谢。 保持赞美的水平和言辞与他们的参与程度相称。 过度的赞美可能会让人觉得不真诚和机械，并使你寻求援手的目的落空。

相关模式

• 只是说声谢谢（摘自《无畏的改变》一书）（https://fearlesschangepatterns.com/）

已知实例

• Nike (multiple projects)

状态

• 结构化

作者

• Russ Rutledge

致谢

• Todd Lisonbee，鼓励 "保持真实"。

• Isabel Drost-Fromm为"合格 "感谢进行的这个额外的解释 。

翻译校对

• 2022-12-07 翻译姜宁

• 2022-12-19 校对谭中意

• 2023-06-18 最后更新日期

Title

小组支持

Patlet

如果某个团队或个人不再支持 InnerSource 项目怎么办？ 由一群感兴趣的个人组成小组来保持项目活跃。

问题

• 即便是一个广受欢迎的 InnerSource 项目也可能陷入孤立的困境。

• 当前没有明确的出路。

故事

一个 UI 组件类库，在全公司有 50 多个项目使用。 该类库的开发团队在资源耗尽后，宣布解散。 起初，没有人注意到，但过了一段时间，每当有人问“谁负责它”时，得不到答案。 接下来会怎么样？ 新的团队会避免使用它吗？ 该项目是否会停滞不前，直到其用户最终被迫转向其他项目？ 如果一个完美且有价值的项目出现这种情况，那将是多么令人遗憾！

上下文

• 广受欢迎的 InnerSource 项目。

• 作为一个构件时的依赖项使用（比如 代码模块）。

• 没有活跃的开发者提供支持。

• 公司无法指派团队提供支持。

约束

• 没有人在日常工作中被指派负责这项工作。

• 每个人都很忙。

• 项目迁移的成本很高。

解决方案

面向全公司征集感兴趣的志愿者，组成一个 可信任提交者 小组来支持该项目。 可能需要根据提交或使用的历史记录联系特定的个人。 重要的一点是要有足够的数量，这样每个人的负担可以相对较小。

该小组成立后，应确定或创建标准基础文档和沟通工具。

团队应尽全力从以下方面管理项目：

• 维护. 如果项目在标准用例中完全失效，那就修复它。 随着项目使用的依赖关系和框架的不断发展，及时更新项目。

• 新人上手. 如果有人对如何使用项目有疑问，确保他们能得到合理的答复。

• 更新. 如果有人想在项目中添加新功能，请为他们提供必要的设计和技术支持，以便他们实现该新功能，使其既能为自己所用，又能为项目增光添彩。 及时评审收到的 PR。

由于该小组由志愿者组成，因此重要的是要传达提供“尽力而为”的支持。 因此，这种支持模式不太适合像实时 API 这类运行时关键的生产项目。 它更适合在构建时使用的项目，例如类库/包/模块。 该小组预计不会为其他人实现任何新功能。

结果背景

• 对 InnerSource 项目有些微弱的支持。

• 从长远来看，小组支持可能会在某个时候再次解散。如果该项目长期持续下去，那么就利用这段稳定的小组支持期，找到一种长期支持的方式（比如 核心小组）。

理由

人们通常都愿意提供帮助。 如果有人邀请某个人是否愿意加入成为可信任提交者，通常会有很多人回答“是的”。 感受到自己是集体的一员，并在组织结构上体现和被赋予一定的责任，通常会激励人们尽最大努力，很多时候这就已经足够了。

已知实例

• WellSky

状态

结构化

作者

Russell R. Rutledge

翻译校对

• 2024-10-10 翻译Chris Yang

• 2024-10-12 校对姜宁

Title

服务 vs. 库

Patlet

由于对服务宕机责任的模糊不清，DevOps团队都不太愿意基于公共代码进行跨团队工作。 解决办法是让大家认识到通常情况下：要么在独立的环境中部署相同的服务，在服务宕机时有独立的问题处理兜底机制；要么将大量的共享代码纳入一个库，大家在此基础上进行协作。

问题

当团队在DevOps环境中工作时，开发人员负责一个功能的端到端：从服务客户到软件部署、从维护和支持。 这也给跨团队工作带来了挑战：对于发生在任何一个团队的错误，问题处理流程可能是不一样的。 源代码和部署的耦合给团队留下了这样的问题，在发生错误时，谁负责及时解决问题。 因此，即使在需求上有很大的重叠，团队也不愿意联合起来进行协作。

上下文

• 团队在一个微服务环境中工作。

• 大家是按照功能齐全的DevOps团队进行组织。每个团队负责他们端到端的贡献，包括维护服务、及时处理问题和客户支持。

• 一个团队的任务是向下游客户提供一个由其他团队构建的和现有服务类似的服务。

约束

• 组织上的问题升级支持路径对每个团队来说可能是不同的。

• 每个团队的成员对于不影响自己下游客户的错误的线上问题并不愿意提供支持。

• 由于每个团队/客户关系的SLA定义不同，同一类型的错误的严重程度在团队之间可能不同。

• 团队可能有不同的安全或监管约束来管理他们的部署。

解决方案

将源代码的责任与部署脱钩：两个团队都致力于准确识别重叠内容并进行协同。

只有共享的源代码被保留成为内源项目的一部分，大家分担责任。共享源代码应该是连贯的，它包括所有的测试代码（如果有的话，包括集成测试）和尽可能多的持续集成管道，以使得贡献验证更容易。

将配置和部署管道与实际业务逻辑解耦。为新的团队建立新的服务部署。

将团队间共用的内容以库（不是直接使用代码）的方式进行使用，并共享代码所有权（通过协商的方式进行修改）。

部署配置的内容可以作为单独的项目列入内源项目中，以允许团队讨论/协作或新团队复制这些配置代码。

实施结果

团队开始愿意合作，并从分享实现业务逻辑的工作中获益。

一个原本专门为单一环境工作的服务，被转换成一个基于特定业务需求的更为通用的解决方案。

两个团队都了解他们各自的升级政策和部署设置，有可能为他们自己的设置找出改进。

需要对共享源代码进行修改的可能性增加，导致更频繁的机会来完善、改进和优化实施。

鼓励在发布包装、遥测、健康/准备就绪端点等方面逐步实现操作标准化，因为团队意识到，如果他们同意贯彻这些标准，就能更有效地在共享代码中维护这一点。

参见

与这种模式相关的是30天保证模式，它采取了不同的方法来解决上述的约束问题。

已知实例

• Europace AG

• Flutter 娱乐公司。一个Flutter 内源应用程序有一个共享的代码 "服务 "库，有跨团队的贡献和持续集成到流水线来构建和发布一个共享的发布工件。 每个采用的团队有一个 "部署配置 "库，定义他们自己的部署。这样方案满足了不同的监管要求、服务和事件管理实践以及不同业务领域的基础设施技能的需求。

状态

• Structured

作者

• Isabel Drost-Fromm

• Rob Tuley

致谢

感谢Tobias Gesellchen在Europace AG 的内部评审。

别名

服务 vs. 库: 这是内源，不是内部部署

翻译校对

• 2022-12-02 翻译姜宁

• 2022-12-06 校对曾江云

• 2023-06-18 最后更新日期

Title

共同的需求

Patlet

共享代码库中的通用代码不能满足所有想要使用它的项目团队的需要；这一点可以通过需求调整和重构来解决。

问题

共享代码库中的通用代码并不能满足所有想要使用它的项目的需求。

上下文

• 许多项目都在尝试使用共同的代码。 有一个所有项目都能访问的共享代码仓库。

• 有人（或某些项目）首先写了代码，并把它提交到了共享代码仓库。

• 通用代码在任何一个项目的总体交付物中只占很小的比例。

• 每个项目都有自己的交付时间表，一组交付物和客户。

• 这种模式适用于以下任何一种情况：

  • 有一个强的代码所有者，即所有对共享库的修改都必须得到共享库所有者的批准。

  • 有弱的代码所有权，即没有人真正拥有这些代码。

  • 没有仁慈的赞助者，即没有组织或行政人员提供资源，以InnerSource的方式组织公共代码。

约束

项目的开发团队为了满足一组需求实现了代码。这些需求与一些代码的使用组织的需求相似，但不完全相同。 对代码的要求应该是可以从真实的客户需求中推导出来的。

不同客户的需求通常是非常相似的；然而，他们可能表达的方式不同，或者客户之间表达的轻重缓急不同。一个例子是，有些客户希望某些结果以一种方式呈现，而其他客户则希望以相反的顺序呈现。在他们之间进行转换很简单，但需要对其中一种情况进行额外的编码，结果是计算结果的模块不能被两个客户重复使用。

许多客户希望供应商能帮助他们了解自己的需求。公司有很多 "系统工程师 "为产品写需求。 这些需求应该是对客户需求的提炼，以指导产品的开发。 重用代码是一个重要的目标，就是节省公司的时间和金钱。

解决方案

解决这个问题有两个方面，应该同时进行。

1. 统一项目的要求，使满足一个项目要求的代码也满足其他项目的需要。

2. 将代码重构为更小的模块，使许多使用项目能在需求上达成一致。

此外，利用客户期望供应商帮助阐明需求的优势。在与客户的谈判中实现需求的一致性，影响客户的需求，而不是改变组件。

在上面的例子中，供应商帮助两个客户认识到他们想要同样的东西，如果他们同意接受相同格式的结果，这将节省每个人的努力（和金钱）。

结果上下文

这可能需要与客户协商需求的变化。 这些变化可能还需要销售团队和产品经理的参与，以获得需求上的一致性。 客户可能需要激励措施，如折扣，以同意这些变化。

一个相关的挑战（和可能的新模式）是在一家采用InnerSource的公司报告的循环故事写作练习。简而言之：

• 开发人员独立写一个故事来解决一个问题。

• 项目经理重写故事以更好地表达他们的需求--保持本质不变。当故事回到开发人员手中时，他们并不能认识到这是他们最初想做的事情，因此在实施时逡巡不前。

• 解决这种模式的方法是在计划表上有更多的参与者，这样故事的修改就会在整个项目中得到理解，而不仅仅是在开发人员或项目经理的阵营中的人。

已知实例

• 大型电信提供商

状态

• 结构化

作者

Robert Hanmer

致谢

• Manrique Lopez

• Daniel Izquierdo

• Tim Yao

• Sebastian Spier

翻译校对

• 2022-12-05 翻译姜宁

• 2022-12-09 校对龙文选

• 2023-06-18 最后更新日期

Title

Trusted Committer

Patlet

许多内源项目会发现自己处于这样一种情况：他们不断收到来自贡献者的反馈、功能和错误修正。 在这种情况下，项目维护者会想方设法对贡献者的工作进行认可和奖励，而不仅仅是对单一的贡献认可。

问题

• 项目维护者希望找到方法来扩大他们支持项目的能力

• 项目维护者希望找到方法来延长项目所提供的价值。

• 项目维护者希望能明显地奖励经常性的贡献者，并授权他们扩大其价值贡献。

• 缺乏对组织内各团队贡献的认可机制和语言

上下文

• 你是一个跨团队的运行库、服务或共享资源的维护者

• 你经常收到别人的贡献

• 您定期收到功能请求

• 您经常收到修复错误的请求

• 有积极的贡献者希望通过内源项目培养专业技能

约束

• 在一个项目的生命周期中，维护者可能因为自己的商业需要会转移工作重点。

• 贡献者寻求对其贡献的明显认可，以证明其价值。

• 对于一个小团队来说，维护一个具有合理复杂性的项目是很费力的。

• 对一个小团队来说，大规模地开发项目功能是很费时费力的。

解决方案

为项目定义一个 Trusted Committer 角色

Trusted Committer 处理什么是由每个项目和它的维护者决定的。确保你在项目中记录下你的 Trusted Committer 角色的范围。清晰的文件为新的社群成员设定了期望，并为未来的候选人确定了角色。

以下是识别潜在 Trusted Committer 的一些准则：

• 积极参与社区渠道（Slack、JIRA问题分流等）的人成为 Trusted Committer，从而正式确定他们在社群支持中的角色。

• 经常提交代码、文档或其他版本库修改的人。可以先从提交 Pull Request 人群中筛选。如果他们积极地提交 Pull Request，可以考虑与他们接触，探讨在项目上进一步合作的机会。

正式确定 Trusted Committers

第一步是与 Trusted Committer 候选人接触。维护者应该对候选人进行教育，使其了解受 Trusted Committer 的角色。我们并不期望候选人会接受 Trusted Committer 的角色。每个候选人应该评估他们是否有足够的空余时间来承担这些责任。当候选者接受了这个角色，项目维护者就应该向公众发布会从用户到 Trusted Committer 转变的消息。并将他们的名字添加到项目README中的 Trusted Committer 一栏中。如下所示：

# 项目名

... 项目的readme ...

## 项目成员 

### 维护者

  - 你的团队

### [Trusted Committers]

  - 新的 trusted committer成员

[Trusted Committers]: https://example.com/link/to/your/trusted/committer/documentation.md

维护 Trusted Committer 关系

一旦你正式确定了一个新的Trusted Committer，在你持续迭代项目的时候需要保证Trusted Committer也能持续获得项目进展的信息。 让他们真正参与到项目进来，可以是简单地邀请他们加入你的项目沟通群，也可以是让他们参与你的计划会议。 更多的参与机会使 Trusted Committer 有机会成为维护者，如果他们愿意的话。

除了让 Trusted Committers 了解情况外，还需要定期检查 （Trusted Committers 的状态）。建议的节奏是先从每周开始，然后逐渐发展到每隔几周。 这些检查的目的是为了确保 Trusted Committers 在他们的新角色中感到被支持。就像与你的经理进行1对1的交流一样，如果有任何问题，倾听和同情，试图了解是什么阻碍了受托承诺者的成功。 始终感谢 Trusted Committers 在使项目成功方面的持续努力，并确定一个新的检查日期。

Trusted Committer的退出

有些时候，Trusted Committer需要退出 ，例如如果 Trusted Committer。

• 不再愿意参与

• 不再能够履行其职责

• 不再受雇于该公司

双方应商定一个取消项目资源访问权的计划，包括将他们在项目的 Trusted Committer 部分的条目进行修改，将其加入到过去的贡献者名单。 在取消访问权时，公开感谢 Trusted Committer 的参与。公开承认可以确保社群内过渡和连续性的清晰沟通。

结果

对于项目贡献者

获得一个项目的 Trusted Committer 资格，表明了对社区项目的主动贡献。对这些努力的认可可以在与经理的年度评审中使用。

对于项目维护人员

随着项目的成熟，维护者对项目的关键方面可能变得不那么熟悉。Trusted Committers 可以填补这些空白，确保项目的各个方面随着时间的推移可以得到更好的服务。一组健康的 Trusted Committer 可以确保在项目维护者转行时有一个负责任的管理计划。

已知实例

已经在以下公司尝试并证明是成功的

• Nike

• PayPal

• Mercado Libre - 在 CONTRIBUTING.md 文件加入了一段，用来描述谁是Trusted Committer。

状态

• 结构化

• 在耐克公司内部发布；2018年6月通过 pull-request 草案.

作者

• Fernando Freire

鸣谢

• Russell Rutledge

• Loren Sanz

• Noah Cawley

• Jeremy Hicks

• Doron Katz

翻译

• 2022-12-01 翻译姜宁

• 2022-12-03 校对龙文选

• 2023-06-18 最后更新日期

Title

核心团队

Patlet

即使一个内源项目被广泛应用，但也可能因为项目难以协作而阻碍项目的贡献和使用。 建立一个核心团队，专门负责处理项目的基本事务。 他们的工作可以确保贡献者能够增加和使用满足他们自己使用场景需要的特性。

问题

• 很难为项目做出贡献。 这可能是由于以下情况：

  • 不能在本地运行该项目。

  • 糟糕的文档。

  • 复杂的代码。

  • 测试不充分。

• 难以使用该项目。 一些可能的原因：

  • 糟糕的文档（再次）。

  • 频繁的bug。

  • 不直观的设置。

故事

有一个人人都依赖的中心项目。 这是一个多么好的内源候选项目啊！ 不幸的是，这个项目是自然发展起来的，各种贡献和补充功能都是胡乱地加进去的。 现在，它是一个恶心的、厚厚的代码泥潭，没有人理解，每个人都不敢去碰。 很明显，它应该进行一次大修（例如，重构、测试、文档等），但尽管每个人都需要并希望这项工作发生，却没有人投入时间和精力来完成这些事。

上下文

许多团队需要这个项目。

• 该项目有大量的技术债务。

• 与团队项目到适配和项目自身的迭代速度比较缓慢。

• 没有一个负责者或维护者对项目和项目贡献生态负责。

约束

• 每个作出贡献的团队都很忙，因此优先考虑那些能给自己带来直接回报的工作。

• 随着项目发展，项目变得越来越难使用和修改是一个普遍的趋势。

解决方案

组建一个核心团队，他们的工作是进行项目的维护，以便其他人可以很容易地加入到项目中并为其做出贡献。 这个核心团队做的工作对于建立一个健康的使用和贡献的项目生态系统是非常必要的。 这种关键的工作往往不会被常规到贡献所关注。 这类工作的类别包括项目沟通、本地环境适配和DevOps基础设施搭建。

下面是一些具体的例子。

• 产品Bug

• 文档

• 入门教程和示例

• 自动化测试

• CI/CD

• 本地环境适配

• 模块化

• 版本管理

• 监测

• 开拓新的类别/功能类别

上面的每一个条目对一个健康的产品生态都是非常重要的，但是却不太可能被优先考虑。

核心团可以由少数的全职或者兼职的人组成。 这种选择取决于所需的工作量、资源的可用性和组织的文化。 最重要的是，和其他团队一样，赋予他们权利，让他们承担责任，通过这样的方式形成一个核心团队。

不断提醒核心团队这一目标的一个好方法是让他们定期报告。

• 使用本项目的活跃团队的数量

• 对项目做出贡献的非团队人数。

持续关注这些指标会自然驱使核心团队优先考虑正确的工作，从而围绕项目创建一个繁荣的InnerSource生态系统。

结果上下文

• 它提升了项目的使用性并降低了项目贡献难度。

• 许多团队使用该项目并为其做出贡献。

• 他人对项目的交互和反馈是衡量核心团队做得好与坏的标准。

理论依据

项目贡献者都只关注自己业务，而不太关心项目的后续的发展，组建一个核心团队，并给他们分配维护项目任务，可以弥补这样的缺陷。 核心团队弥补了这种缺陷，扮演了团队润滑剂的角色，促使项目贡献生态保持健康发展。

已知实例

• 围绕其可重用的CI/CD流水线，*Nike**实施了这种模式来管理其InnerSource工作。*实施了这种模式，

状态

结构化

作者

翻译校对

• 2023-06-18 最后更新日期

Title

内源门户网站

Patlet

潜在的贡献者很难找到他们感兴趣的内源项目。你可以通过创建一个索引所有可用的内源项目信息的内部网站，可以让贡献者了解他们可能感兴趣的项目，也可以让内源项目的负责人发展外部受众。

问题

内源项目团队发现吸引外部贡献是件很难做的事情。

你的组织的内源项目逐渐增加，但潜在的贡献者却没有办法轻易找到这些项目。

故事

你正尝试在你的组织内建立一个内源实践。 你知道有些项目正在使用内源模式运行，但它们只是通过口耳相传、电子邮件或与其他员工的旁听对话来获知其存在。 因此，内源项目负责人发现吸引贡献者是件很难做到事情。

没有一个专注于分享内源项目信息的网站可以供整个组织的员工去方便地使用来了解所有正在进行的内源项目。 这严重制约了每个内源项目的发展。

做什么才能帮助所有内源项目尽可能高地提高其知名度，并吸引整个组织范围中的贡献者呢？

背景

• 你的组织有兴趣采用内源的工作方式。

• 内源项目的所有者正在寻求一种方法来吸引受众参与他们的项目。然而，他们受限于现有的沟通渠道，无法向潜在的贡献者进行宣传。

• 你的组织中的内源项目正在增加。

• 让问题变得更加复杂的是，正在使用的共享源码控制管理应用程序的搜索功能非常有限，即使是寻找内源项目的开发人员也很难找到相关的项目。

前提

• 管理层已经默许他们的员工参与内源项目。

• 使用一个共享的源码控制管理系统，该系统提供了对其托管的代码资源库内容的程序化访问。

• 在你的组织中，有一个部门负责推进内源合作。

约束

• 相互独立的工程团队协作应对共同挑战的潜力没有得到充分发挥

• 个人很难发现内源项目的存在

• 内源项目的负责人很难吸引外部贡献者的关注

解决方案

创建一个内源门户的内部网站，内源项目的负责人可以很容易地宣传其项目的可用性。

该门户网站的关键属性是：

• 内源门户网站的访问者应该能够看到所有可用的项目，以及根据各种标准搜索特定的项目，如项目名称、使用的技术、贡献者姓名、赞助的业务部门等。

• 通过内源门户网站显示的信息应该在任何时候都在内源项目负责人的完全控制之下。 最好是通过直接从特定的数据文件或存储在项目库本身的元数据中获取这些信息。

• 项目负责人应在这些数据文件中包括所有与他们的项目有关的信息，包括项目名称、受信任的贡献者的名字、简要描述和链接到代码库或任何支持文件。

• （可选）虽然大多数组织会选择只在其内部网络上提供他们的门户，但有些组织也会选择在公共互联网上提供他们的门户。后者对于那些想在门户中显示有关其内源方法的额外信息的组织来说可能很有意思，例如出于品牌和招聘的目的。

在启动门户网站时，应该考虑开展宣传活动，推进大家将内源数据文件或元数据添加到代码库中，以增加门户网站中显示的项目数量。

结果

• 内源门户网站使内源项目负责人能够向整个组织的受众宣传他们的项目。 由于曝光度的提高，他们吸引了比以往更大的贡献者群体。

• 对于那些希望参与内源项目的人来说，内源门户允许他们根据特定标准同时搜索所有可用的 内源项目，从而准确发现他们感兴趣的机会类型。

• 满足供给者和消费者的需求，有助于将内源确立为一个可行的、有吸引力的选择方案，使组织内的所有领域都能利用它来完成他们单独无法完成的事情。

已知实例

• 一家大型金融服务机构利用创建的内源门户提供了一个宣传和发现不同业务部门的内源项目的机制。

• Elbit Systems使用了这个模式，并在上面添加了游戏化内容。
• Banco Santander创建了一个名为 "Santander ONE Europe 内源社群" 的公共门户，以支持和增加内源的采用。除了项目目录外，该门户还包括相关内容，如文档、工作方式、新闻和活动。

参考

状态

• 结构化

作者

• Stephen McCall

致谢

• Shelly Nizri

• Melinda Malmgren

• Michael Graf

• Jesús Alonso Gutierrez

翻译校对

• 2023-06-18 最后更新日期

Title

记录你的指导原则

Patlet

通常内源对 "在组织内部应用开源最佳实践 "的解释对缺乏开源背景的人来说效果并不好。 作为一种补救措施，内源最重要的原则被记录下来并广泛宣传。

问题

该组织正试图在更大范围内推广内源。 该倡议是从开源爱好者发起。现在的目标是获得缺乏开源经验的人的支持。 对于这些人来说，典型的"应用开源最佳实践"的口号已经不足以传递内源是什么、它解决了哪些问题以及它使用哪些工具来解决这些问题的信息。 因此，内源在组织中的采用速度减慢了。 当贡献者开始跨越团队边界时进行协作是， 团队对内源的目标是什么以及如何实施最佳实践产生了疑惑。

故事

在一个组织中的早期实验表明，开源合作的最佳实践可以带来好处。 现在的下一步是将该倡议影响到缺乏开放源码深厚背景的团队和个人。

现在的目标是要清楚地传达内源计划的目标以及实现这些目标的明确路径。

上下文

• 内源作为一个术语在员工中流传。

• 该倡议由开源爱好者发起。

约束

• 团队难以准确地沟通实施内源在哪些方面比较重要。

• 缺乏开源经验的人无法理解将开源最佳实践引入组织的意义。

• 在日常工作中，试图遵循内源最佳实践的团队很难决定他们所做的是否符合内源的一般价值观。

解决方案

那些在组织中推动内源计划的人需要帮助那些缺乏深厚开源背景并对内源的缺乏直观理解的团队和个人。

应该通过记录这两个方面来向团队和个人传递清晰的信息。

1. 目的 - 组织为什么要采用内源？

2. 原则 - 哪些内源原则将有助于解决这些挑战？

下面的章节提供了关于这两个方面的更多细节，意味着可以作为你的组织记录这些原则的起点。

为什么该组织要采用内源？

在过去，内源已被证明可以成功地解决组织中常见的几个问题。

然而，您的组织希望使用内源来改善哪些组织挑战？

与其一概而论，不如尝试准确地找出与你的组织的挑战相匹配的解决方案 - 最好是和哪些你想影响的人一起。

其他人通过遵循内源最佳实践解决的一些挑战：

• 减少由过度地盘意识造成的开发孤岛。

• 通过促进健康的代码重用，减少解决类似问题的时间，从而提高创新速度。

• 通过更好的跨团队合作来提升开发速度。

• 解决项目/团队的依赖性，超越 "等待解决方案 "和 "建立变通办法"，从而减少工程瓶颈。

• 提高质量。

• 增加员工的幸福感。

• 提高新员工的入职成功率。

• 建立可操作的文档。

哪些内源原则将有助于应对这些挑战？

一旦团队了解内源将帮助他们解决哪些问题，下一步就是解释哪些原则有助于解决这些挑战。

基于基本的开源开发原则，以下准则已被证明是成功的。

(1) 代码必须透明地托管在组织内

源代码、文档、与项目开发相关的数据必须对组织内的任何人都是可用的，并且容易找到。

(2) 贡献大于提交功能要求

一个项目的所有利益相关者都是潜在的贡献者，并被作为贡献者对待和予以支持。 贡献仍然是建议而不是要求。 贡献前的协调有助于避免精力浪费。 项目提供贡献指南以避免摩擦。

(3) 错误是学习的机会

由于工作在整个组织中都是可见的，任何错误都会被所有人看到。 因此，必须建立一种文化，使错误成为学习的机会，而不是应该不惜一切代价避免的失败。

(4) 书面沟通大于口头沟通

对于跨越多个团队的项目，可能会有不同的会议时间表，需要有可能进行异步协作。 内源项目的目标是招募新的贡献者。 为此，未来的潜在贡献者需要能够在以低门槛，自我服务的基础上关注项目的进展。 如果项目的相关交流是通过同步交流进行的，那么所讨论的论点需要在书面渠道中透明化--最终决定应该只在书面渠道确定。 作为一个副作用，这会产生被动记录的基础文档，对任何项目的新人来说都是非常有价值的。

(5) 允许书面建议积累在一个持久的、可搜索的档案中

所有的项目交流，特别是所做的决定和导致这些决定的讨论，都需要被归档。 必须有可能通过稳定的URL来提供参考链接交流。 以往的交流需要以一种容易搜索的方式来储存。

但有两点需要注意:

1. 这并不能取代结构化文档。但它可以作为收集结构化文档的一个起点。

2. 所有的东西都要写出来，而且要让整个组织都能看到，这个规则也有例外。与个人有关的讨论以及与安全有关的讨论是敏感的，不应公开进行。

(6) 奖励 Trusted Committer 人员

结果

• 组织成员了解他们可以通过应用内源最佳实践来解决哪些挑战。

• 缺乏开源经验的组织成员了解内源项目的基本价值和原则。

• 缺乏开源经验的组织成员能够根据一套共同的既定价值观来检查他们的日常活动。

• 组织的开发实践变得与开源项目更加相似，从而使组织成员更容易参与到开源项目中。

已知实例

Europace AG

GitHub

目的

在GitHub，我们的工作模式是团队为其职责范围以外的领域贡献功能。常见的例子包括：销售工程部贡献功能以促进销售，特别项目部贡献急需的、对整个产品有高度影响的功能，以及一个团队在多个领域工作以交付一个功能。

原则

总的来说，这份文件中概述的原则是为了避免增加技术债务和项目东道主团队的支持负担。很多时候，为东道主团队提供帮助是因为他们在自己的责任范围内由于支持和维护成本导致忙不过来，而且他们没有相关资源来实现这个功能。任何由其他团队完成的新功能，如果增加了支持负担或技术债务，就意味着东道主团队在新功能上的时间更少了，所以我们要确保他们（贡献团队）做得正确。

同时，我们努力成为一个工程师可以自由地跨边界工作的公司，业务优先事项经常要求我们在我们的核心领域之外的领域作出贡献。

对这些原则的一个很好的总结是，离开这个领域时要和你发现它时一样好，甚至更好。

考虑到这一点，以下是我们同意的原则。

• 避开累积功能债务的最小可用产品（MVP）。为了获得客户的反馈，发送一个MVP是可以的，但是贡献团队必须致力于完成功能集。这方面的例子包括。

  • 承诺超越MVP，形成一个能满足大多数客户的解决方案。

  • 完全支持对新功能的管理（例如，在设置的用户界面中支持，而不是只做命令行）。

  • 在UI和API中展示功能，而不是只提供API（或反之）。

  • 确保功能在云和本地服务器环境中工作。

• 对功能提供不局限在部署到生产环境中支持。

  • 协调渐进式的推广

  • 处理支持任务单

  • 计划好时间来处理客户的反馈（功能和bug）

• 以正确的方式构建功能（不要积累技术债务）

  • 与产品和工程团队就需求和解决方案达成共识

  • 合理的架构和设计

  • 确保数据被正确存储，以避免以后的数据迁移。

  • 具有适当的遥测技术

  • 具有适当的测试覆盖率

  • 在云和本地生产环境中得到支持（包括设置、配置、备份/恢复、迁移等）

  • 修复错误

  • 更新文档

参与

我们之所以使用参与模式，是因为我们喜欢让团队在为其职责范围以外的领域贡献功能时，可以采取哪些具体步骤。

在GitHub，一个典型的参与模式是这样的。

• 获得产品负责人对功能集和推广计划的批准。

• 获得工程负责人（通常是工程经理和总监）对工程设计的批准，包括解决非功能需求（遥测、测试覆盖、多环境测试和支持）。

• 沿途进行代码审查，同时审查任何新的或改变的需求。

Robert Bosch GmbH

目的

促进合作、学习和创新是 Bosch 内源计划（BIOS）的主要重点。

原则

为此，Bosch 采用了以下原则。

• 开放性：我们尽可能地降低进入BIOS社区的门槛。

• 透明度：我们是完全透明的，与公司所有员工分享我们的工作成果、我们的沟通和我们的决策。

• 自愿：加入BIOS社区并为之做出贡献的决定是由每个员工自己决定的。员工应该在 BIOS 工作，因为他们有内在的动力，而不是因为他们的经理告诉他们这样做。

• 自我决定：BIOS社区可以自由选择工作内容、工作时间以及工作工具和流程。

• 任人唯贤：BIOS项目成员的权力是基于他们的功绩，也就是基于他们贡献的质量和数量。

开放、透明 和 自愿 的原则有助于发展由内在动机的同事组成的多样化社区。 事实证明，任人唯贤 是做出巨大贡献的有效激励。 自我决定 使社区能够以最有效的方式利用他们有限的时间来做出贡献。

状态

结构化

作者

• Isabel Drost-Fromm

• Georg Grütter

致谢

• Zack Koppert - for sharing GitHub's approach in the Known Instances

别名

明确的内源原则

翻译校对

• 2023-06-18 最后更新日期

Title

利用RFC进行透明的跨团队决策

Patlet

内源项目如果想实现高参与率，并为每个参与者做出最好的决定，就需要想办法在整个软件生命周期中建立易于参与式的环境。发布内部征求意见稿（RFC）文件，可以在设计过程的早期就进行讨论，并促进在参与各方在高参与度下建立解决方案的机会。

问题

为了使内源项目健康发展，它持续需要大量的贡献者。这些贡献者（或团队）可能对给定的项目有不同的要求。例如，他们可能想在项目中添加彼此不兼容的功能，或导致架构的不健康的膨胀。

在过程的后期发现这种分歧或误解，例如，一旦软件已经建成，就会付出很大的代价。这些分歧可能会导致所有参与方的挫败感，甚至会破坏项目中合作文化的健康。常见的分歧是，一个变更请求（pull request）被搁置了很久，因为变更请求的作者和项目的维护者基本上都不同意进行拟议的变更。

对于内源项目来说，当项目由公司内的多个团队一同维护时，这种情况更经常发生，即共享所有权。

故事

一个项目，或由多个项目组成的应用程序，由许多不同的团队维护，每个团队负责不同的项目或应用程序的不同领域。这些团队确实对彼此的领域做出了内源的贡献，但更大的、跨领域的变化只由团队的技术负责人共同推动，或者根本就没有发生。这导致大多数工程师无法实现大规模、跨领域的变革，减少了创新和合作的机会。

通过实施RFCs的流程和模板，团队和个人被授权通过一个透明的决策过程提出大型的、跨领域的变化，并在各团队之间进行异步磋商。这促进了更大的创新，更紧密的合作，以及更多的知识传播。这有赖于各层级的所有专家的认同，以及一个心理安全的环境，以便人们可以公开提出和辩论想法。

像任何过程一样，这必须被不断地改进。可能需要对RFC模板或流程进行修改，以确保其具有包容性、协作性和有效性。

背景

• 一个内源项目由许多团队共同拥有。

• 最重要的设计决策不可能一直由一个中央机构（例如一组架构师）做出，因为他们既没有足够的时间，也没有足够的特定领域的知识来在所有情况下做出好的决策。

• 各种类型的用户对某个项目的发展方向有意见。这样的用户可能是：开发人员、产品负责人、产品经理等。

• 决策需要以异步的方式做出，至少部分是这样，因为经常召集所有参与者的同步会议是不可行的

• 希望记录所做的决定，即确保这些决定是书面的，而不仅仅是口头的。

约束

• 大多数时候，相关各方都希望能很快做出决定（例如，前期的设计时间相当有限）

• 对许多参与的人来说，把事情写下来（在没有实施的情况下）往往是一种新的技能。

素描

解决方案

该方案的重要内容有：

• 关于何时发布RFC（以及何时不发布）的描述

• 一个RFC文件的模板

  • 应该促使RFC作者从多个角度考虑他们的建议

  • 既要提示高层视角的概述，又要提示详细的深入解释

• 一个众所周知的、围绕RFC的轻量级过程，例如

  • 如何发布RFC并与所有利益相关者分享（如Slack、邮件列表）。

  • 如何收集对RFC的反馈

  • 如何在反馈中工作

  • 如何将RFC推向一个结论或决定（例如，相关的指定维护者签字）。

  • 选择适当的工具（例如，非开发人员可能无法使用源代码控制工具）。

• 承诺对RFC模板和流程进行迭代

示例/模版

结果

实施类似于RFC的流程被证明是有价值的，因为它使跨团队的决策过程对每个人来说都更加透明，使所有的声音都能被听到。

可观察到的积极效果。

• 决策过程的民主化，影响到许多团队的决策（同时也减轻了团队负责人的负担）。

• 一个开放的异步沟通方法，在多个团队和地区都能很好地运作。

• 赋予个人和团队大规模变革的能力

• 记录所做的决定供人们参考，以了解情况

• 扩大有经验的工程师的影响，因为他们可以通过异步和远程方式为解决方案做出贡献，而不需要在会议上出现。

• 统一术语，例如，通过阐明我们的测试术语，如 "什么是系统测试"，来实现术语的统一。

• 统一流程，例如，明确说明下班后的支持流程。

• 更清晰的思路，因为写RFC使作者比平时更多的挑战自己。

RFC方法也有我们想要指出的风险。

• 它并不总是有效的！例如，有些人可能仍然反对已经通过RFC做出的决定。然而，在这些情况下，将决策过程写成文字仍然是有益的，因为你可以指出人们是在什么时候和为什么做出某个决定的。

• 一个RFC可能会变得很大，太不方便了。这往往表现在冗长的评论和围绕RFC的讨论。在这种情况下，我们可能会决定用同步交流的方式来补充RFC，比如工作小组和面对面的会议。但时间仍然可以节省，因为人们可以在会议之前阅读RFC，而不是在会议期间分享所有的信息。

原理

已知实例

状态

结构化

作者

• Tom Sadler

• Sebastian Spier

别名

• 架构决策记录（ADR）--不一定是直接的别名，因为它们有时会有非常不同的使用方式，例如，RFC用于寻求意见和建立共识，ADR用于记录决策和实施细节。

翻译校对

• 2023-06-18 最后更新日期

Title

评审委员会

Patlet

对于开发人员和管理人员来说，内源的工作模式与更多的传统方法截然不同。通过建立一个评审委员会，作为内源计划和所有参与该计划的业务部门高级管理人员之间的接口，后者更有可能更加熟悉并支持该计划，因为评审委员会为他们提供了一定程度的监督和控制，而不会助长微管理。

问题

管理人员会认为内源的工作模式与他们习惯的和有经验的工作模式有很大的不同。因此，他们很可能会拒绝内源计划，或对其进行微观管理，以尽量减少这种变化所带来的风险。在这两种情况下，内源的好处都无法实现。结果是，大家都不相信内源能够成功实施。

背景

A公司想引进它的第一个内源计划。A公司的大多数经理都不熟悉开放源码的工作模式，而是习惯于等级制度、自上而下的控制式管理。

约束

• 管理者对内源计划中的工作的控制感越强，就越有可能在没有经验的情况下支持该计划。

• 管理者对开源工作模式的经验越少，就越有可能希望控制内源 计划的风险。

• 对内源计划的管理越严厉、越微观，开源工作模式就越不可能被广泛采纳。因此，内源的好处将无法实现。

解决方案

• 建立一个评审委员会，由参与内源计划的所有业务单位的高级管理人员组成。

• 评审委员会成员有权以集体评议的方式决定哪些内源项目将获得通用资源的支持，特别是资金。

• 申请人可以在会议前被评审委员会成员推选，在评审委员会会议期间提出其拟议的内源项目供评审。

• 目前由评审委员会资助的 内源 项目的负责人有义务在每次评审委员会会议上汇报其项目的情况。

• 评审委员会成员有义务在评审委员会会议期间向新申请人和现有项目负责人提供建设性的反馈意见。

• 每个内源项目都要有对评审委员会会议上收到的反馈做出反应的机会，直到下一次会议，以避免过早地关闭项目。

• 内源项目负责人也可以在评审委员会上主动提出要关闭的项目的动议。然后，评审委员会要决定是否需要给使用该软件的业务部门时间来制定措施，以确保代码库的开发和/或维护继续进行，直到找到内源社区开发的替代解决方案（如果与业务相关或任务关键）。

• 评审委员会应定期举行会议。事实证明，每年召开两次会议是成功的。

结果

• 管理者将他们熟悉的工具应用于内源，以获得所需的关于内源计划内部运作的足量信息和控制权。这种熟悉程度将使他们更有可能签署内源计划，并给予内源项目所需的自由度。

• 开发人员在一定程度上仍然有自组织的空间。微观管理不会发生，因为评审委员会召开的频率相当低。

已知实例

• BIOS at Robert Bosch GmbH

状态

• 结构化

• 截至17年8月31日，已定稿和评审完毕。

作者

• Georg Grütter, Robert Bosch GmbH

• Diogo Fregonese, Robert Bosch GmbH

别名

奶酪接口(Cheese Interface)

翻译校对

• 2023-06-18 最后更新日期

Title

内源许可证

Patlet

属于同一组织的两个法律实体希望彼此共享软件源代码，但他们担心在法律责任或跨公司会计方面的影响。

“内源许可证”为组织内的源代码共享提供了一个可复用的法律框架。它提供了新的合作选择，并明确了参与的法律实体的权力和义务。

问题

当一个组织中的两个或更多的法律实体想要互相分享代码时，他们需要一个关于条款的协议，通常是一个法律合同。在每个项目的基础上创建此类协议需要付出努力并会对共享创造障碍。例如，一个法律实体内的团队可能决定不与组织内的另一个法律实体分享他们的源代码，因为这看起来很复杂。

共享的障碍会导致在组织内多个实体重建类似的解决方案时出现独自开发和重复劳动的现象。

在共享源代码时，可能无法可靠地预测共享的价值。如果共享活动需要付出巨大的努力（例如，对源代码使用的条款进行持续谈判），则法律实体不太可能这样做，因为他们关心投资的回报。

背景

• 大型组织内有许多想要共享代码的法律实体（子公司）。当组织变大时，共享模式的价值会增加。

• 按照定义，法律实体有自己的法律权利和义务。

• 这些法律实体中有多个实体正在开发软件，并正在使用其他法律实体的服务。他们有动力为彼此的源代码做出贡献。

• 该组织及其组织结构足够复杂

约束

• 撰写正式协议所需的努力程度，特别是如果他们需要考虑技术、法律和商业角度。

• 一个大型组织（由许多法律实体组成）有许多内部规定。任何新签订的协议都必须遵守这些规定，例如安全、隐私、采购流程等。规定的数量会导致难以评估两个法律实体之间共享软件是否符合这些规定，尤其是在没有标准程序的情况下。

• 如果组织中的任何一个法律实体有一个商业模式依赖专有代码和组织内许可费用的核算。

• 公司文化不习惯于内源协作和共享代码。这导致了在使用共享代码时权利和义务的不确定性。

• 使用软件的自由导致了竞争以及所有权的分散。

• 有一些法律合同，涵盖了源代码的共享。这些合同并不是标准化的，所以它们为每个项目的谈判和理解带来了额外的负担。现有的合同也可能不允许在足够开放的意义上共享源代码，以支持真正的内源方法。

• 或者，没有法律合同，但源代码被非正式地共享。在需要明确所有权和权利义务的情况下，这可能会造成不确定性。

解决方案

创建一个根据有关组织（及其法律实体）的需要定制的内源许可证。这个许可证需要有足够的通用性，可以应用于最重要的公司间关系。

重要的是，撰写内源许可证，要真正允许类似开源的合作跨越相关法律实体的边界进行。因此，自由软件的4项自由应当被融入许可证中。

许可证按正式的法律文件撰写，并作为法律实体之间的合同的一部分来管理代码共享协议。

结果

有了内源许可证，我们就有了一个在组织内的法律实体之间分享代码的工具。

该许可证简化了我们组织内部关于共享源代码的对话，并推动第一批法律实体这样做。

注意： 已知实例中描述的实验还处于早期阶段。因此，一个可靠的结果还没有形成。几个月后，内源许可证对这一问题空间的影响将更加清晰，本节也将更新。

已知实例

DB AG内部的第一批法律实体（公司）正在使用他们的内源许可证。

一个已经显示出来的积极效果是，它简化了对话，特别是当一些参与方还不太了解内源的概念时。许可证是一个众所周知的概念，因此拥有一个内源许可证是一个很好的讨论起点。

实验还发现，为了实现真正的内源贡献和合作模式，还有更多的合作挑战需要解决。

所提到的合作挑战包括：

• 让大家能够找到适用内源许可的项目

• 像在开源中一样建立项目合作的社群。

值得一提的是，到目前为止，在这个内源许可下分享的软件主要是工程工具、基础设施和底层的工具。

状态

• 结构化

• 在已知实例下所列的实验自2020年2月开始运行。初步的经验显示了第一个积极的效果，但需要更多的经验来全面评估该模式。

作者

• Cornelius Schumacher (DB Systel GmbH)

• Schlomo Schapiro (DB Systel GmbH)

• Sebastian Spier

参考

词汇表

• 组织 - 多个法律实体的综合体。(同义词：集团、企业）（如汉莎航空）。

• 法律实体 - 拥有自身的法律权利和义务的实体（同义词：公司，子公司）（例如汉莎系统有限公司，汉莎工业解决方案TS有限公司，...）

翻译校对

• 2023-06-18 最后更新日期

Title

基准级的文档

Patlet

内源项目的新贡献者很难搞清楚谁在维护这个项目，该做什么，以及如何贡献。在标准文件中提供文档，如README.md/CONTRIBUTING.md，可以为新的贡献者提供一个自助服务流程，这样他们就可以自己找到最常见问题的答案。

问题

一个团队希望与更广泛的组织分享一个新开始的或已经存在的项目，并接受对它的贡献。潜在的贡献者常常迷失。他们无法确定团队的首选沟通渠道。他们难以快速判断添加一个新功能是否有意义。他们很难了解到底哪些同事目前正在积极维护该项目。

上下文

一个项目要作为一个内源项目与他人分享。为了让其他人能够理解项目的内容以及如何做出贡献，项目需要提供一些基本的文件。到目前为止，该项目要么缺乏所有的文档，要么缺乏用户以自助服务的方式进行尝试以及贡献者快速上手所需的某些方面的内容。

约束

• 该项目最近才转为内源项目。以前，用户要么是内部的，要么是在个人面对面的会议上加入进来的。同样，从事项目的人员经历了入职培训，而这种入职培训并不能随着贡献者或远程贡献者人数的增加而扩大。因此，自助服务文档是缺乏的。

• 该项目是作为一个内源项目新创建的。然而，东道主团队缺乏内源的经验。因此，他们需要指导建议在文档中包括哪些信息，把文档放在哪里，以便其他人可以找到它，以及在文档中面向的是哪些类型的读者。

• 该项目是最近才转为内源项目的，东道主团队对内源的经验有限。因此，现有的文档解决了很多技术方面的问题。它不包括促进透明规划所需的沟通、协调和信息。

• 该项目是最近才转化为内源项目的。因此，很多存在于团队中的隐性知识既没有被写下来，也没有对贡献者可见。

• 文档的缺乏导致潜在的贡献者需要很长时间来设置环境和入门学习。制作文档（并保持更新）需要时间投资。即使东道主团队依靠贡献者的帮助来解决缺乏文档的问题，这些贡献仍然需要时间来评审。

• 项目成员要花大量的时间来回答入门问题。维护一个可以被认为是支持问题的综合数据库需要大量的时间和精力。

• 组织内的不同团队对于如何格式化源代码和使用何种软件模式有不同的标准。因此，贡献通常最后会被大幅修改甚至全部重写。将所有这些操作标准化并执行这些标准，需要大量的时间和工作。

• 重复解释和重写的额外工作削弱了内源方法的效用。

• 由于额外的工作和重写造成的延迟而频繁问题升级，导致了一个大奶酪的局面。

解决方案

解决为新的贡献者提供更清晰的文档的需求。创建此文档的目标应该是使入门尽可能成为一个自助服务的过程，用标准的文档格式来解答常见问问题。

README.md

如果它还不存在，为你的项目创建一个README.md。它应该包含。

• 为项目的下游用户提供一个 "入门 指导"部分。它应该解释如何设置/整合项目的工程文件，以及为第一次使用的用户解释一些最初的典型操作步骤。

• 为项目用户提供更深层次的指导文档--或者是文档链接。

• 对项目进行修改所需的文档--或者是文档链接。

• 关于如何为项目做出贡献的文档--或者是文档链接。

• 一个 "参与 "部分，解释项目使用哪些公开的、存档的、可链接的交流渠道。这应该包括一个指向项目问题跟踪器的链接，但也包括任何进一步使用的讨论渠道。

• 解释项目将贡献者变成Trusted Committer的标准是什么--如果存在这种途径的话。

CONTRIBUTING.md

如果对做出贡献的步骤的解释过于复杂，可以创建一个单独的CONTRIBUTING.md文档。这个文件应该回答贡献者过去经常问到的问题。没有必要预先提供全面的书籍。相反，分享已证实为贡献者所需要的信息。它可能会涉及到以下一个或多个主题。

• 如何从版本控制中签出项目的源代码。

• 如何对项目进行修改（可能包括编码指南方面的信息）。

• 如何构建项目。

• 如何运行测试以确保上述修改没有引入新的错误。

• 如何将你的修改提交给项目。

• 关于所作修改的预期周转时间的一些信息。

结果

• 贡献者上手的时间大大减少。

• 由于误解和错位导致的问题升级明显减少。

已知实例

• Paypal Inc.

作者

• Isabel Drost-Fromm

别名

通过README提供标准的基础文档

状态

• 结构化

• 于2019年12月起草。

参考

致谢

翻译校对

模式

附录

• 额外

资源

Title

成熟度模型

Patlet

各个团队已经开始采用内源。这种做法正在向多个部门蔓延。然而，人们对什么是内源项目的理解各不相同。解决方案是提供一个成熟度模型，让团队通过自我检查，发现他们还没有意识到的模式和做法。

问题

当内源在企业中的应用开始增加时，通过一个布道者对每个项目进行单独指导就变得不可行了。此外，越来越多的人至少对在内源项目中工作的意义有了基本的了解。纵观所有的内源项目，对这一概念的理解深度会有差异。团队可能没有意识到那些可以帮助他们进入下一阶段并解决他们所处理的问题和痛点的成熟模式。

背景

一些团队已经开始采用内源实践。各个团队对该实践的确切理解程度不尽相同。团队遇到的具体问题也因每个团队的背景和工作环境而不同。因此，在内源项目中，对什么是重要的最佳实践的定义因每个团队而异。

约束

分享内源经验的团队遇到了误解，因为他们没有意识到各自采用内源的水平。

团队认为，"这都是迁移到一个共享的软件开发"（GitLab、GitHub或Bitbucket是这种锻造的众所周知的例子）。

团队没有意识到可以帮助他们解决日常工作中遇到的问题的最佳实践。

解决方案

要求团队根据建议的成熟度模型进行自我评估。

透明

产品和规划

内源项目路标规划在组织内公开透明，不仅可以使利益相关者能够更好地理解相关决策，也可以让组织内的其他人能够参与或影响决策。

• PP-0：组织内没有正式的路标规划。由个人和团队不定期向多个利益相关方披露他们的计划或产品。

• PP-1: 有公开路标规划。个人和团队在启动之前，向多个利益相关者展示他们的计划或产品。

• PP-2：有公开的路标规划，并且有清晰的指引和贡献规则帮助和指导利益相关方进行反馈。但是，这些过程没有在组织内规范化和标准化，不是所有内源都能提供这些信息。

• PP-3: 项目的路标规划默认是公开共享的，并且在组织内的每个内源项目有统一的标准流程和方法。对路标规划的贡献和变化也有明确的规范。

开发流程及工具

贡献者主动参与到内源项目可以让项目获得更好的发展。因此，需要在使贡献更容易和追求完美的技术目标之间达到平衡。。

• DP-0: 互相区隔的开发团队。各团队有自己的开发流程和工具。没有和其他团队共享知识和作品。

• DP-1: 公司内开发团队之间共享代码库。部分团队有自己的CI流程，没有使用公司统一或标准的CI工具。部分团队内部有自己的代码评审流程。但是公司没有统一的代码评审流程。

• DP-2: 建设公司级的知识共享库。部分团队使用公司CI工具来开发自己的CI流程。公司存在统一的CI环境和代码检视流程。部分项目已经应用。代码审查会邀请外部团队成员协助完成。

• DP-3: 大多数团队使用公司CI工具来完成自己的CI流程。有统一的CI环境和代码检视流程。代码检视由团队内部和外部成员共同完成。

决策

为了激励员工在他们所属的核心团队之外的工作中做出贡献，他们需要了解项目的决策过程，同时也要感觉到他们的声音是被倾听和重视的。

• DC-0：决策者往往有意或无意的隐瞒与项目决策相关的数据和资源。

• DC-1：决策结论定稿后，决策过程中的部分材料可共享可评审。

• DC-2：人们感觉自己了解并帮助决策大多数（但不是所有）重要决定。决策过程公开，可在所参与的项目里程碑中获得决策的相关材料。

• DC-3：人们感觉自己是集体决策的重要一环，决策过程公开规范，并且被组织所支持。可以持续地获取到决策过程中的相关材料。

提供有用的资源

为了吸引贡献者，需要让贡献者很容易获得有用的信息。

• RS-0：个人和团队既不贡献，也不利用共享的知识库。

• RS-1：个人和团队的交付件在内部评审。个人和团队有共享资源，但是知识是碎片化、不连贯的，存储在不同的系统和仓库内。个人和团队有共享资源，但无法确定信息是否敏感，对哪些信息需要共享没有达成共识，也没有标准和规范。没有“和他人分享想法”。

• RS-2：个人和团队可参考已明确定义的信息共享格式或协议，可以让团队成员方便地获取相关资料。团队对于必须保留的敏感信息，仅提供了有限的细节、背景信息和共享范围。

• RS-3：个人和团队可参考明确定义的信息共享格式和协议，可以让组织内部、外部相关人员方便地获取相关资料。对于必须保留的敏感信息，明确定义了共享范围，其他人也能够了解哪些信息不能共享。

总结经验

当在东道主团队中工作时，错误会自动被广泛看见。为了保持贡献水平，企业文化需要庆祝失败，作为大家共同成长和学习的机会。

• ST-0：个人和团队不分享成功或失败的经验，其他人无法学习。

• ST-1：个人和团队愿意分享成功经验，但不愿意分享失败经验。

• ST-2：个人和团队在回顾和评审时，愿意分享成功和失败的经验。。

• ST-3：个人和团队很方便的分享成功和失败的经验，并例行开展总结和学习活动。

协同

提供反馈渠道

为了减少工作间壁垒（silos），同事们需要坦诚地分享反馈意见。一个简单的支持方式是跨层级使用相同的通信原则。 理想情况下，您最终会建立起适当的沟通渠道，并被整个组织广泛使用。这些渠道将聚焦于不同的目标（公告、用户支持、开发渠道、非正式讨论、等）。你将逐渐形成一套最佳实践，例如采用网络礼仪准则，为每一个新的内源项目开辟一套成熟的标准化沟通渠道（消息即时存档、可公开访问、提供搜索功能）。

• CF-0: 没有流程也没有建立渠道。组织成员通过私人渠道或讨论分享资料。

• CF-1：组织开始建立内部规范和渠道，以便组织的任何成员都可以使用，通过这样的渠道来鼓励对公司/部门决策提出不同观点。组织的一些成员利用非官方平台非正式地分享决策材料。领导者至少有一个明确、直接的渠道，让组织成员就一些与工作相关的事项分享有建设性的意见。

• CF-2：组织已经确立了内部规范和渠道，并提供特定的资源（培训项目、获取内容等），来鼓励和征求对于团队或决策的多方意见。

• CF-3：组织成员在官方认可的平台上分享决策材料，组织成员通过多种渠道和方法公开分享材料，征求反馈意见。领导者自己使用这些渠道，并公开鼓励其他成员使用这些渠道。对于收到的反馈以及针对反馈的处理意见，有专门面向团队的公开记录。

领导力

内源项目鼓励员工在不受其部门主管直接影响的情况下为部门外项目做出贡献。这需要信任的文化。

• LS-0：在一个高度层级化的组织中，大家奉行的是指挥与控制文化。

• LS-1：一些领导人愿意接受反馈，并创造一个让人们感到能够安全反馈的环境。

• LS-2：多数领导人愿意接受反馈，并创造一个让人们感到能够安全反馈的环境。领导者在理解所有成员是否都感到有权力和能够分享时表现出消极的态度。组织鼓励领导者积极寻找对话中没有出现的声音，以求包容。

• LS-3：成员们感到有力量，能够就任何与其工作有关的事项或他们有激情的事项建设性地分享意见。

组织和功能结构

当内源的理念离开单纯的编码层面，而是进入社区和工作团队的层面时，即使无法直接进行代码协作，也可以有效减少壁垒。

• OF-0：工作团队中的成员构成和技能组合往往是长期不变的。

• OF-1：跨职能部门团队存在，但团队的定位往往不明确，治理结构也很模糊。

• OF-2：跨职能部门团队较常见，团队会公开指出他们的定位和目标。

• OF-3：跨职能部门团队很常见，并在组织中广泛宣传他们的活动；反过来，组织也会推广这种合作的最佳实践。

贡献

为了减少壁垒，需要牢记改进组织内贡献模式的目标是为了增加职能部门间的合作。

• CB-0：完全区隔的状态，团队和团队间没有协作。只是由于一些跨职能部门团队的需要，会有一些协作。

• CB-1：组织成员会在团队间达成协作，但经常反映 "太难"。团队不经常注重审视合作的结果。

• CB-2：团队中的成员会积极寻找合作机会。团队经常就他们的合作成果进行讨论、审视并辩论，并默认这些合作成果是公开可用的。

• CB-3：组织成员通过内部和外部合作的方式，使所有参与者受益。团队经常就他们的合作成果进行讨论、重新审视和辩论，并在组织外分享他们的学习成果，并默认将这些成果对外公布。

社群

共享策略

共同的共享价值观可以让大家跨越组织边界更好地协作起来。如果拥有一套标准、通用的共享规则及准则，那么跨团队协作将变得更加的容易。

• SP-0：没有共享文化，也没有书面的共享政策。

• SP-1: 组织中的一些成员联合起来协定价值观和原则，但他们这样行为并没有得到明确的支持。

• SP-2：组织成员集体撰写共同的愿景和协议，如使命宣言和行为准则等，使其易于获取，并可以经常参考。入职材料和迎新仪式提供充分的背景材料和信息，以帮助新成员了解组织如何得益于他们的贡献。

• SP-3：共同的价值观和原则为组织成员之间的决策、冲突解决和评估过程提供信息，组织成员以口头和书面的形式不断地引用这些价值观和原则。

组织的归属感

将内源引入组织的可能动因之一是员工参与度的增加。这一条目追踪了组织内推行内源时参与度的变化情况。

• PA-0：参与度低，没有合作，人们不喜欢与他人分享。

• PA-1：组织成员对于分享他们的想法和意见感到安全，但只在熟悉的领域发表意见。不必担心因此被攻击。人们明白，只有最好的想法会最终会被采纳，而领导权将会根据贡献和付出的多少来分派。

• PA-2：组织成员在分享他们的想法和意见时，不必担心因此被攻击。领导者对组织的共同价值观表示认可并投入精力建设。

• PA-3：组织积极主动地告诉成员，组织从他们的贡献中受益；因此，成员表现出强烈的集体意识和强大的执行力，并感到对组织的责任感。领导者明白，他们是通过帮助他人成长而获得自身成长的，因而他们会为组织的初级成员提供指导。

治理

奖励

为了吸引更多的人参与到内源项目中，可以使用一些外在的激励手段来增加跨团队的协作。

• RW-0：没有奖励。

• RW-1：内源项目的管理者鼓励协作，想要奖励那些对项目作出卓越贡献的个人或组织，但是没有制定政策和流程来作为支撑。

• RW-2 制定了标准的流程和制度来鼓励内源项目开发团队之外的组织和个人参与协作，并进行奖励，奖励谁是由项目管理者或者项目管理委员会来决定的。

• RW-3：奖励不仅由组织提出，社区也会提出他们认为的更有价值的奖励。内源社区有责任决定谁应该得到奖励。

监管原则

内源项目需要一种自我评估的方法。度量指标可以作为促进自我评估的一个方面。此外，在一个成熟的内源项目中，我们期望采用一种基于清晰、一致指标的跟踪方法来监控内源项目。

• MP-0：组织中不存在任何级别的监控策略。

• MP-1：指标对某些团队很重要，但他们仅以一种孤立的方式在使用它们。

• MP-2：在组织层面有一个关于度量指标的策略，有助于在整个组织内验证特定的政策。在某些内源项目的层面也存在监控政策。

• MP-3：在组织提供的相应基础设施上，有明确的指导方针、建议和培训，来应用具体的度量指标。这在两个层面都起作用：在组织层面，以及内源项目层面。

支持和维护

内源团队不仅要负责特性开发，支持和维护也是内源团队核心任务的一部分。

• SM-0: 由核心开发或支持团队给予支持和维护，通过商业合同来保证产品的支持和维护。团队之外对产品一无所知。

• SM-1: 有由专门的支持团队提供的规则和制度，来使对产品的支持和维护正式确立。

• SM-3: 有成熟社区的规则和制度正式支持产品。

文化

在多种层次上向合作文化迈进。

• CL-0：筒仓型 - 团队独立的工作，相互封闭隔离，缺少交流和信息共享，甚至缺少协作。

• CL-1: 被动型 - 团队独立的工作，但知道如何对依赖性中的缺陷做出反应。

• CL-2: 贡献型 - 团队通过贡献积极帮助改善他们的依赖性。

• CL-3: 积极型 - 团队积极寻求帮助、指导和招募新的贡献者。

内源角色

内源带有明确的角色。虽然在早期阶段，某些模式可能不需要采用这些角色，但是在项目内部使用明确的角色称号进行沟通会变得更加容易。

• RO-0: 没有具体角色帮助内源夯实。只有常见的开发角色：开发人员、分析师、测试人员等。

• RO-1: 偶尔有个人和团队参与其他项目。这些是技术贡献，即用户/贡献者角色。对于某些团队，可以指定至少一个成员作为技术指导，该成员向其他开发团队成员解释开发过程。他/她可以作为 Trusted Committer 角色的候选人。

• RO-2: 内源管理者角色负责治理和支持，包括流程等。识别教育需求，并确保向组织提供所需的教育和培训。内源领导和教练负责组织参与内源项目。第一个正式步骤是：定义内源愿景和路标。组织定义了 Trusted Committer 角色，不仅为开发团队成员，而且为外部贡献者提供联系/参考。有一个标准的流程描述如何为社区做出贡献，贡献者角色是存在的。数据安全员角色负责管理内源活动留下的操作日志，这是需要衡量内源演变所必需的。Trusted Committer 角色将演变为更具技术性的形象，社区管理员将负责“激励”社区，他的主要职责是吸引和留住新的开发者/用户（贡献者/社区成员）。

• RO-3: 布道师在组织内部活动，让其他人了解当前的工作，内源做什么以及如何做，并帮助其他人理解并成为内源动议的一部分。非技术贡献者出现。

结果

所有团队都了解现有的最佳实践。

团队了解他们对内源的采用程度。

在采用内源作为工作模式之前，团队了解对他们的期望的做法--无论是短期的还是长期的。

已知实例

• Entelgy

• Zylk

• Bitergia

作者

• Daniel Izquierdo Cortazar

• Isabel Drost-Fromm

• Jorge

• Nerea

致谢

• Alexander Andrade （特别感谢拼写修正）

别名

成熟度模型： 了解内源的最佳实践

状态

• 结构化

• 于2019年9月起草

翻译校对

• 2023-06-18 最后更新日期

Title

Short Title Here

Patlet

Concise 1-2 sentence description of the problem and solution. Readers may quickly review dozens of these patlets to discover and browse the larger library of patterns. From http://wiki.c2.com/?PatLet

Problem

What is the problem - crisp definition of the problem. Short description, usually not more than a couple sentences, that describes what the issues and challenges are. Be careful not to morph into information found in other sections below.

Story (optional)

Sometimes there is a story that helps people understand the pattern better.

Context

Where does the problem exist? What are the pre-conditions? Unchangeable before the solution goes into place. The content here is often tied to the applicability of the pattern for other readers: "Do I have this same particular situation?"

Forces

What makes the problem difficult? What are the trade-offs? These are constraints that can be changed at a cost. The solution might change one or more of these forces in order to solve the problem, while also in-turn changing the context.

Sketch (optional)

visual illustration

Solutions

Verified resolutions and possible resolutions to the problem.

Resulting Context

What is the situation after the problem has been solved? The original context is changed indirectly by way of the solution. Often this section can include discussion of the next possible Patterns/problems introduced. This section can be short in content - the solution may not introduce new problems or change much context.

Rationale (optional)

Explains why this is the right solution; using totally different words WHY this solution balances these forces and this context to solve this problem. Can expand on what-if's or theories.

Known Instances (optional)

Where has this been seen before? Helps to reinforce that this is a REAL pattern and that you match the context.

May mention:

• A particular business

• Anonymized instances ex: "3 companies have proven that this is a good solution" or "A large financial services org...".

Status (optional until merging)

General pattern status is stored in GitHub's Label tagging - see any pull request. Note that this GitHub label tagging becomes less visible once the pattern is finalized and merged, so having some information in this field is helpful.

You might store other related info here, such as review history: "Three of us reviewed this on 2/5/17 and it needs John's expertise before it can go further."

Author(s) (optional)

Often, this is yourself. If you need to, find someone in the InnerSource Commons to be the nominal author (As Told To). Could also be no-one if you do not want to take on authorship (common with a donut looking for a solution).

Acknowledgments (optional)

Include those who assisted in helping with this pattern - both for attribution and for possible future follow up. Though optional, most patterns should list who helped in their creation.

Alias (optional)

If this pattern is also known under a different name than what is listed unter Title, please list those alternative titles here. e.g. if the pattern is named after the problem it solves, a helpful alias might be one that describes the solution that is applied.

Title

问题追踪器使用案例

Patlet

内源东道主团队不仅没有使计划和进展，而且也没有将变化背景信息变透明。这可以通过增加项目问题跟踪器的使用案例来解决，它也可以为头脑风暴、实施讨论和功能设计服务。

问题

一个团队开发了组织中许多团队都依赖的组件。 它使用一个标准的问题跟踪器来跟踪开放的错误报告和功能请求。 然而，每个条目的上下文是非常有限的。因此，潜在的贡献者没有办法知道每个问题到底是在谈论什么变化。

上下文

内源项目的工具都已经设置好了。然而，一般的项目问题跟踪器主要用于分享项目进度。 在内源项目中，问题跟踪器则可以用于更多的用例追踪，使远程、异步的沟通更容易。

约束

• 贡献者希望了解他们所需的功能是否已经安排在路线图上。但由于问题中缺少大量的上下文，因此不可能决定现有问题是否符合贡献者的需求。

• 因此，很多重复的问题被打开，核心维护团队不得不处理。

• 由于开放问题中的上下文是如此有限，贡献者无法通过实施一些已经开放的更容易的问题来帮助核心维护团队。因此，大量的工作仍然在东道主团队的手中。

• 由于强烈关注口头交流，在几个月或几年后，不可能辨别出为什么某个功能会被选中实施。因此，重构，特别是简化组件的工作，就成了项目考古学和寻找谁还记得讨论过什么的脑力练习。

解决方案

拥抱 "书面胜于口头 "的理念，不仅是在纯粹的软件开发中，而且在新功能的规划阶段也是如此。

• 对于bug，计划中的功能以及功能想法都会产生单独的问题描述。在每一个问题中包括尽可能多的信息，以便潜在的外部贡献者能够理解其背景。理想情况下，特别是对于比较容易的变化，包括足够的信息，以便外部贡献者通过实现相关的功能来支持东道主团队。

• 尽可能使用问题跟踪器作为提问的渠道。如果你缺乏其他的沟通渠道来解决用户的问题，这尤其有帮助。

• 利用标签和类别，以区分用于不同目的的问题。

• 对于异步开始的头脑风暴会议，打开一个问题来收集想法。当讨论开始平静下来时，在一个单独的文件中总结这个问题中已经确定的要点。在相关的拉动请求（代码实现）发布出来，以深入研究仍然需要澄清的个别要点，以供代码评审使用。由此产生的文件可以用来在其他适当的渠道发布结果，并供未来参考。

• 大多数问题跟踪器的实现都提供了问题模板。利用这些模板，不仅可以收集bug报告的常用信息，还可以包括其他使用类型所需的信息提示。

结果

• 更多地利用项目的问题跟踪器进行交流，使外部贡献者能够跟上，并对贡献什么内容做出更好的。

• 注重结构化的书面交流使东道主团队成员能够远程参与。

• 始终以书面形式进行沟通意味着关于项目决策的被动文件会作为副产品积累起来，而不是需要增加关注。

• 始终如一地使用公共交流渠道，导致更多的人关注讨论。这意味着有更多知识渊博的人可以回答问题，在开放的问题上插话，或者指出计划中的功能的缺陷，否则这些缺陷会在很久以后才被发现。

• 将讨论转移到公共讨论媒介上，为未来的潜在贡献者创造了一个机会，让他们在第一次需要参与之前就能聆听、跟随、适应和了解项目的运作方式。

已知实例

• Europace AG - 请看博文 Issue Use Cases

作者

Isabel Drost-Fromm

状态

结构化

翻译校对

• 2022-12-06 翻译姜宁

• 2022-12-09 校对龙文选

Title

零工市场

Patlet

建立一个市场，创建一个内部网站，将特定的内源项目需求列为 "任务"，并提出明确的时间和技能要求。 这将使管理人员能够更好地了解员工的时间承诺和专业利益，从而增加获得批准做出内源贡献的可能性。

问题

经理和员工都不明白他们如何能从参与内源项目中获益。

员工很难向管理层传达他们需要为内源项目投入多少时间。

管理人员没有统一的方法来跟踪或奖励员工对内源项目的参与。

故事

你已经成功地在公司创建了一个内源项目，并得到了高级管理层、中级管理层和开发人员的支持。 然而，在将近一年之后，除了最初创建内源项目的团队之外，很少有人对这些项目做出实际贡献。 在采访了所有相关方后，主要的症结似乎是很难知道如果开发者选择参与内源项目，他们将被要求做出多少时间承诺，以及他们个人将如何受益。没有统一的方式来告知能够为贡献者提供什么样的机会，他们会被要求做什么，以及大概需要多长时间。 经理们都很支持，并希望他们的员工参与进来，但到目前为止，还缺乏一种方法来记录或奖励他们的员工在内源项目中的活动。 对于所有相关方（内源项目所有者、潜在贡献者和开发经理）来说，可以做些什么来改善这种状况？

背景

员工希望他们能够在不离开他们目前的职位就能接触到公司其他领域的活动。内源项目的存在，可以提供这些经验，但有两个主要因素阻碍了员工的参与。首先，他们无法轻易发现正在进行的内源项目中存在哪些贡献机会，也无法将这些机会传达给他们的经理。 其次，是经理们无法计划和说明他们的员工对这些内源项目任务的时间承诺。 因此，内源项目所有者发现很难建立足够规模的社区来实现他们的既定目标。

约束

• 员工没有简单的方法来发现内源存在的机会。

• 员工不了解如何做出对他们职业发展有利的贡献。

• 管理人员不了解与内源项目相关的时间/精力要求。

前提

• 经理为员工提供时间，让他们参与到内源项目中。

• 管理人员需要一种方法来量化、跟踪和记录内源的贡献，以便对其进行核算和奖励。

解决方案

创建一个基于 "零工"的内部网站，个人可以在这里宣传他们的技能和兴趣领域，内源项目负责人可以宣传合作机会。

员工应该能够在应用程序中创建一个档案，在其中列出他们的技能和兴趣领域。 该系统应利用这些信息，在有符合一个或多个标准的零工发布时，主动通知个人（通过电子邮件或其他方式）。

内源项目负责人发布的每项任务都应包括估计的技能和时间要求，这样就可以很容易地与可用的员工匹配，并清楚地传达给他们的直接管理人员。说明中还应包括一个理由，说明该任务对承担该任务的人有什么好处，以使其尽可能具有吸引力。

可以建立一个基于积分的系统，以奖励和跟踪员工参与零工的情况。 例如，一旦任务完成，任务拥有者可获得10分，完成任务的开发人员可获得100分。完成任务所积累的积分可以作为一种游戏化机制和绩效管理标准，以展示其在组织内专业领域表现。

那些希望接受零工的人应该首先由零工的所有者进行审查，以确定该员工是否具备必要的技能，以及他的经理分配给他完成零工的时间。

通过工作任务所做贡献的透明度可以帮助贡献者建立（或减损）她的声誉，从而创造更多的可能性，使贡献的质量高。 完成 "任务 "也可以作为一个特定领域的专业知识的证明。

发布在市场上的工作性质可以包括硬技能和软技能，如组织团体活动、撰写报告或请求提供指导等。

创建零工市场的工作最好由组织内的一个团队承担，这个团队负责提供全公司的基础设施和能力。

结果

内源零工市场极大地增加了内源项目的数量以及参与这些项目的员工人数。零工市场的自我导向性提高了员工的工作满意度，因为他们可以对自己的工作和公司内部的合作伙伴有一定程度的选择。 员工们清楚地了解他们所签署的是什么，以及他们能从这种经历中得到什么。经理们能够更好地估计和跟踪员工在内源项目上的时间承诺，认可他们的个人努力，并将完成零工作为验证他们具体技能的一种方式。 经理们还能够利用其员工可能遇到的任何现有的休整时间，让他们转而从事零工市场中的工作。 零工市场内的互动所产生的数据也有助于推动所有部门的招聘和培训决策。

当与内源门户模式结合使用时，零工市场除了提供与零工相关的项目的代码库和文档的链接外，还提供了更精细的背景和细节。

已知实例

• 一家大型金融服务机构利用创建内源零工市场网站来推进其内源计划。

• SAP实施了零工市场网站模式-在内部工作平台上增加了一个新的内源项目，在这里可以发布职位和类似的任务。

• 在这种情况下，零工市场模式与相关的内源门户模式已被证明效果非常好。 内源门户网站提高了人们对目前正在进行的具体项目的认识，而零工市场则公布了在这些项目中可以进行的某种类型的任务。

状态

• 结构化

作者

• Stephen McCall

• Shreyans Dugar

翻译校对

• 2022-12-07 翻译姜宁

• 2022-12-26 校对龙文选

项目使命

这里应该包含一个关于你的项目使命的简短描述（3-5句话）。其目的是说明项目打算做什么，并帮助外部的贡献者大致了解项目的哪些类型的功能可能会受到欢迎。

参见《生产开源软件》中的使命宣言篇。

快速入门

这一部分应该包含为第一次使用的用户编写的关于如何开始使用这个项目的简短文档。其它的详细信息文档可以通过链接的方式加入这个小节。

更多信息

这一部分可以列出以下任何或全部内容。

• 软件所涉及的功能、用例的清单。

• 用于解决权衡问题的设计原则的信息

• 用户级文档的链接

• 常见问题（FAQ）的答案，最好是可以链接到具体问题及其答案的格式，以方便参考。

获取帮助

这一部分应该包含一个简短的文档，让用户了解如何获得项目的帮助。 文档可以很简单，如果你的项目想要回答问题的话，可以把用户指向问题追踪链接。 它也可以指向一个存档和可搜索的聊天频道，或者存档的可搜索邮件列表，或者在线用户论坛。

参与项目

这一部分应该包括如何与该项目取得联系的信息。通常，这将包含存档的、可搜索的和可链接的沟通渠道的链接。

关于我们

这是一个给项目的 Trusted Committer 以荣誉的好地方。

这里可以包括作为一个 Trusted Committer 人对这个项目意味着什么的信息--尽管理想情况下， 一个组织中的所有项目都使用相同的定义，而这里提供的只是指向这个定义的链接。在这里保留链接的原因是为了让那些没有或很少 在内源项目中工作和贡献经验的同事能够直接从他们日常工作中需要的技术项目链接中获取到公司范围内的信息。

贡献指南

这一部分应该记录（或链接到文档）所有第一次贡献者需要知道的事情，以便更好开展工作。通常情况下，文档中不会包含下面的所有主题。 文档描述的重点是你的项目中与标准设置不同的地方，以及以前的贡献者认为难以理解的地方。

• 如何获取源代码。

• 如何找到你的项目需要帮助的问题清单--这些问题既可以是技术性的，也可以是非技术性的。一般来说，你会把这些问题放在问题跟踪器中，供贡献者访问。

• 链接到更多的文件，例如关于项目的结构、一般的编码风格、测试惯例......。

• 对于技术贡献。进行代码修改，构建项目并测试你的修改。

• 将你的修改提交给项目。

理想情况下，你还应该包括关于项目的首选开发流程的信息。贡献者应该先打开一个issue并提交修改提案，还是欢迎他们立即提交修改？ 在检视贡献时，什么对你来说是重要的？

此外，你应该概述你希望在项目中遵循的任何设计原则。将这些原则明确化往往有助于更快、更容易地解决权衡问题解决方案。 此外，它还有助于使原本隐含的假设变得透明。

随着时间的推移，你会注意到这一节会有很大的增长。在这种情况下，可以考虑将这些信息转移到不同的文件中，例如，CONTRIBUTING.md和TESTING.md。

Title

跨团队的项目评估

Patlet

要推销跨团队的内源项目的价值是很难的，因为这些项目并没有对公司的收入产生直接影响。 这里有一个数据驱动的方法来展示和凸显你的项目价值。

背景

• 你负责一个跨团队项目，为公司其他团队提供平台服务。

• 这种跨团队的项目并没有为公司的收入带来任何直接的价值。

问题

跨团队的项目有可能对公司产生非常大的影响，但很难用数据驱动的方式来表示。 因此，在不提供真正价值的项目中耗费很多精力或对本来会产生巨大价值的项目投资不足是一种非常容易产生和普遍的现象。

约束

• 项目需要向公司领导展示价值（客观或主观）以获得资金支持。

• 跨团队的项目价值分散在多个终端业务部门。

• 由于这种分散性，跨团队项目的价值很难直接衡量。

解决方案

定义一个如何评估跨团队项目价值的模式和模型。 这种模式给我们提供一个需要关注和放大公司的高价值合作的工具。

所有跨团队项目价值的核心是，我们可以一起完成比分头行动更多的工作。 衡量一个跨团队的工作价值是一个量化大家一起完成的工作 怎么就更多 的练习。 不同的领域和项目的生产效率存在差距。 有一个常见的流程，你可以用它来创建一个模型，用来计算这个协同带来的价值。

解释

组建一个由你的领域内的相关专家组成的小团队。 利用这个专家团队，对使用你项目的每个消费者进行4个方面的估计：

• 他们需要多长时间来消费你的项目产出？

• 如果一切都靠他们自己来实现，他们需要多长时间才能实现和你项目一样的功能？

• 你的项目产出中有多大比例对他们来说是有用的？

• 如果不这样做，他们会花多少时间（每个用户）来维护他们自己的解决方案？

在进行这些估计时，不可能高度准确地知道任何活动需要多长时间。 这不是你的目标。 与其说是准确，不如说你应该努力为这些估算 设定一个最坏情况下的界限。 我们的想法是让专家组能够达成一致："我们不知道到底要花多长时间，但我们都同意至少要花这么多时间"。 具体来说，你应该估计出使用你的项目的 最大 合理时间，以及消费者如果自制、使用和维护他们自己的解决方案的 最小 合理时间。

关于 "实现你自己的解决方案"（home-roll）的成本的一个说明。 自研解决方案的成本不一定（事实上不太可能）与制作一个共享解决方案的成本相同。 通常情况下，对于相同的功能，建立一个跨团队的共享解决方案所涉及的模块化和质量的投入明显高于只使用一次的快速、硬编码的实现。

公式

一旦你有了最坏情况的界定，你就可以通过简单的公式来评估你在给定时间内的跨团队项目产出。

[节省的时间] - [投入的时间] 

([新用户数] * [自研成本] * [有用功能百分比] + [使用次数] * [每次使用的维护成本]) - ([新用户数] * [用户入门成本])

[新用户数] * ([自研成本] * [有用功能百分比] - [用户入门成本]) + [使用次数] * [每次使用的维护成本] 

评论

尽管有严谨的外表，这个过程并没有给出衡量跨团队项目产出的确切方法。 然而，在实践中，它确实提供了一个计算框架，你可以据此对如何资助这个项目做出合理的决定。 根据上面的解释，在有了好的、合理的数据之后，你应该运作项目投入专门的开发时间，投入 至少 要达到以下三个层面中的较小者。

1. 通过上述公式节省的原始时间。 既然我们都确信这个公式会产生一个低于真实节省的小时数的数字，你就可以有信心，就项目投入到节省的时间，对你来说是稳赚的。

2. 支持内源性贡献给跨团队项目所需的时间。 由于贡献者很可能会以一次性的方式完成工作，所以资助他们的工作以达到协同工作所需的时间是值得的。

3. 只要你觉得好就行。拥有一个估值公式的一个有益的副作用是，它自然会迫使大家对项目消费者提供价值的关键使用点进行测量。

通过理解这些测量结果，并以其原始形式进行使用，那你就可以得到一个关于项目有多大价值的直觉想法。

有些人可能会担心这种评估方法缺乏准确性。 虽然这个过程不能给出一个非常准确的测量结果，但它只需要在两个方面提供足够准确评估：

1. 为那些组织和资助跨团队工作的人提供一种展示正在发生的价值的手段。

2. 帮助那些参与者根据价值的优先级明确跨团队工作的哪些领域是值得追求的。

在实践中，只要这些价值是在现实和彼此之间的一个数量级内，它们就足够准确，并满足这些目的。与本文开头的问题部分所描述的临时评估（以及由此产生的影响）相比，它们将在实际结果中提供一个从源头入手的改进。

结果

• 用数据驱动的方式与领导层讨论跨团队项目的价值和资金。

• 围绕跨团队项目的关键指标，以原始形式进行检测。

• 定义跨团队项目所提供的价值，可能导致它实际上为公司产生更大的价值。

• 推动更多项目成功，并且不断宣传这些成功项目。

已知实例

• Nike

状态

• 结构化

• 在多个领域得到证实。

作者

• Russ Rutledge

致谢

• Jeremiah Wright教我把跨团队项目看作是以开发者时间为货币的内部业务。

翻译校对

• 2022-12-07 翻译姜宁

• 2022-12-19 校对龙文选

• 2023-06-18 最后更新日期

Title

标准发布流程

Patlet

如果团队不确定 InnerSource 项目的成熟度，他们可能会犹豫是否采用该项目。为了解决该问题，一致的发布说明和已发布制品至关重要。这些做法展示了对项目的坚定承诺，为用户提振了信心，并向他们保证了对可持续和管理良好的软件的持续承诺。

问题

当一个团队决定是否使用 InnerSource 项目时，他们的考虑因素之一是他们是否可以长期依赖于该项目。更换他们正在使用的工具/项目是有成本的，因此他们只希望在必要时进行这些投资，并获得切实的收益。

开源项目的通常做法是按版本发步，并在发行说明中记录破坏性变更和新功能，同时发布二进制文件或 Docker 镜像链接。对于 InnerSource 项目、模块等来说，这种做法可能不那么透明，或没有很好的文档化/可见性。

缺乏明确的发布制品或规范的发布流程的 InnerSource 项目往往会削弱团队间的信任。在这种情况下，其他团队难以预知下一个版本的发布时间，也无法准确把握可能出现的破坏性变更。

上下文

大型组织会生产大量的内部软件，其中很多软件都可以被整个公司的团队重复使用。运维工具、软件库和基础设施即代码（IaC）模块就是这类软件的常见例子。然而，大多数大型企业不会发布内部软件供公司其他团队使用。出现这种情况的原因可能是他们太忙，没有时间提供文档，或者没有意识到项目对其他人的价值。

应该有一个内部或公共代码库来存储源代码，但团队缺乏一个让外部团队使用软件的流程。

随着组织的发展和更多内部软件的编写，这种模式的价值也在增加。

约束

对于没有集中式 CI/CD 系统的组织来说很困难

对于没有为工程师提供集中式 CI/CD 系统的组织而言，自动化构建和发布流程可能具有挑战性。团队可能需要建立自己的工具（Jenkins、Drone 等）。在没有 CI/CD 系统的情况下，仍然可以制作制品和发行说明，但可能需要在本地构建软件，并手动上传到托管制品的工具。

增加了发布发行说明的负担

除了构建源代码之外，如果无法自动生成 git 提交列表，编写发行说明可能会很枯燥。除了编写更多发布细节之外，还需要其他人手动完成。

没有地方来托管制品增加了难度

如果公司没有提供一个集中位置来存储制品（jar、npm 模块等）和 docker 镜像，工程师可能需要自己决定在哪里适合存储各版本软件。 GitHub 等工具可以提供此功能，但是，如果公司不使用这些流行工具之一，这可能会造成负担。

解决方案

通过提供清晰的发行说明和已发布的制品，可以增强人们的信心，让他们相信你发布的是值得信赖的优质产品。。

以下是实现这一目标的关键要素：

• 代码库中包含一个 CI/CD 流水线配置，可自动化执行发布流程

• 由 CI/CD 系统来生成制品（二进制、docker 镜像、jar 等等）

• 发布的版本有清晰的标签，和语义化的版本标记

• 发布内容包括新功能说明、错误修复和所有的“破坏性变更”。

这里 提供了一个高质量发行说明的范例。

结果背景

接触到您项目的团队会看到已发布的发行说明，并对您的工具充满信心。已发布的制品也会使您的产品使用起来更简单、更快捷。像这样定义明确、清晰可见的流程还有助于跨团队协作和新的贡献者。他们可以确信自己的贡献会在合理的时间内发布，并有明确的使用路径。

发行说明也是表扬参与者的绝佳机会！众所周知，对于希望参与项目的新人来说，文档是极其重要的。表扬外部队友的贡献，包括文档和发布说明，是培养社区和扩大用户群的好方法。

已知实例

• Comcast （多个项目）

• GitHub （多个项目）

作者

David Grizzanti

状态

结构化

翻译校对

• 2024-10-08 翻译Chris Yang

• 2024-10-12 校对姜宁

• 功能名称。(请填写一个独特的身份，my_awesome_feature)

• 开始日期: (填写今天的日期，YYY-MM-DD)

• 被提名的负责人：（受RFC影响的技术领域专家代表。这通常是技术负责人，但他们可以委托。在所有被提名的所有者签字之前，RFC不能被接受。）

概述

一段对该功能的解释。

回顾

这一部分对于让我们从正在实施的事情中学习是至关重要的。

什么时候进行回顾？

[] 复盘完成？

(将在哪里/如何举行，人们如何参与，结果在哪里？)

动机

我们为什么要这样做？它支持什么用例？预期的结果是什么？

指南级的介绍

就像在向另一个工程师介绍一个已经存在的提案一样介绍该提案。这通常意味着：

• 引入新的命名概念。

• 用示例来解释主要特点。

• 解释工程师是如何思考这个功能的。应该尽可能具体地解释其带来的影响。

• 如果适用的话（例如代码/架构建议），提供错误信息样本、弃用警告信息或迁移指导文档。

• 如果适用的话，描述向现有的工程师和新的工程师传授这些知识的区别。

对于面向实现的RFC来说，这一部分应该关注贡献者应该如何思考这个变化，并举例说明其具体影响。对于政策/流程型RFC，本节应提供一个以实例为导向的政策/流程介绍，并具体解释其影响。

参考实现级别的介绍

这是RFC的技术部分。对设计进行足够详细的介绍，以便

• 它与其他功能的交互是清晰的。

• 合理地清楚介绍该功能将如何实现。

• 通过实例剖析如何处理极端情况。

该部分应该回到上一节给出的例子，并更充分地详细地解释如何实现这些例子的。

缺点

为什么我们不应该这样做？

理由和替代方案

• 为什么这个设计是可能的设计空间中最好的？

• 还有哪些设计被考虑过，不选择这些设计的理由是什么？

• 不这样做的影响是什么？

现有技术

讨论与本提案有关的现有技术，包括好的和坏的。 这可以包括几个例子。

• 对于语言、库、工具等。这个功能在其他地方是否存在，他们的社区有什么经验？

• 对于社区建议。这个功能是否由在其他社区已经实现了，他们在这方面有什么经验？

• 对于其他团队。我们可以从其他社区所做的事情中吸取什么教训？

• 论文。是否有任何已发表的论文或有相关的帖子来讨论这个问题？如果你有一些相关的论文可以参考，这可以作为一个更详细的理论背景。

这一部分的目的是鼓励你作为作者思考其他地方的经验教训，为你的RFC的读者提供更全面的信息。 如果没有现有技术，那也没关系--你的想法无论是否是全新的，还是从其他地方改编而来，我们都很感兴趣。

未解决的问题

• 在提案被接受之前，你希望通过RFC过程来解决哪些部分的设计问题？

• 在提案酝酿成熟之前，你希望通过实现这个功能来解决哪些部分的设计问题？

• 你认为哪些相关问题超出了本RFC的范围，可以在未来独立于本RFC的解决方案而得到解决？

未来的可能性

思考你的提案的自然延伸和演变是什么，以及它将如何全面地影响团队和项目。 试着把这一节作为一个工具，更全面地考虑你的提案中与项目和团队的所有可能的相互作用。 还要考虑这一切如何与项目和相关子团队的路线图相适应。 这也是一个 "倾倒想法 "的好地方，如果它们超出了你正在写的RFC的范围，但又与之相关。 如果这些想法超出了你正在写的RFC的范围，但又与之相关，那么这里也是 "抛弃想法 "的好地方。 如果你已经试过了，却想不出任何未来的可能性。你可以简单地说，你想不出任何东西。 请注意，在未来可能性部分写下一些东西并不是接受当前或未来RFC的理由；这样的说明应该放在动机或理由部分。 在这个或以后的RFC中的动机或理由部分。该部分只是提供额外的信息。

贡献的类型

在这里提供你的项目需要什么样的贡献的信息。例如，这些可以是错误报告，帮助回答用户问题，改进文档，修复错误，以及新功能的实现。

错误报告

在这里添加关于如何提交错误报告的信息。这应该包括提示项目需要哪种类型的信息，以便重现和修复问题。它还可以包括常见的看起来像bug的错误配置的信息。

也可以包括关于贡献者在首次回应和之后的处理方面可以期待的信息。

功能请求

在这里添加关于如何提交功能请求的信息。也包括关于贡献者在首次回应和之后的处理方面可以期待的信息。

贡献文档

包括关于你的项目所遵循的任何文档最佳实践的信息，以及如何构建文档、运行检查和如何将所做的修改提交给项目。

贡献源代码

本节应包含以下信息

• 如何访问项目的源代码。

• 一般的项目布局。

• 对开发环境的任何要求。

• 代码格式和风格指南。

• 如何运行测试套件。

如何成为Trusted Committers

如果成为Trusted Committers的途径对贡献者是开放的，那么这一节应该明确解释成为Trusted Committers的过程。

如何提名Trusted Committers

这一节是对现有Trusted Committers的提醒，也是向新的Trusted Committers提供详细解释，如何增补其他人到项目拥有者团队中。理想情况下，本信息也应该适用在组织中的所有项目，因此本信息可以作为统一的定义已链接的形式引用。

Title

签约贡献者

Patlet

想为内源做贡献的同事被他们的直线管理层劝阻。正式的合同和协议为这种困境提供援助。

问题

如果没有中层管理人员的支持，贡献者的总数以及由此产生的贡献量和内源计划产生的价值可能会低于高层管理人员的预期。 如果没有足够的资金和授权给专职社群领袖，这种情况可能会被放大。 这有可能导致高层管理人员放弃内源的想法。

背景

一家大型企业开始了一项内源计划。该计划的主要目标是提高分布式软件开发的效率，并通过允许每个员工自愿为内源项目做出贡献来促进创新，而不论其从事的领域和所在的业务部门。

最高管理层已经加入并支持内源计划。对他们来说内源计划只是促进创新和效率的众多计划中的一个。他们正在为内源提供资金和社群领导人的能力，并在很大程度上给予预算如何使用的自主权。 他们还限制了该计划的范围和持续时间，并参与定期评审，直到证明它产生了预期的结果（见评审委员会）。 最高管理层已经在各种公司内部会议上宣布他们对 内源 的支持。

然而，高层管理人员还没有授权或激励中层管理人员允许或甚至激励他们的员工参与跨部门的内源活动。 除此之外，每个员工的工作时间通常都被分配给非 内源 项目，占到了100%。 跨组织合作尚未成为常态，部门经理通常没有自己组织以外的目标。 对内源项目的贡献应该是在工作时间内做出的，而不是在空闲时间。

约束

• 管理人员要对其业务部门的结果负责。让他们的员工参与内源活动，可能会花时间在他们的业务部门之外做出贡献，减少了他或她的为业务部门工作的时间。这将可能使管理人员更难达到或超过他们的目标。

• 部门经理和人力资源部门会默认其下属的表现是根据其业务部门的目标来判断的，而这些目标可能与内源社区的目标不一致。

• 部门经理认为自己的行政管理权限越小，他或她就越不可能让自己的员工参与内源活动，从而为另一个业务部门作出贡献。

• 部门经理对下属所做工作的透明度和控制力越低，就越不可能让她对外做出贡献。

• 内源工作的管理和组织越不正式，习惯于正式程序的部门经理就越不可能同意其员工对内源做出贡献。

• 一个员工花在非自己本职工作的内源项目上的时间越多，他的业务部门的队友的工作量就会增加。

• 个人贡献者可能会认为参与内源是一个机会，可以增强他们在公司内的专业网络，并获得她所贡献的技术领域的知识和经验。

解决方案

在贡献者、他们的部门经理、企业内统一资助和指导的内源治理办公室（ISGO）之间，建立一个正式的协议，让ISGO为履行协议落实贡献时间的业务部门提供补贴。

• 协议规定了员工在内源中工作时间的最大百分比。

• 协议中明确规定，贡献者所在业务单位的工作优先于内源的工作。

• 协议规定，不要求在内源中的工作时间达到合同中规定的最大百分比。

• 该协议由贡献者、贡献者的直接经理、治理办公室和贡献者将要贡献的社区的专职的社群领导签署。

• 治理办公室在贡献者和她的直接经理在贡献时间上发生冲突时提供调解。

• 专职的社群领导对内源工作占比协议超过20%的贡献者，直接参与其绩效评估或为提供参考意见。

结果

一个正式的协议和统一资助的补贴，令人信服地传达了组织对内源倡议的支持，从而授权中层管理人员签署协议：

• 将公司资金配置到业务部门的开发能力补贴上，向直线经理们传递了这个信号：内源被组织认为是有价值的，已获得管理层的支持，直线经理们应该支持内源。

• 正式的签约贡献者协议表明，内源的工作得到了专业的管理并鼓励相互信任

• 一个正式的合同增加了透明度，并为业务部门和内源项目提供了一个更好的可用人力资源概述，从而减少 "超额预订/预算资源"的风险。

正式的合同对贡献者和社群也有好处。

• 有了一个稳定的贡献者群体，他们中的一些人更有可能最终获得 Trusted Committer 地位。

• 正式的协议为解决内源活动相关的冲突提供了一个基础。请注意，协议调解可能只适用在少数具有文化匹配的公司。

已知实例

• BIOS at Robert Bosch GmbH

状态

• 结构化

作者

• Georg Grütter (Robert Bosch GmbH)

致谢

• Diogo Fregonese (Robert Bosch GmbH)

• Robert Hansel (Robert Bosch GmbH)

• Jim Jagielski

• Tim Yao

• Cedric Williams

• Klaas-Jan Stol

• Padma Sudarsan

• Nick Stahl

• Ofer Hermoni

• Robert C. Hanmer

修改记录

• 2016-10-25 - 第一次评审

• 2017-05-09 - 返工

• 2017-09-08 - 第二次评审，最后修改和合并

• 2021-02-27 - 修复书中图案显示的问题

翻译校对

• 2022-12-06 翻译姜宁

• 2022-12-31校对 陈泳

• 2023-06-18 最后更新日期

Title

通过扩展实现可持续增长

Patlet

InnerSource 项目收到了太多的贡献，这会导致维护变得困难。通过在核心项目之外提供扩展机制，维护者可以用最小的成本和维护开销扩展项目功能。

问题

随着对成熟 InnerSource 代码库的贡献数量迅速增加，代码评审和维护的负担也随之加重。这将导致大量代码评审任务积压或过早拒绝新功能贡献。

项目团队如何才能更快地发布新功能、鼓励创新和实验，同时又能很好地维护代码库呢？

故事

有一个战略性项目，旨在将某一领域内的最佳创新集合到一个通用栈中，从而实现通用基础架构的重复使用，并提供标准的用户体验。通过 InnerSource，组织内从事该领域工作的各个团队都有机会开展合作，并将自己的创新成果贡献给通用代码库。

然而，当多位开发者同时进行大量并行贡献时，代码库的维护变得愈发复杂。这种情况给项目维护者带来了巨大的挑战。他们不仅要肩负确保代码质量的重任，还需要通过多种沟通渠道积极促进社区的健康发展。

项目维护人员面临职业倦怠的风险，原因如下：

• 待评审的贡献者 PR 不断积压。

• 工作不满意： 维护者的大部分时间都花在社区支持上，没有创新的空间。

• 缺乏成就感： 并非所有贡献的功能都有足够的用户需求，并因此被采用。

• 发布耗时： 代码库中的功能越多，测试时间就越长。

• 维护活动增加： 随着新功能的增加，会出现更多错误。