MinIO告别开源：明星存储项目进入维护模式，商业化之路引发争议

一款在GitHub上收获近6万颗星的知名开源项目——高性能分布式对象存储服务MinIO，于12月3日突然调整了开源策略，宣布项目进入“维护模式”：此后代码库仅进行必要的维护性更新，不再添加新功能，现有的Issue、PR将不再被主动处理。

消息一出，令许多开发者措手不及。一时间，各种观点交织。

有人表示理解，有人感到困惑，也有人提出批评，甚至在一些社区论坛中，有用户直接断言“MinIO已死”，并创建了「RIP MinIO」的帖子，表达自己的失望。

那么，这个在众多对象存储场景中仍被广泛采用的项目，为何会作出这样的决定？让我们一探究竟。

下载量高达10亿次的开源项目成长史

其实对于MinIO，许多技术人亲眼见证了它的发展历程，也曾在实际项目中应用过。

MinIO创立于2014年，由Anand Babu Periasamy、Garima Kapoor和Harshavardhana等人联合发起，初始目标是应对私有云/混合云环境中对高性能对象存储的旺盛需求。

当时，企业云存储需求激增，AWS S3成为行业标准，但不少企业希望在本地或私有云环境中使用与S3兼容的对象存储。MinIO正是顺应这一趋势诞生的。

MinIO团队选择用Go语言开发，将其设计为轻量级、高性能，且与Amazon S3 API完全兼容的对象存储服务。这样一来，依赖S3的应用或基础设施可以平滑迁移到自建环境或私有云中。

同时，MinIO从一开始就采用Apache License 2.0开源协议，方便开发者和企业自由使用。正因如此，它在开发者社区和企业用户中迅速流行开来。

数据显示，MinIO在开源社区表现活跃：它拥有超过1,400个依赖包，在GitHub上获得约58.9K Star和6.5K Fork。在Docker Hub上，MinIO镜像下载量已突破10亿次。就国内市场而言，此前统计显示，MinIO被阿里巴巴、腾讯、百度、中国联通、华为、中国移动等超过9,000家企业采用，尤其在构建私有云存储、混合云存储和分布式存储方面表现突出。

MinIO此前的三次关键变革

然而，近来MinIO的“想法”逐渐发生转变，导致其后续动作频频，先后变更了开源协议、删减开源版功能、停止社区版二进制分发，逐渐偏离纯粹的开源理念，向商业化战略倾斜。

一变开源协议：从Apache 2.0转为AGPLv3，理由：防止“白嫖”行为

如前所述，MinIO最初采用Apache 2.0，允许用户自由使用、修改和再发布。

2019年，MinIO决定将开源协议改为AGPLv3，要求使用者在提供服务时必须开放自己的源代码。

此举的背景是，随着项目知名度提升，部分大公司可能直接拿MinIO做商业SaaS或云服务，却几乎不向社区回馈，这让MinIO的维护方面临巨大资源压力。变更协议，也是希望保障项目利益和社区贡献。

在争议声中，MinIO最终于2021年完成了协议变更。

二变功能范围：将部分功能从开源版移除，迁移至商业版本

今年5月，MinIO团队再次“出手”。他们在当时的MinIO CE版本中删除了控制台管理功能，理由依然是：一方面为降低免费版本的维护成本，另一方面推动企业版商业化，让开发团队能更聚焦于核心存储功能和性能优化。

当时，社区版用户仍可通过源码自行构建控制台或借助第三方工具，但官方不再提供现成的管理界面。

三变开源支持范围：停止社区版二进制分发

到了今年10月，我们曾报道过，MinIO官方作出了“停止分发免费的Docker镜像”的决定。

当时，官方在MinIOGitHub项目的README中写道：

仅源码分发

重要提示：MinIO社区版现在仅以源码形式分发。我们将不再提供社区版的预编译二进制版本。

安装最新版MinIO社区版

使用MinIO社区版有两种方式：

1. 从源码安装（推荐）：go install github.com/minio/minio@latest

2. 使用提供的Dockerfile构建Docker镜像

旧版二进制发布

历史的预编译二进制版本仍可作为参考使用，但不再维护：

• GitHub Releases: https://github.com/minio/minio/releases
• 直接下载: https://dl.min.io/server/minio/release/

这些旧版二进制不会再收到更新。我们强烈建议使用源码构建，以获得最新功能、漏洞修复和安全更新。

MinIO宣布进入“维护模式”：这意味着什么？

如今，这算是MinIO第四次，应该也是最后一次对这个开源项目的发展方向作出调整——直接进入“维护模式”。

在传统开源项目的语境下，“维护模式”意味着开发重心从持续推出新功能，转向确保现有功能的稳定可靠。

一个开源项目进入「维护模式」，通常有多重原因：

1. 项目成熟：功能稳定，已能满足大部分用户需求。
2. 开发者资源有限：原作者或核心团队希望减少精力投入，或将注意力转向新项目。
3. 生态被替代：新技术或框架出现，原项目不再是首选，但仍有少部分用户在使用。
4. 战略选择：避免频繁更新带来的不稳定风险。

那么，MinIO进入「维护模式」属于哪一种情况？

在GitHub上，MinIO官方给出了明确说明——

该项目目前处于维护状态，不再接受新的更改：

• 代码库仅进行维护性更新
• 不会接收新的功能、增强或Pull Request
• 关键的安全修复可能会根据具体情况进行评估
• 现有的issue和Pull Request将不再被主动处理
• 社区支持将通过Slack以尽力而为的方式继续提供

如需企业级支持和仍在积极维护的版本，请查看MinIO AIStor

其中最后一句成为众人关注的焦点，这也让外界意识到，一切终究还是向商业化靠拢了。

简单来看，MinIO AIStor是商业/企业级版本，需要订阅服务。每年费用为$96,000，可管理400TB数据。

开源 vs 商业

归根结底，这是开源与商业可持续性之间长期存在的矛盾。

对于MinIO官方的操作，不少人并不感到意外：

不过，这几乎也为MinIO 11年的开源生涯画上了句号：

对此，行业从业者的看法大致呈现三派，有人表示理解MinIO的选择，应心怀感激：

对于免费的开源项目，你首先要明白：有人花时间和精力为你提供软件，却不求任何回报，你就应该心怀感激。你不应该感到“心里不舒服”或有怨言。如果希望这个项目能够继续下去，就应该投入自己的时间或金钱去支持它。

也有开发者持批评态度：

• Linux基金会版的Fork很快就会出现。MinIO可能会在1–2年内回归开源，但那时已经太晚了：社区会继续向前，不会再回头，他们的声誉也将永远失去。
• Richard Stallman（自由软件之父）当年说得没错。开发者社区到底什么时候才能吸取教训，不要再为这些带有糟糕CLA的项目贡献代码？这次就是被人“抽梯子”了。

还有用户愤怒抨击：“真是好一出大戏。把你商业产品背后的开源项目（许多人为其贡献过）直接EOL（终止支持），然后把它变成一个闭源的MinIO AIStor……说真的，这也太离谱了吧……”

更有开发者从法律角度提出质疑：

• “我没有向MinIO贡献过代码，但如果他们在没有让外部贡献者签署CLA的情况下接受了外部贡献，那么在更改许可证之前，必须征得每位外部贡献者对许可证变更的同意。既然是AGPL，他们仍然必须在某处提供源代码。”
• “有人知道MinIO AIStor的法律状况是否合规吗？据我所知，MinIO并没有采用CLA（贡献者许可协议），而在Git提交历史中有559名邮箱非@minio.io的提交作者。如果他们在更改许可证时没有获得这些贡献者的授权，那可能会构成AGPL的违规。或者，AIStor是一个从零重新编写的全新代码库？”

与此同时，也有人开始推荐替代方案，为当前用户提供更多选择。

「非常感谢MinIO、RustFS和Garage的贡献。话虽如此，MinIO如此突然地关上开源大门，确实让社区受到了惊吓。但说实话，这也算情有可原——开源项目最终都需要找到商业化路径。

我分别评估过RustFS和Garage，情况大致如下：

• 发布节奏：Garage的更新节奏稍慢，而RustFS几乎是每周都有更新。
• 许可证：Garage使用AGPLv3，而RustFS采用Apache许可证（这一点对企业采纳来说非常关键）。
• 稳定性：在分布式环境中，目前Garage略胜一筹。

随着MinIO基本退出开源竞争，我更看好RustFS能后来居上。」

最终，MinIO的操作，也让很多人对开源的信任产生了动摇——当曾经免费、开放的项目开始商业化，我们还能像从前那样放心依赖吗？

参考：

https://github.com/minio/minio

https://www.reddit.com/r/selfhosted/comments/1pd97nq/minio_is_in_maintenance_mode_and_is_no_longer/

https://news.ycombinator.com/item?id=46136023