
MinIO erneut wegen Entscheidung für reine Quellcode-Veröffentlichung in der Kritik
MinIO löst neue Kontroversen aus, indem es die Veröffentlichung von Binärdateien für seine Community Edition einstellt und die Nutzer nun selbst aus dem Quellcode kompilieren müssen.
Eine Übersetzung von 🇬🇧 Linuxiac.com
Während viele Projekte auf Open Source setzen, um ihre Community zu vergrößern, ihre Langlebigkeit zu sichern und ihre Produkte kontinuierlich zu verbessern, scheint MinIO, ein leistungsstarker Objektspeicherserver, der vollständig mit Amazon S3 kompatibel ist, den umgekehrten Weg einzuschlagen. Warum sage ich das?
Weil das MinIO-Team erneut eine Debatte in der Community ausgelöst hat, nachdem es stillschweigend die vorgefertigten Binärdateien für seine Community Edition eingestellt hat. Laut dem Projekt müssen Nutzer MinIO nun vollständig aus dem Quellcode erstellen – ein Schritt, den viele als Rückschlag für die Zugänglichkeit und die Open-Source-Zusammenarbeit betrachten.
Die Änderung wurde bekannt, nachdem Nutzer fehlende Docker- und Quay-Images bemerkt hatten. Dies wurde in einem GitHub-Issue bestätigt, in dem die MinIO-Betreuer erklärten, dass künftig nur noch „Source-Only-Distributionen” bereitgestellt werden.
Mit anderen Worten: Wenn Sie bisher die Docker-Images von MinIO für Ihre Bereitstellungen verwendet haben, müssen Sie diese ab sofort selbst erstellen. Diese Entscheidung hat viele Nutzer überrascht. Zum Hintergrund: Die Images von MinIO auf Docker Hub wurden über eine Milliarde Mal heruntergeladen – Sie können sich also vorstellen, wie viele Menschen von dieser Änderung betroffen sind.
Während das Unternehmen argumentiert, dass dies eine bessere Kontrolle und Compliance gewährleistet, sieht die Open-Source-Community dies anders und äußert Bedenken hinsichtlich der Offenheit und des Vertrauens in die Ausrichtung des Projekts. Viele langjährige Nutzer kritisieren die Entscheidung als einen weiteren Schritt weg von Transparenz und Open-Source-Prinzipien und als Komplikation für automatisierte Bereitstellungen und CI/CD-Workflows, die auf offiziellen Binärdateien basieren.
Tatsächlich ist dies bereits der zweite Schlag, den die Open-Source-Community von MinIO einstecken muss. Wie wir bereits berichtet hatten, hat das Unternehmen vor weniger als fünf Monaten fast alle nützlichen Tools aus der Admin-Webkonsole der Community-Version entfernt und sie nur für zahlende Kunden beibehalten.
Mit diesem jüngsten Schritt stellt sich erneut eine ernste Frage: Kann MinIO noch als zuverlässige Option für Open-Source-Communities angesehen werden, die auf die kostenlose Version angewiesen sind? Hier ist meine ehrliche, persönliche Meinung dazu.
Zum jetzigen Zeitpunkt ist es ziemlich klar, dass MinIO versucht, Nutzer seiner Community-Version zu entmutigen und sie zur kostenpflichtigen Version zu lenken, wobei es eine sehr feine Grenze zwischen Open Source und proprietärer Software beschreitet. Aus geschäftlicher Sicht mag das zwar verständlich sein, aber die Art und Weise, wie sie dabei vorgehen, hat für einige Verwunderung gesorgt.
Die Änderungen scheinen über Nacht zu kommen – ohne Transparenz, ohne Vorankündigung und ohne offizielle Ankündigungen. An einem Tag ist noch alles in Ordnung, und am nächsten stolpert man über einen beiläufigen Kommentar, der irgendwo in einem GitHub-Thread versteckt ist und eine große Veränderung offenbart.
Das sagt viel über die Haltung und Herangehensweise des Unternehmens gegenüber der Open-Source-Community aus. Sicher, MinIO hat sich einen guten Ruf aufgebaut und Millionen von Nutzern, die seinem Open-Source-Produkt vertrauen. Aber diesen Erfolg in eine Monetarisierungsstrategie umzuwandeln, könnte sich als zweischneidiges Schwert erweisen.
Angesichts der Unvorhersehbarkeit der jüngsten Maßnahmen des Unternehmens sollten Open-Source-Enthusiasten oder kleine Unternehmen, die auf MinIO angewiesen sind, vielleicht überdenken, wie zuverlässig die weitere Nutzung dieser Software wirklich ist.
Die gute Nachricht ist, dass es großartige, vollständig Open-Source-basierte Alternativen gibt – wie Garage oder RustFS –, die einen Blick wert sind, wenn Sie über eine Migration von Ihrer aktuellen MinIO-Konfiguration nachdenken.
🏁 Zusammenfassend lässt sich also sagen, dass Nutzer, die auf die vorkompilierten Builds von MinIO angewiesen sind, sich entweder an die Kompilierung aus dem Quellcode gewöhnen oder zu einer alternativen Lösung wechseln müssen. Ich möchte mit einem Kommentar eines Nutzers auf GitHub schließen, der wirklich alles sagt: „Wie auch immer, danke für alles – Zeit für einen Fork und einen Build.“















Comments