From the product side, I don't see how this should affect new adopters who didn't read the hn post yesterday
From the product side, I don't see how this should affect new adopters who didn't read the hn post yesterday
It's not changing the fact that it's too premature to reflect on public adoption at this moment.
Just to clarify, I'm not affiliated with or protecting MinIO, I don't know anything about this software. But it seems to me that there's some overreaction about Docker here, and in reality it is highly possible that this decision might not affect the product the way it's being discussed these days.
In other words, what is the significant difference for your team that's worth changing the stack and navigating through the uncertainty of an alternative product?
It's hard to feel good about remaining hitched to a horse that continues to send out red flags, especially when there are other good options out there for us.
However, I also understand that for any organization it is very painful to change their existing stack, thus I'm trying to understand what is gained between AGPL sources without Docker and switching technology to something different with Docker except 'ease of setup'.
Building something on your own on the other hand is probably easily a half-time engineer just for build quality and dependency tracking.
Huge number of MinIO shops is one head node and 7 jbods in a single rack (giving you more thsn 10PB). And two such racks for redundancy and one offside rack for backup.
Open source means what the license says it means. Expectations and conventions can be broken.
For me open source is a license, and Docker is a distribution feature. From this prospective I can not understand how distributional channel and type of license are related, as code is still AGPL.
And by removing docker images, they are intentionally making open source version a badly engineered version.