贡献者是InnerSource项目的生命之源。每个InnerSource的项目，都有最终目标，就是超越最初的创始人，扩大他们的组织 和 调动用户之间更进一步合作的潜在性。
然而，是什么促使一个开发人员花时间在非本职工作的项目上？怎样才能激励其领导为他们的开发人员腾出时间来改进不在他们职权范围内的项目？
个人的动力
最明显的激励是吸引早期贡献者加入开源。
还记得你一直在处理的那个讨厌的错误吗？在维护为它们而做的替代解决方案上花费了很多时间和精力？如果不是等待上游团队在将来某个时候修复这个问题，而是你自己去动手修复它呢？在这种“自己抓痒”的情况下，第一次贡献的人通常从修复他们日常工作所依赖的项目中的问题开始，以减少他们自己代码库中的替代方案的数量。
在决定是否创建和贡献一个解决方法而不是维护你自己的替代方案时，请想想这贡献将为你带来的好处。与其孤立地工作，不如和上游项目的人一起，他们不仅可以审查，还可以改进你的解决方案。你将获得支持和指导，这将大大加快你的开发工作。
花更多的时间和他人一起工作，意味着随着时间的推移，你将了解团队如何工作，如何组织，以及以何种方式使用何种工具来构建他们的项目。通常情况下，你自己的项目会从这种经验中获益：在进行并将其引入你自己的项目之前，你能获得实践经验，而不是仅仅阅读一些新资料和构建系统。从事多个核心项目意味着你将接触到更大的生态系统，可以从中汲取最佳实践和解决方案来应对挑战。
在其他团队中花费一些时间的一个好处是，可以将你的声誉和影响力扩大到自己团队以外。因此，除了向他人学习和自我成长外，你还可以影响项目。你可以通过你的贡献，和分享你在项目中的工具化和部署方面的经验和知识，来产生影响力。这种共享可以帮助上游项目改进和加快开发周期。
除了所有这些客观标准外，还有一个很难度量的，这在 InnerSource 和开源项目中都有报道：人们之所以参与这些项目是因为他们发现这些项目的工作很有个人成就感和乐趣。最有可能的是，能够真正自主选择要做的任务，这一点确实很重要。这种自我选择通常也会导致上游项目的人非常欢迎和支持他们的工作，以保持贡献者的积极性。
团队层面的动力
还记得那个最终被上游团队所修复的恼人的bug吗？为什么你的团队要花费额外的精力来为上游项目修复bug呢？
首先，这意味着你的团队和上游项目一起花时间去维护这个项目。对于项目的每一次更新，都是在为你的需求服务。
让团队成员在你的团队中积极贡献，让他们在项目的方向和项目进度上有发言权，这对团队是有益的。
通过使用 InnerSource，团队可以在“独立构建你自己的系统”（包括你的任何数量的新bug）和“通过依赖现有的实现去节省时间和金钱”（以创建只能受到有限影响的长期依赖关系为代价）之间建立一个中间的选择。这个选择平衡了重新实现和重用这两种方式。
公司的动力
还记得有那种公司级别的问题-在公司层面有多个实现的功能吗？如果有一种办法可以避免许多bug的糟糕实现并将它们合并到共享资产中呢？如果这种共享资产的开发过程没有集中的力量来推动? 许多开源项目正在被许多参与者使用——其中一些人参与了他们的设计和开发。在企业层面上鼓励 InnerSource 项目的跨团队协作意味着你可以从组织的边缘推动集中式创新。
总的来说，众所周知， 卡车/巴士系数 bus factor 为一两个人的项目会对企业构成风险——尤其是当该项目最终成为企业目标的核心时。InnerSource 不仅有助于使此类项目透明化，还提供了一些工具，通过将重点放在指导和扩展贡献者基础来改善这种情况。
跨团队协作虽然很难评估个人贡献，但它使组织内的学习和知识贡献成为可能。因此，个人的影响将得到改善。最佳实践和积极创新将更容易在整个组织中传播。副作用是，在组织范围内的工作环境改善能帮助留住员工。
在技术方面，拥有更多具有不同背景的眼睛意味着代码的更改将受到更多的审查，这能提高整体质量和安全性。
最后，为了使项目的用户和客户能够参与开发，可提供一个非常明确的激励，让这些项目更易于开始：基于标准的工具，即易于理解、易于重用、更具模块化和可替换性。
结论
正如文中所述，个人和公司积极参与开源的许多原因也适用于 InnerSource 项目。我们还发现，促使人们在 InnerSource 项目中进行协作的不仅仅是利他主义的原因—— 而且通常很容易看到这样有意义的合作的商业价值。
