红帽公司约有 11,000 名员工。IT 部门约有 500 名成员。虽然它仅占整个组织的一小部分，但 IT 部门的人员配备仍然充足，拥有许多应用服务、基础设施和运营团队。我们的宗旨是“使红帽公司的所有职能部门的员工都能够高效、高产、创新和协作，从而让他们觉得自己可以有所作为”，更具体地说，是通过尽可能开放的方式提供技术和相关服务来实现这一目标。
像这样保持开放需要时间、注意力和努力。虽然我们始终努力尽可能开放，但这可能很困难。由于各种原因，我们并非总是成功。
在这个故事中，我将解释这样一次经历：在创新浪潮中，红帽 IT 组织忽视了其开放的理想。但我也将探讨回归这些理想——并使用“内部资源”的协作策略——如何帮助我们恢复并极大地改进我们交付服务的方式。
关于内部资源
在解释内部资源如何帮助我们的团队之前，请允许我先介绍一下这个概念的背景。
内部资源是指在组织内部的团队之间采用开源开发实践，以促进更好、更快的交付，而无需将项目资源暴露给全世界或公开许可。它使组织能够在自己的内部获得开源开发方法的许多好处。
通过这种方式，内部资源与开放组织战略和原则非常吻合；它为开放、协作开发提供了一条道路。虽然开放组织将其开放原则广泛定义为透明度、包容性、适应性、协作和社区——并涵盖如何将这些开放原则用于沟通、决策和许多其他主题——但内部资源是关于从开源社区采用特定和战术性的实践、流程和模式，以改进交付。
例如，《开放组织成熟度模型》建议，为了实现透明化，团队至少应与项目团队共享所有项目资源（尽管它建议通常最好与整个组织共享这些资源）。内部资源和开源开发中的常见模式是将所有资源托管在公开可用的版本控制系统中，用于源代码控制管理，这实现了开放组织的高度透明的目标。
价值对齐的另一个例子出现在开源社区接受贡献的方式中。在开源社区中，源代码是透明可用的。以补丁或合并请求形式的社区贡献是常见的（甚至是期望的）做法。这提供了一个如何满足开放组织促进包容性和协作的目标的例子。
挑战
2014 年初，红帽 IT 部门开始朝着使 Amazon Web Services (AWS) 成为业务关键系统的标准托管产品迈出第一步。虽然红帽 IT 部门内部的团队此时已在 AWS 中构建了多个系统和服务，但这些都是定制化的创建，我们希望使在 AWS 中部署符合 IT 标准的服务既简单又标准化。
为了使 AWS 云托管满足我们的运营标准（同时具有可扩展性），红帽 IT 部门内的云启用团队决定，AWS 中的所有基础设施都将通过代码而不是手动配置，并且每个人都将使用一套标准工具。云启用团队设计并构建了这些标准工具；一个单独的团队，平台运营团队，负责使用这些工具在 AWS 中配置和托管系统和服务。
云启用团队构建了一套工具集，名称晦涩地命名为“模板实用程序”，它基于 AWS Cloud Formations 配置，并封装在一个管理层中，以强制执行某些配置要求，并使跨环境快速创建多个服务副本变得更容易。虽然模板实用程序工具集在技术上满足了我们所有的初始要求，并且我们最终使用它为十几个以上的服务配置了基础设施，但每个使用该工具的团队中的工程师都发现使用它很痛苦。一位使用该工具的工程师迈克尔·约翰逊说：“它使做一些相对简单的事情变得非常复杂。”
模板实用程序表现出的问题包括：
- 底层云编队技术暗示了对应用程序堆栈管理的约束，这与我们管理应用程序系统的方式不符。
- 该工具在某些地方不必要地复杂且脆弱，使用了多层模板技术和语言，使得语法问题难以调试。
- 该工具的代码以及用户操作该工具所需的一些数据都保存在大多数用户难以访问的存储库中。
- 没有贡献或接受更改的标准流程。
- 文档质量很差。
随着越来越多的工程师尝试使用模板实用程序工具集，他们发现了该工具的更多问题和局限性。不满情绪持续增长。更糟糕的是，云启用团队随后将优先级转移到其他可交付成果，但并未放弃该工具的所有权，因此对该工具的错误修复和改进进一步延迟。
这里真正核心的问题是我们无法建立一个包容性的社区来协作构建满足每个人需求的共享工具。害怕失去“所有权”、害怕更改需求以及害怕看到辛勤工作被放弃，所有这些都导致了长期冲突，反过来又导致了更差的结果。
危机点
到 2015 年 9 月，在使用模板实用程序工具在 AWS 中启动我们的第一个主要服务一年多后，我们达到了危机点。
许多工程师拒绝使用这些工具。这迫使所有相关的服务配置工作都落到少数工程师身上，进一步分裂了社区，并扰乱了服务交付路线图，因为这些工程师努力处理意外的工作。我们召开了紧急会议，邀请所有相关团队寻找解决方案。
在紧急会议期间，我们发现人们普遍认为我们需要立即改变，并且应该重新开始工具工作，但即使是重新开始的决定也不是一致的。出现了许多解决方案——有时一个团队内部就有多个解决方案——所有这些都需要大量工作才能实施。虽然在这次会议上我们无法就使用哪个解决方案达成共识，但我们确实达成了一项协议，即给不同技术的支持者两周时间跨团队合作，通过原型构建他们的案例，然后社区可以对其进行审查。
虽然我们没有达成最终和明确的决定，但这项协议是我们开始回归指导我们使命的开源理想的第一个点。通过邀请所有相关方，我们能够做到透明和包容，并且我们可以开始重建我们的内部社区。通过明确表示我们希望改进事物并对新选择持开放态度，我们展示了我们对适应性和任人唯贤的承诺。最重要的是，构建原型的计划为人们提供了一条清晰的回归协作之路。
当社区审查原型时，它确定明确的领导者是一个基于 Ansible 的工具集，该工具集最终将在内部被称为 Ansicloud。（当时，参与这项工作的任何人都不知道红帽会在下个月收购 Ansible。还应注意的是，红帽内部的其他团队发现基于 Cloud Formation 的工具非常有用，即使我们特定的模板实用程序工具没有取得成功。）
这个原型设计和测试阶段并没有在一夜之间解决问题。虽然我们对需要前进的大方向达成了共识，但我们仍然需要改进新的原型，使其达到工程师可以可靠地将其用于生产服务的程度。
因此，在接下来的几个月中，少数工程师致力于进一步构建和扩展 Ansicloud 工具集。我们构建了三个新的生产服务。虽然我们正在共享代码，但这种共享活动发生在较低的成熟度水平。一些工程师由于旧流程而难以获得访问权限。其他工程师朝着略有不同的方向前进，每个工程师都必须重新发现一些核心设计问题。
回归开放
这导致了一个转折点：在先前协议的基础上，我们专注于制定统一的愿景并提供更轻松的访问。为此，我们：
- 为项目创建了一个具体目标列表（包括“必备项”和“锦上添花项”），
- 为项目创建了一个开放的问题日志，以避免重复解决相同的问题，
- 开放了我们的代码库，以便红帽中的任何人都可以阅读或克隆它，并且
- 使工程师可以轻松获得受信任的提交者访问权限
我们协作的协议、我们最终统一的愿景以及我们改进的工具开发方法刺激了我们社区的增长。Ansicloud 的采用在相关组织中 распространилась，但这导致了一个新问题：该工具的变化速度开始快于用户适应它的速度，并且不同组提交的改进开始以意想不到的方式影响其他组。
这些问题导致了我们最近转向内部资源实践。虽然每个开源项目的运作方式都不同，但我们专注于采用一些在许多项目中似乎都很常见的最佳实践。特别是：
- 我们确定了项目的业务负责人和核心贡献者开发人员组，他们将管理工具的开发并决定接受哪些贡献。虽然我们希望保持开放，但我们不能让人互相反对或破坏彼此的功能。
- 我们开发了一个项目 README 文件，阐明了工具的用途并指定了如何使用它。我们还创建了一个 CONTRIBUTING 文档，解释了如何贡献、哪种类型的贡献有用以及贡献需要通过哪些类型的测试才能被接受。
- 我们开始为 Ansicloud 工具本身构建持续集成和测试服务。这有助于我们确保可以在项目接受和合并贡献之前，快速有效地从技术上验证贡献。
有了这些基本协议、文档和工具，我们又回到了开放协作和成功的内部资源之路。
为何重要
为什么内部资源很重要？
从开发者社区的角度来看，从传统的孤岛式开发模型转向内部资源模型已经产生了显着的、可量化的改进
- 对我们工具的贡献每周增长 72%（按提交次数计算）。
- 来自非核心提交者的贡献百分比已从 27% 增长到 78%；工具集的用户正在推动其开发。
- 贡献者列表增加了 15%，主要来自工具集的新用户，而不是核心提交者，从而增加了我们的内部社区。
我们通过该项目交付的工具使我们在业务成果方面看到了显着改进。使用 Ansicloud 工具，在 385 天内创建了 54 个新的多环境应用程序服务部署（相比之下，使用模板实用程序工具在 1,013 天内创建了 20 个服务）。我们的新服务部署速度从每 50 天部署一个新服务提高到每周部署一个新服务，交付速度提高了七倍。
真正重要的是，我们看到的改进并非异常现象。内部资源提供了组织可以采用以有效促进协作的常见且易于理解的模式（更不用说其他开放组织原则）。通过镜像开源生产实践，内部资源还可以镜像开源代码的好处，这些好处已经一次又一次地被看到：更高质量的代码、更快的开发和更积极参与的社区。
本文是开放组织工作簿项目的一部分。
评论已关闭。