© xalanx, 123RF.com

Unklare Zuständigkeiten für Softwarepakete, unbearbeitete Bugreports: Der Knoppix-Erfinder Klaus Knopper schreibt sich von der Seele, was ihn an der Open-Source-Gemeinde ärgert.

Open Source gilt als eine bessere Welt, in der alle einander helfen. Manchmal habe ich aber ganz anderes Verhalten erlebt. Deshalb möchte ich der Idealvorstellung ein paar Erfahrungen aus der Realität entgegenhalten, die anderen helfen sollen, Enttäuschungen zu vermeiden.

Auf der Suche

Wer hilft bei Fragen oder Problemen mit freier Software? Der sicherste Weg, um jemanden zu erwischen, der zuständig ist, weil er das Programm mitgeschrieben hat oder sich als Maintainer für das entsprechende Softwarepaket betätigt, ist das Bugtracking-System der verwendeten Distribution oder die jeweilige Developer-Mailingliste.

Das verdienstvolle Debian-Projekt, auf dem mein Live-Linux Knoppix [1] beruht, empfiehlt explizit, nicht den Autor des Programms selbst anzuschreiben, sondern immer den Debian-Paketmaintainer [2]. Das soll es dem Paketpfleger ermöglichen, die Fehler zu sammeln, richtig zu kategorisieren, möglicherweise selbst Patches zu entwickeln und an Upstream zu schicken, also den Originalautor der Software. Dieses Vorgehen soll den Fehler auch für alle anderen Distributionen beheben.

Prinzipiell ist dieses Verfahren sicherlich sinnvoll. Wenn ich mir allerdings die langen Listen der ausstehenden Bugfixes für manche Programmen ansehe, frage ich mich, welcher Anwender so viel Zeit hat, um auf die Behebung aller Fehler im Upstream zu warten.

Reportbug

Um die Fehlermeldungen zu kanalisieren, bringt Debian sogar ein eigenes Softwarepaket namens »reportbug« mit (siehe den Kasten “Bugreporting in Debian”). In der Praxis sieht dessen Anwendung leider so aus: Zunächst muss der hoch motivierte Anwender, der etwa einen Bug in Mkisofs melden möchte, sich durch stolze 102 “noch ausstehende Fehlerbehebungen” kämpfen, um festzustellen, ob der Fehler überhaupt neu ist. Danach ist er angehalten, einen Bugreport in bestem Englisch zu formulieren und mit einem Texteditor wie Emacs oder Vi einzugeben. Für Anfänger empfehlenswert: »export EDITOR=nano« .

Am Ende dieser Mühen wird er aber unter Umständen feststellen, dass Reportbug die Meldung gar nicht abschicken konnte, da es sie direkt per SMTP-Protokoll an den Mailserver des Debian-Projekts zustellen will. Das erlauben aber viele Netzwerke nicht und vereiteln den Versuch per Firewall, da auch Trojaner gerne direkte Verbindungen zu einem SMTP-Port aufmachen, um sich zu verbreiten. Nun liegt eine Textdatei mit dem sorgfältig generierten Bugreport in einem Temporärverzeichnis und lässt sich nicht versenden.

Wenn der Anwender jetzt noch nicht genug hat und etwas Zeit mit Recherche verbringt, findet er vielleicht einen Web-Gateway zu Debians Bugtracking-System. Das Webformular erlaubt oft nur, Bugreports zu bearbeiten oder zu ergänzen, für neue müsste der Anwender Informationen von seinem Rechner sammeln, die nur Reportbug zusammenstellt.

Als Workaround schickt der mittlerweile recht strapazierte Anwender die Textdatei mit dem zuvor generierten Report per Mail an die Adresse, die in einer der vielen Statusmeldungen stand. Wenn das klappt, bekommt der Paketmaintainer eine Nachricht und der Anwender selbst Feedback, sobald sich etwas bezüglich seines gemeldeten Fehlers tut.

Der falsche Weg zum Erfolg?

Wer ähnliche Erfahrungen gemacht hat, wundert sich nicht, dass ich mich bei meinen nicht kommerziellen Projekten wie Knoppix nicht immer an die Vorgaben von Debian oder den neuesten Stand des Software Engineering halte. Ich bin bekannt dafür, Probleme auf einem unorthodoxen Weg zu lösen.

Ich bin ungeduldig, denn schließlich möchte ich etwa mit meiner neuen Release nicht so lange warten, bis der zuständige Debian-Package-Maintainer mir eine Mail schreibt. Darin erklärt er dann im Detail, warum er das Problem mit meiner vorgeschlagenen Lösung nicht beheben kann oder will – und auf jeden Fall nicht wird.

Daneben belehrt er mich, warum ich trotz meines funktionierenden Patch auf Upstream warten soll und warum ich wegen diverser Dinge, die in Knoppix technisch bedingt nun mal anders laufen, sowieso kein offizielles Derivat – einen so genannten Debian Pure Blend [3] – entwickle, womit ich möglicherweise beim Debian-Projektteam von vornherein unten durch bin.

Weil ich viele Dinge selbst repariere, ohne jemanden um Erlaubnis zu bitten, tut mir diese Reaktion aber nicht sonderlich weh. Mein persönlicher Workaround sieht so aus:

• Ich identifiziere den Fehler und behebe ihn möglichst bereits lokal in Knoppix. Dazu forke ich das Softwarepaket mit funktionierender Lösung. Nach Open-Source-Manier biete ich die veränderten Quellen unter [4] an.
• Ich verfasse eine genaue Fehlerbeschreibung und schicke sie per Reportbug oder Mail samt Lösungsvorschlag an den zuständigen Debian- oder Kernel-Maintainer.
• Falls der Fehler tatsächlich irgendwann im Upstream behoben ist, ersetze ich mein geforktes Paket wieder durch das Original.

Die ärgerlichste Antwort, die ich auf meine Fehlermeldungen bekommen habe, lautet: “Das Problem hat, wenn überhaupt, lediglich in der Praxis Relevanz.” Ich habe sie tatsächlich mehrfach erhalten, in verschiedenen Sprachen, auf die Frage, ob man einen meiner Meinung nach dringenden Bugfix für ein Stabilitätsproblem akzeptieren würde.

In den Diskussionen ergibt sich oft eine grundsätzlich unterschiedliche Weltanschauung darüber, ob der Fokus bei Software im Allgemeinen oder beim Kernel im Speziellen eher auf dem herausragenden Beispiel für sauberes Software-Engineering oder aber in praxisrelevanten Lösungen liegen sollte. Dabei sind die beiden Positionen keineswegs unvereinbar – es dauert offenbar nur recht lange, sie unter einen Hut zu bekommen.

Die leidige Praxis

Die Diskussion zwischen Theoretikern und Praktikern könnte erklären, warum es zwischen den einzelnen Linux-Distributionen etliche funktionale Unterschiede gibt. Die einen sehen eine Erweiterung als für ihre Distribution wichtiges Feature an, den anderen ist der gleiche Code hingegen nicht rein genug, um offiziell in die Standard-Codebasis aufgenommen zu werden, die zwischen fast allen Distributionen identisch ist.

Kritisch wird es, wenn für schon länger bekannte Fehler, die die Systemstabilität oder die Sicherheit gefährden, niemand einen Fix in die Basissoftware integriert, weil sich die Betreuer und Hauptentwickler des Softwarepakets uneinig sind, an welcher Stelle und wann das Problem korrekt zu lösen sei, obwohl bereits funktionierende Lösungen existieren.

In Knoppix 7.0.5 sah ich mich erstmals genötigt, den offiziellen Kernel zu patchen, weil ansonsten die RAM- und Swap-Kompression (ein sehr nützliches Feature für Rechner mit wenig RAM) entweder zum Einfrieren des Systems geführt hätte oder ich das Feature zumindest vorläufig hätte entfernen müssen. Das einfache Patch, das das Problem behebt, war bereits im November 2012 bekannt und öffentlich verfügbar. Leider ist es bis zum Redaktionsschluss dieses Linux-Magazins immer noch nicht im offiziellen Kernel angekommen [5].

Offenbar hatte bisher niemand Zeit oder sah nicht die Dringlichkeit, sich des Problems anzunehmen, das vor allem viele Live-Distributionen betrifft, obwohl es viel Mailverkehr bis hin zu Linus Torvalds deswegen gegeben hat. Manchmal funktionieren die Eskalation und die Behebung von Fehlern bei freien Softwareprojekten offenbar nicht besser – wenn auch nicht schlechter – als bei proprietärer Software.

Mein Dauerprojekt Knoppix möchte ich dabei gar nicht von der Kritik ausnehmen. Ich kann bei Weitem nicht rasch genug – oder überhaupt – auf jede E-Mail antworten, die ich dazu bekomme. Ich kenne also auch die Perspektive der meist mit Anfragen überhäuften Entwickler. Mein Live-Linux war aber von Anfang an als ein persönliches, wenn auch veröffentlichtes Lern- und Produktivitätsprojekt angelegt, an dem nur wenige Personen direkt mitentwickeln. Und dabei ist es geblieben. (mhu)