=
无论员工在公司组织结构中的位置如何，InnerSource鼓励并奖励与任何人的协作和代码的重用。这种方法与传统组织中看到的不同，传统组织中的思想和工作产品往往被困在内部企业层级结构及约束的边界内。让我们来探讨一个例子来说明这个想法。
想象一下，同一公司的两个团队交付不同的软件，其中一个团队的软件依赖于另一个团队的软件。例如，用户体验依赖于API服务来检索显示的数据。这种情况在大型企业中很常见，在大型企业中，单个团队生产的软件可能有几十个或几百个消费者。
当软件消费团队(consuming team)需要许多特性时，软件生产团队(producing team)通常自身有一些需求和优先级流程来决定他们将开发哪些特性。对于重要的特性请求，如果没有按照当前工作的优先级排序，消费团队通常会选择3个选项中的一个，每个选项都有自己的缺点。
-
等待结果。消费团队可能什么也不做，没有进入排期的需求只能艰难前行。通常这种特性需求只占用消费团队最少的工作量。从实现特性带来的收益来说，等待可能没什么问题。然而，它可能带来真正的痛苦是所要求的功能从未被交付。
-
变通方案。一个不愿意等待的消费团队可能会在其他地方做额外的工作来弥补他们所需特性的缺失。这些额外的工作可能会随着使用项目的变化而出现。或者，他们可以创建一个新的项目来满足他们的需求，并替换他们对提供团队的全部或部分系统的使用(代码/项目复制)。这种策略只允许消费团队通过自己的努力来获得所请求的特性。不过它也有几个缺点：
-
对于具有相同功能请求的任何其他使用者，消费团队所做的任何工作都是不可用的。
-
消费团队无意中承担了维护新编写的代码的长期负担，这不在他们的核心团队能力范围内。
-
对于整个公司来说，同一个问题空间存在重复的项目和代码。
-
-
问题升级。消费团队可能不会接受生产团队的“不”的答案，相反，他们会建议生产者管理阶层的某个人去影响(或强迫)提供团队去做这项工作。这个选项听起来对消费团队很有吸引力，因为他们无需执行或维护就可以获得他们要求的特性。尽管如此，它仍然是消费团队的累赘，因为它必然会将他们的一些注意力和工作转移到问题升级的非工程任务上。此外，这个选项不具有可伸缩性，因为在破坏消费者在公司的信誉之前，消费者只能提出几次特性请求的问题升级。对于提供团队来说，问题升级也具有类似的破坏性(甚至更严重)，他们正常的工作流程和需求优先级处理了将会被打断，用以处理升级的特性请求。
这一讨论为InnerSource奠定了基础。InnerSource适用于消费团队的个性需求得不到满足的情况。InnerSource为团队提供了一种方法，使他们能够避免 等待结果、变通方案 和 问题升级 所带来的问题同时实现自己特性需要。
随着工程师有机会与更广泛的新技术和人员一起工作，InnerSource也为工程文化提供了普遍的改进。开发人员在跨组织壁垒共享想法和解决方案时互相指导和学习。工程师和团队可以重用内部解决方案来解决商品问题，从而使他们能够将精力集中在组织更高价值的工作流上。
