开源对企业的最大影响可能不是软件本身

开源软件是我们今天使用的许多应用程序的基础，无论是对我们的社会运转至关重要，还是对我们与陌生人共享隔离源照片的能力至关重要。代码本身已明显改变了我们的软件应用程序，但是在此过程中，我们对软件交付和组织文化产生了哪些更深层次的潜在影响？

在本文中，我荣幸地与三个行业知名人士进行了演讲，这三个行业多年来为构建开源项目和社区做出了贡献。我想向他们学习有关软件交付实践从社区和项目到公司和产品的传播的信息。

首先，我采访了Cloud Foundry Foundation的联合创始人兼新任命的执行董事Chip Childers；然后，转给Apex Clearing的首席产品官Dustin Kirkland，他是Ubuntu，Kubernetes和OpenStack的长期撰稿人；最后是云原生独角兽Snyk的早期员工兼工程副总裁Anton Drukh。

Cloud Foundry Foundation最初成立是为了拥有开源Cloud Foundry技术的知识产权并监督项目的治理。如今，基金会旗下拥有48个项目，多年来，已影响了众多企业使用该技术。基金会的项目是独立发布的，大多数项目通过协调的发布过程聚集在一起以形成平台：较小的团队随时准备发布，而整个系统则通过协调的发布过程测试已知良好的组合。

Childers说，从一开始，基金会的基础就是开放源代码许可，开放贡献模型和开放治理模型。自然，贡献者人数众多的公司通常会在项目路线图中获得更大的影响力-但是此过程铺平的道路是双向的。

柴尔德斯（Childers）表示，基金会的做法明显影响了那些员工也是捐助者的公司。例如，他看到越来越多的有贡献的开发人员（通常在不同组织中结对）回到他们的公司，并推动采用极限编程和敏捷开发等方法。

柴尔德斯说，从更深层次上讲，这种影响产生了飞轮效应，使开发商成为公司的代言人，然后改善了基金会的项目。第一步，开发人员在日常工作中采用与Cloud Foundry社区相同的协作思想。第二，当开发人员为开发人员构建工具时，他们倾向于发展同理心和对用户体验的敏锐理解，从而改善了他们在公司中的工作。第三，在组织中使用Cloud Foundry技术和流程的动手经验意味着贡献者拥有更广阔的视野，并经常将其反馈给基金会的项目以寻求改进。

贡献者：提供诸如开源之类的专有软件
Apex Clearing的首席产品官，我的前同事Dustin Kirkland在过去的20多年中担任开源软件方面的各种领导职务，并为Ubuntu，OpenStack和Kubernetes等项目贡献了代码。在到达Apex Clearing时，他想知道公司是否不仅可以重用它可以访问的开源项目的代码，还可以重用他亲身经历过的代码交付方式的一些基础流程。具体来说，他将注意力集中在发布周期上。

Ubuntu，OpenStack和Kubernetes等项目具有可预测的基于时间的发布周期。自2004年10月以来，Ubuntu于每年的4月和10月发布（16年来及时发布了32个主要平台！）；Kubernetes于2014年推出，它选择增加季度发布周期的步伐，并且在过去六年中每年管理4个版本。

Kirkland在Apex Clearing中引入的这些项目的关键概念是“协调周期”：以时间，资源和范围为变量，项目需要使其中两个保持不变，然后管理第三个。例如，对于Ubuntu，时间（按时释放）和资源（贡献者社区的大小）是固定的，并且范围是协商的。通常，一个周期会以峰会或会议（例如Ubuntu开发者峰会）拉开序幕，该峰会或会议汇集了来自业界的贡献者。此外，中期周期峰会是跟踪进度并根据需要纠正路线的好方法。

当Kirkland在2019年到达Apex时，产品和项目是异步管理的。在检查了六个月发行版本（如Ubuntu或OpenStack）的选项后，它被认为很笨拙，因为团队需要连续26周管理两周的冲刺。Kubernetes采用的季度周期被认为太短了，除了最小的单个项目之外，它看不到其他任何东西。最终，团队确定了16周的周期：每年3个完整周期，有48周的开发时间，同时仍允许有4周的假期。

今天在Apex，每个周期涉及三种类型的峰会：

优先级峰会：产品经理收集所有利益相关者的意见，以便他们可以就每个产品系列的优先级达成共识。
计划峰会：一旦定义了产品需求，就在即将到来的周期中，工程和管理之间就整个产品组合的工作承诺进行了协调。
周期中期峰会，更名为“投资组合审查”：报告进度并在必要时调整课程，每个周期大约进行三至三遍。
宣布在今年四月，顶点20A是使用开源的程序和方法首次发布。本月，柯克兰和他的团队将（实际上）举行Apex 20b的投资组合审查，与所有工程和产品负责人一起审查整个投资组合。

初创公司：以开源规范为基础
我的现任同事安东·德鲁克（Anton Drukh）于2015年加入斯奈克（Snyk），成为其第一名员工，并已成功地将工程部门发展为一支由70人组成的一流团队。他说，他一直着迷于最简单的解决方案如何解决最复杂的问题，而人是任何解决方案的关键要素。

Snyk最早的方法是将开发人员视为解决方案的源头，而不是解决软件中引入的安全漏洞的源头。Drukh表示，作为一个在工程技术领导者中处于发展初期的人，他们确实处于云和云原生时代，他特别着迷于新公司的三个方面。

首先，Snyk选择专注于保护开源，而Drukh认为与开源社区紧密合作将有助于培养谦虚的文化。Drukh说，今天，对Snyk大多是开放源代码库的所有外部贡献都在积极提醒人们。

其次，Snyk从许多开源项目中学习，旨在建立一个分散的，多元化的工程团队和公司。Drukh认为，将这些原则纳入招聘流程会给员工带来巨大的授权感。Snyk由五六人组成的小型团队运行，他们总是来自不同的位置（和大陆，因为Snyk的工程师位于英国，北美，以色列以及其他地区），并相信他们“做正确的事”。反过来，这为团队和公司的成功建立了强烈的责任感。

第三，该公司从一开始就着手在软件开发的实践中采用开源实践。这些措施可以提高功能的有效性，但也可以缩短将想法从开发人员的头脑转移到用户手中的时间。示例比比皆是，例如：

Snyk的代码库在团队内部和团队之间共享，从而使入门更加容易，所有权也更加清晰。
每个存储库都需要具有标准化的自动化发布流程，以支持较高的发布速度。
每个拉取请求都需要有一个清晰的指南，说明提出该请求的原因，所选择方法背后的权衡因素，测试如何反映新功能的期望以及谁应审查此更改。这推动了文化的透明性和问责制。
显而易见，对于Snyk的某些用户而言，产品的影响引发了人们对产品交付方式的好奇心，并试图从云原生启动过程中学习。客户可以检查该公司的分娩过程遇到了一些它的代码库，并与Snyk交流思想（如这一个，巩固发布周期）。没有开放源代码启发的文化和流程，这种偶然性就不会展现出来。