编码和谈判？

你可能会好奇这两者如何结合在一起。

特别是对于 InnerSource 主办团队来说，在进行变更谈判时牢记一些绊脚石会有所帮助。

正如上一个部分所讨论的，较小的代码变更通常会更快地被接受。对于主办团队来说，优势是显而易见的，应该向贡献团队传达：

* 它们更容易评审。

* 它们的影响相对更小——无论是积极的还是消极的。

* 它们能更快获得集成。

因此，以临时方式进行小的更改通常不会造成任何摩擦。它们是随意贡献者的最佳选择，通常无需太多协调支持即可处理。通常，InnerSource 贡献是这样开始的：团队中的工程师开始就较小的变更进行协作，并发现这项工作非常简单且轻量。较小的变更通常也是无需升级即可完成。

这可能导致团队形成一种思维定式，认为 InnerSource 只是软件工程师的专属。然而，一旦贡献范围扩大，这种临时工作模式就会被打破。如果仅由软件工程师负责，在最坏的情况下，即使团队中的其他角色也能推波助澜，这也意味着升级会更加频繁。对于范围较大的修改，贡献团队和主办团队中的其他角色需要了解 InnerSource 的工作，并需要发挥他们的技能：

* 两个团队需要共同确定一个进行贡献的最佳时机。如果主办团队没有时间指导，贡献团队更有可能因缺乏支持而感到沮丧。他们也许更可能会开发出一种可能需要大量返工的解决方案，从而导致每个相关人员都感到沮丧。如果贡献团队没有时间专注于贡献，那么变更的完善周期可能会变得过长、中断次数过多。

* 在编写任何源代码之前，贡献者和主办团队需要确定更改是否符合 InnerSource 项目的愿景。理想情况下，这也意味着技术和业务层面的专业知识需要结合在一起，最好是在人人都可以参与的同一沟通渠道上。通常，这会导致就是否应在 InnerSource 项目中实施更改进行协商——随后由主办团队负责维护。这可能意味着相关人员需要澄清每个参与人员的价值是什么，而且还需要澄清贡献团队是否以及如何帮助主办团队减轻维护负担。

=== 协调

“只需编写代码并将补丁发送给我们”——听起来很简单。但实际上，这仅适用于最微不足道的更改。尤其是较大的变更需要协调，以便每个相关人员都有时间参与，否则预计等待时间会更长。跨越团队边界通常也意味着沟通文化的微妙变化。沟通能力强的人可以在团队之间进行翻译，以防出现误解，从而帮助弥合这些差距。

与仅处理本地代码的团队相比，InnerSource 主办团队需要确保与所有潜在贡献者沟通他们的路线图和愿景。此外，主办团队需要确保设计、架构和性能要求对所有参与代码库工作的人（包括临时贡献者）来说都是明确且清晰的。对于习惯在非常有凝聚力的本地环境中工作的团队来说，这种转变尤其困难。本质上，在本地团队中隐含的一切都需要变得透明和明确。从短期来看，这确实会花费时间，但从长远来看，它可以帮助贡献者更快地上手和加速，从而减少主办团队的支持。开源领域已被证明成功的一件事是，让贡献者轻松走上正确的道路，这包括在构建时失败的自动质量检查。虽然编写和维护这些内容非常耗时，但由于明显的问题会自动突出显示，因此主办团队的负担也减轻了。

InnerSource 与常规团队之间协调的一个不同之处是，有机会打破常规思维：想象一下，贡献者 Bob 需要对 Alice 维护的 InnerSource 项目进行非常复杂的修改。Bob 刚刚开始了解代码库，单靠他自己很难理解。此外，指导他完成整个过程会花费 Alice 很多时间。不过，Alice 积压的待办任务中有几个高优先级但易于实现的功能。如果 Bob 从 Alice 的待办任务中剥离其中一些问题并实施——作为回报 Alice 有时间完成 Bob 所需要的变更，会怎么样？为了透明起见，这些协议应同时向主办团队和贡献团队解释。否则，他们将很难理解为什么 Bob 和 Alice 不在各自客户需要的变更上工作。

再举一个例子，假设一个主办团队正在开发一个非常受欢迎的 InnerSource 项目。它可能是公司业务的核心。随着时间的推移，越来越多的贡献者能够做出他们需要的更改，从而将主办团队变成审核瓶颈。要解决这个问题，明确整体业务的优先级和贡献团队的重要性有助于了解哪些补丁需要优先处理，并阻止主办团队成员不断转移焦点。下一步，主办团队需要考虑扩大参与该 InnerSource 项目的可信提交者的数量。如前所述，方法之一是邀请那些向不同业务部门汇报的参与者加入。

尤其是在当面对大量相当复杂的贡献时，主办团队需要了解在哪些方面投入时间来指导贡献者是值得的。指导所需的时间越多，这些贡献者就越有可能坚持更长时间。