das internet als Distributionsmedium für Software zwingt die Hersteller zu immer kürzeren Update-Zyklen. Lassen ein neues Produkt oder neue Funktionen zu lang auf sich warten, kann sich das auf die Marktposition eines Anbieters fatal auswirken. Diese Beschleunigung hat unmittelbaren Einfluß darauf, wie Software entwickelt wird. Eric Raymond, einer der bekanntesten Open-Source-Vertreter, beschrieb in seinem programmatischen Aufsatz "The Cathedral and the Bazaar" die gegensätzlichen Ansätze der "Kathedrale" und des "Basars" (http://www.tuxedo.org/esr/ writings/cathedral-bazaar).
Ersteres ist seiner Meinung nach typisch für die Programmierung geschlossener Software. Die Intervalle zwischen den einzelnen Updates sind lang, Fehler werden nur zögerlich behoben. Offener Quellcode sorgt für schnelle Entwicklung. Der Grund dafür liegt seiner Meinung nach in der Unzugänglichkeit des Quellcodes für die Öffentlichkeit. Unabhängige Programmierer können keine Korrekturen anbringen und nicht zur Weiterentwicklung beitragen. Das relativ kleine Entwicklerteam eines Herstellers ist auf sich allein gestellt und braucht entsprechend lange, bis die nächste Version eines Programms ausgeliefert werden kann.
Demgegenüber sei der Basar-Stil typisch für OSS-Projekte und zeichne sich durch kurze Update-Zyklen aus. Die schnelle Freigabe von aufeinanderfolgenden Updates hilft, Fehler schneller zu beseitigen. Die Entstehung dieser Arbeitsweise verdankt sich der konsequenten Nutzung des Internet als Kommunikationsmedium für die über die ganze Welt verstreuten Entwickler. Die durch das Internet geförderten Geschäftspraktiken kommen dem Basar-Stil von OSS entgegen und sind daher maßgeblich für den überraschenden Erfolg von quelloffener Software verantwortlich.
Hersteller spannenAnwender als Tester ein
Allerdings haben auch die Anbieter kommerzieller Software dazugelernt. Sie geben Teile ihres Sourcecodes frei und veröffentlichen Updates in immer kürzeren Zeiträumen, wobei sich mittlerweile die Verbreitung und Nutzung von Betaversionen eingebürgert hat. Die Hersteller spannen damit eine breite Anwenderschicht als Tester ein, die ihre Fehlerberichte über das Internet blitzschnell zurückmelden können und so das nächste kleine Update oder auch nur eine Fehlerkorrektur vorbereiten helfen. In der Praxis wird deshalb die Zuordnung des Kathedralen- oder Basar-Stils zu offener oder geschlossener Software immer schwieriger. Worin liegen also die wesentlichen Unterschiede zwischen Freeware und kommerziellen Programmen, wenn sich beide Ansätze mehr oder weniger das Basar-Modell zunutze machen? Verwirrung stiftet zusätzlich, daß mittlerweile proprietäre Software wie Javasogar im Quellcode vorliegt und Programme von Microsoft zuhauf kostenlos zu haben sind.
Der wesentliche Unterschied besteht im freien Zugang zu sämtlichem Quellcode und im Recht, daran beliebig Änderungen vornehmen, das Programm unbeschränkt nutzen und weitergeben zu dürfen. In Kombination mit den beinah unbegrenzten Kommunikations- und Kooperationsmöglichkeiten im Internet entsteht nach Auffassung der Freeware-Verfechter so ein Modell für die Software-Entwicklung, das der natürlichen Evolution gleicht. Besonders das Prinzip der Vererbung sorgt dafür, daß frei verfügbarer bewährter Code in neue Projekte einfließen kann und diese schnell auf eine qualitativ höhere Stufe bringt.
Demgegenüber kann proprietäre Software nur auf Programmquellen aus dem eigenen Haus zurückgreifen oder muß anderswo bereits tausendfach geschriebene Routinen wieder neu implementieren. Den Mißbrauch von offenem Code verhindern entweder dessen Lizenzbestimmungen, oder das kostenlose Angebot entmutigt funktionsgleiche kommerzielle Konkurrenz.
Entwickler arbeitenfreiwillig und umsonst
Befürworter des OSS-Ansatzes vergleichen dieses Entwicklungsmodell gelegentlich mit der Wirkungsweise wissenschaftlicher Forschung oder der Entstehung einer Eßkultur: Bei proprietärer Software bekommen die Anwender immer nur das fertige Gericht vorgesetzt. Rezepte werden ihnen vorenthalten, eine Weiterentwicklung ist nicht möglich. Die Benutzer freier Software können das Programm im Notfall selbst fertigstellen. Das Verschwinden eines kommerziellen Anbieters läßt dessen Kunden hingegen häufig hilflos zurück.
Die unentgeltliche Kooperation auf Basis offenen Codes bringt neue Organisationsformen der Entwicklerteams hervor, deren Arbeitsweise direkte Auswirkungen auf die entstehende Software hat. Die freiwillige Tätigkeit der Beteiligten führt unmittelbar zur Trennung von Entwicklung und Marketing. Bei kommerzieller Software ist es üblich, daß Programm-Manager immer wieder neue Vorgaben zu Funktionen und Fertigstellungsterminen machen. Über die ständigen Funktionserweiterungen sollen immer neue Käuferschichten angesprochen werden, selbst wenn dies zu widersprüchlichen Anforderungen an die Software führt. Der Termindruck entsteht durch das Verwertungsinteresse des Herstellers, der Verspätungen bei der Produktfreigabe als Einkommensverluste bucht.
Im Gegensatz dazu kann ein Freeware-Team seine Software nach rein technischen Kriterien gestalten und ist niemandem Rechenschaft schuldig, wann die Anwendung fertig wird. So betonen Autoren freier Software immer wieder, daß nur die Qualität des Programms bestimmt, wann es freigegeben wird. Das Motiv für ihre Arbeit ist nicht Geld, sondern ideelle Werte. Dazu zählen besonders das Bedürfnis nach Anerkennung der eigenen Leistung, die bei allgemein zugänglichen Programmquellen leicht überprüfbar ist. Bei geschlossener Software hingegen kann eine derartige Bewertung des Codes nicht stattfinden.
Diese Konzentration auf Qualitätskriterien schlägt sich üblicherweise auch bei der Bildung von Hierarchien in den Teams nieder. Autorität erlangt nicht unbedingt der, der schon am längsten dabei ist, sich beim Chef einschmeichelt und sich wichtig macht, sondern derjenige, der am meisten zu einem Projekt beiträgt und durch seine Fähigkeiten überzeugt.
Mittlerweile stellt sich aber die Frage, ob der Sportsgeist freiwilliger Entwickler durch die Kommerzialisierung von OSS nicht beeinträchtigt wird. Gemeint ist weniger der oft zitierte Neid, den die Programmierer auf jene bekommen sollten, die das Produkt ihrer unentgeltlichen Arbeit in klingende Münze verwandeln. Vielmehr läßt sich beobachten, daß sich Firmen, die ihr Geschäft auf offene Software gründen, immer mehr in den Entwicklungsprozeß einschalten.
Mag der Beitrag von mehreren IBM-Vollzeitprogrammierern zum Web-Server "Apache" noch ohne weitere Auflagen erfolgen, so ist vorstellbar, daß Linux-Distributoren wie Red Hat ihre Unter-stützung mit konkreten Erwartungen verknüpfen. Eine davon ist sicherlich, daß ihr Sponsoring die Fertigstellung der nächsten Version beschleunigt. Das ist ein durchaus legitimes Anliegen, möglicherweise untergräbt es aber die Trennung von Marketing und Entwicklung. Diese Gefahr ist um so größer, wenn sich ein Projektleiter ("Maintainer") als Angestellter eines solchen Unternehmens nur schwer dessen Wünschen entziehen kann.
Linux-Entwicklersind keine Ästheten
Die Trennung von Marketing und Entwicklung wirkt sich zwar positiv auf die technische Qualität aus, führt aber meist zur Vernachlässigung all jener verkaufsfördernder Eigenschaften, die den ästhetischen Wert einer Ware ausmachen. Es mag ja kein großer Nachteil sein, wenn eine Anwendung keine animierten Helferlein oder keine dreidimensionale Symbolleisten vorweisen kann. Die geringe Aufmerksamkeit, die Freeware-Entwickler der äußeren Erscheinung im allgemeinen schenken, macht sich tendenziell aber in mangelnder Benutzerfreundlichkeit der Programme bemerkbar.
Es ist daher kein Zufall, daß alle komfortablen Installationsroutinen für Linux nicht von der Entwicklergemeinde, sondern von Distributoren beigesteuert werden. Die technische Ausrichtung von OSS-Teams, die sich als Anwender meist andere Programmierer oder professionelle Systemverwalter vorstellen, führt dazu, daß es sich bei Freeware meistens um Technologie und nicht um verkaufsfertige Produkte handelt.
Für gewinnorientierte Firmen wie die Linux-Distributoren entstehen dadurch Geschäftsfelder. Sie versuchen auf diesem Weg, ihre Linux-Zusammenstellung von der Konkurrenz abzuheben. Die geringe Bedeutung, die der äußeren Erscheinungsform häufig beigemessen wird, ist nicht nur das Ergebnis fehlenden Verwertungsinteresses. Sie hat auch damit zu tun, daß sich die Teams großteils aus technisch Interessierten zusammensetzen und die Tradition freier Software generell einen akademischen Hintergrund mit einem Schwerpunkt auf Ingenieurswissenschaften hat. Entwickler aus diesem Umfeld vollbringen meist hervorragende Leistungen bei der Implementierung von Kernfunktionen, sind aber oft keine guten Designer von Benutzer-Schnittstellen. Das ist sicherlich ein Grund, warum die meisten freien Programme für Infrastrukturdienste geschrieben werden.
Entwicklung nachIngenieurmaßstäben
Es gibt darunter eine Fülle von Skriptsprachen, Compilern, Betriebssystemen oder generell Software, die am Server abläuft, aber kaum grafische Client-Anwendungen. OSS hat einen hervorragenden Ruf für diese Backend-Applikationen, die dem Endanwender meist verborgen bleiben. Umgekehrt glänzen kommerzielle Produkte häufig durch hübsch polierte Oberflächen, während es ihnen an inneren Werten mangelt. Ein typisches Beispiel dafür ist "Microsoft Word", das in der neuesten Ausführung Menüs besitzt, deren Einträge sich automatisch umsortieren, dessen Fußnotenverwaltung aber bis heute nicht wirklich verläßlich funktioniert.
Der einseitigen Ausrichtung quelloffener Software auf systemnahe Dienste scheinen einige neuere Projekte zu widersprechen. Dazu zählen die Unix-Desktops "KDE" und "Gnome". Bei näherer Betrachtung lassen sich diese - wie auch das schon lange existierende "Xfree86" - aber ebenfalls eher der Infrastruktur zurechnen, da Benutzer üblicherweise nicht so häufig mit der Systemoberfläche, sondern mit Anwendungen arbeiten.
Zu einem gelungenen Beispiel für Client-Anwendungen könnte indes das leichtgewichtige Office-Paket "K-Office" werden, das im Rahmen des KDE-Projekts entsteht. Ein weiteres Vorzeigeobjekt unter den wenigen grafischen Client-Anwendungen der OSS-Gemeinde ist das Grafikprogramm "Gimp". Das Desinteresse von Freeware-Teams an der Vermarktung ihrer Produkte hat auch Auswirkungen darauf, welche Projekte überhaupt zustandekommen.
Eric Raymond nennt in seinem Aufsatz als wichtige Triebfeder für die Programmierung von Freeware, daß jemand keine passende Software für sein Problem findet oder nicht mit ihr zufrieden ist ("scratching a developer’ personal itch"). Da also meist nicht eine Nachfrage des Marktes für die Entstehung einer freien Software ausschlaggebend ist, sondern das persönliche Anliegen von Programmierern, verstärkt dies die Ausrichtung auf Tools und Infrastruktur.
Die Betonung des persönlichen Interesses und, damit verbunden, des Spaßes am Programmieren, läßt beispielsweise betriebswirtschaftliche Anwendungen für OSS-Projekte ungeeignet erscheinen. Sie erfordern neben Programmierkenntnissen vor allem ökonomisches Wissen - ein Gebiet, auf dem sich technisch orientierte Teilnehmer an OSS-Projekten nicht wohl fühlen. Daran wird auch das Projekt "Linux-Kontor" (http://www.linux-kontor.de) nicht viel ändern, das sich auf die Komponenten Buchhaltung und Warenwirtschaft beschränkt.
Windows-Programmiererwollen Geld sehen
Eine weitere Einschränkung für freie Software besteht darin, daß die technische Kultur der OSS-Gemeinde im PC-Umfeld aufgrund des geschlossenen Charakters von DOS und Windows nie richtig Fuß fassen konnte. Es ist für OSS-Projekte daher vergleichsweise schwierig, Windows-Programmierer für unentgeltliche Arbeit zu gewinnen. Deshalb entsteht die meiste Freeware nach wie vor im Unix-Umfeld, und dort bevorzugt für die freien Systeme Linux und "Free BSD".
Die Organisationsform von Freeware-Programmierern schlägt sich auch in anderer Form direkt in der Architektur der Anwendungen nieder. Diese virtuellen Teams kooperieren über das Internet und arbeiten dabei weitgehend autonom. Ein so umfangreiches System wie Linux setzt sich aus Beiträgen zahlreicher Projekte zusammen, die untereinander nicht zwangsläufig engen Kontakt halten. Deshalb ist der freie Unix-Clone weitgehend modular aufgebaut, die einzelnen Bestandteile wie Kernel, Laufzeitbibliotheken oder das X-Window-System lassen sich unabhängig voneinander erneuern.
Demgegenüber versucht Microsoft, seine dominierende Stellung bei Betriebssystemen im Anwendungsgeschäft auszunutzen. Applikationen nutzen dann undokumentierte APIs, Word 97 unterstützt bereits heute die Mehrsprachenfunktion von Windows 2000, das Backup-Programm von Windows 2000 kennt schon vor der Freigabe von Exchange 6.0 dessen Datenbankformat etc. Dieses Vorgehen verkauft das Microsoft-Marketing als "Integration". Es schafft aber komplexe Abhängigkeiten zwischen den Produkten, die das Update häufig zum Abenteuer machen.
Die weitgehende Unabhängigkeit und Eigenständigkeit von Freeware-Projekten machen sich nicht nur im modularen Design von Software bemerkbar, sondern äußern sich auch in einer Flut unterschiedlicher Lizenztypen (eine gute Übersicht über OSS-Lizenzen bietet http://dmoz.org/Computers/Software/Licensing/Open_ Source_Licenses). Anwender müssen sich darüber normalerweise nicht den Kopf zerbrechen, da sie unter praktisch allen Lizenzvereinbarungen die Software unbeschränkt einsetzen dürfen. Ein Problem stellt diese Vielfalt aber für die Entwickler dar, wenn sie vom Vererbungsprozeß in der Evolution freier Software profitieren wollen.
Weiterverwendung sorgt für Auseinandersetzungen
Die Auflagen für die Weiterverwendung offenen Codes reichen von "Mach damit, was du willst" bis zur Verpflichtung, alle davon abgeleiteten Programme unter die gleiche Lizenz stellen zu müssen. Ein Vertreter der ersten Variante ist Xfree86, für die zweite Form steht die GNU Public Licence (GPL). Aufgrund ihrer virenähnlichen Verbreitung (Code unter der GPL "infiziert" andere Programme, wenn er dort verwendet wird, weil diese ebenfalls unter die GPL gestellt werden müssen) gilt sie als geschäftsfeindlich und wird auch von eher pragmatischen Vertretern der OSS-Bewegung abgelehnt.
Schwierigkeiten können deswegen entstehen, wenn sich ein Projekt aus mehreren Quellen bedient, für die verschiedene Lizenzbedingungen gelten. Insgesamt hat das Freeware-Modell bewiesen, daß die Trennung von Entwicklung und Vermarktung hochwertige Software hervorbringen kann. Diese Konstellation führt aber meist zur Erstellung systemnaher Programme, die sich wegen ihrer schwierigen Installation und Bedienung meist an technisch orientierte Nutzer richtet. Client-Anwendungen und Business-Software bleiben besonders wegen der Entstehungsbedingungen von OSS-Projekten (persönliches Anliegen) und subjektiver Faktoren (vorwiegend technischer Hintergrund) Mangelware.