完成本部分后，你将更好地了解 InnerSource 如何加快产品开发；我们还将介绍其与敏捷开发最佳实践的关系。
+为了实现敏捷性，组织努力建立自治团队。然而，在一个复杂、相互关联的世界中，某些依赖性是不可避免的。 +InnerSource +提供了一种替代 "等待"、"建立变通办法 "和 "升级 "的方法： 需要修改依赖关系的团队可以伸出援手。 +InnerSource 促进了跨团队协作。它注重书面交流，即使在远程模式下也非常适合。
+在本节中，你将了解到敏捷开发和 InnerSource 使用类似的术语甚至技术，但在细节上却有很大不同。了解两者在文化和工具使用目的上的差异，将使你受益匪浅，而不是陷入常见的误解。
+你将了解 InnerSource 对能力规划的影响。此外，InnerSource 没有免费的午餐——托管团队需要时间来指导贡献者。我们还将探讨 InnerSource 带来的额外谈判可能性——保持 "投入与收益 "之间的平衡。
+让我们从一个简单的例子开始。想象一下，你正在开发一款新的可爱风音乐APP。为了了解用户与APP的交互情况，你开始收集一些交互日志。随着时间的推移，你在分析这些日志时会进行更深入的挖掘，并将学到的知识反馈到开发过程。现在，想象一下另一个将内容引入你的APP的团队也有一些需求——他们可能希望根据内容创作者接触到的用户数量来奖励他们。因此，他们也开始使用你收集的日志。但他们需要一些额外的分析步骤，而这是你一开始所没有想到的。他们现在面临着一个挑战：是建立一个变通办法，还是通过你的积压工作来优先处理他们的请求。有了 InnerSource，他们就有了第三种选择： 在你的帮助下自己进行更改。当然，这可能会比你自己修改要慢，但这仍然比等待你进行修改要快。
+在理想的 InnerSource 组织中，你可以进一步扩大规模： 还记得上次必须在整个平台上进行横向关注点修改吗？如果采用“将其放入每个团队的Backlog”的方式，往往会感觉时间拖得很长；另一方面，它实质上是为这些团队提供一个实现修改的补丁，这会大大加快速度。在这种方法中，修改的复杂程度取决于组织的成熟度和代码的可维护性/模块化程度。
+你希望改进产品，更快地将其交付给客户，并让利益相关者满意。InnerSource 可帮助你的团队在高度互联的世界中实现价值并保持自主性。
+组织试图快速向客户交付价值。一个常见的延迟原因是交付过程中的依赖关系。因此，组织更喜欢跨职能团队，涵盖客户沟通、设计、实施、测试和运营，从而消除昂贵的交接。为了实现高绩效，团队消除浪费并重复使用已有组件。从团队的角度来看，每个重复使用的组件都会给该团队增加一个其无法控制的依赖关系。这种优化的负面影响很明显：如果一个团队需要更改所使用的组件，则该团队依赖于另一个团队。为了能够实施这些计划，通常会安排冗长的路线图讨论，有时需要在全球范围内优化详细的优先级。在复杂的情况下以及在大型组织中，这会导致需要增加适应不断变化的业务需求的时间。对于非常受欢迎的核心组件，通常会收到非常多的请求，以至于一个核心组件团队无法实施对所有请求的响应。
+在传统组织中只有 +两种方式来更改依赖：
+提交功能请求/错误报告，然后等待其他团队确定变更的优先级并实施。
+实现一个解决方法来避免错误或在本地提供所需的功能。
+如果这些方案都不成功，问题通常会升级，由更高层级来决定。
+这两种解决方案都不是特别令人满意。从开源的视角来看，有一个明显的解决方案：依赖组件的团队成为贡献者，并向该组件团队提供帮助。
+现在你可能会有这样的疑问：“这样做难道不会引起很大混乱，让人们会随意修改其他团队的代码库吗？”InnerSource 提供了一套角色和流程，使原本可能导致混乱的情况变得更加清晰：
+每个 InnerSource 项目都有一组职责明确的受信任提交者，他们的职责不仅仅是简单地审查代码，还要制定贡献规则。
+贡献以有组织的方式进行：
+尽早交流贡献意向，确保贡献符合项目的愿景和范围。
+尽早分享进展，项目主办团队就有机会指导贡献者，引导他们实现理想的设计和架构；这样就能避免在后期因拒绝贡献而产生的挫败感。
+决策和重要沟通异步进行，以便能够解决不同团队中人员的不同会议安排。因此，贡献团队获得了修复上游组件的自主权，而又不会牺牲所贡献组件的质量。
+此外，InnerSource 还为团队提供最佳实践，让团队在远程文化中轻松工作。
+InnerSource 鼓励团队之间相互协作，而不是各自为政。就像在开源领域一样，这意味着要站在巨人的肩膀上：InnerSource 鼓励复用，而不是在本地重复构建每个组件。它提供了一条明确的途径，支持上游团队修复错误和实现功能，从而降低了重复使用的成本。
+就像在开源领域一样，InnerSource 培养了一种联合力量的思维： 所有业务部门和产品团队所需的基础组件都可以共同构建。因此，百舸争流：组织中某个部门的创新可以为整个公司创造效益。有了熟悉 InnerSource 的团队，所有团队都可以分担推进此类创新的重任，并从中受益，依赖于由此产生的组件和服务。
+InnerSource 为你的团队提供了主动性和工具，以解决阻碍向客户交付功能的问题。如果方法得当，核心组件和服务的维护工作可以由一个“虚拟 InnerSource 团队”以结构合理的方式共享，该团队的规模要大于任何特定的产品团队。
+在高级设置中，相关人员理解贡献者开发较简单功能的价值，这些功能可能不会直接惠及他们的客户-——但前提条件是，这可以让托管团队腾出时间来开发贡献者有业务需求的更复杂的变更。
+直接答案： 完全不是。恰恰相反，两者相辅相成：
+精心设计和经过充分测试的代码是所有敏捷团队的目标之一。在 InnerSource 设置中，团队成员以及团队外部贡献者的上岗都会变短。
+熟悉协作、避免分配任务的团队也能以灵活的方式处理外部贡献。此外，他们的思维方式和沟通方式也能很好地激励那些他们无法直接影响其优先级的贡献者。利用内在动力而不是指挥工作，意味着项目主办团队拥有与贡献者成功合作的工具。
+结对解决问题的团队已经习惯于尽早分享进展。从结对文化转向 InnerSource 有两个挑战：项目主办团队需要为支持贡献者安排时间，并将其纳入计划工作。此外，当跨越团队边界时，往往很难找到刚好匹配的时间段——在这种情况下，应辅之以异步协作。在 InnerSource 环境中，为了避免频繁的干扰，主办团队成员往往需要有意识地更严格地规划自己的一天。通常，最简单的方法是在一天中留出某些时间或每周留出一天用于指导贡献。在团队层面明确规定这一点，既能减轻工程师的压力，让他们努力实现自己的团队目标，又能帮助贡献者。结对的另一个挑战是，它允许结对人员一起快速行动，但这往往以为团队其他成员写下重要信息为代价。在 InnerSource 环境中，确实需要进行培训，以牢记将所有相关决策带回共享的沟通渠道，供团队和贡献者双方使用。从产品的角度来看，这确实会提高开发过程的透明度。这也意味着，原本可能只在工程层面做出的决策，现在对所有相关人员都是可见的。
+还记得上次你坚持要对产品进行完善的测试，最好是自动化测试，这样就可以在无需人工干预的情况下频繁部署产品了吗？现在，这一目标对 InnerSource 也有帮助：如果贡献者可以在本地检查他们的修改是否安全，那么贡献就会容易得多。测试还能确保托管团队在测试失败的情况下记得保留所贡献的功能。
+还记得上次你坚持让团队花时间遵循“让代码变得比你发看到它时更好”的目标吗？这种心态有助于 InnerSource 模型：它能确保代码的质量和凝聚力，即使有来自不同来源的多种贡献，也能保持较高水平。
+InnerSource 和敏捷使用一些相同的工具，但目的不同。
+问题跟踪：在敏捷团队中，用户故事是与客户的对话。通常它们会作为便签贴在白板上。但它们通常也存储在问题跟踪器中。因此，问题跟踪器主要被视为规划工具，本质上是白板上便签的替代品。在 InnerSource 中，问题跟踪器用于与客户进行对话，还用于在一个公共 InnerSource 组件上工作的受信任提交者和贡献者团队的成员之间进行通信。 InnerSource 中的问题比一般组织中的问题更加冗长和啰嗦。他们还跟踪变更的实施历史和详细设计决策。
+代码评审： 在传统组织中，代码审查通常是出于审计目的。
+当开发完成时，代码评审就完成了。在 InnerSource，代码变更在开发过程的早期就会共享，有时甚至只完成了一个粗略的草图。这样做的目的是寻求早期反馈和指导。这对那些日程安排繁多、没有时间结对编程的团队特别有帮助。团队通常都有一个愿望，那就是没有人是孤独前行的，但在现实中，这往往只是一个从未实现的愿望，特别是当贡献跨越团队界限时。
+InnerSource 中使用的工具可以将这一要求正式化，即任何变更都必须有不止一个人参与。
+注重书面沟通：InnerSource 的目标是让项目足够透明，以便非团队成员的开发人员能够理解项目决策并遵循软件创建过程。因此，所有沟通都需要放在每个对对话感兴趣的人都可以跟进的地方：书面的、公开的、可搜索的和可链接的。目标不是减少对他人的干扰——目标是使所有项目对话透明。
+因此，应避免直接消息和邮件。为了使每个人都能更轻松地进行后续对话，应在一个单独的沟通渠道中跟踪与一个 InnerSource 项目相关的消息：目标并非触达 InnerSource 项目团队中的每个人，而是为参与该项目的每个人找到一个共同的共享房间，他们可以在那里重点讨论该 InnerSource 项目。
+注重书面交流并不意味着不允许口头交流，仍然需要时间一起喝杯咖啡。此外，一起解决问题、与他人结对或亲自参加黑客马拉松对于快速找到解决方案也很有价值。团队需要确保所有项目相关决策都保存在每个人都可以访问的渠道中。这也可能意味着推迟重要的项目决策，直到每个人都休假回来，或者如果在另一个国家工作的人现在正在度假，则需要再等待一两天。这不仅与编码决策相关，还与总体项目任务、路线图和方向相关。如果没有这些信息，贡献者将很难理解哪些贡献将有很好的机会被接受。
+InnerSource 项目中的所有讨论对公司中的每个人都是可见的。指责、嘲笑嘲笑他人的错误，在背后谈论他们做错的事情，肯定会扼杀这种信任，并导致 InnerSource 项目的失败。这对于任何处于领导或榜样地位的人来说尤其重要。
+在 InnerSource 中，规划在两种重要情况下发挥着作用：
+贡献团队需要明白，处理上游代码通常比对他们自己熟悉的代码库进行类似的更改花费更多的时间。他们需要意识到这样一个事实：即使主办团队不必实施变革，他们仍然需要接受指导和审查。耗费的时间随所需更改的大小而增加。因此，与主办团队的早期沟通非常重要，特别是在发生较大变更的情况下。
+主办团队还需要了解指导和审查所需的时间。简单地告诉贡献团队他们可以将更改作为补丁提交并不会减少主办团队将更改为零的时间。此外，主办团队可能会发现自己处于一种罕见的情况，即他们被大量的拉取请求淹没。对于该事件，需要清楚地了解发送这些拉取请求的项目的业务优先级。当补丁不堪重负时，通常需要考虑共享组件的所有权。特别是定期参与并赢得主办团队信任的贡献者是获得“可信提交者”称号的良好候选人。
+不过，由于工作文化略有不同而产生的一些摩擦是不可避免的。此时明确设定期望值就非常重要。
+想象一下以下情况：作为贡献者，你最终做出了所需的更改——可能需要主办团队的一点帮助。你自豪地提交了拉取请求。然后——什么也没发生。一天后——仍然没有反应。你开始想知道主办团队是否已经看到了该补丁。你想知道在哪里可以最好地向主办团队传达更新信息。这种沉默非常令人沮丧，尤其对于首次贡献者来说。对于这种情况有几种补救措施——无需编码知识，但至少需要一些基本的沟通技巧：
+明确主办团队的预期响应时间——例如在贡献文档中。
+一旦收到拉取请求，就告知收到实质性反馈所需的预期时间，而不是让贡献者等待。
+为贡献者提供与主办团队的沟通渠道，并在该渠道关注正在发生的沟通。
+这些任务都不需要编码技能，这强调了对具有编程知识之外的人员的需求。最好将负责这些任务的人员视为对 InnerSource 项目的承诺，并将他们也视为可信提交者。
+小的更改和补丁很容易处理——它们可以快速审查，并且在合并时通常不会带来很大的风险。帮助托管团队的方法之一是腾出时间将变更分成更小的块。不过，请确保传达了这些更改所需要的完整背景信息。
+通常，做出更大的变更需要尽早传达意图和目的，确保贡献团队和主办团队留出足够的时间来共同应对变更也是很有益的。这意味着设定团队优先级的人在确定变更优先级时需要超越自己的团队视角。然而，协调仍然可以相当独立地进行，因为通常只有贡献团队和主办团队参与。
+主办团队很少会遇到从贡献团队接收过多补丁的难题。在这种情况下，考虑将可信贡献者发展为可信提交者角色会有所帮助。除了帮助审核，新的可信提交者还可以帮助分流问题、指导新的贡献者等。
+当面对大量的贡献意向时，在优先考虑对贡献者的指导帮助时，还有一个因素需要考虑，那就是贡献者是否有兴趣与主办团队建立长期关系。指导所需的时间越长，贡献者就越有可能坚持更长时间。
+在实践中，与非常活跃的贡献者共享组件的所有权，已被证明能让新加入的可信贡献者在更长的时间内参与到项目中来。通常情况下，在最初的贡献动机得到满足之后，他们还会帮助保持组件的更新，并长期指导新的贡献者。
+编码和谈判？你可能会好奇这两者如何结合在一起。特别是对于 InnerSource 主办团队来说，在进行变更谈判时牢记一些绊脚石会有所帮助。
+正如上一个部分所讨论的，较小的代码变更通常会更快地被接受。对于主办团队来说，优势是显而易见的，应该向贡献团队传达：
+它们更容易评审。
+它们的影响相对更小——无论是积极的还是消极的。
+它们能更快获得集成。
+因此，以临时方式进行小的更改通常不会造成任何摩擦。它们是随意贡献者的最佳选择，通常无需太多协调支持即可处理。通常，InnerSource 贡献是这样开始的：团队中的工程师开始就较小的变更进行协作，并发现这项工作非常简单且轻量。较小的变更通常也是无需升级即可完成。
+这可能导致团队形成一种思维定式，认为 InnerSource 只是软件工程师的专属。然而，一旦贡献范围扩大，这种临时工作模式就会被打破。如果仅由软件工程师负责，在最坏的情况下，即使团队中的其他角色也能推波助澜，这也意味着升级会更加频繁。对于范围较大的修改，贡献团队和主办团队中的其他角色需要了解 InnerSource 的工作，并需要发挥他们的技能：
+两个团队需要共同确定一个进行贡献的最佳时机。如果主办团队没有时间指导，贡献团队更有可能因缺乏支持而感到沮丧。他们也许更可能会开发出一种可能需要大量返工的解决方案，从而导致每个相关人员都感到沮丧。如果贡献团队没有时间专注于贡献，那么变更的完善周期可能会变得过长、中断次数过多。
+在编写任何源代码之前，贡献者和主办团队需要确定更改是否符合 InnerSource 项目的愿景。理想情况下，这也意味着技术和业务层面的专业知识需要结合在一起，最好是在人人都可以参与的同一沟通渠道上。通常，这会导致就是否应在 InnerSource 项目中实施更改进行协商——随后由主办团队负责维护。这可能意味着相关人员需要澄清每个参与人员的价值是什么，而且还需要澄清贡献团队是否以及如何帮助主办团队减轻维护负担。
+“只需编写代码并将补丁发送给我们”——听起来很简单。但实际上，这仅适用于最微不足道的更改。尤其是较大的变更需要协调，以便每个相关人员都有时间参与，否则预计等待时间会更长。跨越团队边界通常也意味着沟通文化的微妙变化。沟通能力强的人可以在团队之间进行翻译，以防出现误解，从而帮助弥合这些差距。
+与仅处理本地代码的团队相比，InnerSource 主办团队需要确保与所有潜在贡献者沟通他们的路线图和愿景。此外，主办团队需要确保设计、架构和性能要求对所有参与代码库工作的人（包括临时贡献者）来说都是明确且清晰的。对于习惯在非常有凝聚力的本地环境中工作的团队来说，这种转变尤其困难。本质上，在本地团队中隐含的一切都需要变得透明和明确。从短期来看，这确实会花费时间，但从长远来看，它可以帮助贡献者更快地上手和加速，从而减少主办团队的支持。开源领域已被证明成功的一件事是，让贡献者轻松走上正确的道路，这包括在构建时失败的自动质量检查。虽然编写和维护这些内容非常耗时，但由于明显的问题会自动突出显示，因此主办团队的负担也减轻了。
+InnerSource 与常规团队之间协调的一个不同之处是，有机会打破常规思维：想象一下，贡献者 Bob 需要对 Alice 维护的 InnerSource 项目进行非常复杂的修改。Bob 刚刚开始了解代码库，单靠他自己很难理解。此外，指导他完成整个过程会花费 Alice 很多时间。不过，Alice 积压的待办任务中有几个高优先级但易于实现的功能。如果 Bob 从 Alice 的待办任务中剥离其中一些问题并实施——作为回报 Alice 有时间完成 Bob 所需要的变更，会怎么样？为了透明起见，这些协议应同时向主办团队和贡献团队解释。否则，他们将很难理解为什么 Bob 和 Alice 不在各自客户需要的变更上工作。
+再举一个例子，假设一个主办团队正在开发一个非常受欢迎的 InnerSource 项目。它可能是公司业务的核心。随着时间的推移，越来越多的贡献者能够做出他们需要的更改，从而将主办团队变成审核瓶颈。要解决这个问题，明确整体业务的优先级和贡献团队的重要性有助于了解哪些补丁需要优先处理，并阻止主办团队成员不断转移焦点。下一步，主办团队需要考虑扩大参与该 InnerSource 项目的可信提交者的数量。如前所述，方法之一是邀请那些向不同业务部门汇报的参与者加入。
+尤其是在当面对大量相当复杂的贡献时，主办团队需要了解在哪些方面投入时间来指导贡献者是值得的。指导所需的时间越多，这些贡献者就越有可能坚持更长时间。
+"如果每个人都拥有它，就没有人需要负责"。传统组织更希望在出现问题时通过单点联系。另一方面，如果允许每个人都进行修改，肯定会导致一团糟，不可持续。
+基于这种观察，每个 InnerSource 项目都有一个专门的可信提交者团队。对 InnerSource 项目的维护兴趣往往是切合自身利益的：团队明白他们自己需要 InnerSource 项目来满足客户的需求，也明白开放项目并接受贡献可以分散工作量，从而推动项目向前发展。不过，开放项目并接受贡献并不意味着可信提交者必须接受所有贡献提交。可信提交者团队才是项目使命和目标的制定者。这样他们才能确定方向，并决定是否接受相应的变更。
+“可信的提交者负责 InnerSource 项目。他们审查提交内容并指导贡献者。”
+这是对可信提交者角色的简单概况。事实上，第一个问题往往围绕着是否要接受每一项贡献。特别是当贡献者已经投入大量时间进行贡献时，当他们听到自己的工作是徒劳时可能会感到沮丧。沟通技巧对于确保贡献者大致了解 InnerSource 项目的路线图非常重要。此外，还需要确保贡献者知道尽早分享意图和进展，以避免花费大量工作却没有结果。最后但并非最不重要的一点是，拒绝贡献需要非常好的沟通技巧。简而言之：即使你不亲自编写源代码，也需要你的支持，以便清楚地传达 InnerSource 项目的愿景，并在需要拒绝贡献时提供潜在的帮助。随着 InnerSource 项目变得越来越受欢迎，另一个方面变得更加重要：评审和指导变得更加耗时，并且随着时间的推移，需要明确地安排到每天的工作中。这确实会对总体能力规划产生影响，并且不应该“暗箱操作”。
+另一方面，对于贡献者来说，重要的是代码评审不是最后阶段的质量关卡。相反，它是一种持续指导贡献者完成代码开发过程的方法，理想情况下可以更快地获得更好的结果。为了在实践中实现这一点，需要有时间和空间来进行团队建设——但要跨越传统的团队界限。对团队中的不同文化至少有一个模糊的了解可以大大减少误解的可能性，并使贡献过程更加顺利。
+尤其是当主办团队被大量的贡献所淹没时，原本只关注本地团队的项目领导者更需要从全局角度来看待问题： +* 帮助团队根据公司整体战略，了解所接收贡献的不同优先级。通常情况下，并非所有贡献都同样紧迫。 +* 帮助团队的另一种方法是接手诸如问题分类、处理对贡献者的初步响应，以及指导较大的贡献完成流程等任务。如果集成变更需要更长的时间，你可以通过与贡献者沟通来帮助团队。 +* 面临更大的贡献请求时，团队可以通过与其他团队协商最佳工作时间来获益。通常情况下，这仍然比你的团队独自完成所有工作要快得多。特别是首次贡献者可能会需要一些指导——尤其是对于较大的变更。协调指导的时间对你的团队有很大的帮助。
+"但我们可以简单地永久分叉"......这是一种误解，潜在的客户团队认为简单地复制代码会更快。
+从短期来看，这是事实。从长远来看，这意味着增加维护工作。作为项目负责人，你可以帮助团队了解为什么对你所依赖的项目进行更改符合业务的最佳利益：总体上减少工作量。长期维护工作由主办团队承担。
+“我们使用拉取请求来开发我们的组件——因此我们每天都使用 InnerSource”。虽然使用拉取请求和评审是一个重要组成部分，但它只是 InnerSource 项目的基线。仅仅因为你依赖的两个项目每天都使用拉取请求，并不意味着它们对团队外部贡献的开放程度是相同的。
+InnerSource 具有不同的最佳实践。为了避免贡献者感到困惑和沮丧，主办团队必须为其 InnerSource 项目定义他们想要采用的治理模型。就像开源一样，不同的治理级别可能存在很大差异。
+在 InnerSource Commons 中，我们提供了一种 InnerSource 模式，它至少定义了三个管理级别： +* 每个人都能看到源代码，但团队没有时间指导贡献者。从外观上看，这可能就像日常的 InnerSource 项目。明确拒绝指导和接受贡献，可以避免试图通过 InnerSource 方式与项目互动的同事产生混淆。相反，这将向那些依赖项目的人传达，团队只能处理功能请求和错误报告。从根本上说，这意味着回归到常规的传统软件开发项目。 +* 每个人都能看到源代码——此外，可信提交者团队还为指导贡献者留出了时间。这些项目欢迎补丁和拉取请求。可信提交者团队确保与项目相关的交流以书面、存档、可搜索和可链接的方式进行。该团队还确保与项目相关的决策会在贡献者可以看到和关注的地方做出。不过，最终的决策还是由可信提交者团队做出——成为项目的可信提交者与为最初的项目团队工作息息相关。 +* 同上，但可信提交者团队对共享写入权限持开放态度。这种方法需要与贡献者建立足够的信任，以便可信提交者团队共享写入权限。如果与贡献者有长期关系，这尤其有用。共享写入访问可以消除评审瓶颈。 +* 在最后阶段，可信提交者团队还准备好分享对谁获得下一个写入访问权限以及项目愿景和使命的控制权。虽然这通常会导致贡献者做出最高的承诺，但也需要跨团队边界的高水平协调。在做出项目决策时还需要最大的透明度。
++总之，每个治理级别都需要不同的合作与协调方法 +* 共享的增加会增加沟通与协调的需求。 +* 共同责任的增加会减缓决策速度。
+如果项目希望鼓励贡献，那么对团队成员而言隐含的内容最好明确并记录下来。比如： +* 提交变更时的期望响应时间， +* 与可信提交者团队联系时使用的沟通渠道， +* 作为贡献者尝试跟踪项目时使用的沟通渠道 +* 项目期望的治理级别 +这些是整个主办团队必须同意并与贡献者沟通的所有主题。
+InnerSource 项目责任共享的增加也会对绩效评估产生影响。在层级结构中，人们通常会考虑团队本地的贡献。然而，InnerSource 贡献者开始在自己的团队之外产生影响。 InnerSource 可信提交者对可能超出其自己团队范围的团队产生影响。这意味着直属经理正在失去一定程度的控制，他们也正在失去直接监督。因此，应该考虑来自潜在远程团队的绩效反馈。
+跨职能团队的常见最佳实践是“谁构建，谁运行”策略。由于下游用户可能做出贡献，这种最佳实践似乎被打破了。在这种情况下也有多种实施 InnerSource 的方法：
+第一个是转向更大的模块化，仅在团队之间共同的部分上进行协作，并保持本地运维。
+或者使用合约测试来避免 API 中断。
+与内部服务水平协议SLA合作，让贡献者签署保修期，以消除主办团队对贡献会破坏生产系统的恐惧。
+InnerSource 是开源协作最佳实践在企业范围内的应用。与 InnerSource 对比而言的相似部分，使得团队更容易理解开源的两大方面：
+与 InnerSource 一样，开源项目也有不同的治理级别。并非所有的开源项目都是一样的： 有些项目组只发布源代码，不希望有任何互动，而有些项目组则希望下游用户积极参与并提交补丁。其他项目则设置了一些程序，允许共享对开源项目的影响。了解这些治理水平意味着，在决定内部使用哪个开源项目时，也要将开源管理考虑在内。InnerSource 项目的下游用户将学会正确评估快速发展但无法影响的项目与慢速推进但能够共同影响的项目之间的平衡。
+在 InnerSource 项目中工作，可以帮助团队实践分担成本和努力共同构建平台的意义。跨团队共享工作有助于加快整体创新速度：具有不同专注领域的产品团队可以联手更快地开发出所需的基础平台，并分担由此产生的维护工作。
+同样的动力也驱动着多个开源项目。理解它意味着对于任何具有 InnerSource 经验的团队来说，参与这些项目是很自然的。从实践经验中了解动态也使团队更容易识别哪些开源项目正在根据这些原则开发。通常，这种理解随后也会对开源项目团队决定在内部使用的内容产生影响。
+这样，许多团队需要的平台功能就可以通过协作来创建，而不是一遍又一遍地在本地重新实现。这让我们更容易理解“分工合作”的概念，即如何让每个人都能分得更大的蛋糕，以及如果采用开源的方式而不是只在内部进行，如何帮助推动行业标准的制定。
+就机制而言，这两种做法非常相似。主要区别在于项目的可见性：对于 InnerSource 而言，项目的可见性仅限于公司内部，而对于 Open Source 而言，项目的可见性则是公开的。
+字面上听起来微不足道的差别，在实践中却是天壤之别。开源意味着每一条信息都是公开可见的，并有可能永久存档。这可能会让不习惯这种工作方式的员工感到不舒服。此外，所有行动的公开意味着它们也可以接受公众的监督——企业的一举一动再也不能由企业传播专家来审查了。同样，在许可证合规性、安全性等方面，生产的人工制品也会受到公众的监督——例如，竞争对手、未来潜在的新员工和客户。
+另一方面，它也为企业在外部与其他企业的合作敞开了大门——极端地说，这可能会导致竞争者联手建立一个共同的技术平台，并在此基础上进行创新和相互竞争。
+开源还减少了跨法律实体边界合作的税务影响。虽然转让奖励是许多 InnerSource 工作的热门话题，但它与任何开源项目无关。
+当谈到积极参与开源领域时，第一个想到的往往是“如何将项目作为开源发布”。当体验过 InnerSource 后就会发现，发布整个项目只是活跃在开源领域的一种方式。
+相反，采用开明的自我利益观点更为自然： +* 当团队在其组件的重要部分使用某些开源依赖项时，确保参与上游非常重要——即使唯一的目标是了项目解未来的路线图。 +* 当团队需要对其所依赖的开源项目进行修改时，InnerSource 的经验使得参与上游的优势显而易见：显然，这不仅涉及“分享即关爱”的心态——而且在贡献时确实具有明显的经济效益，如果团队的变更被集成到了上游，那么他们的后续维护开销就会大大减少。
+退一步说，即使是决定内部采纳和使用哪个开源项目，也会受到团队 InnerSource 经验的影响： +* InnerSource 培训团队了解在协作和交流方式方面的注意事项——根据个人经验，他们将了解为什么项目必须有清晰、存档、可搜索的交流渠道。他们还将理解为什么每个重大项目决策都必须通过这些沟通渠道做出。 +* 了解 InnerSource 中的不同治理级别是一个很好的准备，有助于理解开源项目按照不同开放级别运作的意义。
+