MinIO 开源版突发“安乐死”：维护模式开启，社区愤怒，你的数据还安全吗？

原创于 2025-12-04 18:00:00 发布 · 508 阅读

13 ·

CC 4.0 BY-SA版权

文章标签：

#开源

大家好，我是Tony Bai。

“这个项目目前处于维护状态，不接受新的更改。”

近日，GitHub 上拥有近 60k Star、Go 语言生态中最著名的开源对象存储项目——MinIO，悄然修改了其README。这一行看似平淡的声明，标志着 MinIO 开源版实际上已经被宣判了“死刑”。

曾经，MinIO 是自建 S3 兼容存储的首选，是开源界的宠儿。如今，它转身拥抱了企业级市场和 AI 浪潮，留下了一脸错愕的社区用户和无数依赖它的开源项目。这究竟是一场无奈的求生，还是一次蓄谋已久的“收割”？

突如其来的“维护模式”

MinIO 官方在没有任何预警的情况下，将其开源仓库置于“维护模式”。这意味着：

功能冻结：不再接受任何新功能或改进。
社区关门：不再接受 Pull Request，现有的 Issue 和 PR 也不会被积极审查。
安全补丁随缘：关键的安全修复“可能”会根据具体情况进行评估，不再有保证。

官方建议很明确：“对于企业支持和积极维护的版本，请参阅MinIO AIStor。”，而AIStor则是MinIO的企业版对象存储产品。

这一举动在 Hacker News 上引发了轩然大波。用户感到被背叛，一位评论者愤怒地写道：“太恶心了。构建一个产品，通过开源获得动力，等你做完了就完全抛弃它。我为曾经推广这个项目感到羞耻。”

为何“背叛”？—— 商业化的必然与 AI 的诱惑

MinIO 的转向并非无迹可寻。从更换为更严格的 AGPL 协议，到此次事实上的闭源，其背后的逻辑清晰而冷酷：

开源无法变现的困境

MinIO 作为一个高性能、单二进制文件的存储服务，太容易“被集成”了。云厂商、集成商可以轻松地将其打包进自己的产品中获利，而 MinIO 公司却难以从中分一杯羹。AGPL 协议虽然意在限制云厂商的“白嫖”，但也未能从根本上解决其商业化难题。

AI 浪潮的巨大诱惑

MinIO 的新产品名为 AIStor。这不仅仅是一个改名，更是一次战略转型。在 AI 时代，数据存储是基础设施的核心。MinIO 试图通过重新包装，将自己定位为 AI 基础设施的关键组件，从而向更有付费能力的企业客户（尤其是 AI 公司）靠拢。

正如一位 HN 用户指出的：“他们在上一轮融资中估值 10 亿美元，要想成功退出，必须有深口袋的买家（如 Nvidia, Dell 等）。现在的开源版本只会拖累他们的财报。”

社区的反击与法律迷局

MinIO 的做法也引发了法律层面的争议。

贡献者的权利：MinIO 曾要求贡献者签署 CLA（贡献者许可协议）。这意味着 MinIO 公司拥有代码的版权，他们确实有权改变许可证或停止开源。
AGPL 的约束：但对于那些没有签署 CLA 的早期贡献者，或者包含在代码库中的第三方 AGPL 代码，MinIO 是否有权单方面“私有化”？这是一个复杂的法律问题。

更有趣的是，MinIO 过去曾因 AGPL 许可问题积极“维权”，甚至公开指责其他公司违反协议。如今，它自己却试图摆脱开源的束缚，这种双重标准让社区感到讽刺。

历史的镜像 —— Redis 与 Valkey 的启示

MinIO 的剧变，让人不由得想起了 2024 年初震动开源界的另一场“地震”——Redis 修改开源协议事件。

当时，Redis Inc. 宣布不再遵循开源定义，转而采用限制性更强的 SSPL 协议。这一举动激怒了整个社区和云厂商，Linux 基金会迅速集结了 AWS、Google、Oracle 等巨头，基于 Redis 旧版本 fork 出了 Valkey。如今，Valkey 已经展现出取代 Redis 的蓬勃生命力。

MinIO 与 Redis 的异同：

相同点：两者都面临“云厂商困境”。AWS 直接拿 Redis 做 ElastiCache，拿 MinIO 做兼容 S3 的服务，却无需向原厂付费。原厂为了生存，不得不通过协议（AGPL/SSPL）或停止维护来“筑墙”。
不同点：Redis 选择了“掀桌子”（改协议），引发了激烈的对抗和即时的 Fork（Valkey）；而 MinIO 选择了“冷处理”（维护模式），这更像是一种温水煮青蛙式的告别。

MinIO 会迎来它的“Valkey 时刻”吗？

目前来看，难。对象存储的复杂度和维护成本远高于内存缓存，且市场上已经存在成熟的替代品（如 SeaweedFS, Ceph, RustFS等）。MinIO 社区或许不会像 Redis 那样迅速集结出一个统一的 Fork，而是会走向分裂和迁徙。

对于开发者而言，Redis 和 MinIO 的连续“暴雷”是一个明确的信号：在基础设施选型时，除了关注技术指标，更要评估其背后的治理模式。由单一商业公司绝对控制的“开源”项目，始终悬着一把达摩克利斯之剑。

自救指南 —— 寻找 MinIO 的替代品

对于现有的 MinIO 用户来说，现在是时候寻找备胎了。社区推荐了几个值得关注的替代方案：

SeaweedFS (Go)

特点：基于 Haystack 论文实现，擅长处理海量小文件，自带 File 和 S3 接口。
适用场景：需要高性能小文件存储的场景。
评价：功能丰富，甚至有点“过度”，但性能强悍。

Ceph (C++)

特点：存储界的瑞士军刀，功能极其强大，但也极其复杂。
适用场景：大规模、生产级、需要块存储和文件存储的场景。
评价：如果你有运维团队，Ceph 是永远不会错的选择。

Versity Gateway (Go)

特点：基于文件的 S3 网关，可以在开发测试环境作为 MinIO 的直接替代品，后端直接对接文件系统。

RustFS (Rust)

特点：野心勃勃的新晋选手，试图在性能和易用性上直接对标甚至超越 MinIO。
适用场景：极客尝鲜、非生产环境的测试与评估。
评价：社区评价两极分化。一方面，它展现了强大的潜力；另一方面，用户反馈其目前稳定性欠佳，且项目要求签署 CLA（贡献者许可协议），这让不少刚被 MinIO 伤过心的开发者担心它未来会重演“养肥再杀”的剧本。“潜力巨大，但需谨慎观望。”