Ubuntu砍掉Google Drive：4年没人维护，开源社区终于摊牌了

Ubuntu 26.04的用户最近发现，文件管理器里的Google Drive入口凭空消失了。这不是bug，而是一场酝酿了整整4年的慢性死亡——GNOME团队终于决定，不再为一个无人认领的代码库买单。

一个功能从"能用"到"没了"，中间隔着47个月的无声等待。

事情得从Libgdata说起。这个负责对接Google在线服务的底层库，最后一次有人认真维护是在2021年前后。GNOME开发者Emmanuele Bassi在回复用户投诉时说得直白：「Libgdata已经近4年无人维护，GVFS早在10个月前就默认禁用了这个依赖。」换句话说，系统层面的支撑早就抽走了，只是用户没察觉。

Linux桌面环境的生态有个潜规则：没人维护的功能，等于不存在。Windows和macOS可以靠付费团队硬撑，但GNOME的每个模块都需要志愿者或赞助者认领。Google Drive集成这种"锦上添花"的功能，优先级天然靠后。

用户视角：从"无缝"到"断层"的体验落差

在Ubuntu 25.10及更早版本里，Google Drive的集成堪称丝滑。登录GNOME在线账户后，文件管理器左侧会多出一个云盘入口，文档像本地文件一样打开、编辑、保存。对跨平台办公的人来说，这省去了浏览器来回切换的麻烦。

26.04更新后，同样的操作路径还在，但Drive选项消失了。邮件、日历、联系人依旧正常——Google的OAuth接口没断，断的是文件系统的桥接层。用户以为是升级出了岔子，纷纷提交bug报告，得到的回复却是一盆冷水：这不是故障，是计划内的退役。

GNOME团队给了社区近4年时间，零人响应。

Bassi的回复里有个细节值得玩味：「如果有人想恢复这个功能，可以联系GVFS维护者。」翻译过来就是——代码还在，仓库没删，但核心团队不会为此加班。开源项目的残酷法则在此显露无遗：用爱发电的前提是，真的有人愿意发电。

技术债的连锁反应：为什么偏偏是Drive？

Libgdata的衰落不是孤立事件。Google这些年在API策略上反复横跳，OAuth 2.0的权限范围越收越紧，第三方客户端的生存空间持续压缩。维护一个与Google服务深度绑定的开源库，意味着要持续追踪官方的接口变更，随时应对认证流程的调整。

这活儿不性感，还很累。没有大厂赞助，没有个人开发者能靠"修Google Drive适配"建立技术声誉。相比之下，Wayland显示协议、PipeWire音频系统这些基础设施，至少有Red Hat、Canonical等公司雇人全职投入。

GVFS（GNOME虚拟文件系统）在10个月前默认禁用Libgdata依赖，是个关键转折点。当时GNOME 49还在开发周期，维护者已经释放了明确信号：这个组件进入临终关怀。GNOME 50只是正式拔管。

Ubuntu的处境比GNOME更尴尬。作为面向普通用户的发行版，它不能随意改动上游决策，只能被动跟随。Canonical自己的资源集中在Snap生态和服务器市场，桌面端的Google Drive集成从来不是优先级。

替代方案：用户现在能怎么办？

功能消失后，社区论坛里涌现出一堆 workaround。最主流的替代路径有三条，每条都有代价。

第一条是Chrome OS风格的PWA方案。Google Drive的网页版做成桌面应用，通过Chrome或Edge的"安装为应用"功能固定到任务栏。优点是零配置，缺点是文件操作绕不开浏览器，本地编辑器的无缝调用没了。

第二条是rclone挂载。这个命令行工具支持Google Drive的FUSE挂载，技术用户可以在文件管理器里重建类似的体验。但需要手动配置OAuth令牌，刷新机制也要自己维护，对非技术用户门槛过高。

第三条是彻底换云。Nextcloud、ownCloud这些支持WebDAV的自托管方案，与Linux桌面集成更原生。但迁移成本摆在那里，多年积累的Google Docs格式兼容性问题也不是一键能解决的。

没有一条路能完美复刻当年的体验。GNOME集成方案的消失，本质上抽掉了一根"开箱即用"的支柱，把用户推回碎片化工具链的泥潭。

开源桌面的结构性困境

这件事的深层矛盾在于：用户期待的是"像macOS一样好用的Linux"，但生态运转的逻辑完全不同。Apple可以给iCloud Drive配一个20人的团队，持续优化Finder集成；GNOME的同等功能依赖志愿者，而志愿者的兴趣点永远在迁移。

Google Drive集成的代码量不算大，但维护负担集中在"持续跟进Google的API变动"。这种绑定单一商业服务的模块，在开源社区天然处于弱势——今天修好了OAuth，明天Google可能又改策略。投入产出比算下来，不如去做通用的WebDAV支持。

GNOME 50的发布说明里，这项改动被归类为"移除废弃组件"，语气平淡得像清理阁楼旧物。但对依赖这个功能的用户来说，这是操作系统层面的信任破裂：昨天还在用的工作流，今天就成了技术债的牺牲品。

社区的反应呈现两极分化。技术论坛里，有人理解维护者的无奈：「4年啊，足够任何人站出来接手，没人动就别抱怨。」社交媒体上的普通用户则不买账：「Ubuntu吹了这么多年桌面易用性，结果连网盘集成都能丢？」

谁该为此负责？

追溯责任链，每个环节都能甩锅。Google收紧API策略，让第三方维护成本上升；GNOME核心团队资源有限，被迫做减法；Canonical作为发行商，没有填补上游留下的空缺；社区用户习惯了免费获取，却鲜少贡献维护人力。

最讽刺的可能是Google的态度。这家公司的业务重度依赖Linux基础设施，从Android到Chrome OS到云端服务器，但对桌面Linux的原生体验投入近乎为零。Drive有Windows和macOS的官方客户端，Linux版永远只有浏览器。

GNOME开发者Bassi的回复末尾留了一扇虚掩的门：联系GVFS维护者，功能可以恢复。但这扇门的高度，足以挡住99%的用户——你需要懂C语言，熟悉GLib生态，愿意签署Google的API使用协议，并且承诺长期维护。

开源世界的"用户"和"贡献者"身份重叠度，决定了功能的生死。Google Drive集成不是第一个倒下的，也不会是最后一个。GNOME 50同期移除的废弃组件还有一箩筐，只是Drive的用户基数让这件事显眼了。

Ubuntu 26.04的发布说明里，这项变更被埋在"已知问题"章节，没有前置提醒。升级后才发现工作流断裂的用户，体验堪比软件行业的"先斩后奏"。

现在，文件管理器左侧的云盘入口空了。有人已经习惯了浏览器标签页里的Google Drive，有人在折腾rclone的挂载脚本，还有人正在评估要不要把主力机换回macOS。Bassi那句"我们本可以阻止这一切"的潜台词，大概只有长期混迹开源社区的人才能完全听懂——四年时间，足够长，长到让人误以为这个功能会永远在那里。

你上次为常用的开源工具贡献过代码、文档或bug报告，是什么时候？