1. 估算方法与重要前提
这里的人月数字不是官方预算，也不是精确统计，而是将代码规模、子系统数量、兼容面、测试矩阵、硬件覆盖、安全性、性能优化、工程组织和长期稳定化等因素综合后得到的工程重建成本估算。因此这些数字更适合比较“数量级”和“相对复杂度”，不适合当成项目报价。
1.1 默认包含的工作
- 核心架构设计与实现；
- 主要功能实现；
- 生产级稳定性；
- 基本性能优化；
- 安全加固；
- 基本兼容性；
- 主流硬件或主流操作系统平台覆盖；
- 自动化测试、集成测试、回归测试、故障恢复测试；
- 构建系统、调试、诊断和发布基础设施；
- 一至数年的稳定化过程。
1.2 默认不包含的工作
- 社区培育；
- 市场推广；
- 第三方开发者教育；
- 合作伙伴体系；
- 让所有历史软件、网站、硬件都兼容的无限长尾；
- 为了形成生态而长期补贴开发者的成本。
1.3 为什么不能只看代码行数
代码量只能提供一个非常粗的下界。两个同为数千万行代码的项目，工程难度可能仍然完全不同。真正决定重建成本的因素通常包括：
- 语义深度：例如 JavaScript JIT、SQL 优化器、形式验证器。
- 系统跨度：例如操作系统横跨 CPU、内存、文件、网络、GPU、音频、输入、电源。
- 兼容性：需要兼容多少既有二进制、文档、网站、协议和硬件。
- 可靠性要求：数据库、航电、金融、主机系统的错误容忍度远低于普通应用。
- 测试状态空间：大量硬件、驱动、插件、版本和配置的组合会使验证成本急剧增加。
一个简化模型可以写成：
\[ \text{总工程量} \approx \text{核心实现} \times \text{兼容系数} \times \text{可靠性系数} \times \text{平台覆盖系数} + \text{测试与稳定化成本} \]
其中“兼容系数”并非一个真正可单独分离的模块，而往往渗透在各个子系统中。
2. Linux 内核与 Chromium
2.1 如果要求接近当前完整成熟度
如果要求重新实现今天 Linux 内核和 Chromium 的完整功能、成熟度、兼容性与长尾覆盖，两者都属于“十几万到几十万人月”的超级工程。
| 项目 | 完整成熟度重建粗估 | 主要复杂性来源 |
|---|---|---|
| Linux 内核 | 约 15 万～40 万人月 | 硬件驱动、CPU 架构、文件系统、网络、长期 ABI 与行为兼容、设备长尾 |
| Chromium | 约 18 万～50 万人月 | Web 平台、JS 引擎、渲染、媒体、安全、多进程、网站兼容、测试基础设施 |
这时两者不是十倍级差距，而是处于同一数量级。Chromium 的语义深度非常高，而 Linux 的硬件与架构覆盖极其宽。
2.2 如果只做单一平台
一旦把目标缩小为“单一硬件/操作系统平台”，Linux 可以大幅削掉驱动和架构长尾，而 Chromium 很难削掉现代 Web 平台的大部分核心语义。
- Linux 内核：约 5,000～20,000 人月；
- Chromium：约 20,000～80,000 人月；
- Chromium 通常约为 Linux 内核的 3～8 倍。
2.3 为什么 Chromium 在受限平台下仍很重
即使只支持一个桌面操作系统，现代浏览器仍需要实现：
- HTML 解析、DOM 与事件；
- CSS、布局、字体、绘制；
- JavaScript、JIT、GC；
- WebAssembly；
- HTTP、TLS、缓存、Cookie；
- GPU 合成；
- 图片、音视频；
- Worker、Service Worker；
- 多进程、IPC、沙箱、站点隔离；
- 无障碍、输入法、国际化；
- 大量 Web API 与网站兼容行为。
浏览器最大的困难可以概括为：它必须正确解释一个极其庞大、持续演化、还背负大量历史行为的 Web 平台。
3. 去掉生态成熟成本后的变化
当目标变为“核心功能 + 稳定性 + 基本兼容性 + 基本硬件覆盖”，并明确不要求复刻几十年的生态成熟长尾后，两个项目的人月估算都会下降一个数量级左右。
| 项目 | 较现实的目标范围 | 粗估人月 |
|---|---|---|
| Linux 内核替代品 | x86-64，最多加 ARM64；主流 PC/服务器；常见 Linux 用户态兼容 | 约 10,000～30,000 |
| Chromium 替代品 | 一个桌面平台；主流现代网页可用；基本多进程、安全、音视频 | 约 25,000～70,000 |
中心结论：这种口径下，Chromium 大约是 Linux 内核的 2～3 倍；宽松时可能只有 1.5 倍，严格要求安全、性能和网站兼容时可能达到 4 倍。
3.1 Linux 可以删掉什么
- 绝大多数冷门 CPU 架构；
- 大量老旧总线和外设；
- 数千种冷门网卡、声卡、媒体设备；
- 大量嵌入式 SoC；
- 历史文件系统和特殊协议；
- 极长尾的硬件 quirks。
3.2 Chromium 可以删掉什么
- 账号同步、云服务；
- 完整扩展生态；
- ChromeOS、Android、iOS 多平台支持；
- 全部企业策略；
- 完整 DevTools；
- 实验性 Web API；
- 极旧网站与历史怪癖；
- 像素级兼容所有网站的要求。
但 Chromium 的削减存在更高下限：只要目标是“现代主流网页基本可用”，Web 平台的大量核心语义就不能省。
4. Linux 内核 + 主流桌面环境 vs Chromium
如果不再比较“Linux 内核”，而是比较一个真正可日常使用的 Linux 桌面平台，那么 Linux 一侧的复杂度会明显上升。
| 目标 | 粗估人月 | 中心估计 |
|---|---|---|
| Linux 内核 | 10,000～30,000 | 约 18,000 |
| Linux 内核 + 主流桌面平台 | 30,000～80,000 | 约 50,000 |
| Chromium | 25,000～70,000 | 约 45,000 |
因此：Linux 桌面平台与 Chromium 基本进入同一复杂度等级。
4.1 “Linux 桌面平台”至少包含
- Linux 内核与基本驱动；
- libc、动态链接器、基础系统工具；
- 启动、设备管理、登录、会话和日志；
- GPU 内核驱动与用户态图形驱动；
- Wayland/显示协议与合成器；
- 窗口管理和桌面 Shell；
- GUI 工具包、字体、输入法、剪贴板；
- 音频、摄像头、屏幕共享；
- 有线网络、Wi-Fi、蓝牙、VPN 基础；
- 电源管理、睡眠、唤醒、亮度；
- 权限、文件选择器、桌面门户；
- 安装、更新、回滚与故障恢复；
- 基本系统设置与工具。
4.2 Linux 桌面为什么会迅速变重
最大的新增成本来自 GPU、显示、音频、输入、电源和跨层状态协调。
应用
↓
GUI 工具包 / 桌面 API
↓
合成器 / 音频 / 网络 / 权限服务
↓
用户态硬件驱动
↓
内核驱动
↓
真实硬件插入一个外接显示器这样的普通动作，可能同时触发硬件发现、GPU 输出配置、合成器布局、缩放策略、桌面设置更新与应用重排。各层分别正确并不够，跨层状态还必须一致。
4.3 与 Chromium 的复杂度分布差异
| 维度 | Linux 桌面 | Chromium |
|---|---|---|
| 算法与语言运行时深度 | 高 | 极高 |
| 标准与行为兼容 | 高 | 极高 |
| 硬件覆盖 | 极高 | 相对较低 |
| 跨子系统集成 | 极高 | 高 |
| 安全攻击面 | 极高 | 极高 |
| 稳定性测试矩阵 | 极高 | 极高 |
Chromium 是“语义深度极高的应用平台”；Linux 桌面是“纵向跨度和硬件集成极广的操作系统平台”。
4.4 GPU 驱动是否自己写，会强烈改变结论
- 允许使用厂商 GPU 驱动：Linux 桌面约 25,000～55,000 人月；
- GPU 驱动和桌面栈也从零写：Linux 桌面约 40,000～100,000 人月；
- 连字体、编解码器、国际化、密码学等基础库都从零写：Linux 桌面可能上升到 60,000～140,000 人月。
5. 其他开放源代码的极大型项目
真正能与 Linux、Chromium 同层级讨论的开放源代码项目并不多。可以分成几档。
5.1 第一档：最接近 Linux/Chromium
| 项目 | 粗估人月 | 主要复杂性 |
|---|---|---|
| AOSP 上层平台 | 30,000～80,000 | Framework、ART、Binder、图形、媒体、安全、HAL、系统服务、兼容测试 |
| Firefox / Gecko | 25,000～70,000 | Web 平台、SpiderMonkey、渲染、多进程、沙箱、媒体、Web 兼容 |
| OpenStack 核心项目群 | 20,000～60,000 | 计算、网络、存储、身份、多租户、升级、分布式故障处理 |
5.2 第二档：基础软件领域的超级项目
| 项目 | 粗估人月 | 主要复杂性 |
|---|---|---|
| LLVM 项目群 | 15,000～40,000 | Clang、优化器、后端、LLD、LLDB、libc++、Sanitizer、MLIR 等 |
| GNU 工具链 | 15,000～40,000 | GCC、Binutils、GDB、glibc、libstdc++、多架构与 ABI |
| OpenJDK | 12,000～35,000 | HotSpot、JIT、GC、Java SE 类库、javac、诊断工具 |
| Wine | 8,000～25,000 | Windows 用户态 API、PE、COM、图形、音频、注册表、兼容性长尾 |
| Mesa | 8,000～30,000 | OpenGL、Vulkan、EGL、着色器编译、多家 GPU 驱动 |
| LibreOffice | 8,000～25,000 | 文字处理、电子表格、演示、文档格式兼容、排版与计算 |
| Blender | 8,000～25,000 | 建模、动画、渲染、物理、合成、视频、几何与节点 |
5.3 第三档：专业领域中的极大型项目
- QEMU：约 6,000～20,000 人月；
- Kubernetes 核心：约 4,000～15,000 人月；
- Ceph：约 5,000～15,000 人月；
- PostgreSQL：约 5,000～15,000 人月；
- Apache Spark：约数千到一两万人月；
- FFmpeg、GStreamer、Git、systemd 等：通常低于 Chromium 一个层级，但仍属于大型基础软件。
这些项目中，真正与 Linux/Chromium 同层级的主要是 AOSP、Firefox 与完整 OpenStack 项目群；LLVM、GNU 工具链、OpenJDK 则属于技术深度极高、但领域跨度更窄的基础软件超级工程。
6. OpenJDK 与 .NET 的复杂度比较
.NET 现在已经是完整的开源开发平台，但“dotnet”这个词的边界比 OpenJDK 更宽。公平比较时必须拆分层次。
6.1 对等口径
| 范围 | 粗估人月 | 相对 OpenJDK |
|---|---|---|
| OpenJDK：HotSpot + Java SE + javac + JDK 工具 | 12,000～30,000 | 1.0 |
| .NET 核心：CoreCLR + BCL + C# Roslyn + 基本 SDK | 14,000～34,000 | 约 1.1～1.3 |
| 完整现代 .NET 基础平台：再含 Mono、NativeAOT、完整 Roslyn、MSBuild/NuGet | 18,000～45,000 | 约 1.3～1.6 |
| 再含 ASP.NET Core、EF Core、WinForms/WPF 等 | 25,000～60,000 | 约 1.7～2.3 |
6.2 .NET 更重的地方
- Roslyn 平台化：不仅是编译器，还公开语法树、语义模型、分析器、代码修复、Source Generator、IDE 工作区等 API。
- SDK 与构建链更统一：dotnet CLI、MSBuild、NuGet、发布、裁剪、单文件、自包含等能力都属于基础开发体验的一部分。
- 多运行时与多部署模式：CoreCLR、Mono、NativeAOT、JIT、AOT、WebAssembly、移动平台等。
6.3 OpenJDK 更重的地方
- HotSpot 长期优化深度非常高；
- 拥有多种成熟 GC，例如 G1、ZGC、Shenandoah 等；
- Java SE 自带的桌面标准库更广，包括 AWT、Swing、Java2D、打印、图像、音频等。
核心结论：如果只比生产级基础工具链，.NET 通常比 OpenJDK 大约高 10%～30%，仍属于同一复杂度等级；把 Mono、NativeAOT、完整 SDK 和上层应用框架都算入后，.NET 才明显扩大。
7. 加入闭源软件后的极大型系统
闭源世界中最复杂的软件往往不是单一代码库，而是持续几十年演化的“平台族”或“系统之系统”。
7.1 第一档：全球级系统之系统
| 系统 | 粗略重建量 | 特点 |
|---|---|---|
| AWS / Azure / Google Cloud 核心平台 | 30 万～100 万+ 人月 | 全球计算、网络、存储、身份、计费、容灾、自动化和海量服务 |
| Google 搜索 + 广告 + 全球基础设施 | 30 万～100 万+ 人月 | 搜索、索引、广告、分布式存储、机器学习、全球基础设施 |
| Microsoft 365 完整云平台 | 20 万～60 万人月 | Office、Exchange、SharePoint、Teams、OneDrive、身份与协作 |
| Meta 社交平台与基础设施 | 20 万～80 万人月 | 社交图谱、消息、广告、推荐、存储、全球分发、机器学习 |
| 大型银行支付/清算/风控平台族 | 10 万～50 万人月 | 高一致性、审计、支付网络、反欺诈、合规、灾备 |
这类系统通常比任何单一开源代码库高一个数量级，但严格来说它们已经不是“一个软件项目”，而是由数百到数千个子系统组成的企业级平台组合。
7.2 第二档：极复杂单一平台或紧密产品族
| 项目/平台 | 粗估人月 |
|---|---|
| Windows 基本生产级平台 | 约 6 万～15 万 |
| Windows 广泛历史兼容版本 | 约 10 万～20 万；极端长尾可达 15 万～40 万 |
| Apple 操作系统平台族 | 约 10 万～25 万 |
| z/OS + CICS + IMS + Db2 等主机平台 | 约 10 万～30 万 |
| SAP S/4HANA + HANA 核心平台 | 约 6 万～18 万；完整行业与历史兼容可更高 |
| Adobe Creative Cloud 核心产品族 | 约 6 万～18 万 |
| 完整 EDA 套件 | 约 8 万～25 万 |
| 大型 CAD/CAE/PLM 产品族 | 约 5 万～20 万 |
7.3 第三档：单领域技术深度极高
- Oracle Database + RAC + Clusterware：约 2.5 万～8 万人月；
- Microsoft SQL Server 完整平台：约 2 万～7 万人月；
- VMware vSphere / ESXi：约 2 万～7 万人月；
- Unreal Engine 或 Unity 完整工具链：约 2 万～7 万人月；
- MATLAB + Simulink：约 2 万～7 万人月；
- Excel：约 1.5 万～4 万人月；
- Photoshop：约 1 万～3 万人月；
- AutoCAD / Revit 单体：约 1.5 万～5 万人月。
7.4 第四类：验证成本极高的软件
有些系统代码量未必比 Chromium 大，但验证成本极端高：
- 航空电子与飞控系统；
- 大型自动驾驶平台；
- 航天器与大型任务控制软件；
- 核电、铁路信号、医疗设备等高安全等级系统。
这些项目的难点不仅是“写出来”，而是要证明它在各种故障和边界条件下仍然正确。
7.5 Mermaid：复杂度层级示意
flowchart TD A[全球云/互联网系统之系统
30万~100万+人月] B[操作系统/主机/ERP/EDA/大型产品族
5万~30万人月] C[Chromium / Linux桌面 / Firefox / 大型数据库与引擎
2万~10万人月] D[OpenJDK / .NET核心 / LLVM / Wine / Mesa / Blender
1万~5万人月] E[QEMU / PostgreSQL / Kubernetes核心 / Ceph 等
数千~2万人月] A --> B B --> C C --> D D --> E
8. Windows 的历史兼容负担
Windows 的历史兼容负担确实非常大，但不能简单理解成“Windows 里面额外藏着两个操作系统”。更准确地说，兼容性是一个横向乘数，它渗透到 API、ABI、文件系统、注册表、图形、安装器、安全、驱动和测试等各层。
8.1 更合理的量化
| 目标 | 粗估人月 |
|---|---|
| 全新设计、不兼容 Win32 的生产级桌面系统 | 3 万～7 万 |
| Windows 基本平台 + 主流现代 Win32 兼容 | 6 万～12 万 |
| 广泛兼容近二三十年的桌面、企业与游戏软件 | 10 万～20 万 |
| 近乎复制全部历史行为、驱动和应用长尾 | 15 万～40 万，且可能不可完全实现 |
8.2 为什么兼容性这么贵
API 名称不是重点，行为才是重点
旧程序可能依赖：
- 某个特定错误码；
- 某种参数边界行为；
- 回调和窗口消息的精确顺序；
- 文件共享和锁定语义；
- 路径解析怪癖；
- ANSI/Unicode 转换；
- 未初始化字段的历史处理；
- 旧版本中的 bug。
从设计角度看可能是 bug，但如果大量商业软件依赖它，它就变成了事实上的接口。
二进制兼容比源码兼容昂贵
Windows 需要长期维护：
- PE 可执行格式；
- x86/x64 调用约定；
- DLL 导入导出和装载行为；
- 异常处理与栈展开；
- 线程局部存储；
- COM 二进制接口；
- 窗口消息和回调 ABI；
- 大量旧版运行库。
WOW64 本身就像一个小型兼容环境
64 位 Windows 运行 32 位程序，需要处理：
- 32 位与 64 位系统调用转换；
- 参数、指针宽度转换；
- 32 位系统 DLL；
- 文件系统重定向；
- 注册表 32/64 位逻辑视图；
- 跨位数 COM；
- 调试、异常与诊断行为。
应用兼容 Shim
Windows 可以针对特定程序启用兼容修复，例如：
- 修改 API 参数；
- 修改返回值；
- 模拟旧版本行为；
- 伪装操作系统版本；
- 改变文件和权限行为。
单个 shim 往往很小，真正昂贵的是发现、定位、验证和长期维护。
8.3 为什么兼容性不能单独切出来
现代 Windows 子系统
├─ 文件系统
│ └─ 同时背负旧路径、共享、权限和重定向语义
├─ 装载器
│ └─ 同时处理多代 PE、DLL、manifest 和运行库
├─ 图形与窗口
│ └─ 同时保留旧消息、旧控件和旧 GDI 行为
├─ 注册表
│ └─ 同时支持历史键路径、重定向和虚拟化
└─ 安全
└─ 新安全模型必须避免破坏关键旧应用因此更准确的说法不是“现代 Windows 需要 X，人为追加一个兼容层再需要 Y”，而是：历史兼容让几乎所有核心子系统都变得更难设计、更难演进、更难测试。
8.4 兼容性的复利效应
兼容性不仅增加当前代码，还会限制未来架构选择：
- 不能随意修改路径与大小写规则；
- 不能随意修改消息循环和重入语义；
- 不能随意清理旧注册表路径；
- 不能随意收紧安全规则；
- 不能轻易废弃旧 DLL、图形、打印和音频接口。
于是新系统会不断叠加：
新 API
旧 API
兼容包装层
版本选择机制
应用专用 shim
架构转换层
测试矩阵这也是为什么历史兼容具有“复利”性质。
8.5 Windows 并非无限兼容
微软会主动划边界，例如：
- 64 位 Windows 不再原生运行 16 位 x86 Windows 程序；
- 依赖旧内核驱动、旧复制保护、直接端口访问的软件可能失效；
- 安全模型冲突过大的历史组件会被淘汰；
- 某些兼容性需求会转交虚拟机或专用兼容模式解决。
因此现代 Windows 的策略更接近：优先保留商业价值最高、使用量最大且可以安全兼容的旧软件。
9. 综合复杂度分层
将前面的估算放在同一张表中，可以得到一个非常粗略的“从零重建基本生产级版本”的复杂度阶梯：
| 复杂度层级 | 典型项目 | 粗略重建量 |
|---|---|---|
| 超大规模系统之系统 | AWS、Azure、Google 全球基础设施、Microsoft 365、Meta 平台 | 20 万～100 万+ 人月 |
| 超大型平台族 | 完整 Windows、Apple OS 平台族、z/OS 栈、SAP、EDA、Adobe CC | 5 万～30 万人月 |
| 极大型单一平台 | Chromium、Firefox、Linux 桌面、AOSP 上层、Office 核心、Oracle DB 产品族 | 2 万～10 万人月 |
| 超级基础软件 | OpenJDK、.NET 核心、LLVM、GNU 工具链、Wine、Mesa、Blender | 1 万～5 万人月 |
| 大型基础项目 | QEMU、PostgreSQL、Ceph、Kubernetes 核心等 | 数千～2 万人月 |
9.1 不能只按“代码量”排序
- Chromium 的难度主要来自 Web 语义深度、安全和兼容；
- Linux 桌面的难度主要来自硬件跨度和跨层集成；
- 数据库的难度主要来自数据正确性、并发和故障恢复；
- EDA 的难度主要来自编译、图算法、SAT/SMT、数值分析、几何和物理建模；
- 航电软件的难度主要来自验证与认证，而非代码总量。
9.2 单一代码库与平台族要分开
Chromium、Linux 内核、OpenJDK 更接近“清晰边界的软件平台”；而 AWS、Microsoft 365、SAP、EDA 套件、Creative Cloud 则更接近产品族或系统之系统。后者总工程量可以远大于任何单一开源仓库，但比较时必须明确边界。
10. 核心结论
Linux 内核与 Chromium：如果追求今天的完整成熟度，两者都是十几万到几十万人月级；如果只做基本生产级版本，Linux 内核约 1 万～3 万，Chromium 约 2.5 万～7 万。
Linux 内核 + 桌面：一旦加入图形、GPU、音频、输入、网络、电源、会话、更新和桌面服务，整体会升至约 3 万～8 万人月，与 Chromium 基本同级。
OpenJDK 与 .NET：核心工具链属于同一复杂度等级；.NET 因 Roslyn 平台化、统一 SDK、多运行时与 NativeAOT 等，通常略大约 10%～30%，完整现代 .NET 平台则可高出更多。
开放源代码领域：AOSP、Firefox、OpenStack、LLVM、GNU 工具链、OpenJDK、Wine、Mesa、LibreOffice、Blender 等都属于极大型项目，但真正和 Linux/Chromium 同层级的仍是少数。
闭源领域：Windows、Apple OS 平台族、z/OS、SAP、EDA、Adobe Creative Cloud、Office、Oracle Database 等都可能达到或超过 Chromium 级别；全球云和互联网平台则可能高一个数量级。
Windows 历史兼容：其成本确实足以相当于一个甚至多个大型软件平台，但它不是独立的一块“兼容代码”，而是把 Windows 几乎所有子系统的设计、实现、演进和测试成本都放大。
最重要的估算原则：“核心功能”“生产稳定性”“基本兼容”“完整历史兼容”“生态成熟”是完全不同的项目目标。只要改变其中一个词，人月估算就可能改变数倍甚至一个数量级。
10.1 一句话总结
真正的“超大型软件”不是因为代码行数很多，而是因为它同时承担了庞大的语义、兼容性、硬件/平台覆盖、可靠性、安全性与测试状态空间；Linux、Chromium、Windows、OpenJDK/.NET、数据库、EDA 和全球云平台只是这种复杂性的不同形态。