介绍
本学习路径介绍了InnerSource。 InnerSource是开源实践和原则在企业内部软件开发的应用。 InnerSource的软件仍然是该公司的专有软件，但它对该企业任何内部员工都是开放的，都可以使用它并为它做出贡献。 这一战略能够支持广泛而有效的协作，生成对其许多内部利益相关者不断变化的需求作出响应和灵活反应的软件。 本学习路径教你如何识别适合InnerSource的情况。 我们将从较高的层次概述InnerSource在这些情况下如何提供帮助。 在讨论InnerSource时，您将熟悉使用的专业术语。 我们还将列举InnerSource所基于的关键原则，以及在有效应用时所看到的好处。
Learn
InnerSource解决的问题?
= 无论员工在公司组织结构中的位置如何，InnerSource鼓励并奖励与任何人的协作和代码的重用。这种方法与传统组织中看到的不同，传统组织中的思想和工作产品往往被困在内部企业层级结构及约束的边界内。让我们来探讨一个例子来说明这个想法。 想象一下，同一公司的两个团队交付不同的软件，其中一个团队的软件依赖于另一个团队的软件。例如，用户体验依赖于API服务来检索显示的数据。这种情况在大型企业中很常见，在大型企业中，单个团队生产的软件可能有几十个或几百个消费者。 当软件消费团队(consuming team)需要许多特性时，软件生产团队(producing team)通常自身有一些需求和优先级流程来决定他们将开发哪些特性。对于重要的特性请求，如果没有按照当前工作的优先级排序，消费团队通常会选择3个选项中的一个，每个选项都有自己的缺点。 等待结果。消费团队可能什么也不做，没有进入排期的需求只能艰难前行。通常这种特性需求只占用消费团队最少的工作量。从实现特性带来的收益来说，等待可能没什么问题。然而，它可能带来真正的痛苦是所要求的功能从未被交付。 变通方案。一个不愿意等待的消费团队可能会在其他地方做额外的工作来弥补他们所需特性的缺失。这些额外的工作可能会随着使用项目的变化而出现。或者，他们可以创建一个新的项目来满足他们的需求，并替换他们对提供团队的全部或部分系统的使用(代码/项目复制)。这种策略只允许消费团队通过自己的努力来获得所请求的特性。不过它也有几个缺点：
Learn
InnerSource如何运作?
= 假设团队A使用的软件是由团队B生产的。团队A给团队B提交了一个特性需求，但团队B无法在团队A要求的时间内及时实现该功能。在InnerSource设置中，如果团队A不能得到这个特性请求，它会提一个提拉请求(Pull Request, 简称PR)代替。也就是说，团队A直接在团队B的软件中实现该功能，并提交一个带有代码更改的拉请求。团队B合作伙伴审查并接受提交的代码。 在这个例子中，我们称团队A为 调用(Guest) 团队 ，称团队B为 维护(Host) 团队 。 协同（Guest） 和 主导（Host） 这两个术语暗示了一种类似于在家里接待客人的情况。在这种情况下，大多数人都想成为一个好主人。为了迎接协同方的到来，他们确保所有的东西都保持整洁。来访者在门口受到欢迎并被邀请进来。他们可以使用家中公共区域的功能和公用设施。可能会有一些客人被要求遵守的家规。同样的，大多数客人也想表现出对家庭和主人的尊重。他们对房子里的东西很小心，在他们逗留期间遵守规则。只要他们有礼貌，他们就会希望收到新的访问邀请。这些围绕着家访的概念是一个隐喻，它是团队在一个主导向另一个协同贡献代码库时应该采取的态度和行为。
Learn
InnerSource的收益?
= 通过InnerSource进行协作有很多好处。 InnerSource为公司提供了一个可扩展的策略，以便 调用团队(guest team)在需要的时候获得特性请求 ，而无需承担长期的维护负担。 当调用团队的时间被放入其他人可以使用的代码中时，整个公司就赢了。 虽然这个结果是来自InnerSource的一个闪亮好处，但是对于那些定期接受内部资源贡献的维护团队(host team)来说有很多好处。 回想一下，作为InnerSource过程的一部分，维护团队的产品所有者从一开始就认为贡献的特性是好的和可取的。 InnerSource允许维护团队获得帮助，并为它的用户 打造更好的产品 !
Learn
InnerSource的原则
= 每个公司、团队、项目和个人都是不同的。由于这个事实，内部源的工作方式在不同的情况下会有所不同。 然而，其核心是构成任何成功的InnerSource实例的四个原则。 这些原则对成功的开源项目有启发，为了使InnerSource获得前面描述的好处，这些原则是必需的，它包括： 开放 透明度 优先辅导
Learn
结论
= 在这个学习过程中，我们已经介绍了InnerSource。 InnerSource将开放源码的最佳实践和原则应用于内部软件开发。 当维护团队（Host Team）无法交付所需的特性请求时，它为使用者提供了一个额外的选项。 成功的InnerSource包括来自 维护团队 的 产品所有者（Product Owner） 产品所有者和 Trusted Committer ， 以及来自 调用团队(Guest Team) 的 贡献者（Contributor） 。 如果处理有效，InnerSource将为参与团队带来很多好处。有效的InnerSource可以带来 自愿代码贡献 和 优先指导 。
Learn