Unveränderliche („immutable“) Distributionen, Anwendungen über containerbasierte Formate wie Flatpaks und Snaps. Skeptiker dieser Entwickler verweisen immer wieder gerne auf die Bedeutung der Maintainer als wichtige Kontrollinstanz. Ein kleiner Blick auf die Fakten.
Paketmaintainer sollen dem Anspruch nach die Anwender vor dem Dschungel des Open Source-Ökosystems bewahren. Richtige Versionen finden, Quellcode prüfen, Fehler patchen, sicherheitsrelevante Probleme monitoren und beheben. Der Anforderungskatalog ist gewaltig.
In der Realität werden die Distributionen und ihre Maintainer dieser zugedachten Scharnierfunktion zwischen Entwicklung und Anwendern schon länger nicht mehr gerecht. Nicht weil sie nicht können oder wollen, sondern schlicht, weil Open Source sich weiterentwickelt hat. Programme bestehen heute nicht mehr aus ein paar hundert Zeilen Code und es gibt auch nicht mehr nur 5 Programme für jeden Zweck. Zum Glück für uns Anwender.
Nehmen wir Debian als Beispiel. Für ein Paket wie Dolphin ist laut Informationsseite die Gruppe der „Debian Qt/KDE Maintainers“ verantwortlich. Schon hier schwächt sich das Maintainerprinzip ab, da Außenstehende nicht sofort erkennen, wer verantwortlich zeichnet. Diese Gruppe ist für fast alle Pakete im KDE/Qt-Kontext verantwortlich. Wer jetzt denkt, das müssen bestimmt 10 Personen sein, der täuscht sich gewaltig. Seit dem Rückzug von Norbert Preining treten lediglich 2-3 Maintainer hier in Erscheinung durch Uploads. Das sind im Wesentlichen Pino Toscano und Aurélien Couderc, die für einen Großteil der Pakete verantwortlich zeichnen. Lediglich Qt hat nochmal separate Maintainer.
Debian hebt seine Entwickler und Maintainer besonders hervor und ist hier sehr transparent, aber das ist bei den meisten Distributionen nicht anders und die Personalstärke ist hier nirgendwo besser. Debian kann daher durchaus als Beispiel dienen.
Diese Maintainer leisten tolle Arbeit. Ohne sie gäbe es aktuell kaum ein Linux-System. Die sich rasch entwickelnde freie Softwarewelt in Pakete zu verpacken und an die Anwender auszuliefern, ist viel Arbeit. Arbeit, die für jede Distribution erneut durchgeführt werden muss (ja ja, die Vielfalt…). Arbeit, die immer noch nicht hinreichend automatisiert ist. Arbeit, die viele Maintainer in ihrer Freizeit erledigen.
Aber wer ernsthaft glaubt, dass bei dieser Arbeitsbelastung eine intensive und anlasslose Prüfung des Codes erfolgen kann, der redet sich etwas ein. Die Fähigkeit den Code der betreuten Pakete zu prüfen ist nicht mal eine Qualifikation, die ein Maintainer formal haben muss, weil es nicht seine Aufgabe ist. Solange beim Paketbau keine Probleme auftreten, schaut da niemand genauer hin. Viel bei Open Source basiert auf Vertrauen. Anwender vertrauen ihren Distributionen, die Projekte den Maintainern, diese Maintainer den Upstream-Entwicklern etc. pp. Man darf schon froh und dankbar sein, wenn die Maintainer den Upstreamdiskussionen engmaschig folgen und dort diskutierte Probleme schnell für die Distribution angehen und lösen.
Ein kleines Beispiel ist der KDE Partition Manager bzw. kpmcore. Bis bei SUSE ein (hauptamtlicher) Entwickler sich das mal genauer angesehen und umfangreiche Änderungen infolge erheblicher Sicherheitsbedenken angemahnt hat, haben das alle Distributionen klaglos durchgewunken und akzeptiert. Es fiel dann bei SUSE auf, obwohl die wohlgemerkt den KDE Partition Manager gar nicht standardmäßig verwenden, sondern eine eigene Lösung haben.
Das Maintainer-Prinzip auf einen Sockel zu stellen (z. B. hier und hier) und gegen die aktuelle Entwicklung ins Feld zu führen, wird der Realität somit nicht gerecht. Auch moderne Distributionen mit unveränderbaren Systemen und Anwendungen über Flatpak & Co brauchen Entwickler und entstehen nicht im luftleeren Raum. Hier wird ein bewusst ein Zerrbild zukünftiger Entwicklung gezeichnet und gegen ein idealisiertes Bild der Gegenwart ins Feld geführt.
Den Satz „Das Maintainer-Prinzip auf einen Sockel zu stellen und gegen die aktuelle Entwicklung ins Feld zu führen, wird der Realität somit nicht gerecht, sondern ist ein Argument, das auf einem Idealbild basiert und nicht auf dem aktuellen Zustand der Distributionen“ kann ich nicht wirklich mit dem Inhalt des von Dir verlinkten Artikels in Ei nklang bringen:
> „Was mich bei künftig zu erwartender weiterer Verbreitung wirklich stört, ist der vorhersehbare Wegfall des Paketbetreuers in den jeweiligen Distributionen. Diese Enthusiasten stehen zwischen Entwicklern im Upstream und den Nutzern und erfüllen dort eine technische und soziale Rolle, die ich als wichtig für das Miteinander erachte. Andererseits erleichtern die neuen Paketsysteme die Arbeit der Entwickler. Sie müssen nur noch ein Paket schnüren, das in allen Distributionen funktioniert, wo das jeweilige Framework installierbar ist. Noch universeller ist AppImage, das keinerlei vorherige Installation voraussetzt „.
Zu meinen, dass jemand eine wichtige soziale und technische Rolle spielt, ist etwas ganz anderes, als jemand auf einen Sockel zu stellen. Natürlich kann man bezüglich der Rolle der Maintainer unterschiedliche Meinungen haben. Mir erscheint Dein Text hier aber künstlich zu polarisieren und eher Strohmannargumente aufzubauen, zumal der verlinkte Text ja auch Argumente für die neuen containerbasierte Formate liefert.
Ich habe den von dir zitierten Absatz tatsächlich anders gelesen. Vermutlich weil ich das hier noch im Hinterkopf hatte (was ich jetzt noch nachträglich verlinken werde): https://linuxnews.de/2021/09/plaedoyer-fuer-den-paket-maintainer/
Ja, insbesondere der Originalblog von Drew DeVault [https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html] stellt tatsächlich die Rolle der Maintainer als sehr positiv und elementar dar. Dazu passen Deine Aussagen oben besser ;-).
Gerade heute habe ich auf Heise über Ladybird (Browser – von grund auf neu programmiert) gelesen. Ein Kommentator hat es gewagt zu fragen, „warum eigentlich“. Die meisten Antworten waren dann eher dominant und verteidigen auf den Tod, dass das die Freiheit ist usw.
Ja klar, ist das die Freiheit und das ist auch gut so!
Aber, ich bin schon lange der Ansicht, dass nicht alles 200 mal geforked werden muss, nur weil der eine Entwickler einen Strichpunkt da haben möchte, wo ein anderer lieber ein Komma hätte.
Danke für den Artikel über die Maintainer, denn im Grunde wäre doch auch hier viel besser, wenn es vielleicht nicht ganz so viele flavours (oder wie man sie nennen mag) von jeder Distribution geben würde, sondern eine und eben die großen Oberflächen mit an Board (meistens geht es bei flavours ja um die Oberfläche).
Daher wäre mein Wort zum Dienstag, dass sich besser mehr Menschen zusammentun und ein tolles Produkt herstellen, als dass jeder seine eigene Distro/Programm herausbringt und dann kaum hinterher kommt. Ja, das bedeutet, dass Individuen Kompromisse machen müssen – zum Wohle des Produkts.
Ich rede nicht von einem Zusammenschrumpfen auf eine Distro, sondern, dass das Pendel ein wenig Richtung Zusammenarbeit schwenkt.
Danke für den anschaulichen Artikel!
Markus
In diesem Zuge sehe ich snap, Flatpak, aber auch die Programmiersprachen spezifischen Formate wie Python-Wheels, direkt auf dem Code gebaute executable binaries bei Rust und Go als Verbesserung, WENN diese direkt von den Entwicklern bereitgestellt werden. Natürlich ist da auch ein bisschen Idealismus bei, im Sinne von, dass der Entwickler einer Software ein hohes Interesse daran hat, ein funktionierendes Stück Software in die Welt zu werfen.
Durch die weitesgehende Unabhängigkeit vom darunter liegenden OS durch das Konzept von snap, Flatpak und Co wird das Paketieren einfacher und man muss bei non-rolling Release Distros ggf. nicht mehr warten, bis mit der nächsten Version die benötigte Version von lib$FOO in den Quellen ist.
Bei Flathub haben die KDE Pakete auch < 10 Maintainer und da sind die Leute mit Oberaufsicht über alle Repositories schon eingerechnet. Paketieren ist keine schöne Arbeit und nur wenige nehmen es auf sich.