你希望改进产品，更快地将其交付给客户，并让利益相关者满意。InnerSource 可帮助你的团队在高度互联的世界中实现价值并保持自主性。
组织试图快速向客户交付价值。一个常见的延迟原因是交付过程中的依赖关系。因此，组织更喜欢跨职能团队，涵盖客户沟通、设计、实施、测试和运营，从而消除昂贵的交接。为了实现高绩效，团队消除浪费并重复使用已有组件。从团队的角度来看，每个重复使用的组件都会给该团队增加一个其无法控制的依赖关系。这种优化的负面影响很明显：如果一个团队需要更改所使用的组件，则该团队依赖于另一个团队。为了能够实施这些计划，通常会安排冗长的路线图讨论，有时需要在全球范围内优化详细的优先级。在复杂的情况下以及在大型组织中，这会导致需要增加适应不断变化的业务需求的时间。对于非常受欢迎的核心组件，通常会收到非常多的请求，以至于一个核心组件团队无法实施对所有请求的响应。
在传统组织中只有 两种方式来更改依赖 ：
-
提交功能请求/错误报告，然后等待其他团队确定变更的优先级并实施。
-
实现一个解决方法来避免错误或在本地提供所需的功能。
如果这些方案都不成功，问题通常会升级，由更高层级来决定。
这两种解决方案都不是特别令人满意。从开源的视角来看，有一个明显的解决方案：依赖组件的团队成为贡献者，并向该组件团队提供帮助。
现在你可能会有这样的疑问：“这样做难道不会引起很大混乱，让人们会随意修改其他团队的代码库吗？”InnerSource 提供了一套角色和流程，使原本可能导致混乱的情况变得更加清晰：
-
每个 InnerSource 项目都有一组职责明确的受信任提交者，他们的职责不仅仅是简单地审查代码，还要制定贡献规则。
-
贡献以有组织的方式进行：
-
尽早交流贡献意向，确保贡献符合项目的愿景和范围。
-
尽早分享进展，项目主办团队就有机会指导贡献者，引导他们实现理想的设计和架构；这样就能避免在后期因拒绝贡献而产生的挫败感。
-
决策和重要沟通异步进行，以便能够解决不同团队中人员的不同会议安排。因此，贡献团队获得了修复上游组件的自主权，而又不会牺牲所贡献组件的质量。
-
此外，InnerSource 还为团队提供最佳实践，让团队在远程文化中轻松工作。
InnerSource 鼓励团队之间相互协作，而不是各自为政。就像在开源领域一样，这意味着要站在巨人的肩膀上：InnerSource 鼓励复用，而不是在本地重复构建每个组件。它提供了一条明确的途径，支持上游团队修复错误和实现功能，从而降低了重复使用的成本。
就像在开源领域一样，InnerSource 培养了一种联合力量的思维： 所有业务部门和产品团队所需的基础组件都可以共同构建。因此，百舸争流：组织中某个部门的创新可以为整个公司创造效益。有了熟悉 InnerSource 的团队，所有团队都可以分担推进此类创新的重任，并从中受益，依赖于由此产生的组件和服务。
InnerSource 为你的团队提供了主动性和工具，以解决阻碍向客户交付功能的问题。如果方法得当，核心组件和服务的维护工作可以由一个“虚拟 InnerSource 团队”以结构合理的方式共享，该团队的规模要大于任何特定的产品团队。
在高级设置中，相关人员理解贡献者开发较简单功能的价值，这些功能可能不会直接惠及他们的客户-——但前提条件是，这可以让托管团队腾出时间来开发贡献者有业务需求的更复杂的变更。
直接答案： 完全不是。恰恰相反，两者相辅相成：
精心设计和经过充分测试的代码是所有敏捷团队的目标之一。在 InnerSource 设置中，团队成员以及团队外部贡献者的上岗都会变短。
熟悉协作、避免分配任务的团队也能以灵活的方式处理外部贡献。此外，他们的思维方式和沟通方式也能很好地激励那些他们无法直接影响其优先级的贡献者。利用内在动力而不是指挥工作，意味着项目主办团队拥有与贡献者成功合作的工具。
结对解决问题的团队已经习惯于尽早分享进展。从结对文化转向 InnerSource 有两个挑战：项目主办团队需要为支持贡献者安排时间，并将其纳入计划工作。此外，当跨越团队边界时，往往很难找到刚好匹配的时间段——在这种情况下，应辅之以异步协作。在 InnerSource 环境中，为了避免频繁的干扰，主办团队成员往往需要有意识地更严格地规划自己的一天。通常，最简单的方法是在一天中留出某些时间或每周留出一天用于指导贡献。在团队层面明确规定这一点，既能减轻工程师的压力，让他们努力实现自己的团队目标，又能帮助贡献者。结对的另一个挑战是，它允许结对人员一起快速行动，但这往往以为团队其他成员写下重要信息为代价。在 InnerSource 环境中，确实需要进行培训，以牢记将所有相关决策带回共享的沟通渠道，供团队和贡献者双方使用。从产品的角度来看，这确实会提高开发过程的透明度。这也意味着，原本可能只在工程层面做出的决策，现在对所有相关人员都是可见的。
还记得上次你坚持要对产品进行完善的测试，最好是自动化测试，这样就可以在无需人工干预的情况下频繁部署产品了吗？现在，这一目标对 InnerSource 也有帮助：如果贡献者可以在本地检查他们的修改是否安全，那么贡献就会容易得多。测试还能确保托管团队在测试失败的情况下记得保留所贡献的功能。
还记得上次你坚持让团队花时间遵循“让代码变得比你发看到它时更好”的目标吗？这种心态有助于 InnerSource 模型：它能确保代码的质量和凝聚力，即使有来自不同来源的多种贡献，也能保持较高水平。
InnerSource 和敏捷使用一些相同的工具，但目的不同。
问题跟踪：在敏捷团队中，用户故事是与客户的对话。通常它们会作为便签贴在白板上。但它们通常也存储在问题跟踪器中。因此，问题跟踪器主要被视为规划工具，本质上是白板上便签的替代品。在 InnerSource 中，问题跟踪器用于与客户进行对话，还用于在一个公共 InnerSource 组件上工作的受信任提交者和贡献者团队的成员之间进行通信。 InnerSource 中的问题比一般组织中的问题更加冗长和啰嗦。他们还跟踪变更的实施历史和详细设计决策。
代码评审： 在传统组织中，代码审查通常是出于审计目的。
当开发完成时，代码评审就完成了。在 InnerSource，代码变更在开发过程的早期就会共享，有时甚至只完成了一个粗略的草图。这样做的目的是寻求早期反馈和指导。这对那些日程安排繁多、没有时间结对编程的团队特别有帮助。团队通常都有一个愿望，那就是没有人是孤独前行的，但在现实中，这往往只是一个从未实现的愿望，特别是当贡献跨越团队界限时。
InnerSource 中使用的工具可以将这一要求正式化，即任何变更都必须有不止一个人参与。
注重书面沟通：InnerSource 的目标是让项目足够透明，以便非团队成员的开发人员能够理解项目决策并遵循软件创建过程。因此，所有沟通都需要放在每个对对话感兴趣的人都可以跟进的地方：书面的、公开的、可搜索的和可链接的。目标不是减少对他人的干扰——目标是使所有项目对话透明。
因此，应避免直接消息和邮件。为了使每个人都能更轻松地进行后续对话，应在一个单独的沟通渠道中跟踪与一个 InnerSource 项目相关的消息：目标并非触达 InnerSource 项目团队中的每个人，而是为参与该项目的每个人找到一个共同的共享房间，他们可以在那里重点讨论该 InnerSource 项目。
注重书面交流并不意味着不允许口头交流，仍然需要时间一起喝杯咖啡。此外，一起解决问题、与他人结对或亲自参加黑客马拉松对于快速找到解决方案也很有价值。团队需要确保所有项目相关决策都保存在每个人都可以访问的渠道中。这也可能意味着推迟重要的项目决策，直到每个人都休假回来，或者如果在另一个国家工作的人现在正在度假，则需要再等待一两天。这不仅与编码决策相关，还与总体项目任务、路线图和方向相关。如果没有这些信息，贡献者将很难理解哪些贡献将有很好的机会被接受。