如果 2026 年看 Drupal 时首先只问市场份额，很容易读偏。Wappalyzer 的 CMS 目录显示，Drupal 追踪到的在线站点规模远小于 WordPress、Wix、Squarespace 和 GoDaddy Website Builder。[6] 这个差距有意义，但对于仍在运行严肃 Drupal 资产的运营方，它还不是最有用的信号。更值得追问的是，一个复杂、可扩展的 CMS，在经历二十年的核心升级、贡献模块、安全公告、composer 包、发行版政治和企业采购之后，为什么还能保持可治理。
答案不在于 Drupal 简单。事实相反。答案在于，Drupal 把若干混乱的开源难题转成了看得见的运作表面：谁可以作出核心决策，哪些版本会收到安全公告，安全补丁在什么时间协同发布，官方包和更新 feed 放在哪里，以及基础设施怎样保持足够独立，使一个 CMS 体系不依赖某一家供应商的私有平台。[1][2][3][4]
因此，Drupal 对 CMS 世界之外的 OSS 团队也有治理信号价值。它的强项不只在代码。它的强项是一套安全与发布机器，能够告诉站点所有者正在接下哪一种责任。
安全团队是一层协调层
Drupal 的安全文档对相关工作讲得异常直白。安全团队没有宣称会审查所有核心代码和贡献代码。它负责协调报告，评估问题对受支持版本的影响，调动维护者，审查并测试新版本，创建发布版本，然后通过官方沟通渠道告知用户应采取的行动。[2] 这个区分很重要。这里的安全承诺，重点不在于保证脆弱模块永远不会进入项目；它承诺的是从私下报告到公开公告之间有一条被承认的路径。
公告政策进一步收紧了这份契约。安全公告是由 Drupal Security Team 管理的公开通告，用来告知站点所有者 Drupal core 或某个贡献项目中收到报告的问题，以及他们应采取的步骤，通常是更新到修复版本。[3] 在公告准备好之前，问题保持私密。对于 highly critical 或 critical 问题，团队可在周三安全发布之前，于周一发布 public service announcement，给管理员一个很短的运维提前量，同时避免过早披露利用细节。[3]
这就是治理信号：Drupal 把披露时点当作基础设施处理。当数十万站点都要协调备份、依赖更新、部署窗口和缓存清理时，单个补丁还不够。安全发布需要足够可预测，让站点所有者能安排工作；也需要足够克制，避免提前把路线图交给攻击者。
这条边界同样有用。纳入覆盖的贡献项目需要有稳定版本，并且符合政策要求；sandbox 项目、dev 版本、alpha、beta、release candidate，以及 Drupal.org 覆盖范围之外的外部库，会按不同方式处理。[3] 对于希望每个依赖都继承 Drupal 公告保护伞的团队，这会带来摩擦。但这项政策的价值正在于清晰。Drupal 会告诉运营方，安全契约在哪里结束。
发布窗口把升级疼痛变成日历
Drupal 的发布周期也变得更明确。发布流程概览说明，Drupal 使用语义化版本，并采用可预测的日程：每两年发布一个 major version，每六个月发布一个 minor version，patch release 用于 bug 和安全修复。[4] 当前的核心日程把这一点落到具体日期上。它列出 Drupal 11.4.0 安排在 2026 年 6 月 22 日当周发布，同时 11.2.x 和 10.5.x 的安全支持结束；随后又指向 2026 年 12 月 7 日当周的 Drupal 12.0.0 和 11.5.0，并标明 Drupal 10 将在 2026 年 12 月 9 日结束生命周期。[5]
对一个 CMS 来说，这张日历不是行政琐事。Drupal 站点往往带着自定义模块、贡献模块、主题、编辑流程、集成、搜索索引、认证连接器和部署脚本。升级风险存在于整个资产组合中，并不只在核心里。定时发布日程让所有者把一句含混的“我们应该更新 Drupal”，拆成组合计划：核心分支、PHP 兼容性、模块就绪度、测试夹具、composer 约束，以及安全支持截止日。
Drupal 11.0.0 的发布说明显示了这件事的分量。Drupal 11 在 Drupal 10.3.0 之后不久发布，发布页面说明 Drupal 10.3 已经包含 Drupal 11 的大部分新功能，同时保留向后兼容层；站点预计先更新到 10.3，再迁移到 11。[8] 这是一种特定的升级哲学。Drupal 没有假装 major version 永远不疼。它试图分阶段处理疼痛：先把新功能和废弃项放进前一个 minor line，再在下一个 major 中移除旧层。
反证也很直接：如果贡献项目、托管环境或企业变更窗口跟不上两年一个 major 的节奏，日历就会从安全感变成压力。Drupal 的治理让升级路径清楚可见，但它无法让长期疏于维护的站点以低成本现代化。发布日程是给主动运营者使用的工具，不能替代维护本身。
核心治理让权威可被检查
Drupal 的核心治理文档重要，因为它直接命名角色，没有把权威藏在个人魅力里。文档描述了 Drupal Core Leadership Team、维护者、子系统维护者、主题维护者、initiative coordinators 和核心提交者，并解释决策与签核应如何发生。[1] 在一个会影响安全、可访问性、API、编辑流程和长期自定义代码的项目里，这一点很重要。
Drupal Association 对治理的说明补上了制度层。它说 Drupal 的模型分散权力，使任何单一个人或实体都不能出人意料地改变项目，同时 Drupal Association 作为独立非营利机构，负责监管 Drupal.org 和关键基础设施。[9] 同一说明也坦率写出仍然存在的创始人和商标安排：Dries Buytaert 保留对哪些软件和站点可以使用 Drupal 名称的控制权，而 Association 控制 Drupal.org 服务，包括代码仓库、打包、更新 feed、安全签名、composer 端点、命名空间、沟通表面和贡献系统。[9]
这种组合并不完全齐整。成熟 OSS 项目很少齐整。但它可以被检查。站点所有者可以看到，技术权威、基础设施权威、商标权威和协会治理彼此相关，却并不相同。相比那种用“社区”据称拥有一切来覆盖现实的叙述，这种状态更健康；在那类叙述里，操作控制常常散落在私人账号、供应商控制的服务和未写明的惯例之间。
运营方真正应从 Drupal 带走什么
第一条实践经验，是把 Drupal 当作一份体系契约，而不只当作一个应用包。如果一个站点依赖数十个贡献模块，这些模块是否处在安全公告保护之内、是否有稳定发布版本，就应该进入依赖引入流程，而不是上线后审计时才冒出来。[3]
第二条经验，是围绕发布窗口做计划。2026 年 6 月和 12 月的日期不是遥远路线图上的装饰；它们定义了支持何时转移、旧 minor line 何时停止获得安全覆盖。[5] 如果一个团队无法在支持转移前测试 minor upgrade，即使生产站点看上去仍然稳定，它已经落后于节奏。
第三条经验，是把市场份额与治理质量分开看。Drupal 在 2026 年公共网络上的份额有限。[6] 但对大学、政府、非营利组织、代理机构、出版方，以及拥有复杂编辑模型的企业团队来说，相关问题不是 Drupal 是否赢得受欢迎程度竞赛。相关问题是，这个项目能否持续把安全、升级和权威边界展示到足够清楚，让专业团队能够运营。
这就是 Drupal 持久的 OSS 经验。成熟开源项目不能只靠代码可得性存活。它要存活，需要足够多枯燥机器保持公开：公告规则、发布时钟、受支持版本边界、维护者角色、基础设施所有权，以及用户必须自行承担的失效模式。Drupal 的治理信号在于，这个 CMS 已经让这些机械部分显露出来，即使这些机械部分也显示出前方仍有艰难工作。
Sources
- Drupal Governance, "Drupal core" - Core Leadership Team、核心提交者、维护者、主题维护者、initiative coordinators、签核和决策流的角色结构。
- Drupal Security Team, "General information" - 安全团队目标、报告处理、发布协调、协同披露和受支持版本边界。
- Drupal Security Team, "Security advisory process and permissions policy" - 公告定义、周一 PSA / 周三发布模式、项目覆盖要求和稳定发布限制。
- Drupal.org, "Release process overview" - 语义化版本、可预测发布日程、两年一次 major release、六个月一次 minor release，以及 patch release 的框架。
- Drupal.org, "Drupal core release schedule" - 2026 年 Drupal 11.4、11.5、12.0、受支持 minor，以及 Drupal 10 生命周期结束日程。
- Wappalyzer, "CMS market share, websites and contacts" - 独立 CMS 目录，显示 Drupal 追踪到的在线站点规模与其他 CMS 平台的相对位置。
- Wikimedia Commons, "Dries Buytaert at FOSDEM 2008.jpg" - Steven Fruitsmaak 拍摄的照片，作为封面图片来源。
- Drupal.org, "drupal 11.0.0" - Drupal 11 官方发布说明，解释 Drupal 10.3 迁移路径和向后兼容层背景。
- Drupal Association, "Governance in the Drupal Ecosystem" - Drupal 治理、协会持有的基础设施、董事会结构、商标安排和独立性主张概览。