OpenStack 在 2026 年很容易被误读，因为围绕它的产品语境已经变得过于嘈杂。“私有云”这几个字，如今既可以指向 VMware 替代叙事，也可以指向主权云政治、包着 Kubernetes 控制面的旧式基础设施习惯，或者一串拉得很长的服务采购清单。在这样的语境里，OpenStack 最值得看的地方，并不在功能表，而在治理怎样把一个庞杂的平台压成一份公开的运维契约。真正重要的问题都很具体：谁拥有跨项目的技术权威，协同发布多久一次，稳定分支会被维护到什么程度，大规模操作者是否可以按人的节奏升级，摆脱永远追赶六个月一轮列车的状态。[1][2][3][4][5]
截至 2026-05-09T18:03:56Z UTC，官方发布页面显示，2026.1 Gazpacho 处于 Maintained 状态，2026.2 Hibiscus 已进入 Development，预计初始发布日期为 2026-09-30，2025.2 Flamingo 仍在维护，而 2024.2 Dalmatian 已在 2026-04-29 进入 End of Life。[4] 官方 Gazpacho 发布文又把这套机器背后的规模写得更清楚：OpenStack 将 Gazpacho 称为第 33 个版本，说这一轮周期里大约有 500 位贡献者、来自 100 家组织，SLURP 的引入则直接回应了操作者的升级负担。[6] 这些事实并不能说明平台突然变轻，倒足以说明一件事：这个项目仍在依靠公开的日历、公开的维护状态，以及公开的跨项目协同，它的信任基础也落在这些公开机制上，早已超出一句“老牌成熟”。
图像说明：题图使用的是 NOIRLab 服务器机架的真实照片，避开 logo、架构图，以及某种泛云计算宣传图。[8] 这个选择和本文的判断是一致的。OpenStack 的治理只有在真实机器、真实维护窗口、真实升级劳动面前还能成立，才算真正有意义。
技术委员会之所以重要，在于 OpenStack 从来都大过任何一个仓库
治理总览页面把结构写得很清楚。OpenStack 项目有两套分开的治理机构，其中 OpenStack Technical Committee 是这个开源项目本身的治理主体，由贡献者直接选出，对开发者、操作者和终端用户相关的技术事务拥有监督权。[1] 这一层格外重要，因为 OpenStack 从来都超出一个仓库、一个维护者、一个主分支能够概括的范围。它是一组项目团队的集合，而这些服务最后之所以能被读成一个平台，前提正是有人去定义边界、裁决路径与共同规则。[1][2]
技术委员会章程把这种跨项目角色写得更具体。文档说明，TC 要为整个 OpenStack 提供技术领导，维护开放性与质量等项目理想，决定影响多个项目的问题，并充当技术决策的最终申诉层。[2] 各个项目团队仍旧处理日常工程工作，项目团队负责人也仍旧管理组内争议，但章程在它们之上保留了一层平台级权威，用来处理单个服务之外的共同方向。[2] 这比那种依赖明星维护者的信号更可靠，因为它承认了平台真实的形状：Nova、Neutron、Cinder、Keystone、Ironic 以及其他服务，不会自然长成一个可运作的整体。
章程还把合法性机制放在公开位置。TC 成员由选举产生，每六个月部分改选一次，同时受组织关联度规则约束，任何单一组织都不能占据超过半数席位。[2] 月度状态会议公开举行，正式动议有公开讨论期和明确的票数门槛。[2] 这些安排不会消除分歧，却能让分歧留下可检视的痕迹，而这正是下游操作者真正需要的东西。
半年一轮的发布机器，依旧是这套治理的基本纪律
贡献者指南仍然把 OpenStack 描述为一个拥有 6 个月发布节奏 的项目体系。不同组件可以采用不同发布模型，但大多数官方项目会跟随 Release Management Team 设定的协同时间表。[3] 同一页把这个周期拆得很具体：三个 milestone，一段 release candidate 稳定期，以及稳定分支随着时间进入 Maintained、Unmaintained、End of Life 等不同状态。[3] 这已经不只是贡献流程，它同时构成一套时间纪律，让下游发行版、托管服务商与自运维团队知道什么时候集成压力会上升，什么时候变化应当收紧。[3]
官方发布页则把这套纪律压缩成一眼可读的状态面板。每个系列都有初始发布日期、当前维护状态、下一阶段以及生命周期终点。[4] 这点很重要，因为 OpenStack 最大的下游风险从来都落在时间秩序上：一个多服务、强耦合的平台一旦失去清楚的发布时间表，规划工作就会迅速滑入传闻和经验主义。现在的状态仍是公开的：Gazpacho 在维护，Hibiscus 已排上下一轮，Flamingo 仍有效，Dalmatian 刚刚退场。[4]
正是在这里，OpenStack 看上去比许多不停谈“生态健康”却不给操作者可读发布面的项目更扎实。即便你从不提交代码，这套发布机器本身也已经在告诉你，社区是否还在认真地把这些分散项目压回同一个平台节奏里。
SLURP 才是最关键的操作者信号
对外部观察者来说，最重要的治理变化，也许恰好是听上去最像流程修订的那一条。SLURP 文档把旧问题说得很直白：OpenStack 过去主要支持相邻协同版本之间的升级，于是部署者要么每六个月升级一次，要么走更费力的跨版本快进路径。[5] 文档进一步指出，大型环境往往觉得六个月一轮的升级困难、不可行，或者根本不值得，因为一轮升级刚做完，下一轮压力已经到了眼前。[5] 这种描述之所以有说服力，正因为它谈的是时间、人力与运维摩擦，这比抽象理想更接近真实部署现场。
发布页把这项改变以格外公开的方式摆在了外面。2023.1 Antelope、2024.1 Caracal、2025.1 Epoxy 与 2026.1 Gazpacho 都被标记为 SLURP 版本。[4] 页面说明，在常规相邻大版本升级之外，这些被标记的版本之间同样支持升级路径。[4] 由此展开，项目给出的重点不在一句“大家少升一点版本”，真正落在一份经过测试的升级契约：dot-one 到 dot-one 的年度节奏，使操作者不用为追赶每一班中间列车而耗掉整年。[4][5]
官方 Gazpacho 发布文章也把这层意义写得格外清楚。文中说，SLURP 是围绕操作者需求设计的，它让升级可以按年度发生，同时仍保留可预测的发布节奏。[6] 来自 Open Edge Cloud 的一篇 2026 年 4 月 1 日 独立分析，从外部读出的结论也是同一条：Gazpacho 是一个 SLURP 版本，处在前一个 SLURP 版本 Epoxy (2025.1) 的组织，可以直接升级过来，这意味着更少的强制升级轮次和更小的打断。[7] 这层独立确认很重要，因为它说明这项政策的含义已经超出 OpenStack 自己的宣传口径，进入了真实运维者的阅读方式里。
SLURP 并没有把 OpenStack 变轻。它只是把升级负担变得更可治理。这种承诺反而更可信。
下游团队真正应当读到什么
正面的信号远比“OpenStack 回来了”或者“私有云赢了”要窄，也更有用。真正值得带走的判断是：OpenStack 依然保留着一套面向操作者的公开维护机器，适合那些需要多项目协同、清楚生命周期状态和可信升级路径的团队。[1][2][3][4][5][6] 技术委员会提供跨项目权威层，发布页和贡献者指南把时间结构写得很直白，SLURP 则承认真实部署者没有义务把整年都花在一段又一段版本楼梯上。[2][3][4][5]
边界也同样清楚。良好的治理不会把 OpenStack 突然压缩成一个小团队玩具。恰恰相反，支撑正面判断的同一批证据，也提醒你这里面仍有多少机器在一起工作：多个项目团队、协同发布、稳定分支策略，以及一套正因为平台足够庞大才必须存在的操作者契约。[2][3][5] 若团队真正想要的是一种完全消失在托管抽象里的基础设施，上游治理再稳，也不会替你拿掉下游平台劳动。
因此，OpenStack 在 2026 年最强的治理信号，最终还是那只升级时钟。当一个成熟基础设施项目愿意把发布政策改到更贴近操作者现实的位置，再把这种改变公开写清，并把带有标记的版本与其他生命周期状态放在同一张页面上，它其实已经说出了自己准备怎样继续存活。[4][5][6][7] OpenStack 真正的信任表面，并不在早年私有云时代的情绪回声，而在那些看上去无趣、实际上极其关键的机器里：选举、协同发布、维护阶段，以及如今已经被公开摆出来的 skip-level 升级承诺。[1][2][3][4][5]
来源
- OpenStack Governance：项目治理总览、技术委员会角色、项目团队、SIG 与选举结构。
- OpenStack Technical Committee Charter：TC 使命、跨项目权威、选举结构、会议流程，以及组织关联度约束。
- OpenStack Contributor Guide《Releases》：六个月发布节奏、milestone、release candidate，以及稳定分支维护阶段。
- OpenStack Releases：Hibiscus、Gazpacho、Flamingo、Dalmatian 当前系列状态，以及 dot-one 版本上的公开 SLURP 标记。
- OpenStack Project Team Guide《Release Cadence Adjustment: SLURP Model》：相邻版本升级路径给操作者带来的问题，以及 skip-level 支持的调整理由。
- OpenStack Blog《OpenStack Gazpacho: Built by a Global Community, Designed for Real-World Infrastructure》：第 33 个版本、贡献者规模，以及面向操作者的 SLURP 说明。
- Open Edge Cloud《OpenStack Gazpacho (2026.1): What's New and What It Means for Managed Cloud》：从独立运维视角解读 Gazpacho 作为 SLURP 版本的意义，以及年度升级路径的现实价值。
- Wikimedia Commons《File:NOIRLab HQ Server Racks (6V6A0404-CC).jpg》：本文所用真实机房照片的来源页。