Seite 4: Kritik an freier Software

Kritiker bemängeln, Open-Source-Entwicklung sei chaotisch: Es fehle an Management, Controlling und Marketing, zu selten würden definitive richtungsgebende Entscheidung getroffen. Tatsächlich kann ein Open-Source-Projekt genau wie ein Closed-Source-Projekt auf unterschiedliche Weise "gemanagt" werden. Wie Eric Raymond in seinem Essay Homesteading the Noosphere beschreibt, werden viele Open-Source-Projekte von einem "wohlwollenden Diktator" geleitet, der entscheidet, welche Veränderungen den Weg in die offizielle Version eines Programms finden. Je nach Projekt hat dieser Leiter einen unterschiedlich starken Einfluss, und manche Projekte werden demokratisch oder anarchistisch verwaltet: Es wird abgestimmt, oder jeder Autor hat die gesamte "Macht" über das Projekt, und Fehler werden von der Mehrzahl der Autoren letztlich gegenseitig ausgeglichen, ähnlich wie bei Wiki-Webs wie Wikipedia.

Welches dieser Modelle das "richtige" ist, hängt letztlich auch vom Projekttyp ab, woraus sich z.B. eine unterschiedlich große Zahl von Entwicklern, Häufigkeit von Veränderungen und Wichtigkeit schneller Veröffentlichung ergibt.

Kritiker merken weiterhin an, dass unzählige Open-Source-Projekte schlicht inaktiv bleiben - SourceForge ist voll von solchen "Projektleichen". Das hat mit mehreren Faktoren zu tun:

1. Hobbyisten haben eine tolle Idee, es fehlt ihnen aber das Wissen oder die Motivation, sie umzusetzen. Dies kann schon zu Anfang des Projektes geschehen oder erst später.
2. Ein vormals lebendiges Projekt kann durch den Ausfall einer Schlüsselperson einen schnellen Tod erleiden. Job und Familie können unerwartet in die Quere kommen.
3. Es gelingt dem Projektleiter nicht, sein Projekt bekannt zu machen. So mangelt es dem Projekt sowohl an Nutzern als auch an Entwicklern, bis es schließlich eingestellt wird (selbst wenn es von guter Qualität ist).
4. Das Projekt verwendet eine Programmiersprache oder Bibliotheken, die eine Massenverbreitung verhindern. Auch unterschiedliche Lizenzen ziehen unterschiedliche Entwickler an.
5. Programmierer haben untereinander Konflikte, die Entwicklung spaltet sich oder schläft ein. Entscheidungsprozesse funktionieren nicht.
6. Die Ziele eines Projektes wurden zu hoch gesteckt, die gewünschte Funktionalität wird nicht erreicht oder in einer Form, die für niemanden außer dem Programmentwickler selbst von Interesse ist.

Fast alle diese Probleme - und einige spezifische - gelten in anderer Form auch für Closed-Source-Software. Der wesentliche Unterschied ist, dass sie bei Open-Source-Software offener sichtbar sind. Natürlich kann man aber auch für diese Probleme Lösungen erarbeiten (dazu mehr in Teil 3).

Als Beispiel für Open-Source-Software von minderwertiger Qualität wird oft der Web-Browser Mozilla angeführt: Im Januar 1998 wurde der Code des Netscape-Browsers freigegeben und so eine offene Weiterentwicklung ermöglicht, in der Hoffnung, dem Beinahe-Browser-Monopolisten Microsoft auch ohne Mammut-Investments Paroli bieten zu können. Doch das Projekt war bislang ein Fehlschlag: Zwar verfügt Mozilla über exzellente Funktionalität und hält sich penibel an die Standards des W3C, doch Speicherbedarf, Geschwindigkeit und Stabilität lassen nach wie vor sehr zu wünschen übrig. So sehr, dass viele Stimmen (unter anderem das Online-Magazin Suck) gar forderten, das Projekt endlich zu begraben und neu anzufangen.

Mozilla und auch das von Sun freigegebene StarOffice unterscheiden sich jedoch von der meisten Open-Source-Software insofern, als dass der ursprüngliche Code nach dem traditionellen Closed-Source-Modell entwickelt wurde. Die Version von Mozilla, die den Open-Source-Hackern 1998 zur Verfügung gestellt wurde, war keineswegs identisch mit Netscape 4, den viele immer noch als Alternative zu IE benutzen. Vielmehr handelte es sich um eine interne Entwicklungsversion, die von Netscape als "nicht einmal Alpha" bezeichnet wurde - im Alpha-Stadium gilt eine Software als mit Sicherheit fehlerbehaftet, bis sie dann in der Beta-Phase zum Test freigegeben werden kann. Das Programm war so voller Bugs, dass sich die Entwickler entschieden, große Teile neu zu schreiben.

Dies geschah aber immer noch im Rahmen des von Netscape vorgegebenen Funktions-Frameworks, das ziemlich gigantisch war. Zu allem Überfluss scheinen aufgrund von Koordinationsproblemen immer mehr Funktionen hinzugefügt worden zu sein, während prinzipielle Fehler teils über Monate hinweg im Code verblieben. Eigens für die Verwaltung von Bugs und Vorschlägen wurde ein System namens Bugzilla entwickelt, das es unter anderem erlaubt, über die wichtigsten Fehler abzustimmen.

Da Bugzilla jedoch ein recht komplexes Interface verwendet und primär von Entwicklern genutzt wird, bleiben die meisten Bugs ohne Bewertung. Hier wären sicherlich Verbesserungen und eine größere Einbeziehung der Nutzer möglich. Denn wenn das Beseitigen wichtiger Fehler Entwicklern in der gesamten User-Community einen höheren Statusgewinn verschafft als das Hinzufügen hübscher neuer Features, könnte sich die Richtung der Entwicklung drastisch ändern.

Das eigentlich Erstaunliche an Mozilla ist, dass der Browser trotz allem stetig besser und stabiler geworden ist und trotz aller Kritik (die, wenn sie bösartig formuliert ist, für Freiwilligenprojekte oft tödlich sein kann) die Arbeit an dem Projekt emsig fortgesetzt wird. Während man es bei proprietärer Software oft erlebt, dass die nächste Version eines Programms deutlich schlechter ist als die vorherige, gilt es in der Open-Source-Gemeinde fast schon als selbstverständlich, dass ein neues Programmrelease besser sein muss als das vorherige. Das liegt nicht nur am Entwicklungsprozess, sondern auch an der stets gegebenen Möglichkeit, ein Programm zu "forken" (von engl. "fork", Gabel).

Wenn die neueste Version eines Programms nicht tut, was man will, und der Projektleiter Sturheit signalisiert, können sich andere Entwickler abspalten und das Projekt selbst weiterentwickeln. Da oftmals Nutzer und Entwickler identisch sind, ist die Motivation hierfür groß. Im Falle von Mozilla gibt es sowohl unter Windows als auch unter Linux Mozilla-Forks, die den Funktionsumfang des Browsers auf das Wesentliche reduzieren: K-Meleon und Galeon.

Was Open-Source-Projekten oft als Nachteil vorgehalten wird, nämlich die vielfach parallelen Entwicklungen, ist in Wirklichkeit ein großer Vorteil, der an die biologische Evolution erinnert: Veränderungen, die sich als nachteilhaft erweisen, sterben aus, während sich die beste Lösung langfristig durchsetzt. Dass ein solches System von seinen Partizipanten mehr kritisches Denken erfordert als eine Monokultur, ist klar.