InnerSource如何运作?

=

假设团队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 代表维护团队在提供一个成功的拉取请求所需的任何及时支持和指导。在小规模的基层工作中，一个人通常同时担任产品所有者和受信任提交者的角色。

有了这些定义，下面是一个InnerSource的贡献的基本概要。

请注意，这些步骤并没有为团队的时间或优先级的一般组织假定一个特定的系统。InnerSource假设团队已经有了现有的组织方法，并提供了一个框架，用于在有调用团队希望向维护团队贡献代码时，如何使用这些方法进行协作。

这个选项对调用团队很有效，因为他们在需要的时候获得了所需的功能，而无需承担解决方案的长期维护负担。这对于维护团队来说是有效的，因为他们能够更好地拓展和服务他们的消费者。它适用于整个公司，因为共享问题的解决方案最终都在共享的、集中维护的位置，任何人都可以使用它们。更多的工程时间集中于生成解决公司问题的代码，而不是花费在特性协商和问题升级过程中。