红帽撤离中国，一个时代的落幕。

在每天人声鼎沸的 AI 声浪中，一条突发消息让我们恍惚了一下：红帽（Red Hat）宣布停止在中国的全部工程活动，仅保留销售和支持职能，裁撤 419 名研发员工，雇佣关系统一于 2026 年 7 月 31 日终止，赔偿方案 N+3 至 N+6，研发职能将转移至亚太地区其他工程枢纽。

云头条获取的内部邮件显示，红帽CTO兼全球工程高级副总裁向红帽中国团队发送了一份邮件。

公告的措辞很简洁，像一份例行的业务调整声明。但对于国内所有关注开源的朋友们来说，这意味着一个时代的落幕。

✅OSC源创会 × FAIR plus 2026
深圳会展中心（福田）9号馆4号会议室
报名oschina.net/event/8598188不一样的本土团队

红帽在中国设立研发中心已有多年，核心团队分布在北京和上海。和大多数外企在中国设置的“本地化团队”不同，这批工程师的工作不是把产品翻译成中文，也不是维护本地销售配套的技术支持 ——他们是真正意义上参与全球开源上游的重要力量。

Linux 内核是他们工作的核心舞台之一。多年来，红帽中国工程师持续在内核邮件列表中提交补丁，涉及虚拟化（KVM）、文件系统（XFS）、网络子系统、存储驱动等方向。这些代码并不“本地”，它们最终进入 Linux 主线，跑在全球数以亿计的服务器上。

红帽（含其母公司 IBM）历来是 Linux 内核贡献最活跃的企业之一，长期处于全球前三的位置，与Intel、Google 并列。内核社区里有一条不成文的规矩：谁提交补丁、谁维护子系统，谁就对那块代码负有长期责任。维护者的名字被写进MAINTAINERS文件，随着每个内核版本发布流传下去。

现在，这份责任链条上，将有 419 个缺口。

340 亿美元买来的困局

2019 年 7 月，IBM 以 340 亿美元完成对红帽的收购，这是当时企业软件史上规模最大的并购之一。彼时 IBM 的逻辑清晰：押注混合云，用红帽的开源品牌和工程能力为自己打开通路。收购完成后，IBM 特别强调红帽将保持独立运营，保留自己的工程文化。

这个承诺在一定程度上兑现了，但商业现实没有那么浪漫。

IBM 在全球范围内持续承受营收压力，中国区业务尤其复杂。过去几年，外资 IT 企业在中国的处境发生了结构性变化：数据合规要求提升、政府采购向国产软件倾斜、安全审查趋严。对于依赖政府客户和大型国企的 RHEL（红帽企业 Linux）来说，这些变化是系统性的利空。

更直接的问题是替代方案的崛起。以 openEuler 为核心的国产 Linux 生态，在华为、麒麟软件、统信等企业推动下，已经完成了从技术论证到规模落地的跨越 —— 金融、能源、运营商、政务等关键行业的迁移正在加速，整体市场份额已超过 50%。openEuler 的官网上，有一整个“迁移专区”，专门提供从 RHEL 切换过来的工具和文档。

讽刺的是，帮助这套国产生态建立起来的，有相当一部分是红帽工程师本人。他们带进来的“上游优先”的工程文化，在内核社区的参与方式，以及开源协作的方法论，成了国内开源工程师的早期教科书。

一个企业研发中心存在的前提，是它的工作创造商业价值。当 RHEL 在中国的市场份额被蚕食殆尽，继续在这里养活一支数百人的工程团队，对 IBM 和红帽来说很难在内部写出合理的预算依据。

代码还在

开源的逻辑是：代码永远不会消失。那些被合并进 Linux 主线的补丁，依然在git log里，依然标注着Signed-off-by: ***@redhat.com。

但代码背后的人 —— 一个子系统的维护者离职，他维护的那段代码就会进入“维护者缺失”的灰色状态 —— bug report 可能得不到回应，新提交的补丁可能长期无人 review，依赖这段代码的下游项目开始累积技术债。内核社区有一套应对机制，但每次维护者离开都会付出真实的磨合成本。这不是危言耸听，而是内核社区反复经历过的情形。过去每当某家企业削减对某个方向的投入，社区里就会开始找人接盘 —— 有时候能接住，有时候接不住。

从历史的尺度看，外资科技企业在华工程中心的收缩并非孤立事件。早年思科、摩托罗拉的中国研发中心曾培养出大批工程师，随着企业战略调整而关闭或缩编；微软亚洲研究院虽然依然存在，规模和影响力也早已不比当年。红帽中国的关闭，是这条时间线上的又一个刻度。区别在于，红帽中国裁撤的，是参与全球基础设施建设的工程师。他们的离开，在一定程度上是一段技术输出关系的终结。

谁来接盘

当然，这不是 Linux 内核社区第一次面对“维护者缺失”的问题。2024 年 10 月，由于美国所谓的“合规性要求”，多名俄罗斯籍维护者被从MAINTAINERS文件中移除过一次 —— 那次事件引发了极大的争议，但从某种程度上来说算是提前演练了今天的场景。

Linux 内核社区对“维护者空白”有一套相对成熟的应对机制。MAINTAINERS文件中的每个子系统都有一个状态标记：Supported（有企业付费支持）、Maintained（有活跃维护者）、Odd Fixes（维护者时间有限）、Orphan（无当前维护者）、Obsolete（已废弃）。当一个维护者离职，其负责的子系统可能被标记为Orphan，意思是“没有当前维护者 —— 但也许你在写新代码的过程中可以接手这个角色”。

内核社区没有正式的“维护者申请表格”，维护者角色是基于贡献历史自然演化的：持续提交高质量补丁的开发者，会逐渐被认可为事实上的新维护者，然后发送补丁更新MAINTAINERS文件。这是一种缓慢、有机的接替方式。

这一次红帽中国研发团队的裁撤留了近 4 个月的交接缓冲时间，比俄罗斯那一次的情况还是好很多的。红帽会从其他工程中心（印度、欧洲）调配资源接手关键子系统；Intel、Google、Meta 等公司的工程师也可能填补部分缺口；一些低活跃度的子系统可能长期处于Orphan状态，依赖社区零散贡献。如果最终没人接手，那段代码会被标记为Obsolete，用户被建议迁移到替代方案 —— 这是内核社区的“自然选择”机制。

而那些被裁撤的红帽中国工程师，大概率会散入国内的云厂商、芯片公司、操作系统创业团队。他们带进来的上游工程文化，或许还会以另一种方式流传 —— 甚至增强国产 OS 团队参与全球开源的能力。

从某种角度看，“维护者空白”可能不是单纯的损失，而是开源人才在全球和中国本土之间的一次重新分布。那些写进git log的名字还在，只是他们下一次提交补丁时，邮箱后缀可能不再是@redhat.com。

1. https://www.oschina.net/news/317406
2. https://docs.kernel.org/next/maintainer/feature-and-driver-maintainers.html