AUR helper oder: das Open Source-Dilemma?

Dieser Artikel entstand als News-Mitteilung, gewann dann an Dynamik und hat eine philosophische Komponente über freie Software erhalten. Er ist länger als üblich und aus der Sicht eines Nutzers geschrieben, der viele FOSS-Produkte einsetzt und an einigen kleineren beteiligt war.

Prolog: das AUR

Seit 2012 bin ich Arch Linux-Nutzer. Neben der Möglichkeit, sein System ganz individuell zusammenzustellen (und dann wieder bei GNOME zu landen ;)), ist das Repository das Herzstück der Linux-Distribution, die eher für fortgeschrittene Linux-Nutzer empfohlen wird. Aktuelle und vielfältige Pakete sorgen für entspanntes Arbeiten, obskure Eigenheiten wie Debians "*-dev"-Pakete für Headerfiles bleiben erspart und minimieren die Dependency-Hell.

Und wenn ein Paket benötigt wird, das nicht über das Haupt-Repository zu beziehen ist, kommt das Arch User Repository ins Spiel. Hier lassen sich alle nahezu erdenklichen Pakete für Linux-Anwendungen finden. Im Unterschied zum normalen Repository sind diese "Pakete" nicht vorkompiliert, erhalten keine offizielle Unterstützung, bringen aber eine PKGBUILD-Datei mit, die abgerufen und mithilfe vom Kommando makepkg (enthalten in pacman) eingelesen wird. In der Datei stehen Paketinformationen, Abhängigkeiten und Build-Instruktionen. Ist das Paket gebaut, liegt es in einem für Pacman, dem Paketmanager, verständlichen Format vor und wird an diesen zur Installation übergeben. Am Ende des Tages verwaltet bei diesen "Custom" Packages der normale Paketmanager die Programmdateien, obgleich ein Paketupdate ein manuelles Neubauen erfordert. Schwierigkeiten bei dieser Verfahrensweise treten besonders dann auf, wenn AUR-Pakete von anderen AUR-Paketen abhängig sind, was zur manuellen Auflösung in Handarbeit führt. Wie genau das AUR funktioniert, lässt sich im Wiki-Artikel dazu nachlesen.

AUR helper

Ihr könnt es euch denken, die Nutzerschaft entwickelt seit jeher Helfer (sog. AUR helper), um diese Prozesse zu vereinfachen und den Komfort von pacman im AUR genießen zu können. Offizielle Unterstützung bleibt dafür aus (use at your own risk, weil der Paket-Input weniger streng kontrolliert wird), sodass es gerne rüberkommt, als würden AUR helper-Nutzer auch schwarze Messen feiern. Gut, der wahre Grund, warum AUR helper nicht unterstützt werden, ist hier nachzulesen, würde jedoch die Dramatik zerstören. Trotzdem finden die folgenden Helfer keinen Platz im sonst so vollständigen Arch Wiki finden und werden lediglich in einer Tabelle abgehandelt.

Welche AUR helper sind momentan verfügbar? Da geht die Qual der Wahl los - es gab andererseits bisher einige Quasi-Monopole. So galt überwiegend vor einigen Jahren noch "yaourt und gut ist". Funktioniert, ließ sich sogar mit einem Repository über Pacman installieren und vollbrang sein Dienst. Die Installation über Pacman war sogar ganz interessant, weil dies einer Knackpunkte auf dem Weg ist AUR ist. AUR helper lassen sich eben nicht aus dem normalen Arch Repository installieren, sondern müssen selber gebaut werden - wozu sie ja eigentlich benötigt werden. Wer nicht weiß, wie Pakete manuell über die PKGBUILD gebaut werden, hat an dieser Stelle schon ein echtes Henne-Ei-Problem.

yaourt lief und lief ... und stockte irgendwann in 2017. "low activity" betitelt die besagte Tabelle den aktuellen Entwicklungsstatus. Last update July 2017. Klar, yaourt lebt noch, aber gerade bei diesen community-driven repostitories, schlafe ich auf der anderen Seite besser, wenn die Hilfsscripte wenigstens aktiv entwickelt und eventuelle Änderungen am AUR-Verfahren zeitnah implementiert werden. Nicht nur ich denke so, it's foss hat hierzu ebenfalls geschrieben.

Zu der Zeit hatte ich gerade mein System neu aufgesetzt, warum dann nicht also gleich dieses Problem vom Tisch bekommen. pacaur sah ganz nett und funktionsmäßig gut bestückt aus, warum ihm nicht also eine Chance geben? War rückblickend keine nachhaltige Idee.

Aus aktuellem Anlass: aurman

Nächster Kandidat: aurman. Und jetzt kommt der interessantere Teil, wo die News anfangen. aurman verschwand vor knapp zwei Wochen still und heimlich. Vor fünf Tagen hat der Entwickler hinter dem Tool seine Entscheidung auf Reddit ausführlich begründet. Eine Entscheidung, die ich im ersten Moment ganz gut nachvollziehen kann. aurman bleibt fortbestehen, nur ohne Community. Entscheidungen und Abhängigkeiten, die der Autor nicht in der Hand hatte, wurden auf ihn abgewälzt, obwohl 30 Sekunden Hirn einschalten von Nutzerseite die Sache massiv entschärft hätten. Das Ergebnis: der Issue Tracker wurde deaktviert und das Projekt befindet sich jetzt in einem Modus, in dem der Entwickler die Software für sich entwickelt und den Code öffentlich teilt.

Ich für mich habe mich die Tage wieder umgeschaut und für yay entschieden. Das auf Go baiserende Tool wird nicht nur vom aurman-Entwickler empfohlen, es bietet einen ähnlichen Funktionsumfang. Hoffen wir, dass diese Entscheidung nachhaltiger ist.

Kritischer Blick

Wie bereits angekündigt, lässt sich dieses Problem allerdings auf etwas Größeres abstrahieren.

Lassen wir erst einmal die Fakten sprechen: beim AUR handelt es sich um eine Art unregulierten Markt, es gibt keine "offizielle Stelle", die ein bestimmtes Tool empfiehlt oder besonders hervorhebt. Die Zielgruppe ist in ihrer Marterie fortgeschritten und weiß überwiegend, was sie tut. Die Problematik (Hilfssripts für das Bauen aus dem AUR) ist zudem grundsätzlich in vertretbarem Zeitaufwand lösbar (aurman sowie yay kommen mit unter 10.000 Zeilen Code zurecht).

Fragmentierung: einfältige Vielfalt?

Die nun folgende Erscheinung ist interessant: es gibt nicht ein Projekt, sondern viele. Sie lösen alle das gleiche Problem auf ihre Weise. Das ist gut und hat seine Vorteile. Auf der anderen Seite entsteht ein Single Point of Failure: ein kurzer Blick auf GitHub offenbart, dass viele Projekte nur von ein oder zwei Autoren nennenswert gemaintained werden. Steigen diese aus, ist das Projekt unmaintained. Die Wahrscheinlichkeit, dass ein Projekt übernommen wird, ist geringer als die Chance, dass ein neues Projekt entsteht. Gründe dafür gibt es viele und Hand auf's Herz - wir haben alle unseren eigenen coding style, den wir, sofern es nicht das Projekt oder eine Guideline erfordert, ungern über Bord werfen - schon gar nicht, wenn wir das Projekt alleine hucken. "Neuschreiben" hat seinen eigenen Charme. Der Open Source-Charakter sorgt für die Beruhigung des Gewissens, jeder verfügt ja bei Zweifeln über die Möglichkeit, alles nachzuvollziehen.

Ausnahmen bestätigen die Regel: so wurde die Software Firewall Builder erfolgreich wiederbelebt. Ausschlaggebend dafür war mitunter der große Funktionsumfang, der es sinnvoller erscheinen lässt, ein Projekt weiterzupflegen, als es von Grund auf neu zu entwickeln.

Nicht zwingend wird dabei das Rad neu erfunden, dieser Prozess lässt sich aus der Distanz wie eine Evolution betrachten - dem Endnutzer werden Innovation und neue Funktionen zuteil. Yay ist z.B. in einer Programmiersprache (Go) geschrieben, die nicht einmal zehn Jahre alt ist und hat somit die Chance, wartungsfreundlicher und effizienter als vergleichbare Codebases in anderen Sprachen zu sein. Ich kenne nicht viele kleinere Projekte, die im Laufe ihrer Zeit ihre gesamte Sprache gewechselt haben, meist wurden es neue Projekte. Diese Beobachtungen lassen sich allerdings nur unter den o.g. Voraussetzungen betrachten.

Gegenbeispiele: der Linux-Kernel als Projekt, ein unixodes, hochkompatibles System zu schaffen, hat einen gigantischen Umfang und eine große Entwicklerschaft, die eine klare Leitung (Linus Torvalds) hat, sodass eine Fragmentierung unwahrscheinlich ist. Bürosoftware hat einen ähnlichen Umfang und höhere Hürden, bis ein Fork entsteht - z.B. lizenzrechtliche Streitigkeiten oder Frust der Entwickler.

Forks, also Abspaltungen, bringen eine eigene Dynamik in die Materie, die den Bogen dieses Artikels überspannen würden. Insgesamt lassen sich aus den Beobachtungen Vor- und Nachteile schlussfolgern, die uns zur nächsten Problematik führen.

Freie Software braucht mündige Bürger!

Freie Software ist eine Steigerung von Open Source. Der englische Begriff FOSS (Free Open Source Software) bringt dies stärker zum Ausdruck. Denn wenn der Quellcode verfügbar ist, heißt es nicht, dass auch der Prozess drumherum sich um den Nutzer dreht. aurman würde aus meiner Sicht mit der neuen Strategie ohne den Issue Tracker und Support nicht mehr die Kriterien als FOSS erfüllen, ein FOSS-Entwickler muss sich andererseits nicht alles (wie bisher) gefallen lassen.

Viel mehr ist es wichtig, unter (neuen) Nutzern Werte freier Software in den Vordergrund zu rufen: nämlich selbstständig verantwortungsbewusst zu agieren - mündige Bürger sind (im Idealfall) ebenfalls nicht solche, die lediglich laut schreien können. Dazu gehört es, sich bei Problemen selber ein wenig über die Hintergründe zu informieren, bevor ein Ticket oder eine E-Mail an den Entwickler geschrieben wird. Programmierkenntnisse sind nicht zwingend erforderlich, Lesekenntnisse schon! Existiert zum Problem vielleicht schon einen Issue? Sagt die README was? Wird das Problem im Entwicklerblog erwähnt?

Es wirkt verlockend, dass bei FOSS der Entwickler greifbar nahe ist, wichtig für ein gutes Klima ist der verantwortungsvolle Einsatz dieses Privilegs.

Nutzer von konkurrierenden Plattformen mit dem "hier ist es kostenlos und Open Source"-Argument abzuholen, ist im Zweifel aus meiner Sicht nicht nachhaltig und schafft zeitversetzt Frust - auf Nutzer- und Entwicklerseite.

Hier liegt meiner Meinung nach einer der Gründe, warum FOSS bisher eher im professionellen (Apache/nginx, SQL, Linux, ...) als im Endnutzer-Umfeld anzutreffen war: die "guten Tugenden" (Recherche vor Ticket) sind hier etablierter.

Die Vielfalt gibt uns Freiheit – diese einzusetzen braucht Wissen und Verstand. Das bringt uns zurück zur AUR helper-Tabelle, denn viele Arch User werden sich nicht an dieser stören, weil sie diese optimal für sich einsetzen und das Projekt suchen können, das ihre Anforderungen am besten abdeckt.

Fazit

Bildung und Verstand sind wichtig und das gilt in gleicher Weise für die FOSS-Welt. Wenn Nutzer selbstständiger denken und agieren, haben wir eine Chance, den Frust bei den Entwicklern zu minimieren. Und wenn trotzdem eine Frage ansteht, denkt an RTFM und How To Ask Questions The Smart Way.