​

最近圈子里那篇《MinIO 已死，MinIO 复生》传得很火。老冯（Pigsty）干了一件挺硬核的事：在 MinIO 彻底转向商用、抛弃开源社区之后，他一个人把代码 Fork 了出来，用 AGPL 许可证接着维护。

看完挺感慨的。这不仅是 MinIO 一家的问题，HashiCorp、Elasticsearch、Redis……大家都在经历同一个轮回：​开源获客，闭源收割​。

站在 2026 年这个时间点上，如果你现在要选一个对象存储，其实只有两条路可以走。

---

路线 A：社区续命派（Go + AGPL）

这就是老冯正在做的事。

​核心逻辑很简单​：MinIO 的代码写得确实好，单机性能至今能打。既然公司不要社区了，那社区就自己养。

​优势很明显​：

• 迁移成本极低。API、行为、部署方式几乎 100% 兼容，老用户无痛切换。

• 保留了 Go 语言的生态积累，出问题大概率是已知问题。

​但隐患也客观存在​：

1. ​AGPL 本身就是一道高墙​。对于很多国内企业来说，AGPL 和商用闭源没太大区别，法务照样不敢碰。

2. ​技术债固化​。这是在维护一个既定事实，很难借机重构架构。CVE 漏洞、内存安全问题依然存在，只是有人修了。

3. ​单点英雄风险​。这种模式极其依赖核心维护者的个人意志和精力。

这条路线解决的是 ​“生存问题”​——让 MinIO 这个名字不至于消失。

---

路线 B：架构重构派（Rust + Apache-2.0）

另一条路，是像 RustFS 这样的新项目在尝试的方向。

​核心逻辑是​：既然旧时代的合同结束了，那就用新时代的铲子重挖一遍。

为什么是 Rust？

• ​内存安全​。对象存储是长周期、高并发服务，C/C++/Go 里的空指针、数据竞争，在 Rust 里被编译期直接干掉了。对于存储系统来说，这是底层的可靠性红利。

• ​交付形态极简​。RustFS 目前主打单二进制文件，部署一个分布式集群不需要像 Ceph 那样养一支运维团队。

• ​许可证干净​。Apache-2.0，不玩文字游戏，企业敢用。

代价是什么？

• 生态还在早期。你没法指望它现在就有 MinIO 那么多的第三方工具集成。

• 迁移需要验证。虽然 S3 API 兼容，但底层行为变了，需要做一轮完整的回归测试。

这条路线解决的是 ​“发展问题”​——面向 AI 训练、高密度存储、云原生环境重新设计。

---

选型建议：别选最好的，选最合适的

维度	路线 A（社区 Fork）	路线 B（Rust 重构）
适合人群	已有大量 MinIO 存量集群，只想续命	新建项目，或受限于 AGPL 无法商用
运维难度	中等（继承 MinIO 复杂度）	低（设计目标就是降运维）
法务风险	高（AGPL 传染性）	低（Apache-2.0）
长期预期	维持现状	迭代新特性（RDMA、AI 优化）

老冯的坚持值得尊敬，那是开源精神里最硬核的那一部分。但对于大多数只是想安稳存数据的企业来说，或许不需要在 AGPL 的漩涡里纠结太久。

开源不只是许可证，更是​选择权​。当一条路堵死了，换条路走，未必是背叛，可能只是进化。

(注：RustFS 目前处于 Beta 阶段，有兴趣可以在 GitHub 自行了解项目进展。)

---

以下是深入学习 RustFS 的推荐资源：RustFS

官方文档： RustFS 官方文档- 提供架构、安装指南和 API 参考。

GitHub 仓库： GitHub 仓库 - 获取源代码、提交问题或贡献代码。

社区支持： GitHub Discussions- 与开发者交流经验和解决方案。

​​