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.

Garage installation is easy.

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..

> RustFS and SeaweedFS are the fastest in the object storage field.

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 the IOs, in particular the metadata lookup, for accessing 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.

> Although many people criticize RustFS, suggesting its CLA might be "bait," I don't think such a requirement is excessive for open source software, as it helps mitigate their own legal risks.

What legal risks does it help mitigate?

> 4. Ceph [...]

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.

> too many people globally who use open source without being willing to pay for it.

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.

I want to like RustFS, but it feels like there's so much marketing attached to the software it turns me off a little. Even a little rocket emoji and benchmark in the Github about page. Sometimes less is more. Look at the ty Github home page - 1 benchmark on the main page, the description is just "An extremely fast Python type checker and language server, written in Rust.".

Gosh, Ceph what a pita. Never again LOL. I wouldn't even want an LLM to suffer working on it.