Die Woche: Freie Software zwischen Anspruch und Entwicklung

Lang erwartet und mit praktisch komplett neuem Unterbau (siehe Artikel Neues in KDE 4.0) ist Anfang dieses Jahres KDE 4.0 erschienen. Die technische Entwicklung ähnelt der, die KDE beim Sprung auf Version 2.0 des Desktops machte. Damals war die Begeisterung groß: Der Konqueror löste nicht nur kfm als Dateimanager ab, sondern bot sich auch als Browser-Alternative an; neue Programme, Features und Änderungen in der Architektur versprachen ein neues Desktop-Erlebnis. Da es die Anwender kaum erwarten konnten, lieferte Version 7.0 von Suse Linux im September 2000 sogar eine Betaversion von KDE 2.0 zur optionalen Installation mit.

Auch auf KDE 4 haben die Anwender mit Spannung gewartet, doch die Anspruchshaltung ist seit damals gestiegen.

So gab es für die neue Desktop-Shell Plasma, die Umstellung von DCOP auf den Standard D-Bus zur Interprozesskommunikation, die neuen Frameworks Phonon und Solid für Multimedia und Hardware eher leises Lob. Vielmehr hagelte es Prügel und Häme – das Diskussionsforum zur Meldung Erstes Bugfix-Release für KDE 4 vor wenigen Tagen zeigt die Haltung vieler Anwender.

Sicher, das angekündigte Akonadi-Framework zur Speicherung von PIM-Daten wurde nicht fertig, sodass KDE 4.0 ohne Korganizer und Kmail erschienen ist; und auch der beliebte Audio-Player Amarok fehlt. Instabile Anwendungen, Abstürze des Desktops und ein funktionsarmes neues Panel, das sich nicht einmal verschieben lässt, gaben ebenfalls Anlass zur Kritik.

Aber selbst eingefleischte KDE-Fans waren eher in mäkeliger als freudiger Stimmung angesichts der neuen Version: In Foren, Chats und Mailinglisten ärgerte man sich gemeinsam über nicht fertige und fehlende Features, beklagte sich, als Beta-Tester missbraucht zu werden, und manche drohten gar mit einem Wechsel der Desktop-Umgebung. Lob gab es eher in verbrämter Form, meistens abgeschwächt durch einen mit "aber" beginnenden Nebensatz.

Nun kann man sagen: "Wer wie das KDE-Projekt sogar auf Unternehmensdesktops will, muss sich auch böse Schelte gefallen lassen". Doch sollte man nicht vergessen, dass die Entwicklung freier Software eigentlich genau wie bei KDE 4 funktioniert. Eric S. Raymond hat in seinem Essay The Cathedral and the Bazaar die Entwicklung von Open-Source-Software mit einem Basar verglichen, wo der der Code nicht im stillen Kämmerlein hinter geschlossenen Türen entsteht, einem festen Bauplan folgt und in ein fertiges Produkt mündet. Vielmehr darf – und soll – bei freier Software jeder seinen Teil zur Entwicklung beisteuern.

Allerdings ergibt sich daraus, dass man nie sagen kann, die Software sei "fertig". Das Prinzip, Software oft und auch in einem frühen Entwicklungsstand zu veröffentlichen, kann dem Code nur gut tun, da man nur so ausreichend Feedback und Bugreports von den Anwendern erhält. Der Erfolg freier Software beruht gerade darauf, dass sie inmitten einer großen Gemeinschaft gedeiht, die eben nicht nur aus einem geschlossenen Kreis von Entwicklern besteht: Jeder einzelne kann etwas zu freien Projekten beitragen – sei es Code, Artwork, eine Übersetzung, Bugreports oder Feedback an die Entwickler. Das Prinzip funktioniert seit Jahren und es gab lange Zeit kaum Kritik, wenn ein Feature fehlte oder ein Programm instabil war: Schließlich hatte man die Software kostenlos erhalten, hatte Einblick in den Code und konnte nach Herzenslust selbst daran herumbasteln.

In seiner Biographie "Just for fun" erzählt Linus Torvalds von einer Mail, die er in den Anfangstagen der Linux-Entwicklung erhielt. Der Verfasser lobte Linux in mehreren Absätzen, um schließlich mitzuteilen, er habe wohl einen Fehler im Plattentreiber gefunden, dieser habe nämlich seine Festplatte zerstört und er so alle Daten verloren. Doch diese Zeiten sind offenbar vorbei: Statt Pioniergeist pflegen auch die Nutzer von Open-Source-Software ihre Qualitätsansprüche und erwarten, mit einer neuen Version ein fertiges, ausgereiftes Produkt zu erhalten. Programme sollen einfach funktionieren und dafür haben die Entwickler zu sorgen.

Dieses Anspruchsdenken kommt nicht von ungefähr. Seitdem Open Source salonfähig geworden und eine Alternative zu kommerzieller Software ist, gibt es mehr als genug freie Projekte, deren Entwicklung eher nach dem Kathedralenmodell funktioniert: Man stellt eine Roadmap mit klar verteilten Verantwortlichkeiten auf, kümmert sich im Rahmen der Qualitätssicherung um ausgiebige Tests, statt nach dem "Works for me"-Prinzip vor sich hin zu werkeln und den Anwendern das Testen zu überlassen, und plant für jedes Release bestimmte Features ein, die dann auch fertig sein müssen. Beispiele für solche Projekte sind neben Anwendungen im Business- und Server-Bereich – etwa Apache und MySQL – auch Projekte wie Gnome, OpenOffice, der Linux-Kernel oder Ubuntu. Die Benutzer haben sich daran gewöhnt, das sie auch bei freier Software Anwendungen erhalten, die zuverlässig und stabil arbeiten und bei denen man nicht unvermutet auf Baustellen trifft.

Reversibel ist diese Entwicklung wahrscheinlich nicht. Freie Projekte werden sich überlegen müssen, zu welchem Entwicklungsmodell sie tendieren und welches für sie größeren Erfolg verspricht. An kleine Entwickler-Communities werden die Anwender weniger Qualitätsansprüche stellen als an große, populäre Projekte vom Kaliber Firefox.

Aber wenn sich ein großes Projekt einen Teil der Freiheit auf dem Basar erhalten will, muss es die Anwender von Anfang an darauf hinweisen, welche Fehler ein neues Release noch hat. Erst kurz vor dem Release von KDE 4.0 erschien ein Artikel von Stephan Binner mit der Kernaussage "KDE 4.0 is not KDE 4", der auf die noch vorhandenen Schwächen der Desktop-Umgebung hinwies. Dabei darf man nach guter alter Linux-Tradition von einem Major-Release durchaus erwarten, dass dessen Kern-Features zuverlässig funktionieren. Die Entscheidung, statt eines KDE 4.0 – das nicht ist, was es mit der Versionsnummer vorgibt zu sein – eine Version 3.99 zu veröffentlichen, hätte den Entwicklern wohl viel Kritik erspart und die hohe Anspruchshaltung vieler Nutzer gar nicht erst aufkommen lassen. (amu) (amu)