[ox] iX 01/00: Wer kodiert?
- From: Stefan Meretz <stefan.meretz hbv.org>
- Date: Thu, 30 Dec 1999 11:27:43 +0000
Liebe oxis,
damit Euch nicht langweilig wird ;-) hier noch ein Artikel zum Lesen:
Matthias Ettrich vom KDE-Projekt über Freie Software. Auch ein Kandidat
für den Linuxtag, finde ich. Inhaltlich fällt mir auf, das mehr oder
weniger ausformuliert immer die monetäre Verwertbarkeit als
Bewertungsmaßstab im Hintergrund schwebt, von dem sich auch die
eingefleischtesten Anhänger freier Software nicht frei machen können.
IMHO ist das Besondere freier Software gerade daran nicht messbar.
Quelle: http://www.heise.de/ix/artikel/2000/01/112/default.shtml
Ciao,
Stefan
++++++++++++++++++++++++++++++++
Gedanken zur Freie-Software-Szene
Wer kodiert?
Matthias Ettrich
Keine Frage: Open Source Software ist ?in?. Der Erfolg von Linux und
Apache, eines der wenigen Produkte, das Microsoft im direkten Wettbewerb
in puncto Marktanteile geschlagen hat, weckt Erstaunen und Bewunderung.
Betrachtet man, in welchem Umfeld diese Projekte entstehen, stellt sich
die Frage, wie das funktioniert.
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.
(avr).
+++++++
Kasten:
+++++++
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.
+++
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
--
Gewerkschaft Handel, Banken und Versicherungen
HA II, Abteilung Datenverarbeitung
Kanzlerstr. 8, 40472 Duesseldorf
--
stefan.meretz hbv.org
maintaining: http://www.hbv.org
private stuff: http://www.meretz.de
--
--------------------------------------------
http://www.homepages.de/home/smerten/Oekonux/