Manchmal muss man sich kurz hinsetzen und den eigenen inneren Meckerzwerg am Kragen packen.
Nicht, weil Kritik falsch ist.
Kritik ist wichtig. Gerade bei Software. Gerade bei Linux. Gerade bei Dingen, die man täglich benutzt und bei denen man irgendwann denkt:
Warum ist das so?
Warum macht das keiner besser?
Warum ist dieses Paket alt?
Warum gibt es das nur als Snap?
Warum ist das nicht im Repo?
Warum muss ich für diesen Treiber erst durch drei Forenthreads, zwei Wikiseiten und einen kleinen seelischen Umzug?
Alles berechtigte Fragen.
Aber manchmal vergisst man dabei eine ziemlich einfache Sache:
Software entsteht nicht aus Luft und Liebe.
Auch wenn Open Source sich manchmal so anfühlt.
Irgendwer muss das alles machen
Ein Linux-System wirkt von außen gerne wie ein großer magischer Werkzeugkasten.
Man installiert eine Distribution, öffnet den Paketmanager und plötzlich ist da alles.
Browser.
Editoren.
Desktops.
Treiber.
Bibliotheken.
Tools, deren Namen klingen, als hätte jemand eine Tastatur fallen lassen.
Und darunter nochmal tausend kleine Dinge, die man nie bewusst sieht, die aber beleidigt umfallen würden, wenn sie nicht da wären.
Das wirkt selbstverständlich.
Ist es aber nicht.
Irgendwer muss diese Pakete bauen.
Irgendwer muss schauen, ob sie noch funktionieren.
Irgendwer muss Sicherheitsupdates einpflegen.
Irgendwer muss Buildfehler lesen, bei denen normale Menschen nach drei Zeilen anfangen, über eine Karriere als Kartoffel nachzudenken.
Irgendwer muss entscheiden, ob eine neue Version rein kann.
Irgendwer muss Abhängigkeiten anfassen, ohne dass danach das halbe System klingt wie ein Schrank voller Besteck beim Erdbeben.
Und sehr oft ist dieser „irgendwer“ kein Konzern mit goldenen Wasserhähnen.
Sondern ein Mensch.
Mit Alltag.
Mit Job.
Mit Familie.
Mit Müdigkeit.
Mit eigenen Problemen.
Und vermutlich mit einem Kaffee, der schon seit zwei Stunden kalt ist.
Dieses gefährliche Wort: einfach
Ich glaube, eines der gefährlichsten Wörter in Softwarediskussionen ist:
„Einfach“.
Dann sollen die das doch einfach prüfen.
Dann sollen die das doch einfach paketieren.
Dann sollen die das doch einfach aktuell halten.
Dann sollen die das doch einfach ins Repo aufnehmen.
Dann sollen die das doch einfach sicherer machen.
Einfach.
Dieses Wort ist tückisch.
Weil „einfach“ aus Nutzersicht oft bedeutet:
Ich möchte, dass mein Problem verschwindet.
Aus Maintainer-Sicht bedeutet es aber gerne:
Herzlichen Glückwunsch, du hast gerade einen neuen dauerhaften Arbeitsbereich erfunden.
Denn etwas einmal zum Laufen zu bringen, ist eine Sache.
Es dauerhaft zu pflegen, ist eine andere.
Ein Paket ist nicht fertig, nur weil es heute baut.
Morgen kommt eine neue Library.
Übermorgen ändert sich ein Buildsystem.
Nächste Woche gibt es eine kritische Sicherheitslücke.
Dann stirbt ein Upstream-Projekt.
Dann ändert Python wieder irgendwas und irgendwo weint ein kleines Skript in der Ecke.
Software ist kein Stein, den man einmal irgendwo hinlegt.
Software ist eher ein Garten.
Wenn niemand gießt, schneidet, repariert und gelegentlich die Schnecken höflich, aber bestimmt vom Salat entfernt, sieht das irgendwann aus wie ein verwildertes Grundstück mit WLAN.
Der Paketmanager ist kein Wunschbrunnen
Ich habe das selbst oft genug vergessen.
Man öffnet den Paketmanager und erwartet, dass alles da ist.
Natürlich aktuell.
Natürlich sicher.
Natürlich passend zur eigenen Distribution.
Natürlich ohne Brüche.
Natürlich ohne seltsame Abhängigkeiten.
Natürlich bitte am besten schon gestern.
Und wenn etwas fehlt, ist der erste Impuls schnell:
Warum ist das nicht da?
Aber die bessere Frage wäre manchmal:
Wer sollte es denn pflegen?
Das ist keine rhetorische Klatsche.
Das ist der Kern.
Pakete fallen nicht vom Himmel.
Auch nicht bei Debian.
Auch nicht bei Fedora.
Auch nicht bei Arch.
Auch nicht bei Ubuntu.
Selbst große Distributionen kämpfen mit Maintainer-Zeit. Mit alten Paketen. Mit Sicherheitsupdates. Mit Software, die upstream ständig neue Anforderungen stellt. Mit Nutzern, die gleichzeitig maximale Aktualität, maximale Stabilität und maximalen Komfort erwarten.
Also im Grunde das digitale Äquivalent von:
Bitte ein Auto, das Formel 1 fährt, nie kaputtgeht, nichts kostet und sich selbst putzt.
Verständlicher Wunsch.
Aber schwierig.
Snap, Flatpak und der unbequeme Hintergrund
Man kann Snap kritisieren.
Oh ja.
Man kann über Canonical diskutieren. Über Entscheidungen, über Zwang, über Integration, über Geschwindigkeit, über dieses Gefühl, dass ein Programm manchmal startet, als hätte es vorher noch kurz einen Antrag beim Amt gestellt.
Alles legitim.
Aber selbst da muss man fair bleiben.
Formate wie Snap und Flatpak existieren nicht nur, weil irgendein Konzern morgens aufgewacht ist und dachte:
Wie können wir heute Leute im Internet wütend machen?
Sie existieren auch, weil klassische Paketpflege wahnsinnig viel Arbeit ist.
Gerade bei großen Desktop-Anwendungen.
Browser sind dafür das Paradebeispiel.
Firefox, Chromium und ähnliche Programme sind nicht einfach „ein Paket“.
Das sind moderne Monster mit Sicherheitsupdates, neuen Build-Abhängigkeiten, schnellen Release-Zyklen und einer Angriffsfläche, die ungefähr so entspannt ist wie ein offenes Fenster im Erdgeschoss mit Schild „Wertsachen hier“.
Wenn eine Distribution für mehrere Versionen gleichzeitig Pakete pflegen muss, wird das sehr schnell sehr viel Arbeit.
Dann kommt irgendwann die Idee:
Was wäre, wenn die Anwendung einmal gebaut und über mehrere Systemversionen hinweg ausgeliefert wird?
Man muss das Ergebnis nicht mögen.
Aber man sollte den Druck verstehen, aus dem solche Lösungen entstehen.
Das AUR und die schöne gefährliche Freiheit
Beim AUR sieht man das gleiche Problem von der anderen Seite.
Das AUR ist mächtig, weil es niedrigschwellig ist.
Jemand schreibt eine Paketbauanleitung.
Andere können sie nutzen.
Software, die nie in offiziellen Repos landen würde, ist plötzlich verfügbar.
Das ist großartig.
Aber es ist eben auch kein offizielles Komfortversprechen.
Wenn man das AUR stark prüfen, kuratieren und absichern würde, wäre es vermutlich nicht mehr das AUR, wie es heute existiert.
Dann bräuchte man Regeln, Zuständigkeiten, Prüfprozesse, Verantwortliche und Menschen, die diesen ganzen Kram dauerhaft machen.
Und da ist sie wieder, die unbequeme Frage:
Wer macht es?
Nicht theoretisch.
Nicht „die Community“.
Nicht „man müsste mal“.
Wer setzt sich hin?
Wer prüft?
Wer pflegt?
Wer antwortet auf Bugreports?
Wer entscheidet Streitfälle?
Wer macht weiter, wenn die erste Motivation weg ist?
Das ist der Punkt, an dem viele schöne Forderungen plötzlich weniger bequem werden.
Eine kleine Verbeugung
Darum möchte ich einfach mal Danke sagen.
An die Menschen, die Pakete pflegen.
An die, die Sicherheitsupdates einbauen, während andere schlafen oder sich gerade über Icons aufregen.
An die, die alte Software noch irgendwie am Leben halten, obwohl upstream längst in ein anderes Dorf gezogen ist.
An die, die Buildfehler lesen, die aussehen wie ein Dämonenbeschwörungsprotokoll mit Semikolonproblemen.
An die, die Dokumentation schreiben.
An die, die Bugreports sortieren.
An die, die in Foren und Chats ruhig bleiben, obwohl zum vierundzwanzigsten Mal jemand fragt, warum „die das nicht einfach besser machen“.
An die, die Distributionen bauen, testen, veröffentlichen, spiegeln, signieren, patchen, stabilisieren und sich dafür oft mehr Gemecker als Dank abholen.
Danke.
Wirklich.
Nicht als pathetisches Open-Source-Gedicht mit Geige im Hintergrund.
Sondern ganz praktisch:
Danke, dass mein Rechner morgens startet.
Danke, dass Updates meistens funktionieren.
Danke, dass ich Software installieren kann, ohne jede einzelne Zeile selbst aus dem Quellcode-Sumpf ziehen zu müssen.
Danke, dass ich mich über Dinge beschweren kann, die überhaupt nur existieren, weil jemand anderes vorher Arbeit hineingesteckt hat.
Kritik bleibt erlaubt
Das heißt nicht, dass man alles abnicken muss.
Open Source ist nicht heilig.
Distributionen treffen fragwürdige Entscheidungen.
Pakete können schlecht gepflegt sein.
Projekte können komisch kommunizieren.
Maintainer können Fehler machen.
Firmen können Dinge durchdrücken, die sich für Nutzer nicht gut anfühlen.
Kritik ist erlaubt.
Aber vielleicht sollte man öfter versuchen, sie mit einem kleinen Stück Demut zu verbinden.
Nicht:
„Warum machen die Idioten das nicht einfach?“
Sondern eher:
„Ich verstehe, warum das nervt. Ich frage mich, welche Arbeit dahinter steckt und ob es eine realistische bessere Lösung gibt.“
Das ist weniger befriedigend für den inneren Meckerzwerg.
Aber wahrscheinlich fairer.
Fazit: Es hält sich nicht von selbst zusammen
Je mehr ich selbst an kleinen Projekten bastle, desto mehr merke ich:
Schon ein kleines Paket sauber zu bauen, kann nerven.
Eine Installation reproduzierbar zu machen, nervt.
Dokumentation zu schreiben, nervt.
Fehler auf einem frischen System zu finden, nervt.
Etwas nicht nur für mich, sondern für andere nutzbar zu machen, ist nochmal eine ganz andere Hausnummer.
Und dann schaue ich auf große Distributionen und denke:
Okay.
Vielleicht sollte ich etwas leiser meckern.
Nicht gar nicht.
Nur leiser.
Genauer.
Fairer.
Denn am Ende hält sich dieses ganze Open-Source-Universum nicht von selbst zusammen.
Es besteht aus Menschen, die freiwillig oder bezahlt Arbeit hineinstecken.
Aus Zeit.
Aus Nerven.
Aus Wissen.
Aus Geduld.
Aus kaltem Kaffee.
Aus Leuten, die um 1:37 Uhr auf einen Buildfehler starren und leise fragen:
Warum bist du so?
Und genau dafür darf man ruhig mal Danke sagen.
Nicht, weil alles perfekt ist.
Sondern weil überhaupt so viel funktioniert.