Drei Fragen und Antworten: Viele überlastete Maintainer in Open-Source-Projekten

Viele Open-Source-Maintainer fühlen sich überlastet: Der neue Tidelift State of the Open Source Maintainer Report wirft einen Blick auf die Belastungen, denen Maintainer heute ausgesetzt sind. Insbesondere die mangelnde Vergütung wirkt weiter Druck auf Projektbetreuer aus und gut 60 Prozent von ihnen sehen kein Geld für ihr Engagement. Manche schmeißen hin. Wir sprechen mit Volker Lendecke, langjähriges Mitglied im Samba-Team, über seine Erfahrungen damit.

Nehmt Ihr auch steigenden Druck durch erhöhte Anforderungen, beispielsweise für die Sicherheit, bei gleichzeitig sinkender Unterstützung durch die Community wahr?

Ganz ehrlich – nein. Wir hatten immer schon viel Druck, was die Sicherheit angeht. Auch wir hatten sicherlich einen guten Anteil an generischen Sicherheitslücken, aber Samba bewegt sich im Umfeld der Windows-Protokolle. Allein aus diesen Protokollen heraus ergibt sich ein ganzer Schwung an Angriffspunkten, mit denen wir es zu tun haben. Wir haben deshalb schon vor vielen Jahren unsere Sicherheitsprozesse definiert. Insofern, und das mag Selbstüberschätzung sein, sehen wir uns in Samba eigentlich ganz gut aufgestellt.

Kennst Du denn benachbarte Projekte, die unter steigendem Druck ächzen und dem vielleicht sogar nicht mehr standhalten können?

Ein sicherheitsrelevantes Projekt, das seit langem öffentlich um finanzielle Unterstützung bittet, ist gnupg. Gerade bei gnupg zeigt sich, dass freie Software von Menschen gemacht wird. Und immer, wo Menschen aufeinander treffen, treffen unterschiedliche Arbeitsweisen aufeinander. Auch Samba ist davon nicht frei. Das Samba-Team hat es in der Vergangenheit aber immer geschafft, sich zusammenzuraufen und an einem Strang zu ziehen. An OpenPGP, gnupg oder librepgp sieht man aber auch den großen Vorteil freier Software: Man kann, wenn die Vorstellungen zu weit auseinander liegen, forken und muss nicht komplett von vorne anfangen.

Ein benachbartes Projekt, bei dem es aus meiner Sicht auch nicht gut läuft, ist das smb-Subsystem im Linux-Kernel (fs/smb/*). Im Linux-Kernel ist Refactoring praktisch unmöglich, man kann Code einfach nicht aufräumen und schöner machen. Viele Stellen sind einfach ultimativ hässlich und so unverständlich, dass man kaum eine Chance hat, diese Stellen unter Sicherheitsaspekten zu überprüfen.

Diese radikale Verweigerung von Refactoring hat allerdings einen Grund: Der Linux-Kernel muss Patch-kompatibel zu Versionen von vor vielen Jahren sein, denn es gibt Zusagen, Backports extrem lange durchzuführen. Wenn man jetzt im Hauptzweig Refactoring für besser verständlichen Code zuließe, würde das die Arbeit der Backporter deutlich erschweren. Und das gilt es, um jeden Preis, auch um den Preis von komplett unverständlichem Code, zu vermeiden.

Beurteilen kann ich dies im Unterverzeichnis fs/smb des Kernels, aber ich habe von Bekannten gehört, dass es in anderen Bereichen des Kernels nicht anders ist. Darüber hinaus habe ich eigentlich zu wenig Einblick in Projekte, als dass ich mir ein Urteil erlauben könnte.

Hast Du persönlich auch schon mal ans Hinschmeißen gedacht?

Nein :-)

Volker, vielen Dank für die Antworten!

In der Serie "Drei Fragen und Antworten" will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vor dem PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.

(who)