jlkDEs Blog

Als ich das erste Mal Software in einer Linuxdistribution nachinstallierte war ich begeistert vom Ansatz einer zentralen Softwareverteilung. So musste man zur Installation nicht beim Hersteller/Entwickler nach einer passenden Installationsroutine suchen und sich auf einen neuen Wizard mit eigener Benutzerführung einlassen, sondern konnte ohne Umschweife aus derselben Quelle mit den gleichen Befehlen alle Arten von Software verwalten - An den Luxus, sowohl Einbindung, Abhängigkeitsauflösung als auch Installationsroutine von der Community nach zumeist wohldefinierten Regeln erledigt zu bekommen, gewöhnte ich mich schnell.

Heutzutage dominiert die App Store Metapher die Art, Software zu installieren und wird von nahezu jedem massentauglichen Betriebssystem eingesetzt. Währenddessen setzt die Linuxwelt aber zunehmend auf neue Paketformate, allen voran Flatpak, dann Snap und AppImage und teilweise ähnlicher Konstrukte mit Sandboxing und/oder Containerisierung, um Herausforderungen an moderne Softwarelebenszyklen zu erfüllen - Hinsichtlich der Paketierung verspricht man sich vor allem kürzere Releasezyklen, Lösung von komplexen Abhängigkeitskonflikten über klassische Bibliotheken hinaus und einen einheitlichen Build- & Releaseprozess für alle unterstützten Plattformen.

Gerade diese vermeintlichen Vorteile sind es jedoch, welche den neuen Paketformaten gegenüber der klassischen Softwareverteilung einen großen Nachteil bescheren: Wenn Build & Release direkt vom Entwickler für alle Nutzer koordiniert werden kann die Vielfalt, welche Linuxdistributionen bieten, nicht zum Tragen kommen. Es gibt durchaus genügend Diskussionen, ob die Fragmentierung der Open-Source Welt nun aufgrund doppelter Arbeit den Fortschritt hemmt oder ob gerade kleine Gemeinschaften innovativ iterieren, daher will ich gar nicht auf das Für und Wider dieser Eigenschaft eingehen. Richtig ist jedoch, dass diese Aufteilung eine große Wahlfreiheit hinsichtlich der eigenen technischen Präferenzen bietet: Auch zwischen Standardisierung und Quasi Standardsoftware gibt es noch genügend Freiraum, um auch noch Themen wie Stabilität vs. Aktualität, Abhängigkeit zu bestimmten Entwicklergruppen, Paradigmen oder auch soziale Aspekte in die Auswahl des eigenen Softwarestacks einfließen zu lassen.

Genau diese Rolle können moderne Pakete aber nicht mehr erfüllen. Da die Hoheit nun nicht mehr bei den Maintainern der Distribution, sondern beim Herausgeber der Software und höchstens noch zum kleinen Teil beim Betreiber zentraler Paketquellen wie Flathub liegt entscheidet auch dieser, nach welchen Regeln die Software den Endanwender bereichert. Das nimmt der Distribution viel Spielraum hinsichtlich dessen, was nichtkommerzielle Linuxdistributionen von kommerziellen Betriebssystemen unterscheidet, denn vor allem technische Abwägungen werden so nicht mehr von einer abgestimmten Gruppe, sondern willkürlich entschieden: Angefangen bei Buildflags und der Auswahl optionaler Abhängigkeiten sind auch Paradigmen wie Speicherplatzsparsamkeit oder Kompilierung gegen alternative Bibliotheken nicht mehr möglich.

Und auch ein weiterer Schwachpunkt tritt hierbei zutage: Der Entwickler oder Herausgeber der Software hat nicht nur mehr Gewalt, sondern auch mehr Verantwortung inne. Er verliert dadurch auch eine Teilmenge an Anwendern, die sich selbst eingehender mit Buildprozess und Release der Software auseinandergesetzt hat, ganz zu schweigen von der gestiegenen Verantwortung, dem Missbrauchspotential und dem Ausfallrisiko.

Insgesamt glaube ich, dass die modernen Paketformate für mich ideell nicht so nutzbar sind wie es mir wichtig ist. Auch, wenn ich andere Vorteile in dieser Entwicklung sehe werde ich daher vorerst auf diese Art der Softwareverteilung verzichten, solange nicht Herausgabe und Betreuung der neuen Formate vorrangig auch in Händen der Maintainergemeinden liegen.