如何利用内部开源加速创新

介绍

开源改变了我们开发软件的方式。从酒店预订到银行业务，几乎每个新应用程序都是基于全球开发者社区创建的免费、可重复使用的代码构建的。根据 Gartner 的数据，全球超过 87% 的 IT 企业使用开源来处理其关键任务 IT 工作负载，无论他们是否意识到这一点。

但过程与产出同样重要。随着开源社区的建立和发展，他们找到了跨地区、跨时区、跨语言快速有效协作的方法。他们大规模地编写了由分布式团队构建的代码，使分布式版本控制系统成为行业标准，甚至建立了现代 DevOps 背后的基础。如果您使用 Git、Python 或在团队中共享和重复使用代码，那么您就参与了开源最佳实践。

正如我们在 DevOps 中看到的那样，当企业开发团队采用这些最佳实践时，他们可以实现相同的速度和创新。通过模仿开源社区的工作方式，企业可以按照开发人员熟悉和喜爱的方式构建软件 - 创建一个熟悉的环境，没有不必要的干扰，并通过快速增量迭代专注于创新。

我们所描述的就是“内部开源”。与开源一样，即使你从未听说过这个术语，你也可能仍然会认识到它背后的一些原则。内部开源在不同公司可能看起来不同，但始终有着相同的目标：采用开源工具、实践和文化来构建专有软件。

定义内部开源

内部开源有多种描述方式。许多公司使用“内部开源”一词来描述他们的工程团队如何共同编写代码。已经与大型开源社区合作的组织中的开发人员可能根本不使用内部开源一词。相反，他们只是将其视为将开源方法应用于工作中的软件开发的方式。

内部开源是一种开发方法，工程师使用大型开源项目的最佳实践来构建专有软件。采用内部开源实践就像在您的组织内创建一个开源社区。与开源一样，透明的协作可以调动社区的集体知识和技能来创建更好的软件。相比之下，内部开源社区包含单个企业内人员和工具的知识、技能和能力。

内部开源带来了开源中的最佳实践，从而形成了一种沉浸式的 DevOps 文化。这些最佳实践包括与核心团队以外的开发人员合作、使用可共享和可重用的代码减少重复工作、鼓励透明的讨论和协作以及快速迭代和反馈循环。所有这些结合起来？更好的客户体验，更快的交付。

内部开源加速创新的五种方式

跨团队、跨时区协作

随着全球分布的团队和远程工作成为常态，人们的工作方式发生了变化。充分利用全球劳动力意味着无论在哪里工作，从总部到客厅沙发，工作都会以协作、透明和开放的方式进行。这也意味着组织可以采用更具包容性和灵活性的招聘方式：无论他们身在何处，都可以雇用合适的人来工作。

Zendesk 的全球办事处就是一个很好的例子。该公司重视透明度，尤其是在工程方面，以便哥本哈根的工程师能够了解和利用旧金山的工作。Zendesk 的工程副总裁 Jason Smale 将该团队的内部设置描述为类似于开源项目中的设置，维护者和贡献者在公司的生态系统上进行协作。

明确且记录在案的项目所有权使每个团队能够管理不同工作流的混乱，而不会让他们无法获得伟大的想法。他们允许任何团队中的任何人为现有工作做出贡献、在其基础上进行构建或重复使用现有工作，从而充分利用公司的集体智慧。正如 Smale 所解释的那样，“我们的工程文化是开放的，以团队拥有服务并负责在生产中运行它们为中心。”

共享所有权也是 Spotify 代码质量和协作的一个重要方面。“你需要开放性和所有权，”产品经理 Laurent Ploix 说。让团队拥有特定项目的所有权会增加他们对工作的自豪感，并简化决策，因为一个人或一个团体在批准变更方面拥有最终决定权。“有了强大的所有权，我们就可以避免代码堆积在没有人知道它是否被使用的地方，”Ploix 说。但允许和鼓励非所有者提交改进会增加寻找错误的眼睛数量，并为这些项目开放创新的新功能。或者，正如 Ploix 所说：“有人可能会找到比我更好的解决方案。”

更快地将新想法传达给客户

开放项目可以激发更多创意。它还可以帮助团队提高代码质量，消除流程中的摩擦，并更快地将工作投入生产。福特全球软件工具和流程主管 Tom Erickson 认为，不仅要鼓励更多有关代码的想法，还要鼓励更多有关流程和工作风格的想法。“开发人员可以提出建议，并采用更开放、更符合他们需求的工作风格，”他说。“如果你想更快地交付更高质量的软件，内部外包就是明智之举。”

速度和创新与内部开源密不可分，将 GitHub 等平台上的代码共享过程转化为开发人员和客户的双重好处：例如，DXC 可以更快地构建应用程序（在市场动态快速变化的时代尤其重要），并为开发人员提供他们创建的所有代码的单一索引。例如，DXC 技术主管 Tom Halpin 说，当同事对 Web 测试框架 Cypress 有疑问时，他只需搜索公司的 GitHub 即可找到该技术的内部专家。“它帮助我们释放 DXC 的智力，”他说。

DXC 研究员、Modern Apps 和 Cloud Native 副总裁兼首席技术官 Chris Swan 表示，现在，他们原以为需要六个月才能完成的产品最终只用了六周时间。“客户原本以为在建房之前必须打好很多地基，”Swan 解释道。“但我们能够主动告诉他们‘我们已经完成了所有工作。只需安装木框架和侧面即可。’”因此，DXC 的客户可以更快地进入市场并提高竞争力。

对于像 Otto Group 和 3M 这样拥有多个部门和子公司的组织来说，内部外包让开发人员（而不仅仅是客户）能够更快地访问内部解决方案和技术。“一次完成，服务众多”，企业研究系统实验室 (CRSL) 首席 DevOps 工程师 Kevin Truckenmiller 说。无数 3M 部门使用 Docker 容器并在 AWS 上进行开发。由于它们都需要访问 AWS，这也意味着要管理数千个 AWS 凭证。在 GitHub 出现之前，各个部门会创建自己的凭证工具，从而产生用于同一目的的多个工具。相反，CRSL 创建了一个联合工具来帮助团队使用来自其公司目录的凭证访问他们的 AWS 账户。现在，团队可以轻松打开拉取请求，从 GitHub 存储库下载工具的代码并投入使用。“速度是关键。他们不必再问我们是否可以为他们构建功能，而是可以打开拉取请求并自己添加它”，Truckenmiller 说。这种自助服务模式使人们能够解除自己的依赖关系。

不过，成功的内部外包归根结底还是要保持平衡——以最快的速度前进，同时不跳过中间的关键步骤。为了避免随着团队的壮大而拖慢项目进度，周到的流程和文档发挥着同样重要的作用。例如，Stripe 的团队经常在彼此的代码上工作，但无论代码来自哪里，它总是经过相同的审查流程。（借助自动化工具，如 GitHub Advanced Security 代码扫描和 linters，审查流程可以快速高效地进行。）关于贡献和审查代码的文档减轻了个人贡献者弄清楚“下一步是什么”的负担，使他们更容易参与项目的条款。Stripe 开发者倡导者 Michael Glukhovsky 发现，能够毫无阻碍地做出贡献是一种赋权：“如果您发现需要修复的问题，您可以提交拉取请求并开始对话。”

跨团队发现和重用代码

这是一个再熟悉不过的时刻：您的团队为您的产品规划、设计和实施了一个新的 UI 模式。它可用、有效，并在几个月内不断迭代完善。但随后，您偶然发现了一个具有类似功能的拉取请求，该请求是由另一个团队独立开发的。您的代码不仅可以为其创建者节省一些工作量，而且现在您的产品的用户体验也出现了不一致。调整和重复使用经过现场测试的功能似乎很明显。但让其他团队可以发现您的代码却并非如此。

对于 ENGIE Digital 的内部资源项目负责人 Florent Zara 来说，“[内部资源的目标] 是打破孤岛，鼓励人们共同努力。”他解释说，内部资源将项目公开，使整个组织更容易发现、重复使用和构建代码。数字社区和通信主管 Charline Grenet 对此表示赞同。“我们所做的一切都必须工业化才能重复使用，”Grenet 说。“我们希望拥有 100% 内部资源的项目。”

这种做法甚至在 Autodesk 和福特等大型公司中也得到应用，福特首席工程师 Florian Frischmuth 认为将代码保存在一个地方（如 GitHub）可以更轻松地发现代码。“我们的环境允许开发人员找到已经开发的解决方案。他们可以就这些解决方案进行协作，然后重复使用它们。”

以前，Autodesk 工程师会多次构建复杂的软件，“因为现有的软件只能满足我们 90% 的需求”，Build Platform 高级总监 George Swan 说道。他们会复制分支，将其变为自己的，然后添加最后的 10%。现在，员工可以访问几乎 100% 的 Autodesk IP。在 19,000 个存储库中，只有大约 10 个是私有的。“我们对所有人开放。”

通过代码共享和重用，一些团队开始变得像开源社区一样，内部源和 DevOps 最佳实践就是在这些社区中开始的，比如在 Spotify，拥有项目的开发人员承担着类似于一些开源维护者的角色。他们接收并分类新的错误、想法和代码。他们还可能负责弃用甚至归档他们的项目。据 Ploix 称，“他们肯定会成为维护者。有了强大的所有权，我们就可以避免代码堆积在没有人知道是否正在使用的地方。”

提高代码质量和安全性

“开放”与“安全”之间存在逻辑上的矛盾。随着人们发布的软件中越来越多地依赖开源软件，软件团队从一开始就将安全性放在首位比以往任何时候都更加重要。在实践中，企业团队发现，更多的合作者创造了更多的机会来发现错误和其他问题。他们还发现，这种方法可以更快地将安全专业知识引入到流程中。

在 Nationwide，团队曾经对项目秘而不宣，但至少在内部公开这些项目，已被证明是大规模提高代码质量不可或缺的因素。Nationwide 的 IT 应用服务副总裁 Cindy Payne 解释说，团队最不愿意分享的项目往往从外部视角中获益最多。这种做法还有助于解决安全漏洞，使团队能够快速评估影响，然后对情况进行相应的分类。

通过自助服务节省时间并加速创新

在启动新项目时，许多团队仍然遵循请求和等待模型。他们提出请求，然后中央管理员启动一个新的存储库。这种模式给本来可能更简单的流程增加了两层复杂性：管理维​​护和尝试新事物的障碍。另一方面，内部开源赋予每个人自主权，让他们可以毫无阻碍地开始工作。

允许团队创建自己的项目听起来可能工作量更大，记录新流程甚至创建治理模型的前期工作似乎令人望而生畏。但许多团队发现，自助服务模式最终可以节省维护时间，并让开发人员能够轻松上手。

Payne 发现，自助式 GitHub 存储库不仅可以消除阻碍因素，而且从基础设施角度来看还可以为公司节省时间和金钱。谈到转换模式，她表示：“我们知道我们会省钱，但省下来的钱会立即转化为团队的更多能力，让我们能够为我们的业务做最有价值的工作。”

大陆集团内部资源项目经理 Zsuzsanna Gnandt 解释说，大陆集团和福特等知名制造商也发现，消除障碍有助于激发新的创造力。“通过内部资源，我们希望让所有开发人员都能自由发挥创造力，不受障碍地推动创新，并让他们的贡献得到整个公司的赞赏。”

由于福特的代码可供组织中的每个人访问，因此团队不再因组织结构而分开。相反，他们可以共同开发新代码并充分利用现有解决方案。“我们的环境允许开发人员找到已经开发的解决方案。他们可以就这些解决方案进行协作，然后重复使用它们，”首席工程师 Florian Frischmuth 说。

通过利用 GitHub 的协作平台和与开源社区的安全连接，Spotify 的开发人员可以同时获得两全其美的效果：内部外包和开源非 IP 工作。

无论是在防火墙之外还是防火墙之后，成千上万的贡献者意味着成千上万的想法、更多样化的思想，以及最终更好的客户体验。“欢迎提出请求，”Ploix 说。“有人可能会找到比我更好的解决方案。”

原文地址：https://blog.csdn.net/hairenjing1123/article/details/143498420

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！