OpenStack 和 Linux 开发者社区对比

上周，我们查看了一些数字，这些数字定义了 OpenStack 社区及其构建的项目。但是，这些数字与其他大型开源项目相比如何？更重要的是，它们告诉我们关于 OpenStack 的什么信息？我们可以从其他类似规模的项目的成功和失败中学习到什么？

在上个月于亚特兰大举行的 OpenStack 峰会上，我参加了 Parallels 服务器虚拟化首席技术官 James Bottomley 的演讲，他试图解释这些数字的含义。Bottomley 在这两个项目上都有经验，他是 Linux 内核中 SCSI 子系统的维护者，同时他的日常工作是在 Parallels 使用 OpenStack 和相关技术。

Linux 内核和 OpenStack 在某些衡量标准上出奇地接近；在二月份，OpenStack 的每月提交次数首次超过内核，尽管数字有所波动，但这些数字跟踪得相当接近。那么，考虑到它们相似的规模，这些项目有何不同呢？以下是 Bottomley 给出的四个例子。

流程

提交代码并使这些更改被接受的过程有些不同。这两个项目都有正式的文档，但在内核中，与 OpenStack 不同，执行这些规则取决于代码各个部分的维护者个人。结果是规则的应用不均衡，有好有坏。在某种程度上，更长的正式流程可能会劝退新的贡献者或使提交小修补程序变得更加繁琐，但它在可预测性和公平性方面具有明显的优势。

测试

OpenStack 的测试程序提供了一个 Linux 内核以前从未有过的例子，但内核最近已开始努力在 Linux 基金会支持的项目下模拟 OpenStack 的模型。OpenStack 广泛的测试基础设施依赖于 Jenkins，它与审查过程相关联，由于审查过程的差异，Jenkins 无法被完全复制。但是，正在采取措施来模拟这些概念，即使不是工具。

审查

与其他领域一样，OpenStack 具有更正式的流程。但形式化与否并不是主要问题。相反，我们看到这两个项目都存在一个共同的问题：没有足够的审查人员来阻止提交堆积。吸引和维护合格且敬业的审查人员一直是这两个项目的问题。与此相关的是，这两个项目都难以解决“自行车棚效应”，或者说在审查过程中出现任意的代码重构请求。这不是工具问题，而是社会问题，并且从这个领域吸取的教训将使这两个项目都受益。

发布周期

内核的发布周期大约是 OpenStack 的两倍快。在内核的情况下，大约有 2-3 个月的发布周期，其中包括两周的合并期和六到十周的稳定工作。OpenStack 的周期为六个月，由四周的计划窗口、14 周的代码合并和六周的稳定化组成。结果呢？内核的发布速度更快，但每次发布的更改可能不那么重要。

想了解更多信息吗？完整视频时长 37 分钟，非常值得观看。