"如果每个人都拥有它，就没有人需要负责"。传统组织更希望在出现问题时通过单点联系。另一方面，如果允许每个人都进行修改，肯定会导致一团糟，不可持续。

基于这种观察，每个 InnerSource 项目都有一个专门的可信提交者团队。对 InnerSource 项目的维护兴趣往往是切合自身利益的：团队明白他们自己需要 InnerSource 项目来满足客户的需求，也明白开放项目并接受贡献可以分散工作量，从而推动项目向前发展。不过，开放项目并接受贡献并不意味着可信提交者必须接受所有贡献提交。可信提交者团队才是项目使命和目标的制定者。这样他们才能确定方向，并决定是否接受相应的变更。

“可信的提交者负责 InnerSource 项目。他们审查提交内容并指导贡献者。”

这是对可信提交者角色的简单概况。事实上，第一个问题往往围绕着是否要接受每一项贡献。特别是当贡献者已经投入大量时间进行贡献时，当他们听到自己的工作是徒劳时可能会感到沮丧。沟通技巧对于确保贡献者大致了解 InnerSource 项目的路线图非常重要。此外，还需要确保贡献者知道尽早分享意图和进展，以避免花费大量工作却没有结果。最后但并非最不重要的一点是，拒绝贡献需要非常好的沟通技巧。简而言之：即使你不亲自编写源代码，也需要你的支持，以便清楚地传达 InnerSource 项目的愿景，并在需要拒绝贡献时提供潜在的帮助。随着 InnerSource 项目变得越来越受欢迎，另一个方面变得更加重要：评审和指导变得更加耗时，并且随着时间的推移，需要明确地安排到每天的工作中。这确实会对总体能力规划产生影响，并且不应该“暗箱操作”。

另一方面，对于贡献者来说，重要的是代码评审不是最后阶段的质量关卡。相反，它是一种持续指导贡献者完成代码开发过程的方法，理想情况下可以更快地获得更好的结果。为了在实践中实现这一点，需要有时间和空间来进行团队建设——但要跨越传统的团队界限。对团队中的不同文化至少有一个模糊的了解可以大大减少误解的可能性，并使贡献过程更加顺利。

尤其是当主办团队被大量的贡献所淹没时，原本只关注本地团队的项目领导者更需要从全局角度来看待问题：

* 帮助团队根据公司整体战略，了解所接收贡献的不同优先级。通常情况下，并非所有贡献都同样紧迫。

* 帮助团队的另一种方法是接手诸如问题分类、处理对贡献者的初步响应，以及指导较大的贡献完成流程等任务。如果集成变更需要更长的时间，你可以通过与贡献者沟通来帮助团队。

* 面临更大的贡献请求时，团队可以通过与其他团队协商最佳工作时间来获益。通常情况下，这仍然比你的团队独自完成所有工作要快得多。特别是首次贡献者可能会需要一些指导——尤其是对于较大的变更。协调指导的时间对你的团队有很大的帮助。

"但我们可以简单地永久分叉"......这是一种误解，潜在的客户团队认为简单地复制代码会更快。

从短期来看，这是事实。从长远来看，这意味着增加维护工作。作为项目负责人，你可以帮助团队了解为什么对你所依赖的项目进行更改符合业务的最佳利益：总体上减少工作量。长期维护工作由主办团队承担。

=== InnerSource 治理级别

“我们使用拉取请求来开发我们的组件——因此我们每天都使用 InnerSource”。虽然使用拉取请求和评审是一个重要组成部分，但它只是 InnerSource 项目的基线。仅仅因为你依赖的两个项目每天都使用拉取请求，并不意味着它们对团队外部贡献的开放程度是相同的。

InnerSource 具有不同的最佳实践。为了避免贡献者感到困惑和沮丧，主办团队必须为其 InnerSource 项目定义他们想要采用的治理模型。就像开源一样，不同的治理级别可能存在很大差异。

在 InnerSource Commons 中，我们提供了一种 InnerSource 模式，它至少定义了三个管理级别：

* 每个人都能看到源代码，但团队没有时间指导贡献者。从外观上看，这可能就像日常的 InnerSource 项目。明确拒绝指导和接受贡献，可以避免试图通过 InnerSource 方式与项目互动的同事产生混淆。相反，这将向那些依赖项目的人传达，团队只能处理功能请求和错误报告。从根本上说，这意味着回归到常规的传统软件开发项目。

* 每个人都能看到源代码——此外，可信提交者团队还为指导贡献者留出了时间。这些项目欢迎补丁和拉取请求。可信提交者团队确保与项目相关的交流以书面、存档、可搜索和可链接的方式进行。该团队还确保与项目相关的决策会在贡献者可以看到和关注的地方做出。不过，最终的决策还是由可信提交者团队做出——成为项目的可信提交者与为最初的项目团队工作息息相关。

* 同上，但可信提交者团队对共享写入权限持开放态度。这种方法需要与贡献者建立足够的信任，以便可信提交者团队共享写入权限。如果与贡献者有长期关系，这尤其有用。共享写入访问可以消除评审瓶颈。

* 在最后阶段，可信提交者团队还准备好分享对谁获得下一个写入访问权限以及项目愿景和使命的控制权。虽然这通常会导致贡献者做出最高的承诺，但也需要跨团队边界的高水平协调。在做出项目决策时还需要最大的透明度。

总之，每个治理级别都需要不同的合作与协调方法

* 共享的增加会增加沟通与协调的需求。

* 共同责任的增加会减缓决策速度。

=== 明确的贡献指引

如果项目希望鼓励贡献，那么对团队成员而言隐含的内容最好明确并记录下来。比如：

* 提交变更时的期望响应时间，

* 与可信提交者团队联系时使用的沟通渠道，

* 作为贡献者尝试跟踪项目时使用的沟通渠道

* 项目期望的治理级别 这些是整个主办团队必须同意并与贡献者沟通的所有主题。

=== 对领导力的影响

InnerSource 项目责任共享的增加也会对绩效评估产生影响。在层级结构中，人们通常会考虑团队本地的贡献。然而，InnerSource 贡献者开始在自己的团队之外产生影响。 InnerSource 可信提交者对可能超出其自己团队范围的团队产生影响。这意味着直属经理正在失去一定程度的控制，他们也正在失去直接监督。因此，应该考虑来自潜在远程团队的绩效反馈。

=== 在较高的共享级别中施行“谁构建，谁运行”

跨职能团队的常见最佳实践是“谁构建，谁运行”策略。由于下游用户可能做出贡献，这种最佳实践似乎被打破了。在这种情况下也有多种实施 InnerSource 的方法：

* 第一个是转向更大的模块化，仅在团队之间共同的部分上进行协作，并保持本地运维。

* 或者使用合约测试来避免 API 中断。

* 与内部服务水平协议SLA合作，让贡献者签署保修期，以消除主办团队对贡献会破坏生产系统的恐惧。