=
通过InnerSource进行协作有很多好处。 InnerSource为公司提供了一个可扩展的策略，以便 调用团队(guest team)在需要的时候获得特性请求 ，而无需承担长期的维护负担。 当调用团队的时间被放入其他人可以使用的代码中时，整个公司就赢了。
虽然这个结果是来自InnerSource的一个闪亮好处，但是对于那些定期接受内部资源贡献的维护团队(host team)来说有很多好处。 回想一下，作为InnerSource过程的一部分，维护团队的产品所有者从一开始就认为贡献的特性是好的和可取的。 InnerSource允许维护团队获得帮助，并为它的用户 打造更好的产品 !
InnerSource 为维护团队提供了一种可伸缩的策略 ，用于满足来自其众多客户的不同数量的功能需求。 考虑到维护团队全职成员的固定容量，很可能在某些时候，其消费者的组合业务路线图将需要(甚至不合理地)在维护团队的产品中完成大量的工作。 如果没有内部资源，这种情况很容易导致因为问题升级至维护团队领导，而让一个压力大、工作过度的团队处理更多特性请求。
但是，如果维护团队通过InnerSource进行操作，那么构建这些特性所需的工程资源将以调用贡献者的形式按其重要性的比例出现。 InnerSource成为一个 力量倍增器 ，允许维护团队在高需求时临时采取比实际规模更大的行动。 当需求结束时，团队吞吐量将恢复到正常水平，所有这些都不需要对团队人员总数或工作项进行任何微管理。 InnerSource允许工程时间在给定的时间内有机地流到组织需要它的地方。
除了维护团队能够在其系统中完成的原始工作之外，定期的内部资源贡献还为维护团队提供了更好的需求， 并使其优先级与所有使用者保持一致。维护团队可以对其生成的工作进行最佳的需求收集， 但是当使用者本身提交工作时，结果更改与使用者的需求保持一致的几率要高得多。虽然可能只有一个调用团队提交更改，但该团队可能代表许多其他客户。
除了这种联合之外，还有对 贡献者（Contributor） 的一般培训和教育，因为他们与 Trusted Committer 一起工作并向他们学习。 这种互动有助于贡献者在他们的职业生涯中学习和成长，从而获得 更高的工作满意度 。 项目文档的改进使这些贡献能够规模化。贡献者认为自己与维护团队项目是有利害关系的。 这是他们向同事或新加入的团队推荐的东西。他们能够更好地理解项目，并能够向其他人回答关于项目的问题，从而减轻维护团队的一些负担。 更多的人为一个项目做出贡献，自然会有来自公司各个部门的不同想法相互交流。随着时间的推移，这种学习和跨团队协作有助于 打破传统公司壁垒 。
