Open Source im professionellen Einsatz
© xalanx, 123RF.com

Über die Free-Software-Community und ihre Eigenheiten

How To Do Things The Wrong Way Successfully

Unbearbeitete Bugreports, ewiges Warten auf Upstream, weltfremde Diskussionen: Klaus Kopper, Herausgeber der Live-Distribution Knoppix, macht sich Gedanken über ein paar Dinge, die seiner Meinung nach in der Open-Source-Welt schief laufen.

Entgegen dem allgemeinen Trend vieler anderer Autoren mit der selbstverständlich Open-Source-freundlichen Einstellung, alle Nutzer von GNU/Linux zum Mitmachen aufzufordern, werde ich im folgenden einige Geschichten aus dem Real Life von Nutzern und Entwicklern Freier Software zum Besten geben, die einen vielleicht etwas unerwarteten Verlauf nehmen.

Das typische Szenario, das wohl jeder schon erlebt hat, der beginnt, sich mit Open Source und Freier Software näher zu beschäftigen, ist: Ich habe ein Problem mit oder eine Frage zur Software, und alle sagen mir, dass bei Freier Software eine große Gemeinde vorhanden sei, die sich aller Probleme annimmt und Einstiegshilfen bietet.

Aber: Wer ist jetzt für meine Frage oder mein Problem zuständig, wie melde ich mich richtig? Muss ich englisch sprechen, Foren oder komplizierte Bugtracker verwenden? Und warum verhalten sich die hochgelobten Entwickler, wenn man sie mal erreicht, so komisch, wenn ich doch einfach nur erklären will, was bei mir nicht funktioniert hat, oder was ich mir als Erweiterung wünsche? Halten die mich vielleicht für doof, nur weil ich selbst nicht programmieren kann oder möchte?

Ich will mich selbst hier nicht ausschließen, auch mein Dauerprojekt Knoppix folgt nicht eins zu eins dem empfohlenen Vorgehensmodell im Software Engineering, aber das muss es auch nicht, da es von Anfang an als ein persönliches, wenn auch veröffentlichtes Lern- und Produktivitätsprojekt angelegt war und ist, an dem nur wenige Personen direkt mitentwickeln, und das nicht, wie bei großen Projekten sonst üblich, koordiniert werden müsste. Und auch ich kann aus den noch zu schildernden Gründen bei weitem nicht so schnell, oft oder überhaupt auf jede E-Mail antworten, oder allen Wünschen gerecht werden, kenne also auch die andere Seite.

Warum antwortet mir keiner?

Ein häufiges Szenario ist die unbeantwortete Frage im Forum (worauf man auch oft stößt, wenn man seine eigene Frage in einer Suchmaschine eingibt). Offenbar tritt das Problem, für das man eine Lösung sucht, doch bei vielen auf, doch die meisten Fragen bleiben unbeantwortet, oder die Antworten sind schnell, und viele - aber schlichtweg alle falsch oder sie bringen keine wirkliche Lösung.

Der Grund für die unbeantwortete Frage kann einfach der sein, dass man den oder die falschen befragt. Gäbe es unter GNU/Linux doch nur so viele tatsächliche Experten wie Windows-Anwender, die sich für Experten halten ... Lassen wir das, jedenfalls kommt es nicht selten vor, dass die Frage "Warum komme ich mit meinem Rechner unter Linux nicht ins Netzwerk?" mit vielen professionell wirkenden, ausführlichen und fachkundigen Beträgen honoriert wird, die allesamt am Problem vorbeireden. "Nimm doch lieber eine andere Distribution!", oder "Vielleicht ist dein Accesspoint zu langsam?", oder "Hast Du schon mal ein Update versucht?" widmen sich weniger dem Problem als einem früheren und leider selten reproduzierbaren eigenen Erfolgserlebnis, zum Beispiel, wie man damals selbst Internet-Zugang erhielt, als es noch "wirklich schwierig" war. Der Nachsatz „Aber unter Windows komme ich ohne Probleme ins Netz.“ macht alles nur noch schlimmer, weil er das Problem weder erklärt, noch zur Lösung beiträgt.

Kommt bei den "Unter Windows geht’s aber"-Anhängern eigentlich niemand auf die Idee, sich dort einmal die Netzwerk-Parameter analog, also auf ein Blatt Papier, aufzuschreiben, mit denen man damals das Windows-Netzwerk konfiguriert hatte? Die DSL-Zugangsdaten, das 32-stellige WPA-Passwort oder längst vergessene oder geänderte DSL-Zugangsdaten lassen sich unter Linux genauso gut oder schlecht "erraten" wie unter Windows, wenn man die Unterlagen seines Providers verlegt hat. Dass tatsächlich Treiber fehlen, ist unter Linux eher die Ausnahme.

Mitunter fühlt sich tatsächlich auch niemand für eine Frage zuständig - oder unfair behandelt, schließlich ist der Anbieter einer Softwaresammlung selten auch der alleinige Autor aller 9000 beinhalteten Programme. So kommt es nicht selten vor, dass jemand, der eine Distribution vorgeschlagen hat, automatisch als zuständiger "Techniker" gesehen wird, der ab sofort den Support zu leisten hat. Kostenlos natürlich, schließlich ist unter Linux ja alles kostenlos, nicht wahr? Es wundert dann nicht mehr, wenn die Anzahl von Personen, die in Foren gerne Antworten geben, stark zurückgeht zu Ungunsten der Fragenden, denn Support kostet nun mal immer etwas – und wenn es auch "nur" die eigene Freizeit ist, die man mit spannenderen Dingen verbringen kann.

Trolle

In jedem Forum gibt es selbsternannte IT-Experten, die sich einen Spaß daraus zu machen scheinen, mit unqualifizierten Aussagen oder undurchsichtigen Empfehlungen andere zu diskreditieren oder Fragesteller einzuschüchtern und zu verwirren. Manchmal werden auch Links auf für die Frage völlig irrelevante Seiten gepostet. Der Sinn dahinter ist mir selbst bis heute nicht klar, einige Verschwörungstheoretiker sprechen aber mittlerweile von Bezahltrollen, die durch Negativwerbung Forenbesucher auf "die andere Seite" ziehen sollen, was immer das bedeutet. Andere mutmaßen dass Foren vielleicht eine ähnliche Funktion wie ein Psychologe haben: Jemand hört immer zu, egal, was man sagt.

Mein Tipp: Ignorieren. Diskussionen über sinnfreie Inhalte und persönliche Anfeindungen machen nichts besser, alleine schon das Herausfinden, was denn eigentlich mit einer kontroversen Aussage gemeint sein könnte, kostet viel Zeit und macht die Stimmung auch nicht besser.

Intermezzo: Gibt es ein Leben ohne das Internet / Computer / soziale Netzwerke?

Als quasi zweites Vorwort, noch eine kurze vorauseilende Entschuldigung: Auch Software-Entwickler und Software-Supporter sind Menschen, die ein einigermaßen geregeltes Einkommen, und auch mal Zeit für sich und/oder die Familie - ohne Computer - brauchen, und die mit der Zeit, die sie nun mal am Computer (das allerdings oft und gerne!) verbringen, irgendwie haushalten müssen. Manchmal ist es – leider – einfach nicht möglich, alle Fragen an einem Tag zu beantworten, und es ist oft nicht leicht, die optimale Priorität für die Bearbeitung aller Aufgaben zu finden, so dass nichts oder nur sehr wenig liegenbleibt. Gewagte Hypothese: Etwa 400 bis 600 E-Mails am Tag (wie lange der dauert, ist Definitionssache) kann ein Mensch mit sinnvollem Inhalt bearbeiten, der sonst aber nichts anderes mehr tun muss. Alles darüber hinausgehende bleibt potenziell liegen. Auf der positiven Seite melden sich die dringenden Fälle, deren Anfragen bis dato nicht bearbeitet wurden, meistens doch noch einmal, wenn sich ihre Frage nicht von alleine erledigt hat.

Ich würde sagen, dass die Tatsache, nicht alle Mails beantworten zu können, die eine Antwort verdienen, und damit die Absender zu enttäuschen, ebenso frustrierend ist, wie in umgekehrter Richtung selber eine E-Mail oder Anfrage nicht beantwortet zu bekommen, bei der man sich doch viel Mühe mit der Formulierung und vorausgehender eigener Recherche gemacht hat.

Technische Lösungen zur Ablaufoptimierung (die in den nächsten Abschnitten noch behandelt werden) helfen nur bedingt weiter, wenn die für die Erledigung einer Aufgabe verfügbare Zeit einfach geringer ist als die tatsächlich notwendige Zeit.

Nach diesem Versuch, das Problem etwas zugunsten der Entwickler zu beleuchten, wenden wir uns den Szenarien zu, in denen die von der Community bevorzugten Lösungen unterschiedlich gut funktionieren.

"Benutze den Bugtracker"

(Oder: "Use the force"?). Die sicherste Art, doch noch jemandem zu erwischen, der zuständig ist (weil er das Programm tatsächlich mitgeschrieben hat oder sich als Maintainer für das entsprechende Softwarepaket "geopfert" hat), ist das jeweilige Bugtracking-System der verwendeten Distribution, oder die Developer-Mailingliste. Vielleicht bekommt man dort die eigene Frage beantwortet? Unpraktisch nur, wenn man sich in dem technischen Jargon, der verlangt wird, nicht auskennt, oder sich in der verwendeten Kommunikationssprache – meist "Techno-Englisch", nicht wohl fühlt.

Ein Beispiel aus der wunderbaren Welt von "reportbug", dem Bugtracker von Debian (und damit auch der meisten Debian-Derivate): Nachdem der hoch motivierte fortgeschrittene Anwender, der einen Bug in "mkisofs" melden möchte, sich durch die 102 (!) noch ausstehenden Fehlerbehebungen gekämpft hat, um festzustellen, ob der zu berichtende Fehler überhaupt neu ist, oder wenigstens neue Erkenntnisse zu dessen Behebung beigetragen werden können, nachdem dann ein Report in einem genau einzuhaltenden Textformular in bestem Englisch formuliert und mit dem beliebten Texteditor Emacs Oder Vi eingegeben wurde (für Anfänger empfehlenswert: "export EDITOR=nano"), nachdem alle Abhängigkeiten untersucht und das Szenario, in dem der Fehler auftritt berichtet wurde, stellt man unter Umständen fest, dass das Programm Reportbug die Meldung nicht abschicken konnte, da es direkt per SMTP-Protokoll an den Mailserver des Debian-Projektes zustellen will – was viele Schulen und Einrichtungen nicht erlauben und per Firewall sperren, da direkte Verbindungen zu einem SMTP-Port auf externen Mailservern gerade auch von Trojanern zur Verbreitung verwendet werden. Da liegt nun eine Textdatei in einem Temporärverzeichnis mit dem sorgfältig generierten Bugreport und kann nicht versendet werden.

In Debians Tool Reportbug muss sich der Anwender unter Umständen erst einmal durch eine lange Liste von ausstehenden Bugs kämpfen.

Wenn der Anwender jetzt noch nicht genug vom "richtigen Weg" des Bugreportings hat, und noch etwas Zeit mit Recherche verbringt, findet sich vielleicht noch ein Web-Gateway zum Debian Bugtracking-System, was allerdings, da nur per Webformular bedienbar, oft nur die Bearbeitung oder Ergänzung alter Bugreports erlaubt, denn für die neuen müssen die Informationen vom eigenen Rechner gesammelt werden, auf die nur Reportbug Zugriff hat.

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

Es wird explizit von Debian empfohlen, nicht den Autor des Programms selbst anzuschreiben, sondern immer den Debian-Paketmaintainer. Dieses organisatorische Feature erlaubt es dem Paketmaintainer, die Fehler zu sammeln, richtig zu kategorisieren, eventuell auch selbst Patches zu entwickeln und an den Original-Autor der Software zu schicken, damit der Fehler nicht nur in Debian, sondern auch für alle anderen Distributionen behoben wird. Debian nennt den Programmentwickler "Upstream", was gleichzeitig die Original-Softwarequelle bezeichnet.

Prinzipiell ist dieses Verfahren sicher gut und sinnvoll. Wenn man sich allerdings die sehr langen Listen der ausstehenden Fehlerbehebungen in einigen Programmen anschaut, fragt man sich, welcher Distributor so viel Zeit hat, um auf die Behebung aller Fehler in Upstream zu warten, geschweige denn der Anwender, der immer noch das gleiche Problem hat, und – vielleicht vergeblich – auf eine schnelle Lösung hofft.

Knoppix – der falsche Weg des Bugfixing?

An dieser Stelle noch einmal eine persönliche Anmerkung: In Bezug auf meine non-commercial-Projekte bin ich durchaus bekannt dafür, Probleme auf dem "falschen" Weg zu lösen (oder: mich vielleicht nicht ganz an die Regeln zu halten).

Ich gebe zu: Auch ich bin ungeduldig, ich möchte zum Beispiel mit dem Release einer neuen Version nicht so lange warten, bis der jeweilige Debian Package-Maintainer mir sehr rational und natürlich unvoreingenommen im Detail erklärt hat, warum er das Problem mit meiner vorgeschlagenen Lösung nicht lösen kann oder will, auf jeden Fall nicht lösen wird, warum ich trotz meines funktionierenden Patches auf Upstream warten soll, und warum ich wegen diverser Dinge, die in Knoppix technisch bedingt nun mal anders laufen, sowieso keinen "Debian Pure Blend" (http://blends.alioth.debian.org) entwickle, womit ich möglicherweise beim Debian Projektteam von vornherein unten durch bin und jeglichen Anspruch auf eine offizielle Problemlösung verwirkt habe, was mir auf der anderen Seite aber auch nicht sonderlich weh tut, weil ich ja dazu tendiere, viele Dinge selber und ohne jemand um Erlaubnis zu bitten, zu reparieren.

Mein persönlicher Workaround lautet also:

  1. Fehler identifizieren, nach Möglichkeit bereits lokal (in Knoppix) beheben, Softwarepaket mit funktionierender Lösung "forken", konform mit der Open-Source-Policy werden die Quellen unter http://debian-knoppix.alioth.debian.org veröffentlicht
  2. Genaue Fehlerbeschreibung generieren, per Reportbug oder Mail an den zuständigen Debian- oder Kernel-Maintainer mit Lösungsvorschlag schicken
  3. Falls der Fehler tatsächlich in Upstream irgendwann behoben ist, das geforkte Paket wieder durch das Original ersetzen

"Das Problem hat, wenn überhaupt, lediglich in der Praxis Relevanz"

Ernsthaft: Schon mehrfach habe ich diese Antwort bekommen, in verschiedenen Sprachen, auf die Frage, ob man einen meines Ermessens dringenden Bugfix für ein Stabilitäts-Problem akzeptieren, oder einen neuen virtuellen Dateisystem-Treiber in den Kernel aufnehmen könnte. In Diskussionen ergibt sich dabei oft eine grundsätzlich unterschiedliche Weltanschauung darüber, ob der Fokus bei Software im Allgemeinen, oder beim Kernel im Besonderen eher auf dem herausragenden Beispiel für sauberes Software-Engineering (oder "die Kunst des perfekten Programmierens"), oder aber hingegen eher im realen Einsatz praxisrelevanter Bereiche liegen soll.

Dabei sind die beiden Positionen keineswegs unvereinbar, es dauert nur offenbar immer etwas länger, sie unter einen Hut zu bekommen. Als Pragmatiker würde ich dazu tendieren, häufig eingesetzte Kernel-Erweiterungen sehr freizügig im Staging-Bereich unterzubringen, so dass sie jeder benutzen kann, der entsprechend experimentierfreudig ist. Auf der anderen Seite sind die Entwickler von Distributionen natürlich auch in der Lage, entsprechende Patches in ihren Kernel selbst zu integrieren.

Die Diskussion zwischen Theoretikern und Praktikern könnte erklären, warum wir zwischen den verschiedenen Distributionen doch etliche funktionale Unterschiede beobachten können. 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.

Wirklich kritisch wird es, wenn für schon länger bekannte Fehler, die die Systemstabilität oder Sicherheit gefährden, keine Fehlerbehebung in die Basissoftware integriert wird, weil sich die Betreuer und Hauptentwickler der Software uneins sind, wie, an welcher Stelle und wann das Problem "richtig" zu lösen ist, obwohl bereits funktionierende Lösungen existieren. In Knoppix 7.0.5 sah ich mich erstmals genötigt, den offiziellen Kernel entsprechend zu patchen, weil ansonsten die RAM/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 vorerst hätte entfernen müssen. Der relativ triviale Patch, der das Problem behebt, war bereits im November 2012 bekannt und öffentlich verfügbar, leider ist er bis jetzt (Stand Januar 2013) immer noch nicht in den offiziellen Kernel übernommen worden. Offenbar hatte 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 Mr. Torvalds deswegen gegeben hat. Manchmal funktioniert die Eskalation und Behebung von Fehlern bei Freie Software Projekten wohl doch nicht besser, wenn auch zumindest nicht schlechter, als bei proprietärer Software.

Community-Software in der Schule - Beispiel Debian Edu

Da ich selbst Lehrer bin, weiß ich ein gut funktionierendes IT-System mit zentraler Benutzerverwaltung genauso zu schätzen, wie stabile und universell einsetzbare Client-Software für den Unterricht. Viele GNU/Linux-Distributionen, und speziell Debian, bieten hierfür eine riesige Auswahl an Software für den Unterricht, zur Planung und zur Benutzerverwaltung an, aus der man sich frei bedienen kann.

Ein engagierter und Linux-kundiger Lehrer, und so ist es an vielen Schulen der Fall, kann oft an einem Nachmittag einen kompletten Schulserver für alle Klassen, mit Terminalserver, WWW-Proxy und Backupsystem, ganz alleine aufsetzen. Obwohl das viel Spaß machen kann, und man eine Menge dabei lernt, ist es etwas unsicher: Was passiert mit dem selbst gebauten IT-System, wenn der Lehrer die Schule wechselt oder aus dem Dienst ausscheidet? Dann wäre es doch besser, eine von Fachpersonal installierte und langfristig gewartete Lösung, natürlich ebenfalls auf Open Source Basis, anzuschaffen.

Das Problem bei der Sache: Schulen (außer solche mit starkem Informatikbezug) wollen eigentlich nicht den Baukasten, den Debian liefert, sondern ein in sich stimmiges und vorkonfiguriertes Produkt, das sich sofort einsetzen und mit wenig Aufwand auch langfristig von frei wählbarem IT-Personal aktuell halten lässt.

Debian Edu ist ein solches, auf Debian basierendes Community-Projekt und Derivat mit vorkonfigurierter LDAP-basierter Benutzerverwaltung, File- und Printserver, Thin- und Workstation-Clients. Leider sehr "speziell": Einige Eigenheiten wie LDAP-basierter DNS und eine recht eigenwillige Netzwerk-Konfiguration bedingen oft Umstellungen des Schulnetzwerkes, um den Aufwand für die Installation gering zu halten.

Die große Überraschung kommt jedoch auf die Betreiber des Systems zu, sobald eine neue Version erscheint: Anders als bei Debian mit den gewohnt nahtlosen Updates, ist bei Debian Edu bislang mit jeder neuen Version eine vollständige Neuinstallation notwendig gewesen. Eigene Änderungen gehen dabei verloren, sofern sie nicht offiziell in die Debian-Edu-Softwarebasis übernommen wurden. Was dort integriert wird, unterliegt jedoch einem langwierigen Entscheidungsprozess. Erweiterungen, die wir im Rahmen eines dreijährigen Projektes für Schulen in Rheinland-Pfalz entwickelt haben, um einen sicheren Klassenarbeitsmodus, Desktop-Projektion und einige Netzwerkoptimierungen für WLAN-Netze zu integrieren, scheiterten leider an der Aufnahme in die offizielle Distribution, und müssen nach wie vor manuell nachinstalliert werden. Unsere Entwickler fühlten sich zuletzt sehr ausgegrenzt, an Entscheidungsprozessen nicht beteiligt, trotz aller Bemühungen und Ausrichtung von Entwicklertreffen des Projekts für und zusammen mit der Debian-Edu-Community.

So lange die Software in der Schule das tut, was sie soll, bleiben die internen Probleme zumindest von den Anwendern allerdings größtenteils unbemerkt.

Und sie bewegt sich doch

Mein Fazit daraus: Einige Communities sind offener und zugänglicher als andere, und natürlich haben alle ihre durchaus nachvollziehbaren Gründe für ihre jeweilige Organisationsstruktur. Bevor man sich beteiligt, Zeit und Arbeit investiert, sollte man sich jedoch mit den Zielen, Abläufen und der Koordination des Projektes vertraut machen, und nicht zu viel Energie in "systematisch unmögliche" Veränderungen investieren, die in der Struktur nicht vorgesehen sind. Und manchmal ist es besser, flexibel mit den Regeln umzugehen, wenn man an einem schnellen Erfolg interessiert ist.

Eine vernünftige Community verzeiht auch vieles, wenn das gemeinsame Ziel im Vordergrund steht.

Beim kooperativen Software-Entwicklungsmodell von Open Source kann eine motivierte Community aus Entwicklern und Anwendern eine selbstorganisierende und antreibende Kraft für die Verbesserung Weiterentwicklung und Verbreitung der Software sein, auch wenn das Zusammenspiel nicht immer einfach ist. Oft genug funktioniert es eben doch.

Ausgabe 09/2014

Digitale Ausgabe: Preis € 6,40
(inkl. 19% MwSt.)

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.

Insecurity Bulletin

Insecurity Bulletin

Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...

Linux-Magazin auf Facebook