OpenStack：为什么一个被所有大厂支持的开源云平台，最后连发起方都慢慢不用了？
把几十个独立组件组装成一套云，组装和维护的成本被留给了客户
OpenStack：巅峰期由大型互联网公司与托管服务商共同发起的开源云计算平台，一度被视为企业私有云的标准方案，几乎所有主流 IT 厂商都推出了发行版；终局是部署与运维的复杂度远超企业承受能力，客户纷纷转向公有云与轻量编排方案，多家厂商退出相关业务，基金会最终改名并转向更宽泛的开放基础设施。
公开报道整理 待核查 Figures as of 2020 2 sources（1 primary） What do these mean?
How to read this bar
This bar states plainly what we know and what we have checked, so you can judge it yourself.
· Review status: “pending” means no editor has checked it against the sources yet; “checked” means key facts match the sources.
· Figures as of: the year the numbers are current to; later changes are out of scope.
· Sources: listed one by one at the bottom of the page. “Primary” means official filings, annual reports or regulator documents.
· Corrections: every change and its basis is published — nothing is edited silently.
Editorial policy → Editorial policy: the full inclusion rules, verification process, AI disclosure and correction promise.
由大型互联网公司与托管服务商共同发起的开源云计算平台，一度被视为企业私有云的标准方案，几乎所有主流 IT 厂商都推出了发行版
部署与运维的复杂度远超企业承受能力，客户纷纷转向公有云与轻量编排方案，多家厂商退出相关业务，基金会最终改名并转向更宽泛的开放基础设施
4,930 votes cast
1 plans · 1 insights
投稿会先进入待审，通过后才进入公开目录和站点地图。
Root Causes Consensus Poll
Vote for the primary fatal error that caused this enterprise to collapse.
平台由大量独立组件拼装而成
组件版本与接口节奏不统一，集成与升级成本长期居高不下
把组装与运维成本转移给客户
企业需要专门团队长期维护，总拥有成本高于预期
公有云提供了成本更低的替代方案
企业自建私有云的收益无法覆盖运维投入，需求转向托管服务
生态繁荣掩盖了使用体验问题
厂商各自推出发行版追求生态影响力，客户侧的可用性没有被放在首位
Timeline: peak to collapse
联合发起
由互联网公司与托管商发起并成立基金会，迅速获得厂商支持
私有云主流方案
大量企业开始自建云平台，各厂商推出商业发行版
厂商陆续退出
客户发现运维成本过高，多家厂商关停或转型相关业务
改名与转向
基金会改名并扩大范围，平台在企业私有云中的主导地位基本结束
Four-Dimensional Retrospective Breakdown
Background & Golden Era
平台由多家公司联合发起，目标是让企业像使用公有云一样运营自己的资源池，凭借开放生态与厂商支持迅速成为私有云的主流选择巅峰期的成绩单是：由大型互联网公司与托管服务商共同发起的开源云计算平台，一度被视为企业私有云的标准方案，几乎所有主流 IT 厂商都推出了发行版。此时的它拥有渠道、品牌与资本的合力，看起来没有任何理由会输。
Fatal Turning Point Miscalculation
平台由数十个相互独立、版本节奏不一的组件构成，集成、升级与运维的复杂度极高；而公有云把同样的能力做成开箱即用的服务，企业自己组建云平台的动力迅速消失底层架构的缺陷被增长掩盖了很多年，真正爆发时表现为线上事故、体验崩塌与迭代停滞，修复成本远高于当年重做的代价。
Internal Culture & Bureaucratic Hubris
技术决策长期被短期交付目标绑架，「先上线，以后再改」变成永久状态，没人对架构健康度负责。
The Collapse & Aftermath
部署与运维的复杂度远超企业承受能力，客户纷纷转向公有云与轻量编排方案，多家厂商退出相关业务，基金会最终改名并转向更宽泛的开放基础设施。OpenStack的结局不是某一次意外，而是上面这些判断在数年里不断叠加、又始终没有被纠正的必然结果。
Battle-Tested Actionable Survival Rules
Distilled practical DOs and DONTs forged from costly corporate catastrophes.
开源项目的商业成功取决于客户的运维成本，而不是厂商数量
生态越热闹，越要问客户维护它要花多少人。
- •把部署与升级的复杂度作为核心产品指标
- •明确客户需要承担的人力与技能门槛
- •不要把厂商背书当作产品成熟度
- •不要在客户运维成本高企时继续扩大组件数量
Revival Simulation: If you were the CEO at the inflection point, how would you save it?
History cannot be rewritten, but executive decision-making can be honed. Propose decisive divestitures and strategic bets, and let entrepreneurs & VCs vote on feasibility.
把平台收敛成可交付的整体，而不是组件的集合
Critical intervention point：2016 年前后企业客户普遍反映运维成本过高时
- •停止继续扩大核心组件数量
- •停止由厂商各自定义互不兼容的发行版
- •停止把集成与升级工作默认交给客户
- •收敛核心组件并提供整体升级路径
- •以托管式交付降低客户的人力门槛
- •明确平台与公有云的差异化场景，聚焦合规与本地化需求
投入集中在集成体验与升级工具，发行版兼容性由基金会统一约束。
平台在需要本地部署与数据合规的场景中保持位置，客户以可承受的人力成本长期使用，而不是在运维压力下整体迁往公有云。
Expert Post-Mortem Insights
Firsthand diagnostic analyses from entrepreneurs, VCs, alumni, and analysts.
这个平台的技术方向没有错，错的是它的交付形态：几十个组件各自迭代，版本和接口需要客户自己对齐，升级一次就是一次内部项目。在大厂手里这不是问题，因为大厂本来就有这样的团队；但对企业 IT 部门来说，这是一项长期的人力承诺。当公有云把同样的能力做成一键开通的服务，自建的理由就只剩下合规与成本两个，而这两个理由往往也算不过账。
判断基础设施产品，先看客户要投入多少人才用得起来。
Sources
2 sources · 1 primaryThese are the references used to compile this case; the numbers match the [1][2] marks in the timeline. Primary sources come first, and archive links are kept where possible.
-
[1]
-
[2]
Business Post-Mortem Memo · OpenStack
为什么一个被所有大厂支持的开源云平台，最后连发起方都慢慢不用了？
# Business Post-Mortem Memo：OpenStack > 为什么一个被所有大厂支持的开源云平台，最后连发起方都慢慢不用了？ > Period: 2010 - 2020 | Industry: Enterprise SaaS > Peak: 由大型互联网公司与托管服务商共同发起的开源云计算平台，一度被视为企业私有云的标准方案，几乎所有主流 IT 厂商都推出了发行版 > Final: 部署与运维的复杂度远超企业承受能力，客户纷纷转向公有云与轻量编排方案，多家厂商退出相关业务，基金会最终改名并转向更宽泛的开放基础设施 ## Overview 把几十个独立组件组装成一套云，组装和维护的成本被留给了客户。巅峰期由大型互联网公司与托管服务商共同发起的开源云计算平台，一度被视为企业私有云的标准方案，几乎所有主流 IT 厂商都推出了发行版；终局是部署与运维的复杂度远超企业承受能力，客户纷纷转向公有云与轻量编排方案，多家厂商退出相关业务，基金会最终改名并转向更宽泛的开放基础设施。 ## Top-voted root causes 1. [Product & Tech] 平台由大量独立组件拼装而成 (1,622 votes) 2. [Strategy] 把组装与运维成本转移给客户 (1,362 votes) 3. [Strategy] 公有云提供了成本更低的替代方案 (1,103 votes) ## Actionable lessons ### 开源项目的商业成功取决于客户的运维成本，而不是厂商数量 > 生态越热闹，越要问客户维护它要花多少人。 - ✅ DOs: - 把部署与升级的复杂度作为核心产品指标 - 明确客户需要承担的人力与技能门槛 - ❌ DON'Ts: - 不要把厂商背书当作产品成熟度 - 不要在客户运维成本高企时继续扩大组件数量 ## Revival plans ### 把平台收敛成可交付的整体，而不是组件的集合 — 良略编辑部 Intervention: 2016 年前后企业客户普遍反映运维成本过高时 - Must cut: - 停止继续扩大核心组件数量 - 停止由厂商各自定义互不兼容的发行版 - 停止把集成与升级工作默认交给客户 - Breakthrough moves: - 收敛核心组件并提供整体升级路径 - 以托管式交付降低客户的人力门槛 - 明确平台与公有云的差异化场景，聚焦合规与本地化需求 - Expected outcome: 平台在需要本地部署与数据合规的场景中保持位置，客户以可承受的人力成本长期使用，而不是在运维压力下整体迁往公有云。 ## Community insights ### 企业自己组一套云，真正付的钱不是软件，是养一支运维团队。 — 良略编辑部 (工程师) 这个平台的技术方向没有错，错的是它的交付形态：几十个组件各自迭代，版本和接口需要客户自己对齐，升级一次就是一次内部项目。在大厂手里这不是问题，因为大厂本来就有这样的团队；但对企业 IT 部门来说，这是一项长期的人力承诺。当公有云把同样的能力做成一键开通的服务，自建的理由就只剩下合规与成本两个，而这两个理由往往也算不过账。 - Alternative Move if Replayed 判断基础设施产品，先看客户要投入多少人才用得起来。 --- Source: 良略 · https://www.lianglue.com/c/openstack