Wer codiert?

Inhaltsverzeichnis

Wie ist es möglich, dass wenig organisierte, unabhängige Entwickler dezentral und ohne finanzielles Interesse wettbewerbsfähige Software schreiben, für die Firmen Entwicklungskosten in Millionenhöhe aufbringen müssen? Analysten wie Eric S. Raymond bieten dazu Erklärungsmodelle an. Das bekannteste ist sein Paper ‘The Cathedral and the Bazaar’ [1], das die Interna eines ‘Freie Software’-Projekts am Beispiel von fetchmail beleuchtet. Dies weckte das Interesse kommerzieller Softwarefirmen: Ist die Methode übertragbar? Kann man sich einen Basar kommerziell zu Nutze machen?

Die Idee erscheint verlockend: Wenn man sowieso kein oder fast kein Geld mehr mit dem Verkauf von Lizenzen seines Produkts verdienen kann, warum nicht andere Leute umsonst für sich arbeiten lassen und mit deren Arbeit auf andere Weise Geld verdienen? Das überzeugende Paper ‘Setting Up Shop: The Business of Open-Source Software’ [2] des Netscape-Mitarbeiters Frank Hecker beschreibt detailliert Alternativen zum traditionellen Verkauf von Lizenzen; und führte schließlich zur Freigabe des Mozilla-Quellcodes. Das Ereignis gilt als der Durchbruch des Open-Source-Modells in der professionellen Softwareentwicklung. Die Signalwirkung war immens, das Medienecho umwerfend. Andere Firmen folgten rasch oder sprachen zumindest davon. Selbst der Office-Suite-Hersteller Applix kündigte damals an, Teile seiner Produktpalette im Quellcode unter einer Open-Source-Lizenz zur Verfügung zu stellen.

Open Business mit Freier Software

Es steht außer Frage, dass das Open-Source-Modell funktionieren kann. Linux-Distributoren werden oft als Beispiel genannt. Sie verdienen ihr Geld jedoch nicht in erster Linie mit Software, sondern durch die Dienstleistung, Freie Software zusammenzustellen, zu vermarkten und professionellen Support anzubieten. Außerdem steht die Zahl der Autoren der Freien Software auf den CDs (einige tausend) in keinem Verhältnis zur Zahl der Personen, die durch den Verkauf von Distributionen verdienen. Support genügt hier also nicht, die Softwareentwicklung zu finanzieren. Gleiches gilt für Firmen wie WilberWorks, die das freie Bildbearbeitungsprogramm ‘The Gimp’ kommerziell vertreiben und supporten. Auch hier profitieren nicht die ursprünglichen Autoren der Software, es sei denn, über freundliche und freiwillige Spenden.

Neben Support gibt es noch weitere Open-Source-Business-Methoden. OpenSource.org nennt Lockprodukte, Software als Beigabe zu Hardware und Merchandising als die wichtigsten. Aber auch hier profitieren selten die eigentlichen Autoren. Welcher Linux-Programmierer näht und verkauft denn zum Beispiel Plüsch-Pinguine, um seine Programmierarbeit zu finanzieren? Richtig ist, dass jeder mindestens einen Plüsch-Pinguin hat. Wer schreibt denn schon Bücher über Freie Software? Richtig ist, dass jeder Programmierer einen Berg solcher Bücher in seinem Arbeitszimmer hat. Accessorizing ist wichtig, scheint die Mehrzahl der Programmierer Freier Software aber mehr Geld zu kosten, als ihnen einzubringen.

Zwei der Vorteile, die die Open-Source-Bewegung kommerziellen Softwareanbietern verspricht, sind Qualitätssicherung und schnelle Weiterentwicklung. Beides setzt ein breites Heer freiwilliger Programmierer voraus, die unentgeltlich Bugs fixen, Ideen liefern oder gar neue Features implementieren. Doch nicht jede Open-Source-Software hat einen kommerziellen oder proprietären Hintergrund wie Netscapes Browser Mozilla. Der überwiegende Teil Freier Software entsteht ‘from scratch’, also aus dem Nichts und ohne kommerzielle Absichten. Ein Beispiel für solche Software ist das K Desktop Environment (KDE), dessen Gesamtmenge an Quellcode diejenige von Mozilla inzwischen bei weitem übertrifft. Ein Projekt in der Größenordnung einer der umfangreicheren KDE-Applikationen von Grund auf neu anzufangen, bedarf sicherlich einer weitergehenden Motivation, als ‘mal eben schnell’ in fremdem Code einen Bug zu fixen. Denn als Entwickler ist man mit einer eigenen Anwendung in der Regel zwischen einem halben Jahr und zwei Jahren beschäftigt. Was motiviert diese Leute? Und was haben sie als Programmierer davon?

Alles nur selbstlose Egomaniacs

Die Antwort der Open-Source-Protagonisten auf diese Fragen ist dünn. Vielmehr wird auf die vielfältigen Möglichkeiten der kommerziellen Nutznießer der bereits entwickelten Software abgehoben. Neben kostenlosen und besseren Produkten besteht nach Hecker unsere Motivation als Free-Software-Programmierer in erster Linie in der Belohnung unseres Egos, wenn wir sehen, dass unsere Software von anderen Leuten benutzt und von anderen Entwicklern gepriesen wird. Oder wie Raymond sagt, ‘the intangible of their own ego satisfaction and reputation among other hackers.’

Die Open-Source-Bewegung ist aber nicht das einzige Erklärungsmodell für das Phänomen Freie Software. Eine andere, ältere Variante kommt von Seiten des GNU-Projekts der Free Software Foundation. Richard M. Stallman, ihr Präsident, wird nicht müde, die soziale und gesellschaftliche Verantwortung Freier Software zu betonen - und alle anderen Softwareentwickler zu verdammen und zum Boykott ihrer Produkte aufzurufen. Der Entwickler Freier Software wird in der FSF-Philosophie zum selbstlosen Kämpfer für eine bessere Gesellschaft. Er sucht nach anderen Verdienstmöglichkeiten und bettelt lieber um Geld, als sich seine Qualifikation angemessen bezahlen zu lassen. Das hehre Ziel, mehr Freiheit in die Welt zu bringen, wiegt ihm mehr als sein persönlicher Vorteil. Doch neben dem guten Gefühl, das Richtige zu tun, nennt das GNU-Manifesto auch noch zwei durchaus stichhaltige pragmatische Gründe: Mehr Quellcode, um davon zu lernen, und eine breitere Codebasis, die in eigenen Programmen nutzbar ist.

Unter diesen Gesichtspunkten hätte Mozilla einfach ein Erfolg werden müssen. Schließlich bietet Mozilla wie kaum ein anderes Projekt eine Gelegenheit, Microsoft prestigeträchtig im direkten Wettbewerb zu schlagen. Die heutige Bedeutung eines Browsers als die zentrale Internet-Anwendung würde die GNU-Freunde motivieren. Mit Mozilla können sie verhältnismäßig einfach der Gemeinde einen besseren, und vor allen Dingen freien Browser zur Verfügung stellen. Das Programmierer-Ego sollte bei dem Gedanken frohlocken, mit bekannten, ‘coolen’ Leuten wie Jamie Zawinski zusammenzuarbeiten und seinen eigenen Namen auf die Autorenliste einer erfolgreichen und bekannten Anwendung zu setzen. Kurzum: Der Erfolg schien vorprogrammiert, und nicht nur bei Netscape war man davon überzeugt, das Ende des Internet Explorer sei gekommen.

Das Imperium schlägt zurück

Ein Jahr später machte sich Ernüchterung breit. Im April 1999 verlässt Jamie Zawinski resigniert Netscape Communications, die mittlerweile von AOL geschluckt wurden. In seinem lesenswerten Paper ‘resignation and postmortem’ [3] beschreibt er das Open-Source-Musterprojekt als gescheitert und diskutiert ein letztes Mal die Entschuldigungen, mit denen man bis dato die traurige Wahrheit der Öffentlichkeit zu erklären suchte. Trotz des positiven Einflusses auf Netscapes Entscheidungsfindungen, den die offene Softwareentwicklung dank des direkten Anwender-Feedback hat, verbleiben drei entscheidende Nachteile:

• Mozilla ist entgegen der ursprünglich propagierten Timeline immer noch kein benutzbares oder gar fertiges Produkt.
• Es gelang Netscape so gut wie nicht, externe freiwillige Programmierer zu gewinnen. Die Entwicklung wird fast ausschließlich von fest angestellten Mitarbeitern getragen.
• Der Internet Explorer konnte seine Führungsposition weiter ausbauen, sowohl technisch als auch bei der Marktdurchdringung. Konkurrenz kommt allenfalls von neuen kommerziellen Entwicklungen wie Opera, nicht von Mozilla.

Was war geschehen? Warum stürzte sich die Freie-Software-Gemeinde nicht wie vorhergesagt auf den Quellcode? Sind die Open-Source-Ressourcen erschöpft, die Gemeinde müde? Dem widerspricht, dass im selben Zeitraum andere Open-Source-Projekte einen immensen Zulauf und Erfolg hatten. Insbesondere dem KDE-Projekt gelang es, eine große Zahl neuer Entwickler zu gewinnen, die vorher noch nicht in die Entwicklung Freier Software eingebunden waren. Ironischerweise enthält das KDE-Projekt einen eigenen, leichtgewichtigeren Web-Browser, den Konqueror, der sich mittlerweile für die alltäglichen Webaufgaben eines normalen Linux-Anwenders bis auf die fehlende Java-Unterstützung nicht hinter dem Communicator zu verstecken braucht, insbesondere unter der Annahme, dass Java in der Regel sowieso abgeschaltet ist.

Mozilla versus Konqy

Eine Analyse der beiden Projekte offenbart signifikante Unterschiede. Der offensichtlichste ist der Umfang oder die Reichweite des Projekts. Während Mozilla ein eng gestecktes, klar definiertes Ziel vorgibt, ist KDE ein Meta- oder Superprojekt, das sich wiederum in viele einzelne, konkrete Projekte unterteilen lässt. Diese gehorchen keiner klaren Vorgabe, abgesehen von definierten User Interface Guidelines und der Forderung, dass eine Anwendung soweit wie möglich mit dem Rest des Desktops zusammenarbeiten sollte. Aber auch hierbei setzt KDE nicht auf Druck, sondern auf positive Motivation. Die Grundidee des Framework ist, es einfacher zu machen, konforme Anwendungen zu schreiben als nicht-konforme. Die Integration der Anwendungen resultiert hauptsächlich aus der Verwendungen des Framework, nicht aufgrund arbeitsintensiver Projektspezifikationen.

Mozilla kann diese Freiheit nicht bieten. Das hehre Ziel, einen aktuellen, standardkonformen Webclient im Jahre 1999 zu schreiben, ersetzt Kreativität durch einen gewaltigen Berg klar spezifizierter Ingenieursaufgaben: HTML, XML, CSS1/2, DOM, XSL, JavaScript, Java, um nur einige zu nennen. Die Größe der Codebasis und die Menge integrierter Techniken erfordern wiederum ein umfangreiches Vorwissen oder zumindest eine entsprechende Einarbeitungszeit. Mit Mozilla kamen plötzlich über eine Million Zeilen freien Quellcodes über die Freie-Software-Entwickler. Sich darin zurechtzufinden ist weder trivial noch sonderlich unterhaltsam. Zwar zeigten fünf Programmierer im sogenannten ‘QtScape’-Hack, dass eine Portierung auch ohne Dokumentation innerhalb von fünf Tagen möglich ist. Doch handelte es sich dabei eher um den Marketing-Stunt einer norwegischen Firma als um übliche Freie-Software-Entwicklung, auch wenn alle Beteiligten einschließlich des Autors viel Spaß hatten.

KDE auf der anderen Seite verlangt je nach Wahl des Teilprojekts deutlich weniger bis gar kein Vorwissen. So war das allererste KDE-Programm, das nach Projektgründung von dritter Seite eingecheckt wurde, einfach nur eine Neuimplementierung von xclock. Das Resultat hieß kclock und bestand gerade mal aus 90 Zeilen Code. Andere unabhängige Beiträge verdienen das Prädikat ‘esoterisch’. So kommt KDE mit einem eigenen Fraktalgenerator, mehr oder weniger nutzlos, aber unterhaltsam. Es ist schwer vorstellbar, dass ein Patch von Mozilla.org akzeptiert würde, der einen Fraktalgenerator direkt in den Browser integriert. Das würde zugegebenermaßen auch keinen Sinn machen. Der festgelegten Roadmap Mozillas mit all seinen Spezifikationen und Milestones setzt KDE viel Platz entgegen, in den jedes noch so ‘abgefahrene’ Projekt irgendwie hineinpasst.

Balsam für die Entwicklerseele

Ein weiterer Unterschied ist die Rolle, die der einzelne Programmierer innerhalb des Projekts spielt. Derselbe Neueinsteiger, der bei Mozilla als kleiner Entwickler unter vielen anfängt, beginnt bei KDE üblicherweise als Projektleiter. Und wenn es nur die Leitung des clock-Projekts mit einem einzigen Entwickler im Team ist. KDE hat sich dem ‘ego-less programming’ verschrieben, das den Teamgedanken weit über den andernorts praktizierten Personenkult erhebt und vom Grundgedanken ausgeht, jeder Einzelne ist ersetzbar und sollte ersetzbar sein. Dennoch kann niemand abstreiten, dass das Programmierer-Ego nicht doch so manches Mal gestreichelt werden will.’ Wichtiger als der Titel eines Projektleiters ist dabei unmittelbare Gratifikation. Ein KDE-Programmierer sieht sofort entsprechende Pixel auf dem Bildschirm. Jegliche Änderungen, die er an dem Programm durchführt, werden wenige Stunden oder sogar Minuten später von einer großen Schar Alpha-Tester und Mitentwickler ausprobiert. Entsprechendes Feedback, positiv wie negativ, ist garantiert.

Bei Mozilla sieht die Sache etwas anders aus. Die Arbeit an diesem Projekt führt kaum zu einer unmittelbaren Gratifikation, zumal es sich noch nicht um ein einsetzbares Produkt handelt. Man kann beispielsweise erreichen, dass eine bestimmte, künstliche XML-Seite noch ein bisschen genauer gemäß dem W3C-Standard gerendert wird. Das hilft heute aber noch keinem beim Browsen und stößt wohl kaum auf begeisterte Ah- und Oh-Rufe in der unmittelbaren Umgebung desjenigen, der gerade eine Nacht durchprogrammiert hat. Auch wenn es dann endlich ein fertiges Release gibt, war man doch nur einer unter mehr als hundert fest angestellten Netscape-Programmierern. Der Kollege bei KDE wird sich hingegen bald als ein Teil einer Gruppe von Freunden fühlen. Dies klingt zwar pathetisch, lässt sich aber durchaus anhand diverser Treffen in der wirklich Welt bestätigen.

Dieselben Beobachtungen lassen sich im Vergleich mit anderen erfolgreichen Open-Source-Projekten treffen. Ein Paradebeispiel ist der Presseliebling aller Open-Source-Programme, das Bildbearbeitungsprogramm Gimp. Wenngleich die grobe Richtung durch die Nähe zu Photoshop festgelegt wird, bietet die Plugin-Architektur auch hier den Charakter eines Metaprojekts. Zwar wurde das Framework einschließlich des GUI-Toolkits GTK in erster Linie von zwei einzelnen Programmierern, Spencer Kimball und Peter Mattis, gestellt. Dank dem offenen Design und der Möglichkeit, eigene Projekte in Form von Plugins zu integrieren, wurde es dennoch ein erfolgreiches Projekt mit vielen freiwilligen und engagierten Helfern.

Aufklärung der Phänomene

Wer schreibt aber jetzt all den Code? Und aufgrund welcher Motivation? Das Mozilla-Experiment zeigt, dass Freie Software keineswegs von der amorphen, gesichtslosen Masse anonymer Programmierer geschrieben wird, von der oft im Netz zu lesen ist. Vielmehr handelt es sich um selbstbestimmte Individuen, die aus persönlichen Beweggründen handeln, sei es aus Spaß an der Sache, Eigeninteresse an der fertigen Software oder bloßer technischer Neugier. Immer steht jedoch der einzelne Entwickler und seine Interessen im Vordergrund, keine abstrakte ‘Community’. Entwickler Freier Software sind daher weder leicht berechenbar, noch lassen sie sich selbstlos vor fremde Karren spannen, sei es, um die Gesellschaft zu verbessern oder sei es, um Microsoft und alle anderen kommerziellen Softwarehersteller zu bekämpfen.

Dies erklärt auch ein anderes Phänomen Freier Software: den geradezu manischen Drang zur Doppelentwicklung, zur Reimplementierung bereits existierender Applikationen. Anwender sehen darin für gewöhnlich tragische Dummheit oder zumindest verlorene Liebesmüh, der sie gerne mit der Forderung nach besserer Projektorganisation oder Briefen an die Autoren entgegenzuwirken versuchen. Aus Programmierersicht ist das hingegen normal. In erster Linie geht es darum, Spaß an einem wunderschönen Hobby zu haben. Die Tatsache, dass man mit derselben Tätigkeit im selben Zeitraum auch eine Stange Geld verdienen könnte, macht das zugegebenermaßen von außen manchmal schwer begreifbar.

Matthias Ettrich
ist Begründer des KDE-Projektes und arbeitet als Programmierer bei Troll Tech AS an der Weiterentwicklung der Qt-Bibliothek.

Literatur

[1] Eric S. Raymond; The Cathedral and the Bazaar

[2] Frank Hecker; ‘Setting Up Shop: The Business of Open-Source Software’

[3] Jamie Zawinski; ‘resignation and postmortem’

[4] Eric S. Raymond; Homesteading the Noosphere;

[5] Peter Mattis, Interview in LinuxWorld, Januar 1999;

[6] Matthias Kalle Dalheimer; Freie Software; Sandkastenspiele; Wohl und Wehe freier Softwareentwicklung; iX 6/1998, S. 102

Mehr Infos

iX-TRACT

• Für das Phänomen Freie Software existieren unterschiedliche Erklärungsmodelle.
• Trotz guter Voraussetzungen ist der Open-Source-Ansatz bei Mozilla weitgehend fehlgeschlagen.
• Ein Hinterfragen der Motivation der beteiligten Entwickler verschafft Klärung.

Mehr Infos

Motivation zum Schreiben Freier Software

Peter Mattis, Gimp- und Gtk-Autor, äußerte sich Anfang des Jahres in einem Interview der LinuxWorld [5] zu seinen Beweggründen, Free Software zu schreiben: ‘You should understand that the Gimp and Gtk weren’t written to fill holes in the software available under the GPL and LGPL. The Gimp was started because I wanted to make a Web page. Gtk was started because I was dissatisfied with Motif and wanted to see what it took to write a UI toolkit. These are purely selfish reasons. That is probably why the projects progressed so far and eventually succeeded.’

Generischer formuliert lässt sich die Motivation, Freie Software zu entwicklen, in drei Kernaussagen zusammenfassen.

Wissenschaftlicher Grad und Qualifikation für einen späteren Beruf: Ein nicht unerheblicher Teil Freier Software hat seine Wurzeln im universitären Milieu. Andere Anwendungen werden geschrieben, weil sich der Autor in ein bestimmtes Thema der Programmierung einarbeiten möchte oder muss.

Das eigene Interesse, die Software anzuwenden: In Ermangelung entsprechender existierender Programme schreibt man sich seine Wunschsoftware einfach selbst. Dies ist die Motivation, von der Anwender am meisten profitieren. Populäre Beispiele sind das LaTeX-Frontend LyX, die Entwicklungsumgebung KDevelop oder die bereits erwähnte Bildverarbeitung Gimp.

Technische Neugier: Als Programmierer fragt man sich manchmal: Wie funktioniert das? Was braucht es, so etwas zu schreiben? Dies ist bei weitem die häufigste Motivation und einer der Gründe, warum Freie Software manchmal bis zur Grenze des technisch Machbaren geht. Beispiele waren die CORBA-fizierten Designstudien für KDE-2.0 oder Systeme, die so flexibel und universell sind, dass sie kaum ein normaler Mensch benutzen kann. Da Menschen oft gar nicht so verschieden sind, geschieht es immer wieder, dass sich unterschiedliche Leute dieselben Fragen stellen. Aus diesem Blickwinkel verwundert es nicht, dass eine Unmenge freier IRC-Cients, Audiomixer, Texteditoren und GUI-Toolkits existieren.

(avr)