Looking at the change to the README last week[1], it looks like MinIO went from "MinIO has no planned or scheduled releases for this repository" and "
While a new release may be cut at any time, there is no timeline for when a subsequent release may occur." to "The MinIO community edition is now distributed as source code only".
Based on promises alone, I think that means they un-dropped the open source project but still only distribute the binaries to their customers.
Keep in mind this is the same project that removed all useful functionality from the included web UI in the community edition with the excuse that it was too much effort to maintain.
This is another case of VC-funded companies pulling up the ladder behind themselves.
I'm glad to have migrated to garage in time. This is quite unfortunate though as a lot of open source projects, like plane.so, used minio via container images for s3 with docker compose.
It's an Open Source project - I don't understand what people are complaining about. Noone is entitled to receive free Docker images. I'm sure if there is enough demand, someone else who is trustworthy will step up and automate building them.
What I'd like to complain about instead is the pricing page on the Min.io webpage - it doesn't list any pricing. Looking at https://cloudian.com/blog/minios-ui-removal-leaves-organizat... it seems the prices are not cheap at all (minimum of $96,000 per year). Note that Cloudian is a competitor offering a closed-source product.
MinIO is not actually open source, their source code is just public.
The company I work at spun up a MinIO instance, and we got hounded by MinIO lawyers claiming we had to pay because "hosting MinIO alters the source because of injecting configuration" and therefore violates their open source license.
There have been multiple hacker news threads about this:
1. The MinIO image on Docker Hub has more than a billion downloads [^0]. With those download counts, people have almost certainly written scripts that rely on this image existing (including their own Dockerfile! [^1]). Them leaving these images around is just asking for security breaches later down the line.
1b. While, yes, no-one's entitled to freely-available container images, it cost them almost nothing to maintain their existing toolchain for this. Them deciding to pull the plug is purely and entirely a money grab (and a dumb one, if you ask me; look at how the community responded with OpenTofu when Terraform when BUSL).
2. Fortunately, MinIO is a Golang app and can be built with a simple "go install" (though the build instructions in their docs don't align with the build recipe in their Makefile [^2]). However, they could pull a Tesla and make the source that they publish differ from the source that their binaries are built from.
3. They gave NO notice. That's the slimiest part of all of this. Tens of thousands of Kubernetes clusters, and handfuls of enterprise products, run or package MinIO that are now using images that will no longer be updated. All of these people will need to completely change their toolchains to account for that, and soon. That's just not a kind thing to do.
Years ago I worked in customer service. There was this guy who came in to to motivate us. He talked about the work of someone named Bob Farrell who had a chain of ice cream shops and sold burgers. He had received a letter from a disappointed customer. The customer had been given the extra pickles on his burgers for years and now one of Bob's employees told him he now had to pay extra for it. The customer said he'd never come back. Bob could have said "what an entitled idiot" and kept charging for pickles but he took that letter as a calling for how you should treat customers - just give 'em the pickle. It costs you next to nothing to give the customer the pickle and it makes them happy.
Minio doesn't have to give non-paying users anything, but the story still applies. Give them the pickle. It costs nothing in the grand scheme of things, and if it does, ask for donations like any open source project would do to cover your costs. But as others have pointed out, Minio is not an open source company, they are a commercial company that has source available.
While not notifying of the change earlier is annoying, I also don't see anywhere stated that they're obligated to provide services in addition to just providing me the source. Moreover the build-instructions don't seem complicated at all, anyone already extracting value from this should be capable of pulling the source and keep on running with it.
Shame. Textbook OSS rug pull. These people love to rely on OSS, and claim how committed they are to contribute to the ecosystem and to their community, but as soon as people are drawn to the project, start relying on it and using it in the same spirit of OSS that they enjoy themselves (which their chosen license allows, mind you), then it becomes a financial burden, priorities shift to their commercial offering, there's no "bandwidth" to maintain and support the "community" edition, and so on.
STOP ABUSING OSS AS A MARKETING GIMMICK.
Or perhaps an advice to people who might actually listen: stop being attracted to open source projects because of the word "open", and because you can use it gratis. There are plenty of good proprietary and commercial software whose authors treat their users with more respect than these leeches of good will and abusers of trust.
I'm not against OSS being commercialized. In fact, I think that it's crucial for maintaining a healthy project in the long-term[1][2]. But this lingers on the developer having respect and equal regard for all their users, regardless of how much they're paying them. Yes, nobody working on software should be expected to work for free. But there is a philosophy behind this movement that goes beyond a financial transaction. It only works if everyone in the ecosystem is honest, and first and foremost has the intention of making the world a better place for everyone, by not only depending on others who have this mindset, but by adopting it themselves. Claiming to be part of the OSS community, but being hostile to your OSS users is dishonest at best, and worthy of all criticism.
We're working on a binary build process now. We hope to have something up at https://github.com/golithus soon.
We use MinIO (community edition) a fair amount. And while we like it, it is also becoming increasingly clear that our days of deploying are numbered.
We want to start experimenting with Garage for smaller deployments, and would be interesting to hear of any production experiences there. (Anyone done multi-PiB deployments?)
Other than that we're going to start looking at Ceph/Rook for larger deployments.
The title of the HN submission might look a bit misleading. It's easy to misinterpret it and think MinIO stops being open source (which would be a bigger deal IMHO).
I think this would be better: "MinIO stops distributing free Docker images"
While I understand the frustration with MinIO’s approach here, I want to be upfront about what Cloudian HyperStore is and isn’t - it is designed for multi-node, multi-site deployments (think 3+ nodes minimum) and performs best on bare metal or dedicated infrastructure rather than containerized environments.
It’s a very mature S3 and offers IAM, SQS and STS endpoints as well.
If you’re running MinIO at scale in production and looking at migration options, I’m happy to connect you with our team who can discuss whether HyperStore makes sense for your use case.
That said, for single-node dev environments or lightweight deployments that many here are using MinIO for, the community alternatives mentioned in this thread are probably better fits. Different tools for different scales.
Happy to answer any technical questions about HyperStore’s architecture if helpful.
The latest release is already available on ghcr and on dockerhub for amd and arm.
Well they have locked the discussion right now it seems but hope the community does something since my brother once asked for how to store audio and I thought that something like S3 could be perfect for it and wanted him to use minio or check it out.
Just make a fork and release built images via github actions with ghcr. Then ask people to switch to it.
The great thing about open src is the ability to walk away. removed features in new release? fork and put it back. quit complaining and be the change the world needs you to be
115 comments
[ 3.3 ms ] story [ 104 ms ] threadBased on promises alone, I think that means they un-dropped the open source project but still only distribute the binaries to their customers.
[1]: https://github.com/minio/minio/commit/9e49d5e7a648f00e26f224...
https://git.deuxfleurs.fr/Deuxfleurs/garage
This is another case of VC-funded companies pulling up the ladder behind themselves.
What I'd like to complain about instead is the pricing page on the Min.io webpage - it doesn't list any pricing. Looking at https://cloudian.com/blog/minios-ui-removal-leaves-organizat... it seems the prices are not cheap at all (minimum of $96,000 per year). Note that Cloudian is a competitor offering a closed-source product.
The company I work at spun up a MinIO instance, and we got hounded by MinIO lawyers claiming we had to pay because "hosting MinIO alters the source because of injecting configuration" and therefore violates their open source license.
There have been multiple hacker news threads about this:
- https://news.ycombinator.com/item?id=35328316
- https://news.ycombinator.com/item?id=32148007
1. The MinIO image on Docker Hub has more than a billion downloads [^0]. With those download counts, people have almost certainly written scripts that rely on this image existing (including their own Dockerfile! [^1]). Them leaving these images around is just asking for security breaches later down the line.
1b. While, yes, no-one's entitled to freely-available container images, it cost them almost nothing to maintain their existing toolchain for this. Them deciding to pull the plug is purely and entirely a money grab (and a dumb one, if you ask me; look at how the community responded with OpenTofu when Terraform when BUSL).
2. Fortunately, MinIO is a Golang app and can be built with a simple "go install" (though the build instructions in their docs don't align with the build recipe in their Makefile [^2]). However, they could pull a Tesla and make the source that they publish differ from the source that their binaries are built from.
3. They gave NO notice. That's the slimiest part of all of this. Tens of thousands of Kubernetes clusters, and handfuls of enterprise products, run or package MinIO that are now using images that will no longer be updated. All of these people will need to completely change their toolchains to account for that, and soon. That's just not a kind thing to do.
[^0] https://hub.docker.com/r/minio/minio/tags
[^1] https://github.com/minio/minio/blob/master/Dockerfile
[^2] https://github.com/minio/minio/blob/master/Makefile#L179
Minio doesn't have to give non-paying users anything, but the story still applies. Give them the pickle. It costs nothing in the grand scheme of things, and if it does, ask for donations like any open source project would do to cover your costs. But as others have pointed out, Minio is not an open source company, they are a commercial company that has source available.
At least that's all we use it for really
STOP ABUSING OSS AS A MARKETING GIMMICK.
Or perhaps an advice to people who might actually listen: stop being attracted to open source projects because of the word "open", and because you can use it gratis. There are plenty of good proprietary and commercial software whose authors treat their users with more respect than these leeches of good will and abusers of trust.
I'm not against OSS being commercialized. In fact, I think that it's crucial for maintaining a healthy project in the long-term[1][2]. But this lingers on the developer having respect and equal regard for all their users, regardless of how much they're paying them. Yes, nobody working on software should be expected to work for free. But there is a philosophy behind this movement that goes beyond a financial transaction. It only works if everyone in the ecosystem is honest, and first and foremost has the intention of making the world a better place for everyone, by not only depending on others who have this mindset, but by adopting it themselves. Claiming to be part of the OSS community, but being hostile to your OSS users is dishonest at best, and worthy of all criticism.
[1]: https://news.ycombinator.com/item?id=45540307
[2]: https://news.ycombinator.com/item?id=45537750
We use MinIO (community edition) a fair amount. And while we like it, it is also becoming increasingly clear that our days of deploying are numbered.
We want to start experimenting with Garage for smaller deployments, and would be interesting to hear of any production experiences there. (Anyone done multi-PiB deployments?)
Other than that we're going to start looking at Ceph/Rook for larger deployments.
seriously, minio sucks perf wise but they really did a good job making it easy to deploy with docker
I think this would be better: "MinIO stops distributing free Docker images"
---
See also the relevant README section: https://github.com/minio/minio?tab=readme-ov-file#source-onl...
While I understand the frustration with MinIO’s approach here, I want to be upfront about what Cloudian HyperStore is and isn’t - it is designed for multi-node, multi-site deployments (think 3+ nodes minimum) and performs best on bare metal or dedicated infrastructure rather than containerized environments.
It’s a very mature S3 and offers IAM, SQS and STS endpoints as well.
If you’re running MinIO at scale in production and looking at migration options, I’m happy to connect you with our team who can discuss whether HyperStore makes sense for your use case. That said, for single-node dev environments or lightweight deployments that many here are using MinIO for, the community alternatives mentioned in this thread are probably better fits. Different tools for different scales. Happy to answer any technical questions about HyperStore’s architecture if helpful.
I was reading the github discussion and found out that coollabs has taken on the decision to make docker images for these.
https://github.com/coollabsio/minio
https://github.com/minio/minio/issues/21647#issuecomment-342...
>Until we (the community) figure out something, I made an automated docker image version here: https://github.com/coollabsio/minio
The latest release is already available on ghcr and on dockerhub for amd and arm.
Well they have locked the discussion right now it seems but hope the community does something since my brother once asked for how to store audio and I thought that something like S3 could be perfect for it and wanted him to use minio or check it out.
Idk what I will recommend now? Garage? Seaweedfs?
The great thing about open src is the ability to walk away. removed features in new release? fork and put it back. quit complaining and be the change the world needs you to be