Klipper: Open Source ohne Community
Klipper ist für viele Druckerbesitzer zum Standard geworden. Ein Artikel von Aleksey Sviridkin im Ænix-Blog stellt jedoch eine unbequeme Frage: Was passiert, wenn ein Projekt an einer einzigen Person hängt? Der Autor stellt klar, dass es sich um seine persönliche Meinung handelt, und untermauert sie mit recht konkreten Argumenten.
Die Kernthese: Der Code von Klipper ist hervorragend, das Projekt ist aber nicht wie eine Organisation aufgebaut. In der CONTRIBUTING.md wird nur Kevin O'Connor genannt. Es gibt vier Reviewer, doch nur er hat Commit-Rechte auf master, der Bus-Faktor liegt also bei eins. Der Issue-Tracker ist faktisch geschlossen: Ein einziges offenes Issue erklärt, dass der Tracker nicht mehr genutzt wird, und die Diskussionen sind in ein Forum abgewandert, in dem mehr als 200 PRs warten.
Als Beispiel nennt der Autor den PR #6826, der neben dem Unix-Socket auch das Lauschen auf einem TCP-Socket ergänzt. Nach seiner Schätzung, gestützt auf das Docker-Image mkuf/moonraker, würden mehr als 400 Menschen diese Funktion nutzen, doch eine inhaltliche Antwort blieb aus. Funktionen, die nicht im Kern landen, wandern deshalb in Forks ab. Snapmaker hat für seinen Drucker U1 rund 20 % der Codebasis verändert, und Creality sowie andere Hersteller liefern eingefrorene alte Versionen aus.
Der Autor meint, Forks seien für Hersteller wegen Rebases und Backports teuer, und ruft dazu auf, Änderungen in den Mainline-Zweig einzubringen, wo der Eingangskanal funktioniert. Für kommerzielle Forks schlägt er neutrale Stiftungen nach dem Vorbild von OpenTofu, Valkey und OpenSearch vor.
Man muss nicht allem zustimmen, aber wer Drucker und Firmware auswählt, sollte wissen, auf welchem Ökosystem er aufbaut. Für mich ist die wichtigste Erkenntnis des Artikels, dass eine offene Lizenz keine offene Entwicklung garantiert.
Quelle: Habr (Ænix blog)
Die Kernthese: Der Code von Klipper ist hervorragend, das Projekt ist aber nicht wie eine Organisation aufgebaut. In der CONTRIBUTING.md wird nur Kevin O'Connor genannt. Es gibt vier Reviewer, doch nur er hat Commit-Rechte auf master, der Bus-Faktor liegt also bei eins. Der Issue-Tracker ist faktisch geschlossen: Ein einziges offenes Issue erklärt, dass der Tracker nicht mehr genutzt wird, und die Diskussionen sind in ein Forum abgewandert, in dem mehr als 200 PRs warten.
Als Beispiel nennt der Autor den PR #6826, der neben dem Unix-Socket auch das Lauschen auf einem TCP-Socket ergänzt. Nach seiner Schätzung, gestützt auf das Docker-Image mkuf/moonraker, würden mehr als 400 Menschen diese Funktion nutzen, doch eine inhaltliche Antwort blieb aus. Funktionen, die nicht im Kern landen, wandern deshalb in Forks ab. Snapmaker hat für seinen Drucker U1 rund 20 % der Codebasis verändert, und Creality sowie andere Hersteller liefern eingefrorene alte Versionen aus.
Der Autor meint, Forks seien für Hersteller wegen Rebases und Backports teuer, und ruft dazu auf, Änderungen in den Mainline-Zweig einzubringen, wo der Eingangskanal funktioniert. Für kommerzielle Forks schlägt er neutrale Stiftungen nach dem Vorbild von OpenTofu, Valkey und OpenSearch vor.
Man muss nicht allem zustimmen, aber wer Drucker und Firmware auswählt, sollte wissen, auf welchem Ökosystem er aufbaut. Für mich ist die wichtigste Erkenntnis des Artikels, dass eine offene Lizenz keine offene Entwicklung garantiert.
Quelle: Habr (Ænix blog)
Kommentare 0
Schreib den ersten Kommentar, in jeder Sprache.
Zum Kommentieren anmelden