[HN Gopher] MinIO Is Dead, Long Live MinIO
___________________________________________________________________
MinIO Is Dead, Long Live MinIO
Author : zufallsheld
Score : 104 points
Date : 2026-02-28 21:16 UTC (1 hours ago)
(HTM) web link (blog.vonng.com)
(TXT) w3m dump (blog.vonng.com)
| seneca wrote:
| I very much appreciate the sentiment, and wish him well. However,
| one guy maintaining a fork as a side project from his core work
| is not very promising.
|
| He seems to believe AI will help lessen the burden. I hope he's
| able to find other maintainers.
|
| Best luck!
| dijit wrote:
| To be fair, most open source is like that.
|
| The most famous one I can think of right now is xz.
| InsideOutSanta wrote:
| A vastly less complex project whose maintainer burned out.
| You're not wrong, but this only underlines how unsustainable
| this is.
| BadBadJellyBean wrote:
| I am wondering if Minio Inc has rewritten the software in a clean
| room. Otherwise wouldn't they need to publish the source anyways?
| Since it is AGPL anyone might potentially be interacting with the
| software. Do they do that?
| Macha wrote:
| The copyright for Minio consists of:
|
| - Code written by the Minio team, which they have full
| ownership of and can relicense as they wish
|
| - Code written by third party contributors, where Minio
| required the contributors to provide Minio a BSD license to use
| the contributions but only published it to other people under
| AGPL.
|
| So the AGPL doesn't bind Minio themselves because of their
| licensing policy. (Which is why while pure AGPL might be the
| open source maximalist license, AGPL + CLA is almost at the
| opposite end of the scale)
| phoronixrly wrote:
| Was going to mention the CLA. Each time you sign a CLA you're
| doing free work. Never do that. Keep and maintain your
| patches locally instead.
| bigfatkitten wrote:
| Sometimes that's far more work than it'll ever be worth.
|
| If I get my patches upstream, then I don't have to waste
| time reintegrating patches and rebuilding packages when I
| could instead be doing productive things.
| rzerowan wrote:
| Question , can MinIO the company assert AGPL copyright
| against the fork - i see in the writeup they mentioned
| trademarks as far as the fork is concerned.
|
| Whats the situation for a AGPL fork , were one to use it can
| the company assert rights like they did to Nutanix.
| Macha wrote:
| As long as the fork complies with the terms of the AGPL,
| Minio can't stop them from using the code. As the article
| acknowledge,s hey could potentially rely on trademarks to
| make them rename it.
| throawayonthe wrote:
| the FSF position is that GPL is unenforceable without a
| single copyright owner, which is why almost all gnu projects,
| linux, canonical/redhat/etc projects have a CLA or something
| functionally similar
| Macha wrote:
| That would seem a bizarre position from the FSF, since it
| would make the license on combined GPL works unenforceable.
| Do you have a source for that?
| patmorgan23 wrote:
| Doesn't that depend on the CLA?
|
| Could you not have a CLA that only allows the project to use
| a specific license?
| Macha wrote:
| You could, but the reason that companies ask for CLAs is to
| free themselves by that restriction.
|
| If Minio just wanted to use the changes under AGPL, the
| contributor could just license them under AGPL, no CLA
| needed.
| tfolbrecht wrote:
| Only if they'd taken contributions without authors signing over
| their rights.
| polskibus wrote:
| Surely MinIO dual-licenses its software so paying customers get
| commercial license?
| gionn wrote:
| How could the company behind minio not seeing this coming?
| PunchyHamster wrote:
| Seeing what coming ? They pivoted into storage for AI, lone
| maintainer is not threat to their business model
| dijit wrote:
| Still, I would probably abandon the name for trademark
| enforcement reasons. It's low hanging fruit for them if they
| want to kill you.
|
| (this is also why the Pentium was called the Pentium instead
| of the numbers that processors used to be called.. and why
| the gameboy copyright text was embedded into the ROMs)
| awesan wrote:
| It's nice that people are taking this up, and one of the main
| benefits of open source in the first place. I have my doubts that
| this will succeed if it's just one guy, but maybe it takes on new
| life this way and I would never discourage people from trying to
| add value to this world.
|
| That said I increasingly have a very strong distaste of these AI
| generated articles. They are long and tedious to read and it
| really makes me doubt that what is written there is actually true
| at all. I much prefer a worse written but to the point article.
| Aurornis wrote:
| I agree completely. I know everyone is tired of AI accusations
| but this article has all of the telltale signs of LLM writing
| over and over again.
|
| It's not encouraging for the future of a project when the
| maintainer can't even announce it without having AI do the
| work.
|
| It would be great if this turns into a high effort, carefully
| maintained fork. At the moment I'm highly skeptical of new
| forks from maintainers who are keen on using a lot of AI.
| kjuulh wrote:
| Seems like a very balanced take on forking Minio. I don't have
| high hopes for the future Minio, but as mentioned it is more or
| less feature complete, good enough for most use-cases.
|
| I was searching for a fairly simple replacement for s3 for
| testing. I'd been using Minio for a while now, and simply ended
| up implementing my own on top of Postgres. Fun intersection given
| the post. (Note, I know it isn't optimal, but as I always have
| Postgres available it fits well, and I don't have high storage
| needs, just the api compatibility)
| gbcfghhjj wrote:
| I've been using garage without issue
| bigfatkitten wrote:
| For our needs at work (~100TB), buying Pure Storage flash
| arrays (hardware, software, onsite support) worked out cheaper
| than MinIO licensing alone.
| boulos wrote:
| Maybe the author isn't aware that Chainguard is going to keep
| patching MinIO for CVEs:
|
| https://www.chainguard.dev/unchained/secure-and-free-minio-c...
|
| You wouldn't get the other changes in this post (e.g., restoring
| the admin console) but that's a bit orthogonal.
| aljarry wrote:
| There are 3 new commits, and the only actually fixes are: Go
| update and revert to earlier version of console.
|
| But there are a bunch of changes to docs, CI workflows and issue
| templates. Which is what is the easy part of managing a fork, and
| I've seen a bunch of forks that ended up only updating readme-s,
| CI, etc.
|
| I'll have more faith in the fork when the maintainers do actual
| fixes.
| NewJazz wrote:
| Although, to be fair, getting too aggressive off the bat would
| be concerning. A clean fork that is bit for bit compatible with
| the last open source version is definitely an attractive
| proposition from a software supply chain perspective.
| gbcfghhjj wrote:
| Wish the effort well. I has plans to self host s3 with minio that
| took some time to actually get around to and when I did they had
| done the enterprise rug pull. I do think one maintainer may be
| able to pull it off with AI assistance if the scope is limited to
| security bug fixes. Minio is one of the nastiest rug pulls I can
| think of.
| Aurornis wrote:
| It's nice to see people taking this on, but for a project like
| this I'd prefer to wait and see if the maintenance continues.
|
| This blog post is extremely heavy on LLM written content, which
| isn't a promising early sign
|
| > Normally this is where the story ends -- a collective sigh, and
| everyone moves on.
|
| > But I want to tell a different story. Not an obituary -- a
| resurrection.
|
| I've seen several announcements of forked open source projects
| from people who thought that maintaining a fork is easy now that
| they can have an LLM do all the work. Then their interest trails
| off when they encounter problems the AI can't handle for them or
| the community tires of doing all of the testing and code review
| for a maintainer who just wants to prompt the LLM and put their
| name on the project. When someone can't even write their own
| announcement without an LLM it's not an encouraging sign.
| holysoles wrote:
| I'll plug that Chainguard has been maintaining a fork for awhile
| and seems to have a history with supporting forks like this:
| https://github.com/chainguard-forks/minio
|
| For a web GUI, I had been using this project:
| https://github.com/huncrys/minio-console
|
| I switched to rustfs this week though and am not looking back.
| I'd recommend it to others as well for small scale usage. Its
| maturing rapidly and seems promising.
| paxys wrote:
| > MinIO as an S3-compatible object store is already feature-
| complete. It's finished software.
|
| I don't see how these two lines can be written together.
|
| The goal is either to remain S3-compatible or to freeze the
| current interface of the service forever.
|
| As it stands this fork's compatibility with S3, and with the
| official MinIO itself, will break as soon as one of them pushes
| an API update. Which works fine for existing users, maybe, but
| over time as the projects drift further apart no new ones will be
| able to onboard.
___________________________________________________________________
(page generated 2026-02-28 23:00 UTC)