=
无论员工在公司组织结构中的位置如何，InnerSource鼓励并奖励与任何人的协作和代码的重用。这种方法与传统组织中看到的不同，传统组织中的思想和工作产品往往被困在内部企业层级结构及约束的边界内。让我们来探讨一个例子来说明这个想法。
想象一下，同一公司的两个团队交付不同的软件，其中一个团队的软件依赖于另一个团队的软件。例如，用户体验依赖于API服务来检索显示的数据。这种情况在大型企业中很常见，在大型企业中，单个团队生产的软件可能有几十个或几百个消费者。
当软件消费团队(consuming team)需要许多特性时，软件生产团队(producing team)通常自身有一些需求和优先级流程来决定他们将开发哪些特性。对于重要的特性请求，如果没有按照当前工作的优先级排序，消费团队通常会选择3个选项中的一个，每个选项都有自己的缺点。
等待结果。消费团队可能什么也不做，没有进入排期的需求只能艰难前行。通常这种特性需求只占用消费团队最少的工作量。从实现特性带来的收益来说，等待可能没什么问题。然而，它可能带来真正的痛苦是所要求的功能从未被交付。
变通方案。一个不愿意等待的消费团队可能会在其他地方做额外的工作来弥补他们所需特性的缺失。这些额外的工作可能会随着使用项目的变化而出现。或者，他们可以创建一个新的项目来满足他们的需求，并替换他们对提供团队的全部或部分系统的使用(代码/项目复制)。这种策略只允许消费团队通过自己的努力来获得所请求的特性。不过它也有几个缺点：
对于具有相同功能请求的任何其他使用者，消费团队所做的任何工作都是不可用的。
消费团队无意中承担了维护新编写的代码的长期负担，这不在他们的核心团队能力范围内。
对于整个公司来说，同一个问题空间存在重复的项目和代码。
问题升级。消费团队可能不会接受生产团队的“不”的答案，相反，他们会建议生产者管理阶层的某个人去影响(或强迫)提供团队去做这项工作。这个选项听起来对消费团队很有吸引力，因为他们无需执行或维护就可以获得他们要求的特性。尽管如此，它仍然是消费团队的累赘，因为它必然会将他们的一些注意力和工作转移到问题升级的非工程任务上。此外，这个选项不具有可伸缩性，因为在破坏消费者在公司的信誉之前，消费者只能提出几次特性请求的问题升级。对于提供团队来说，问题升级也具有类似的破坏性(甚至更严重)，他们正常的工作流程和需求优先级处理了将会被打断，用以处理升级的特性请求。
这一讨论为InnerSource奠定了基础。InnerSource适用于消费团队的个性需求得不到满足的情况。InnerSource为团队提供了一种方法，使他们能够避免 等待结果、变通方案 和 问题升级 所带来的问题同时实现自己特性需要。
Learn
=
假设团队A使用的软件是由团队B生产的。团队A给团队B提交了一个特性需求，但团队B无法在团队A要求的时间内及时实现该功能。在InnerSource设置中，如果团队A不能得到这个特性请求，它会提一个提拉请求(Pull Request, 简称PR)代替。也就是说，团队A直接在团队B的软件中实现该功能，并提交一个带有代码更改的拉请求。团队B合作伙伴审查并接受提交的代码。
在这个例子中，我们称团队A为 调用(Guest) 团队 ，称团队B为 维护(Host) 团队 。 协同（Guest） 和 主导（Host） 这两个术语暗示了一种类似于在家里接待客人的情况。在这种情况下，大多数人都想成为一个好主人。为了迎接协同方的到来，他们确保所有的东西都保持整洁。来访者在门口受到欢迎并被邀请进来。他们可以使用家中公共区域的功能和公用设施。可能会有一些客人被要求遵守的家规。同样的，大多数客人也想表现出对家庭和主人的尊重。他们对房子里的东西很小心，在他们逗留期间遵守规则。只要他们有礼貌，他们就会希望收到新的访问邀请。这些围绕着家访的概念是一个隐喻，它是团队在一个主导向另一个协同贡献代码库时应该采取的态度和行为。
让我们仔细看看InnerSource的流程机制是如何工作的。为了帮助解释，我们将列出调用团队和维护团队中的几个关键人物。首先， 产品所有者（Product Owner） 确定维护团队愿意接受哪些功能作为贡献。 贡献者（Contributor） 是调用团队中提交代码贡献以供主人团队评审的个人。 Trusted Committer 代表维护团队在提供一个成功的拉取请求所需的任何及时支持和指导。在小规模的基层工作中，一个人通常同时担任产品所有者和受信任提交者的角色。
Learn
=
通过InnerSource进行协作有很多好处。 InnerSource为公司提供了一个可扩展的策略，以便 调用团队(guest team)在需要的时候获得特性请求 ，而无需承担长期的维护负担。 当调用团队的时间被放入其他人可以使用的代码中时，整个公司就赢了。
虽然这个结果是来自InnerSource的一个闪亮好处，但是对于那些定期接受内部资源贡献的维护团队(host team)来说有很多好处。 回想一下，作为InnerSource过程的一部分，维护团队的产品所有者从一开始就认为贡献的特性是好的和可取的。 InnerSource允许维护团队获得帮助，并为它的用户 打造更好的产品 !
InnerSource 为维护团队提供了一种可伸缩的策略 ，用于满足来自其众多客户的不同数量的功能需求。 考虑到维护团队全职成员的固定容量，很可能在某些时候，其消费者的组合业务路线图将需要(甚至不合理地)在维护团队的产品中完成大量的工作。 如果没有内部资源，这种情况很容易导致因为问题升级至维护团队领导，而让一个压力大、工作过度的团队处理更多特性请求。
Learn
=
每个公司、团队、项目和个人都是不同的。由于这个事实，内部源的工作方式在不同的情况下会有所不同。 然而，其核心是构成任何成功的InnerSource实例的四个原则。 这些原则对成功的开源项目有启发，为了使InnerSource获得前面描述的好处，这些原则是必需的，它包括：
开放
透明度
优先辅导
自愿贡献
让我们更详细地看看这些原则：
开放式项目的配置可以实现无摩擦贡献。项目应该通过在主仓库的 README.md 和 如何贡献.md中被发现，并得到良好的文档记录。 组织中的任何人都应该能够找到想要的项目，并且不需要过多的来自维护团队(host team)成员的直接指导。 维护团队的联系信息应该在对项目有意义的尽可能多的渠道中流行。宿主团队接受来自内部的对项目的贡献的意图应该通过相关组织渠道来共享，以提高意识。 特别是在较小的设置中，您可能希望在您的团队正在进行的内部源工作上建立一个定期的“广播”。 但是，在较大的环境中，这样的广播可能会产生很多噪音，而且更适合确保项目可以在一个易于使用的工具中被发现。 记住，我们的目标是让员工意识到，要利用 本公司 的适当渠道。
Learn
= 在这个学习过程中，我们已经介绍了InnerSource。 InnerSource将开放源码的最佳实践和原则应用于内部软件开发。 当维护团队（Host Team）无法交付所需的特性请求时，它为使用者提供了一个额外的选项。 成功的InnerSource包括来自 维护团队 的 产品所有者（Product Owner） 产品所有者和 Trusted Committer ， 以及来自 调用团队(Guest Team) 的 贡献者（Contributor） 。 如果处理有效，InnerSource将为参与团队带来很多好处。有效的InnerSource可以带来 自愿代码贡献 和 优先指导 。
Learn