Maintainer of Milvus here. A few thoughts from someone who lives this every day:

  1. The free user problem is real, and AI makes it worse. We serve a massive community of free Milvus users — and we're grateful for them, they make the project what it is. But we also feel the tension MinIO is describing. You invest serious engineering effort into stability and bug fixes, and most users will never become paying customers. In the AI era this ratio only gets harder — copy with AI becomes easier than ever

  2. We need better object storage options. As a heavy consumer of object storage, Milvus needs a reliable, performant, and truly open foundation. RustFS is a solid candidate — we've been evaluating it seriously. But we'd love to see more good options emerge. If the ecosystem can't meet our needs long-term, we may have to invest in building our own.

  3. Open source licensing deserves a serious conversation. The Apache 2.0 / Hadoop-era model served us well, but cracks are showing. Cloud vendors and AI companies consume enormous amounts of open-source infrastructure, and the incentives to contribute back are weaker than ever. I don't think the answer is closing the source — but I also don't think "hope enterprises pay for support" scales forever. We need the community to have an honest conversation about what sustainable open source looks like in the AI era. MinIO's move is a symptom worth paying attention to.

It’s been amazing to watch Milvus grow from its roots in China to gaining global trust and major VC backing. You've really nailed the commercialization, open-source governance, and international credibility aspects.

Regarding RustFS, I think that—much like Milvus in the early days—it just needs time to earn global trust. With storage and databases, trust is built over years; users are naturally hesitant to do large-scale replacements without that long track record.

Haha, maybe Milvus should just acquire RustFS? That would certainly make us feel a lot safer using it!

Unfortunately, a majority seems to hate GPL these days even though it prevents most of the worst corporate behaviors.

You’re right about the "tension" in OSS. That’s exactly why we are pledging to keeping the RustFS core engine permanently open-source. We want to provide the solid, open foundation you mentioned so that teams like yours don't feel forced to build and maintain a storage layer from scratch.

On the sustainability question—you've described the challenge better than most. We're still figuring out the right model, and I don't think anyone has a perfect answer yet. What we do know is that we're building something technically excellent first, and we're committed to doing it in a way that keeps the core open.

1. Download or build the single binary into your system (install like `/usr/local/sbin/garage`)

2. Create a file `/etc/garage.toml`:

  metadata_dir = "/data/garage/meta"
  data_dir = "/data/garage/data"
  db_engine = "sqlite"
  
  replication_factor = 1
  
  rpc_bind_addr = "[::]:3901"
  rpc_public_addr = "127.0.0.1:3901"
  rpc_secret = "[your rpc secret]"
  
  [s3_api]
  s3_region = "garage"
  api_bind_addr = "[::]:3900"
  root_domain = ".s3.garage.localhost"
  
  [s3_web]
  bind_addr = "[::]:3902"
  root_domain = ".web.garage.localhost"
  index = "index.html"
  
  [k2v_api]
  api_bind_addr = "[::]:3904"
  
  [admin]
  api_bind_addr = "[::]:3903"
  admin_token = "woG4Czw6957vNTXNfLABdCzI13NTP94M+qWENXUBThw="
  metrics_token = "3dRhgCRQQSxfplmYD+g1UTEZWT9qJBIsI56jDFy0VQU="

Also, NVIDIA has a phenomenal S3 compatible system that nobody seems to know about named AIStore: https://aistore.nvidia.com/ It's a bit more complex, but very powerful and fast (faster than MinIO - slightly less space efficient than MinIO because it maintains a complete copy of an object on a single node so that the object doesn't have to be reconstituted as it would on MinIO.) It also can be a proxy in front of other S3 systems, including AWS S3 or GCS etc and offer a single unified namespace to your clients.

IMO, Seaweedfs is still too much of a personal project, it's fast for small files, but keep good and frequent backups in a different system if you choose it.

I personally will avoid RustFS. Even if it was totally amazing, the Contributor License Agreement makes me feel like we're getting into the whole Minio rug-pull situation all over again, and you know what they say about doing the same thing and expecting a different result..

[1] https://garagehq.deuxfleurs.fr/documentation/cookbook/real-w... [2] https://www.symas.com/mdb [3] https://www.openldap.org/

I might extend this with ZeroFS too.

I could see running Aistore in single binary mode for small deployments, but for anything large and production grade I would not touch Aistore. Ceph is going to be the better option IMO, it is a truly collaborative open source project developed by multiple companies with a long track record.

What legal risks does it help mitigate?

While DCO is excellent for tracking provenance, we opted for a CLA primarily to address explicit patent grants and sublicensing rights—areas where a standard DCO often lacks the comprehensive legal coverage that a formal agreement provides.

It’s a common and sustainable practice in the industry to keep the core code open-source while developing enterprise features. Without a solid CLA in place, a project faces massive legal hurdles later on—whether that’s for future commercialization or even the eventual donation of the project to an open-source foundation like the CNCF or Apache Foundation. We're just trying to ensure long-term legal clarity for everyone involved.

My focus on the CLA is about building a solid foundation for RustFS so it doesn't face the licensing "re-branding" drama we've seen with other storage projects recently. It’s about long-term stability for the community, not just a marketing ploy.

We’ve officially updated the CLA to a standard License Grant model. Under these new terms, you retain full ownership of your contributions, and only grant us a non-exclusive license to use them. You can check the updated CLA here: https://github.com/rustfs/rustfs/blob/main/CLA.md.

More importantly, the RustFS team is officially pledging to keep our core repository permanently open-source. We are committed to an open-core engine for the long term, not a "bait and switch."

  Subject to the terms and conditions of this Agreement, You hereby grant to RustFS and to recipients of software distributed by RustFS a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works under any license, including proprietary or commercial licenses and open-source licenses, at RustFS's sole discretion.

That's an odd take... open source is a software licensing model, not a business model.

Unless you have some knowledge that I don't, MinIO never asked for nor accepted donations from users of their open source offerings. All of their funding came from sales and support of their enterprise products, not their open source one. They are shutting down their own contributions to the open source code in order to focus on their closed enterprise products, not due to lack of community engagement or (as already mentioned) community funding.

You mean like Linux, Python, PostgreSQL, Apache HTTP Server, Node.js, MariaDB, GNU Bash, GNU Coreutils, SQLite, VLC, LibreOffice, OpenSSH?

Uh, no, OpenAI didn't pivot from being open in order to survive.

They survived for 7 years before ChatGPT was released. When it was, they pivoted the _instant_ it became obvious that AI was about to be a trillion-dollar industry and they weren't going to miss the boat of commercialization. Yachts don't buy themselves, you know!

No but open source rugpulls do!

Not many open source projects are Linux-sized. Linux is worth billions of dollars and enabled Google and Redhat to exist, so they can give back millions, without compulsion, and in a self-interested way.

Random library maintainer dude should not expect their (very replaceable) library to print money. The cool open source tool/utility could be a 10-person company, maybe 100 tops, but people see dollar-signs in their eyes based on number of installs/GitHub stars, and get VC funding to take a swing for billions in ARR.

I remember when (small scale) open source was about scratching your own itch without making it a startup via user-coercion. It feels like the 'Open source as a growth-hack" has metastasized into "Now that they are hooked, entire user base is morally obligated to give me money". I would have no issue if a project included this before it gets popular - but that may prevent popular adoption. So it rubs me the wrong way when folk want to have their cake and eat it.

Yes, open-source is a software license model, not a business model. It is also not a software support model.

This change is them essentially declaring that MinIO is EOL and will not have any further updates.

For comparison, Windows 10 which is a paid software released in the same year as first minio release i.e. 2015 is already EOL.

Just fork it!

AGPL means you cannot do this. This is less of a risk, than it is the explicit intention of the Licence.

MinIO was more for the "mini" use case (or more like "anything not large scale", with a very broad definition of large scale). Here "works out of the box" is paramount.

And Ceph is more for the maxi use case. Here in depth fine tuning, highly complex setups, distributed setups and similar are the norm. Hence out of the box small scale setup experience is bearly relevant.

So they really don't fill out the same space, even through their functionality overlaps.

I'm not sure if SeaweedFS is comparable. It's based on Facebook's Haystack design, which is used to address a very specific use case: minimizing IO, in particular the metadata lookup, to access individual objects. This leads to many trade-offs. For instance, its main unit of operations is on volumes. Data is appended to a volume. Erasure coding is done per volume. Updates are done at volume level, and etc.

On the other hand, a general object store goes beyond needle-in-a-haystack type of operations. In particular, people use an object store as the backend for analytics, which requires high-throughput scans.

Claude Code is amazing at managing Ceph, restoring, fixing CRUSH maps, etc. It's got all the Ceph motions down to a tee.

With the tools at our disposal nowadays, saying "I wouldn't dare deploy it without a deep understanding of the source code" seems like an overexaggeration!

I encourage folks to try out Ceph if it supports their usecase.

In my experience, SeaweedFS has at least 3–5× better performance than MinIO. I used MinIO to host 100 TB of images to serve millions of users daily.