浏览器分叉是开源生态中最具代表性的技术决策之一。当主流项目做出影响用户体验的重大改变时，社区往往通过分叉来保留被放弃的功能与设计理念。Waterfox 作为 Firefox 最重要的第三方分支之一，自 2010 年左右诞生以来，已经走过了十五年的演进历程。它不仅是一个浏览器项目，更是研究开源项目如何在大厂决策夹缝中生存、如何平衡兼容性继承与安全更新的绝佳案例。
Waterfox 的起源：从 64 位诉求到独立分支
Waterfox 项目由开发者 Alex Kontos 在学生时代创立，最初的动机非常直接 —— 在 Mozilla 官方提供 64 位 Firefox 之前，为用户提供一个原生 64 位版本的 Firefox 分支。彼时 Mozilla 的 Firefox 主要以 32 位构建为主，即便在 64 位操作系统上运行，也只能调用 32 位版本，这一限制在处理大文件、复杂网页渲染时成为性能瓶颈。Waterfox 正是抓住了这个市场需求，在 Firefox 源代码基础上编译出纯 64 位版本。
与单纯追求 64 位性能不同，Alex Kontos 很快为 Waterfox 赋予了更多差异化定位。该项目主动移除了 Mozilla 官方版本中的多项争议性功能： telemetry 遥测数据收集、内置赞助链接、以及后来被收购的 Pocket 阅读服务。这些改动虽然看似细微，却精准切中了注重隐私与自主权的用户群体。Waterfox 从一开始就不仅仅是一个技术分叉，更是一种立场表达 —— 它代表了对 Mozilla 商业化路线的不满与对用户自由选择权的坚持。
值得注意的是，Waterfox 的早期策略展现了对上游代码的高效追踪能力。由于直接基于 Firefox 主线构建，每次 Firefox 发布重大更新时，Waterfox 团队需要快速完成代码同步、兼容性测试与安全补丁的后向移植。这种开发模式奠定了该项目多年来的核心工程实践：以稳定的节奏追随上游发布，同时保留必要的本地定制能力。
Firefox 57 量子革命与 Waterfox Classic 的诞生
2017 年是 Firefox 历史上最具争议的转折点。Firefox 57 版本（代号 Quantum）带来了革命性的架构升级，包括用 Rust 重写的部分浏览器引擎、新的 CSS 渲染管线以及全新的 Quantum Compositor。然而，这一版本最具破坏性的改变是彻底移除了 XUL 与 XPCOM 基础的传统扩展系统。
XUL（XML User Interface Language）是 Netscape 在 1997 年为 Mozilla 引入的界面描述语言，支撑了 Firefox 长达二十年的扩展生态。据 Classic Addons Archive 项目统计，Firefox 57 的这一决定一次性废弃了约 19,450 个由 14,274 名开发者历时十五年创建的扩展。对依赖这些扩展的老用户而言，Firefox 57 无异于一次 “突然死亡”。
Waterfox 正是在这一背景下推出了 Waterfox Classic 分支。该分支基于 Firefox 56（最后一个支持传统扩展的版本），在此基础上持续回移植 Mozilla 后续版本的安全补丁。Waterfox Classic 不仅仅是简单冻结在 Firefox 56，而是保持了活跃的安全维护 —— 项目团队会将 Mozilla 针对较新 Firefox 版本发布的安全修复手工移植到 Classic 分支，确保用户即便使用老旧浏览器引擎，也能获得关键的安全更新。
这种维护策略面临巨大的工程挑战。每次安全补丁的移植都需要深入理解代码变更上下文，判断该补丁是否与 Classic 分支保留的旧 API 兼容，以及是否可能引入新的依赖冲突。Waterfox 团队在这一过程中积累了丰富的逆向移植经验，形成了一套系统化的补丁分类与优先级评估流程。
除了扩展兼容性，Waterfox Classic 还保留了另一个实用功能：对旧版 macOS 的支持。Apple 在后续 macOS 版本中逐步淘汰了对 32 位应用的支持，许多旧版浏览器因此无法在新版系统上运行。Waterfox Classic 一直维护着对 macOS 10.7 及以上版本的支持，这让持有较旧 Apple 硬件的用户得以继续使用现代浏览器功能。
双轨策略：Classic 与 Current 的并行演进
Waterfox 项目在 Firefox 57 事件后逐步形成了经典版与现代版并行的双轨策略。Waterfox Classic 面向无法割舍传统扩展的用户，而 Waterfox Current（后续更名为 Waterfox G3、G4）则面向追求新功能与安全更新的用户。这种分叉策略在开源社区并不罕见，但 Waterfox 的执行方式有其独特之处。
Waterfox G3 发布于 2020 年，基于 Firefox 78 ESR（扩展支持版本）。选择 ESR 作为基础是一个关键决策 ——ESR 版本提供更长的维护周期（通常为一年），相比 Firefox 快速发布通道的六周周期，提供了更稳定的升级节奏。更重要的是，G3 在此阶段开始支持 Chrome 与 Opera 扩展，这意味着用户可以在 Waterfox 上使用来自 Chrome Web Store 的庞大扩展生态，一改 Firefox 传统扩展消亡后的颓势。
G3 还恢复了一些被 Mozilla 移除的经典 UI 元素：标签栏可以放置在地址栏下方，状态栏可以重新启用。这些看似微小的功能调整，实际反映了 Waterfox 对 “用户选择权” 这一核心理念的坚持。项目团队认为，浏览器不应该强制用户接受单一交互范式，而应该允许用户根据个人偏好进行定制。
Waterfox G4 则基于 Firefox 91，并首次引入了对 ARM 架构 Mac 电脑的支持。随着 Apple Silicon（M1/M2 系列芯片）的普及，浏览器兼容性面临新的硬件挑战。G4 的发布标志着 Waterfox 从单纯追随 Firefox ESR 转向更积极的版本策略 —— 开始关注 Firefox 的 central 开发分支，以便更早获取新功能而非被动等待 ESR 发布。
最新的 Waterfox G5 则进一步明确了 ESR 102 基础的定位，同时引入了自动升级机制。用户可以选择即时升级到最新版本，也可以选择暂缓升级以等待更充分的测试验证。这种弹性升级策略平衡了安全需求与稳定性担忧，赋予用户对浏览器演进节奏的部分控制权。
兼容性挑战：扩展、系统与安全的三重平衡
维护一个浏览器分支意味着要在多个相互冲突的目标之间找到平衡点。对于 Waterfox 而言，核心挑战来自三个方面：扩展兼容性、遗留系统支持、以及安全更新的及时跟进。
在扩展兼容性层面，Waterfox 面临的是一个渐进的衰退问题。随着时间推移，越来越多的网站与服务升级其前端技术栈，基于旧版渲染引擎的浏览器在访问这些网站时可能出现样式错乱、功能异常或安全警告。Waterfox Classic 维护的时间越长，其与现实 Web 环境的脱节就越严重。项目团队需要持续评估：是继续维护一个越来越与世隔绝的 legacy 环境，还是引导用户迁移到现代版本。这种决策没有标准答案，取决于用户群体的实际构成与需求强度。
在系统支持层面，Waterfox 面临的挑战同样复杂。项目需要同时维护对 Windows、macOS 与 Linux 的支持，而在每个操作系统内部，还要应对不同版本间的 API 差异。以 Windows 为例，早期 Waterfox 需要支持 Windows XP/Vista，而现代版本则需要适配 Windows 10/11 的新安全特性与通知系统。macOS 方面的情况更为棘手 ——Apple 频繁变更系统 API，每次 macOS 大版本升级都可能导致浏览器功能异常或性能退化。
安全更新机制是浏览器分叉项目最关键也最脆弱的环节。相比 Mozilla 拥有专职安全团队与自动化漏洞赏金计划，Waterfox 作为一个依赖志愿者与少量付费员工的项目，在安全响应的及时性上必然存在差距。项目团队的策略是优先关注高危漏洞（影响内存安全、可能导致代码执行的类型），而对低风险问题采取累积到下一版本统一修复的方式。这是一种务实的资源分配决策，但也意味着某些安全公告可能在 Waterfox 上的修复时间晚于官方 Firefox。
开源可持续性：从个人项目到商业支撑
Waterfox 的商业模式与可持续性问题同样值得关注。项目在 2021 年被广告技术公司 System1 收购，这一消息在开源社区引发了关于项目独立性命运的担忧。与 PureOS（同样隶属于 System1 旗下）的情况类似，Waterfox 的用户担心商业化可能导致隐私政策的松动或数据收集的增加。
然而，从实际运营结果看，System1 的收购为 Waterfox 带来了更稳定的资金来源，使项目能够维持常规的开发节奏与服务器成本。商业化并非必然导致开源项目背离其核心价值 —— 关键在于商业所有者是否愿意尊重项目的开源性质与用户社区的合理预期。Waterfox 在被收购后依然保持了代码的开源可获取性，持续发布更新版本，这说明在当前框架下，商业化并未根本性地改变项目的运作方式。
从更宏观的视角看，Waterfox 的十五年历程折射出开源生态的复杂性。当一个大厂项目做出争议性决策（如 Firefox 57 放弃扩展兼容性）时，分叉项目可以成为社区的 “安全阀” 与 “备选方案”。但分叉项目的长期存活需要满足几个关键条件：持续的维护者投入、稳定的资金或志愿者资源、以及足够差异化的用户价值主张。Waterfox 之所以能存活十五年，正是因为它在每个关键时间点都做出了正确的策略调整：从 64 位差异化到 Classic 分支，从 ESR 追踪到 ARM 支持，每一次转型都对应着用户需求的演变与市场竞争的格局变化。
对于其他有意参与开源分叉项目的开发者，Waterfox 的经验提供了几点可操作的参考。首先，明确分叉的核心价值主张 —— 为什么用户应该选择这个分支而不是直接使用上游项目或竞争对手。其次，建立可持续的维护节奏 —— 分叉项目最常见的死亡原因是维护者的热情消退，因此需要在贡献者培养与任务自动化方面投入建设。第三，审慎处理商业化与合作意向 —— 接受外部投资可以解决资金问题，但需要在治理结构与透明度方面设置适当的保障机制。
Waterfox 的故事远未结束。随着 Web 标准的持续演进与浏览器技术的不断突破，浏览器分叉这一形态将长期存在 —— 只要有不同的用户群体，只要有大厂决策与社区需求之间的张力，就有分叉项目的生存空间。理解 Waterfox 过去十五年的技术选择与商业决策，对于任何关注开源生态演进的人来说，都是一堂值得深思的实践课。
资料来源：The Register 文章《Waterfox: A Firefox fork that could teach Mozilla a lesson》（2021 年 11 月）。