Flight record about MinIO

I wanted to leave a small flight record for my future self about what happened to MinIO.

By the time I reread this, it will be old news. That is fine. This is less about the timeline and more about what it reminded me about my own preferences.

I recently wrote about a data-first view of systems, where programs are transient and data is the center of gravity. What happened with MinIO is, in a small way, a practical example of why that perspective matters to me. MinIO moved its public project toward maintenance mode and is steering users toward a commercial offering whose codebase has diverged.

I understand why a company might do this. Sustainability, investor pressure, and the cost of maintaining popular software are real. But understanding the reasons does not automatically mean agreeing with the direction. From a user and ecosystem perspective, these shifts erode a bit of long-term trust. I can understand the move and still be uncomfortable with its consequences.

What I want to remember is why I liked it in the first place.

I was drawn to MinIO because of its very literal relationship with the filesystem. An object stored as foo.mp3 was, in simple deployments, a foo.mp3 on disk. For someone who thinks in snapshots, backups, and plain files, that felt reassuring. The data looked like data.

More than that: I like when a file is still a file and is in an open or documented format that can be decoded even after the original software disappears. The same applies on the network side. This is why open formats and open protocols matter so much to me in practice. Open formats on disk and open protocols on the wire are both part of the same mental model for me, as I already outlined in a previous post.

There are, of course, alternatives. Ceph, SeaweedFS, and Garage all make architectural choices that are rational for distributed systems. Chunking, internal layouts, and abstraction layers exist for good reasons.

I work with these systems professionally. They solve real problems at scale. This is not a critique of their design.

But this note is about my personal compass.

Even within Ceph, I notice my own bias. RADOS Gateway is the natural S3 layer, but in personal contexts I often feel drawn to CephFS. It is not perfect and not always the richest in features, yet the files appear as files. They can be inspected, copied, and even written to tape. I have done exactly that for a customer. That tangibility still matters to me.

Trust, for me, is not moral. It is practical.

When adopting a tool, I quietly ask:

• Will this still be usable in 10–15 years?
• If the project changes direction, can I still read my data?
• How painful is the exit?

Big communities help, but they are not a guarantee. Some small, boring, open tools last precisely because there is little commercial incentive to reshape them. Simplicity and openness can be their own form of longevity.

So this is the reminder to my future self:

Prefer formats that outlive tools.
Prefer protocols that remain understandable.
Assume any project can change direction.
Keep exits cheap and data readable.

If one day a tool disappears, I should still be able to reach my data without drama. That has always been the real philosophy.