Distributionen als Scharnier – Eine Rolle, die auch gefüllt werden will

Linux-Distributionen sind etwas fast einzigartiges. Bei keinem anderen Betriebssystem schieben sich zwischen Endanwender und Entwickler so zahlreiche und gleichzeitig mächtige Zwischenhändler. Kritik an diesem System wird von Verteidigern oft begegnet mit dem Einwand, die Distributionen würden einen wichtigen Prüfauftrag erfüllen. Wirklich?

Natürlich kann es bei Linux nicht wie bei macOS oder Windows lediglich einen Anbieter geben, der gleichermaßen Entwickler wie Verteiler ist, wobei auch andere freie Software wie z. B. die diversen BSD andere Systeme etabliert haben. Die Situation mit zahlreichen Distributoren, die alles vom Kernel bis zum Browser kontrollieren und im Extremfall in ein eigenes Betriebssystem „branden“ ist einzigartig. Es ist zudem nicht nur einzigartig, sondern auch umstritten und bereits seit vielen Jahren Ziel der Kritik, nicht zuletzt von den eigenen Softwareentwicklern, die den Distributoren vorwerfen, ein zu enger Flaschenhals im System zu sein.

Der vielfältigen Kritik begegnen die Distributoren und ihre Unterstützer mit dem umfassenden „Auftrag“ der Distribution. Dem Selbstverständnis nach bilden sie das Scharnier, das Entwickler und Endanwender verbindet und die unterschiedlichen Bedarfe vermittelt. In der Theorie prüfen die Distributoren schließlich den von den Entwicklern (Upstream) stammenden Code, verpacken ihn und stimmen die einzelnen Bestandteile des modularen Linux-Ökosystems aufeinander ab, verändern den von Upstream stammenden Code meist noch durch verschiedene Patches, ergänzen zudem noch eigene Tools und liefern es an den Endnutzer aus. Hinzu kommen ggf. weitere Prüfaufträge wie bei Debian z. B. die Konformität zu den DFSG.

In der Praxis können die Distributoren diesem Auftrag eigentlich nicht wirklich gerecht werden und sie tun es faktisch auch nicht. Dazu reicht Logik und Beobachtung.

Beginnen wir bei der Logik. Wir sind nicht mehr im Jahr 1995. Anfang der 1990er enthielt selbst der Linux-Kernel „nur“ einige Tausend Teilen Code. Heute sind es Millionen und von einer Version zur nächsten ändern sich gut und gerne mal Hunderttausende Zeilen. Der Kernel ist ein extremes Beispiel, aber große und wichtige Softwareprojekte wie systemd, Firefox oder die großen Desktopumgebungen sind da nicht viel besser. Die Schlagzahl ist bei nahezu allen Softwareprojekten rasant gestiegen. Die Zeiten, wo es mehrere Jahre infolge höchstens Minorversionen gab, sind schon lange vorüber. Heute kommen wichtige Veröffentlichungen gerne im Monatstakt. Ebenso gestiegen ist die Erwartungshaltung der Anwender. Nicht nur bei Rolling Release-Distributionen soll bestenfalls am Release-Tag die neue Version verfügbar sein, auch bei stabilen Varianten gibt es Backports und alle 1-2 Jahre neue Funktionsreleases. Gleichzeitig ist die Zahl derjenigen, die sich als Entwickler an den Distributionen beteiligen, tendenziell eher rückläufig. Eine nicht anlassbezogene und systematische Prüfung des kompletten Paketbestandes ist faktisch unmöglich.

Es scheitert aber nicht nur am „Mengenproblem“, sondern auch am Willen, den Prüfauftrag konsequent zu erfüllen. Das kann man seit vielen Jahren beobachten. Dazu gehört nämlich auch die Bereitschaft, qualitativ schlechte Software nicht an den Anwender auszuliefern, selbst wenn dadurch Lücken im Portfolio entstehen. Vorgänge, wie man sie z. B. im openSUSE Bugzilla am Beispiel des KDE Partition Manager / kpmcore nachlesen kann, wo wegen massiver Mängel Versionen zurückgehalten und Upstream Änderungen eingefordert werden, sind meiner Beobachtung nach extrem selten. Das kann man beispielsweise auch daran sehen, wie viele Distributionen immer noch bedenkenlos encfs ausliefern, obwohl das seit bald einem Jahrzehnt als gebrochen gilt oder ihre Anwender dem gefährliche Fingerprint-Authentfizierungssystem fprint aussetzen.

Innerhalb der Distributionen können weiterhin auch Inkonsistenzen vorherrschen. So entfernt Debian bei Firefox zahlreiche Telemetriefunktionen von Mozilla, verändert aber z. B. Chromium nicht. Es gibt somit keine konsistente Anti-Tracking-Policy, sondern es hängt an der Meinung des Maintainers und seiner Bereitschaft, etwas zu tun.

Dieser Zustand ist auch ein Grund weshalb ich neuen Softwareverteilungsformen offen gegenüberstehe und davor warne das alles überragende Distributorenmodell des Linux Server/Desktop-Ökosystems, das sich letztlich nur aus den Pfadabhängigkeit in der Entwicklung von Infrastruktur erklären lässt, auch auf moderne Bereiche wie mobile Systeme zu übertragen. Leider passiert momentan genau das. Weshalb wir für eine Handvoll Hardware zig Distributionen haben, die alle den gleichen nicht-alltagstauglichen Zustand paketieren, sich gegenseitig kannibalisieren und Geld kosten, das anderswo besser investiert wäre. Oder weshalb neue Konzepte wie Flatpak verunstaltet werden, bis alle sie alle Kennzeichen der bisherigen Distributorenlogik auch erfüllen und ihre Vorteile einbüßen, siehe Fedoras eigene Flatpak-Quelle. Da kommt halt ein weiterer Teil von Infrastrukturlogik zum Tragen: Das System versucht sich krampfhaft selbst zu erhalten und bremst die Entwicklung bis zur Blockade, weil bei neu aufkommender Infrastruktur Verlierer entstehen

Kurzum, die Distributionen erliegen an der Aufgabe, sind größtenteils auch nicht bereit, ihre selbst zugeschriebene Rolle konsequent zu erfüllen und dort, wo sie es tun, erledigen sie es inkonsequent. Die Position als verbindendes Scharnier zwischen Entwickler und Anwender und ihre Bedeutung sollte man also nicht zu hoch hängen. Viele Upstream-Projekte sind heute so professionell, dass sie durchaus ihre Software direkt auf den Anwender loslassen könnten, ohne dass es zu einem allgemeinen Qualitätsverfall kommen würde. Nichtsdestotrotz werden uns Distributionen in der aktuellen Form wohl erhalten bleiben, weil zu viele von dem System profitieren, die ansonsten keine Rolle spielen würden.