Kommentar: Canonicals aggressives Marketing nervt

Snaps sind erneut ein weiterer Alleingang Canonicals. Es ist nicht der erste und wird auch nicht der letzte sein. Es ist auch nicht das erste oder das letzte Mal, dass Canonical den Rest der Linux-Welt mit ihm zuträglichen Ideen beglücken will. So wollte Mark Shuttleworth vor Jahren Debian überzeugen, einen aufeinander abgestimmten Releasezyklus mit auch für Debian festen Terminen zu etablieren. Zum Glück hat Debian dankend abgelehnt.

Das Paketsystem krankt

Jeder, der aktiv mit Linux zu tun hat, weiß, dass das etablierte Linux-Paketmanagement seine Unzulänglichkeiten hat. Darunter leiden Anwender, Paketbetreuer und Entwickler. Es gibt zu viel Fragmentierung zwischen den Distributionen, wenn es um das Paketieren geht. Wenn Pakete bei den Endanwendern ankommen, sind sie oft bereits veraltet.

Von daher sind Snaps und Flatpaks theoretisch eine gute Alternative, um abseits der Kernanwendungen der Distributionen Pakete schnell, sicher und für alle Distributionen nutzbar anzubieten. Aber warum sollen es denn Snaps sein? Warum soll es ein von Canonical kontrollierter Closed-Source-App-Store sein? Warum müssen Entwickler, die zu Snappy beitragen möchten, eine CLA unterschreiben? Ist Mark Shuttleworth etwa der Gutmensch, der Linux einigen will? Ich denke eher, es geht um den schnöden Mammon, denn in Canonicals App-Store werden neben kostenlosen auch bereits erste Snaps kostenpflichtig angeboten.

Augenwischerei

Die Ankündigung von Canonical führt eine Reihe von Namen, Projekten und Distributionen auf, die zusammen daran arbeiten wollen, Snaps universell einsetzbar zu machen. Einige der genannten Firmen und Projekte werden mit Aussagen zu den erwarteten Früchten der Zusammenarbeit zitiert. Aber Distributionen? Da wird lediglich Steve Langasek zitiert, der hauptberuflich Canonical-Angestellter ist.

Wenn er in einer Canonical-Verlautbarung als Debian-Entwickler verkauft wird, um ihn für Debian sprechen zu lassen, so hat das zumindest ein Geschmäckle. Bei Fedora wurde die Meldung mit Erstaunen aufgenommen, da niemand etwas von einer Zusammenarbeit weiß und Fedora auch klar, wie zu erwarten, hinter Flatpak steht.

Die Liste der Distributionen, die Snap mit Paketen unterstützen oder dies angeblich in Betracht ziehen, liest sich imposant. Schaut man genauer drauf, so befinden sich entsprechende Pakete bei Arch im Anwenderarchiv AUR, bei Fedora in einem externen Repository Copr, bei Gentoo kann man das Paket direkt aus GitHub bauen. Bei Debian wurden die Ubuntu-Pakete von Paketbetreuer Langasek nach Unstable verschoben. Das hört sich dann doch weniger nach aktiver Unterstützung seitens der genannten Distributionen an.

Zugegeben, Canonical hat Red Hat bei der Entwicklung der neuen Paketformate geschlagen, jetzt ist Canonical auch beim Marketing vorn und tut das in gewohnter Manier mit Halbwahrheiten und gewagten Versprechen.

Kein Allheilmittel

Aber auch generell können die neuen Formate, egal ob Snap oder Flatpak, nicht auf ganzer Linie überzeugen. Neben der Duplikation vieler Bibliotheken und damit verbundener Probleme bei Upgrades sehe ich weitere Nachteile. Derzeit sitzen zwischen Upstream – den Entwicklern – und dem Endanwender die Paketbetreuer der Distributionen. Sie werden bei Snap und Co. nicht mehr gebraucht, da die Entwickler selbst paketieren. Dabei erfüllen Paketbetreuer einige wichtige Funktionen, indem sie als Filter in beide Richtungen wirken.

Künftig würden sich die Entwickler ohne die Maintainer mit der ungefilterten Masse der Bugreports der Anwender konfrontiert sehen. In der anderen Richtung sichern Paketbetreuer und die hinter ihnen stehenden Mechanismen der jeweiligen Distribution, dass Anwender den Begriff „Freie Software“ ernst nehmen können, da unfreie Anteile, die mancher Entwickler ausliefert, herausgefiltert werden. Sollte sich das kontrollierte App-Store-Modell, das Canonical vorschwebt, durchsetzen, kann Linux nur verlieren.

Es bedarf künftig einer Lösung, Entwickler und Endanwender zeitlich dichter zusammen zu bringen und Fragmentierung zu beseitigen. Eine solche Lösung sollte es auch Drittanbietern erleichtern, Software für Linux bereitzustellen. Jedoch sollten Schnellschüsse vermieden werden, die Linux nicht bereichern, sondern einengen würden.

Hinweis: Der Inhalt dieses Kommentars gibt die persönliche Meinung des Autors wieder. Diese Meinung wird nicht notwendigerweise von der gesamten Redaktion geteilt.