Open Source Software als Innovationstreiber in kommerziellen Softwareprojekten
Dr. Christian Dürr, Dirk Weske
Erschienen in: HMD - Praxis der Wirtschaftsinformatik, Heft 238, August 2004, ISSN 1436-3011
Open Source Software ist ein Kuriosum. Gemessen an den Rahmenbedingungen der allermeisten traditionellen Projekte dürfte sie nicht existieren. Dennoch ist sie in modernen Softwareprojekten nicht mehr wegzudenken und in Form von nützlichen Werkzeugen allgegenwärtig. Erstmals setzen Großprojekte auf Open Source Software im Anwendungsbereich und nutzen Open Source Software mit Erfolg als Mission Critical Software. Bis auf die Persistenzschicht kann eine komplette IT-Infrastruktur mit Open Source Software bereitgestellt werden. Kostenoptimierung bei der Erstellung und dem Einsatz von Software ist im gegenwärtig schwierigen Marktumfeld ein Hauptziel und damit der Einsatz von Open Source Software Pflichtprogramm. Kundenseitig (privat und öffentlich) besteht inzwischen eine allgemein hohe Akzeptanz für Open Source Software mit ihrem überwiegend vorteilhaften Eigenschaften.
Inhaltsübersicht
2. Engagement für Open Source Software
2.1. Personen
2.2. Staaten
2.3. Firmen
3. Einsatz von Open Source Software
3.1. Motive
3.2. Werkzeuge
3.3. Anwendungssoftware
3.4. Mission Critical Software
4. Der Einfluss auf Projekt- und Prozessmanagement
4.1. Der OSS Entwicklungsprozess
4.1. Erfolgsfaktoren für kommerzielle Projekte
Open Source Software (OSS) ist technisch, wirtschaftlich und organisatorisch ein Kuriosum. OSS entsteht durch das lose und freiwillige Zusammenwirken von Softwareentwicklern, deren Interaktion und Kommunikation zum Großteil allein über einen dem Produkt gewidmeten Entwicklungsprozess abgewickelt wird. Über einen speziellen, zunächst allen ökonomischen Grundsätzen widersprechenden Vertrag zur Regelung der Eigentumsrechte wird dabei gewährleistet, dass keine Vereinnahmung des entstehenden Mehrwerts durch einen oder wenige Akteure erfolgt.
Der Grundsatz, dass Innovationen im wachsenden Produkt allein durch strikte Eigentumsrechte gesichert sind, ist bei OSS außer Kraft gesetzt, oftmals ist das Gegenteil der Fall. Endanwender, verantwortlich für die Definition der Anforderungen und Entwickler, verantwortlich für die Umsetzung der Anforderungen sind zumeist identisch. Entwickler beschäftigen sich dabei nach dem Grundprinzip der Freiwilligkeit mit Problemen, für die sie sich überdurchschnittlich spezialisiert sehen. Der Handlungsspielraum des Entwicklers ist selten terminlich, marketingtechnisch oder wirtschaftspolitisch eingeschränkt. Dies ermöglicht ein überraschend hohes Qualitätsniveau, vergleichbar mit und nicht selten besser als das ähnlicher kommerzieller Produkte.
Der offene und regional stark verteilte Softwareentwicklungsprozess bedingt besondere Sorgfalt bei der Kommunikation zwischen Entwicklern, der Dokumentation und der Offenlegung von Schnittstellen. Erfolgreiche OSS Projekte sind transparent strukturiert und unterstützen Selbstorganisation.
Definitorisch ist Software dann OSS, wenn sie unter einer den OSI-Kriterien entsprechenden Lizenz verwendet und verteilt wird. Diese Kriterien sind [OSI-Kriterien] 1.Unentgeltliche Weitergabe der OSS 2.Offenlegung und Weitergabe des Quellcodes 3.Garantie der Unversehrtheit von originärem Quellcode 4.Zulassung von Weiterentwicklungen 5.Automatische Weitergabe der Lizenzierung an Nutzer 6.Keine Einschränkungen für den Einsatz der Anwendung 7.Keine Einschränkungen für den Nutzerkreis der Anwendung 8.Keine Einschränkungen der Lizenz bei der Art der Paketierung der Software 9.Keine Einschränkungen bei der Weitergabe mit anderer Software 10.Neutralität gegenüber Technologien und Standards
Eine OSS-Lizenz schützt damit das Urheberrecht durch ein ungewöhnliches Konstrukt: sie macht die kreative Arbeit von Entwicklern öffentlich und frei zugänglich und erzwingt diese Offenheit auch für alle anderen Formen der Weitergabe und in Folgeprodukten der ursprünglichen Software.
Zu den populärsten OSS-Lizenzen (nach der Downloadhäufigkeit auf [sourceforge]) zählen die GNU General Public License (GPL) und GNU Lesser/Library General Public License (LGPL), die Berkeley Software Distribution (BSD) und die Artistic License (AL).
2.1. Personen
OSS Entwicklung erfolgt Community-basiert. Kennzeichnend für diese Konstellation ist, dass Gleichgesinnte für einen langen Zeitraum zusammenarbeiten und ein gemeinsames Ziel verfolgen. Die Kommunikation der Teilnehmer in dieser Community wird bestenfalls moderiert, niemals zensiert. Das verlangt von allen Konstituenten eine hohe Eigenverantwortung und steigert automatisch die Qualität aller Beiträge.
Persönliches Engagement in einer OSS-Community lässt sich damit sehr vielschichtig begründen. Zum einen existiert ein ausgeprägtes Gemeinschaftsgefühl aufgrund des gemeinsamen Gestaltens eines Entwicklungsprozesses hin zu einem öffentlich definierten Ziel. Zum anderen ist die Projektkultur in OSS-Communities geprägt von gegenseitigem Respekt, Anerkennung und der Bereitschaft zur Eigeninitiative. Auf diesem Nährboden ist Produktivität selbstverständlich.
Darüber hinaus begründet sich persönliches Engagement auch rein praktisch. So braucht die Entwicklergemeinschaft dringend das Produkt, an dem sie gerade arbeitet. Oder durch die Arbeit in der OSS-Community lässt sich Erfahrung gewinnen, die auf keine andere Weise gewonnen werden könnte.
2.2. Staaten
Staatliches Engagement für den Einsatz von OSS in der öffentlichen Verwaltung erklärt sich am besten damit, dass auch der Staat seine Kaufentscheidungen optimiert. Zu Entscheidungskriterien zählen dabei: Kosten der Software inklusive aller Neben- und Folgekosten, Datensicherheit, Qualität und Zuverlässigkeit. Daneben besteht zunehmend der Drang zur Lösung von Abhängigkeiten zu proprietären Anbietern, die Brechung von Monopolstellungen und die Verhinderung von Spionageangriffen durch Closed Source Software.
Zusätzlich ist der Staat verpflichtet, eine verfassungsgemäße Garantie einzulösen: jedem Bürger ist der freie Zugang zu Daten, im Sinne eines nichtkommerziellen, dauerhaften und kostenneutralen Standards für den Zugriff und die Auswertung von Daten zu gewährleisten.
Mittlerweile ist OSS Tagesthema in den Regierungen vieler Staaten und die Liste konkreter Vorhaben ist lang. Für Europa wegweisend kann der Beschluss der Kommission der Europäischen Union im 6. Rahmenprogramm zum Thema 'Technologien der Informationsgesellschaft' gesehen werden [Council of the European Union (2000), p. 23] und inzwischen definiert sich der moderne und schlanke Staat auch über die Effizienz seiner Datenverarbeitung in der Verwaltung. Über diese Hintertür ist, im positiven Sinne, OSS zum Politikum geworden und kaum eine Regierung hat es versäumt, Taten in Form konkreter Beschlüsse folgen zu lassen. Als Beispiele seien genannt England: [OSS England], Frankreich: [OSS Frankreich], die Rahmenvereinbarung des Bundesministerium des Inneren zum verstärkten Einsatz von OSS in den Bundesbehörden, sowie die Entscheidungen des Deutschen Bundestages 150 Server auf Linux umzustellen [OSS Bundestag].
Diese ermutigende Tendenz setzt sich auch auf Landes- und Kommunalebene fort (Beschluss der Stadt München über den Einsatz von OSS auf 14000 Einzelplatzrechnern in der städtischen Verwaltung [OSS München]. Besondere Beachtung verdient in diesem Zusammenhang die IT-Strategie des Ministerium des Inneren bei der Polizei in Niedersachsen für das Projekt NIVADIS [OSS Niedersachsen]. Dort ist seit Anfang 2003 eine flächendeckende Linux-Architektur inklusive Linux-Clients für das gesamte Land Niedersachsen im Einsatz. Dieses ist zur Zeit die größte produktive, OSS-basierte Gesamtlösung in Europa [nivadis].
Auf Bundesebene wird in diesem Zusammenhang das SAGA Projekt des Bundesministerium des Inneren eine Schlüsselrolle spielen [SAGA]. SAGA beschreibt die empfohlenen technischen Rahmenbedingungen für die Entwicklung, Kommunikation und Interaktion von IT-Systemen der Bundesbehörden. Damit sollen kostenintensive Doppelentwicklungen vermieden und Synergien möglich werden. Im Rahmen von SAGA sind eine Reihe von Standards festgelegt, die bei der Umsetzung von E-Government-Anwendungen berücksichtigt werden müssen. Gleichzeitig definiert das Projekt einen Lebenszyklus für Produkte die zum Einsatz kommen, in einem Forum werden ihre Vor- und Nachteile diskutiert. SAGA diktiert nicht den Einsatz von OSS, dennoch unterstützt das Vorgehen mit Sicherheit den Einsatz von OSS, die in ihrer Entstehung einen ähnlichen Prozess schon einmal durchlaufen hat.
Global gesehen bietet der Einsatz von OSS gerade für Schwellen- und Entwicklungsländer enormes Potenzial. Brasiliens Regierung geht dabei einen vielleicht zukunftweisenden Weg: sie plant alle mit öffentlichen Geldern finanzierten Softwareprojekte als Open Source zu veröffentlichen [OSS Brasilien].
Durch den empfohlenen Einsatz von OSS kommt es zu positiven Effekten bei ihrer Verbreitung: je mehr Nutzer ein Produkt benutzen, desto nützlicher wird dieses Produkt für alle anderen Nutzer. So werden sich beispielsweise durch den flächendeckenden Einsatz von Linux in Verbindung mit OSS-Officelösungen auf Arbeitsplatzrechnern die Kosten für Einführung, Wartung und Schulung reduzieren. Der Staat erhöht den Bekanntheitsgrad von OSS und damit das Vertrauen der Nutzer.
2.3. Firmen
Es ist allgemein ein verstärkter Einsatz großer Firmen für OSS zu beobachten (IBM, Sun, HP, SAP). Eine solche Unterstützung kann indirekt auch wirtschaftlichen Nutzen erbringen. So ist die Freigabe von NetBeans durch Sun oder Eclipse durch IBM vor allem zu dem Zweck geschehen, die Zahl der potenziellen Entwickler für diese Produkte zu erhöhen. Aber auch strategische Beteiligungen an der Weiterentwicklung von OSS sind allgemein bekannt, unter diesem Gesichtspunkt kann beispielhaft die Linux-Unterstützung von IBM betrachtet werden.
Über OSS kann zudem auch ein Quasistandard lanciert werden, der unter Umständen so von bestimmten Akteuren am Markt gewollt ist. Darüber hinaus lassen sich Marktpositionen von Konkurrenten mittels OSS gezielt angreifen. So ist Suns offene J2EE-Architektur ein wichtiger Gegenentwurf zu Microsofts kommerzieller .Net Initiative. Auch die Freigabe von OpenOffice/StarOffice fällt in diese Kategorie. Zusätzlich ist die Offenlegung von Code in einem OSS Projekt von Firmen oder die Unterstützung von OSS Projekten durch Firmen eine exzellente Eigenwerbung.
Unter kommerziellen Gesichtspunkten ist OSS beileibe nicht immer ein Segen. OSS kann soweit fortgeschritten sein, dass Firmen Schwierigkeiten mit der Vermarktung ganzer Produktlinien bekommen. So stellte IBM die Weiterentwicklung seiner kommerziellen Entwicklungsumgebung VisualAge ein und startete das OSS Projekt Eclipse. IBM will nicht die Kontrolle im Markt für Entwicklungsumgebungen vollständig an die Konkurrenz abgeben. Ähnliche Beweggründe müssen Borland, einer der bedeutenden Akteure in diesem Marktsegment, dazu bewegt haben, sich von Beginn an im Lenkungsausschuss von Eclipse zu engagieren. Firmen sehen sich in solchen Fällen offenbar aus Angst vor Kontrollverlust gezwungen, OSS zu unterstützen oder zu institutionalisieren.
3.1. Motive
Die Motive für den Einsatz von OSS wurden zum Teil schon in der Einleitung beleuchtet und sind hier noch einmal analysiert.
Monetäre Aspekte
Es liegt in der Natur der Sache, dass aufgrund der nicht kommerziellen Ausrichtung der Einsatz von OSS Kostensenkungspotenzial beinhaltet. Die realen Kosten eines Produkteinsatzes umfassen jedoch nicht nur die Anschaffungskosten. Eine seriöse Kostenabschätzung versucht möglichst viele kostenverursachende Aspekte zu berücksichtigen. Standardvorgehen ist in diesem Bereich die Total Cost of Ownership-Analyse (TCO) der Gartner Group. Hier wird zunächst nach direkten und indirekten Kosten unterschieden, diese werden weiter aufgeschlüsselt und nach verschiedenen Gesichtspunkten gewichtet (zum Beispiel nach Anwendergruppe, Anwendungsfeld, Komplexität der Anwendungslandschaft, technologisches Umfeld), wobei insbesondere den 'verdeckten' indirekten Kosten Aufmerksamkeit geschenkt wird.
Der Einsatz von OSS ist also aus monetärer Sicht eine individuelle Entscheidung und hängt vom konkreten Anwendungsszenario ab. Dennoch lassen sich Tendenzen identifizieren:
Direkte Kosten a) Anschaffungskosten für Hardware - OSS ist im allgemeinen ressourcenschonend, das kann die Hardwarekosten senken b) Lizenzkosten für Software - bei OSS verschwindend geringe Kosten (zum Beispiel für Download oder für eine Distribution) c) Kosten für Upgrades - für OSS verschwindend gering d) Kosten für Administration - OSS besitzt Potenzial zur Reduktion laufender Administrationsaufwendungen (unabhängige Schätzungen liegen bei 25% bis 50%) e) Supportkosten - betrachtet man hier die tatsächlich anfallenden Kosten für die Lösung eines Problems beim Betrieb der Software, so gibt es für OSS einen breiten Bereich von exzellenter Unterstützung durch eine weltweite Community (in Newsgroups, Foren) bis hin zum Zwang zur Selbsthilfe. Support ist für OSS nicht garantiert, dennoch meistens gegeben und erfordert eine Einzelfallanalyse. f) Schulungskosten - hier ist OSS im Nachteil. Der Umgang mit freien Betriebssystemen oder freier Anwendersoftware ist im persönlichen Umfeld der meisten Endanwender nicht selbstverständlich. g) Migrationskosten - OSS ist hier operativ im Nachteil, denn bei den meisten OSS IT-Strategien werden Migrationsaufwände entstehen (weg von proprietären Formaten hin zu offenen Standards). Strategisch gesehen kann eine solche Migration aber als ohnehin unvermeidlich angesehen werden.
Indirekte Kosten: a) Endnutzerkosten - die zentrale Frage ist dabei: wie effizient arbeitet der Endnutzer mit der Software und welchen Mehrwert kann er mit ihr produzieren. In diesem Punkt herrscht kein Konsens. Die Antworten werden aber entscheidend sein, denn Endnutzerkosten können nach TCO durchaus mehr als ein Drittel der Gesamtkosten für ein IT-System in seinem gesamten Lebenszyklus ausmachen. Hier spielen auch 'weiche' Kriterien eine wichtige Rolle: wie gerne arbeitet der Endnutzer mit dem System, wie oft wird er von diesem bei seiner eigentlichen Arbeit abgelenkt, empfiehlt er die Software, bildet er sich freiwillig und selbständig weiter, verbringt er Zeit mit Spielen. b) Systemausfälle - auf den Einsatz von OSS für geschäfts- und infrastrukturkritische Anwendungen wird noch näher eingegangen. Eines vorweggenommen: Kann man sich aus technologischer und architektonischer Sicht für OSS in kritischen Bereichen entscheiden, dann wird die tendenziell hohe Stabilität und Performanz der OSS-basierten Lösung hier Kostenvorteile sichern (siehe dazu Abschnitt 'Strategische Aspekte').
Operative Aspekte
Hier kommt OSS Produkten die vielschichtig geprüfte Qualität in Design und Codierung zugute. Im allgemeinen wird man durch den Einsatz von OSS ein hohe Stabilität im Betrieb und eine solide Basis für Performanz erreichen. Solche Eigenschaften minimieren zudem die Aufwände für die Entwicklung, Optimierung und Verwaltung einer Anwendung. Im Vergleich zu kommerziellen Produkten fällt der hohe Sicherheitsstandard von OSS auf, eine Konsequenz des offenen Entwicklungsprozesses (Linus' Law: 'Given enough eyeballs, all bugs are shallow.', Sicherheitslücken werden von vielen Testern gesucht und umgehend beseitigt).
Strategische Aspekte
Strategisch gesehen besitzt OSS einige sehr vorteilhafte Eigenschaften. Wer sich auf OSS einlässt wird sich nicht in ein Abhängigkeitsverhältnis zu einem Drittanbieter begeben und muss keine markt- oder produktstrategischen Überraschungen einplanen. Die Schnittstellen offener Software unterstützen naturgemäß auch offene Standards und vermeiden proprietäre Formate. Damit gibt OSS eine hohes Maß Zukunftssicherheit - auch wenn das verwendete OSS Produkt nicht mehr genutzt wird, werden Schnittstellen und Formate noch unterstützt. Oft besitzt OSS bei der Etablierung von Standards eine Trendsetter-Rolle.
Dem gegenüber stehen jedoch zwei gewichtige Nachteile. Zum einen gibt es in der Regel beim Einsatz von OSS keine formal-juristische Haftung. Der Einsatz von OSS geschieht somit auf eigene Gefahr. Zum anderen hat man als Nutzer einer offenen Lösung keinen nennenswerten Einfluss auf die Zukunft des OSS Projekts. Abgesehen davon, dass ein Projekt jederzeit eingestellt werden kann wenn das Engagement der OSS Community erlahmt, gibt es auch bei populären OSS Projekten niemals eine Support-Garantie zum Beispiel für neue Hardware oder ein bestimmtes Betriebssystem.
3.2.Werkzeuge
Mit Werkzeugen ist hier im engeren Sinne alles gemeint, was die Erstellung von Software in allen Phasen des Entwicklungsprozesses unterstützt (Compiler, Entwicklungsumgebungen, Versionsverwaltung, CASE-Tools, Codegeneratoren, Profiler und Code-Analysierer, Werkzeuge zur Anforderungsanalyse und Fehlerverfolgung). In diesem Bereich kann OSS wirklich trumpfen, hier besteht eine Personalunion zwischen Anwender und Entwickler und die meisten dieser Projekte wurden aus einem wohl definierten Bedürfnis heraus initiiert.
Im realen Projekt wird der Einsatz solcher Werkzeuge eine wichtige strategische Entscheidung sein. Es ist angezeigt, die Entwickler als Nutzer dieser Tools bei der Entscheidungsfindung mit einzubeziehen. Die Wahl der richtigen Werkzeuge ist für den Erfolg eines Projekts durchaus entscheidend.
Auffällig ist die Dominanz von Java-basierten Produkten in diesem Bereich. Die wichtigsten Gründe dafür sind die Plattformunabhängigkeit dieser Software und der generell offene Ansatz der Java- Entwicklungsumgebung und aller damit verbundenen Technologien. Und mit der Zahl der zur Verfügung stehenden offenen Werkzeuge und Module wächst auch die Motivation, neue OSS aus diesen Komponenten zu kombinieren [Backschat 2004, Eickstädt 2003].
Integration von Komponenten bei der Softwareentwicklung bedeutet für den Entwickler, dass er mit wenig Aufwand Funktionalität in seine Lösung integrieren kann. Diese Lösung ist im Normalfall fehlerarm, optimiert und gut dokumentiert. Handelt es sich um eine OSS Komponente, so ist sie zudem noch kostenfrei.
3.3. Anwendungssoftware
Die Grenze zwischen Werkzeugen und Anwendungssoftware ist fließend. Anwendungssoftware meint hier Software zur individuellen Bearbeitung von Dateninhalten: Textverarbeitung, Tabellenkalkulationen, Präsentationssoftware, Mailclients, Web-Browser, sowie Programme zum Bearbeiten von speziellen Dateiformaten (Bilder, Filme). Für alle Plattformen existiert mittlerweile ein umfangreiches Angebot an Anwendungssoftware aus dem Open Source Bereich (OpenOffice, Ghostscript, Ghostview, Gimp, Xmovie, GPG, Jabber, Mozilla). Diese Entwicklung hält weiter an, möglicherweise wird der Einsatz von OSS in diesem Bereich bald zum Selbstverständnis.
Das eingangs erwähnte Projekt NIVADIS der Polizei in Niedersachsen ist ein Praxisbeispiel für die Machbarkeit der Bereitstellung hocheffizienter und sicherer Client-Arbeitsplätze auf reiner OSS-Basis: mit SuSE Linux als freiem Betriebssystem sind dort folgende Anwendungen im Einsatz: 1. OpenOffice für Textverarbeitung, Tabellenkalkulation und Präsentationssoftware 2. Mozilla als Web-Browser 3. Ximian Evolution für Mail- und Terminverwaltung 4. Konqueror als Dateimanager 5. J2SE als Plattform für die Clients der polizeispezifischen Geschäfts-Applikationen 6. weitere Desktop-Tools (Calc, Snapshot, etc.)
Es ist rätselhaft, dass sich das sehr gelungene OpenOffice als vollwertiger Ersatz für die Office-Suite der Firma Microsoft nur langsam durchsetzt. Wahrscheinlich ist der von Microsoft über Jahre etablierte Quasi-Standard noch zu tief im Bewusstsein des Nutzers eingeprägt, zusätzlich existiert eine unüberschaubare Zahl verschiedenster Insellösungen für diese Produktlinie. Zum einen kommt OpenOffice hier zugute, dass es plattformunabhängig implementiert ist und damit auch für das freie Betriebssystem Linux zur Verfügung steht. Zum anderen sehen sich die Anwender in nächster Zeit ohnehin mit Migrationsaufwänden konfrontiert, die durch die Umstellung der Microsoft-NT auf die -XP Technologie entstehen. Für viele Entscheider kann das der Anlass für ein radikalen Strategiewechsel sein.
Ein oft zitiertes Argument gegen OSS Anwendersoftware ist fehlendes Anwender-Know-how und der damit verbundene Mehraufwand bei der Einführung und Schulung der Nutzer. Dieser Einwand ist jedoch möglicherweise weniger kritisch als vielfach angenommen. Ein arrivierter Anwender wird kaum Schwierigkeiten haben, eine GUI- basierte, nach modernen ergonomischen Grundsätzen entworfene Applikation zu bedienen. Der wenig erfahrene Nutzer wird sich ohnehin neu einarbeiten müssen und kennt keinen Vergleich zum kommerziellen Pendants.
3.4. Mission Critical Software
Damit ist hier infrastrukturkritische Software gemeint, also Software zur Bereitstellung zentraler, das gesamte System betreffende Dienste. OSS ist hier schon länger und mit bemerkenswertem Erfolg für dedizierte Services im Einsatz (zum Beispiel Webserver, Mailserver, Namensdienste, Firewalls). Es ist weiterhin ein allgemeiner Trend zur Nutzung von OSS als einheitliche serverseitige Konsolidierungsplattform zu beobachten (x86 bis zLinux). Die allgemeinen Stärken von OSS, Stabilität, Sicherheit, Modularität Herstellerunabhängigkeit, Entwicklungstransparenz, systemnahe Dokumentation sowie genügsame Hardwareanforderungen bringen hier enorme Vorteile. Zudem werden mehr und mehr praktisch alle relevanten Hardwareplattformen berücksichtigt (Mobile Devices bis Mainframes) und es gibt eine flächendeckende Unterstützung durch Hersteller von Basis- und Standardsoftware.
Dennoch sind Projekte mit einer reinen OSS-Basis derzeit eher die Ausnahme. Zum einen existiert noch nicht genügend Expertise im Bereich Administration und Verwaltung. Zusätzlich gibt es Grenzen bei der Verfügbarkeit von Spezialanwendungen.
Die gravierendste Einschränkung bei der Umsetzung einer OSS-basierten Infrastruktur ist im Moment eine fehlende Persistenzschicht. Zumindest wenn man zugleich Verfügbarkeit für Linux, Transaktionalität, Sicherheit und Skalierbarkeit fordert. Die Situation scheint sich hier gerade zu entspannen: Im kommerziellen Bereich treibt Oracle massiv sein Engagement für das Betriebssystem Linux voran, andere Anbieter werden hier alsbald nachziehen. Im OSS-Bereich existieren das performante MySQL (allerdings mit eingeschränkter Transaktions-Funktionalität) und die viel versprechende PostgreSQL Datenbank (mit zurzeit noch eingeschränkter Skalierbarkeit).
Zum jetzigen Zeitpunkt muss das Persistenz-Backend (egal ob kommerziell oder OSS-basiert) als das fehlende Teil einer vollständigen OSS Infrastruktur gesehen werden. Es kann dennoch davon ausgegangen werden, dass sich die Situation diesbezüglich in einem überschaubaren Zeitraum ändert.
4. Einfluss auf Projekt- und Prozessmanagement
Die Erstellung von Software ist ein Prozess. Für umfangreichere Projekte ist die Gestaltung und Kontrolle dieses Prozesses entscheidend für die Qualität des erzielten Ergebnisses und dafür dass das Ziel mit den zur Verfügung stehenden Ressourcen überhaupt erreicht wird. Insgesamt ist eine Analyse der in OSS Projekten eingesetzten Prozesse sehr inspirierend, zumindest wenn man sich an den zumeist positiven Ergebnissen der OSS Entwicklungen orientiert.
Jeder Softwareentwicklungsprozess besitzt fünf Phasen, die sich mehr oder weniger stark voneinander abgrenzen und Rollen im Projekt definieren: 1. Anforderungserhebung - Ermittlung der Problemstellung des Anwenders, der Akteure, Definition des Systemverhaltens, 2. Analyse - Abbildung der Anforderungen auf ein implementierbares Modell, 3. Entwurf - Konstruktion einer konkreten Lösung, das beinhaltet den Systementwurf und die Identifizierung von Subsystemen, einen Architekturentwurf und ein Design mit Schnittstellenanalyse. In dieser Phase kann mittels Prototypenentwicklung die Machbarkeit des Entwurfs demonstriert werden. 4. Implementierung - Erzeugung von Quellcode der den Entwurf umsetzt und die Problemstellungen des Anwenders detailliert löst, 5. Tests - Überprüfung, inwieweit die Ergebnisse und Produkte der einzelnen Phasen des Projekts die geforderten Ziele erfüllen und 6. IT-Rollout und Softwareeinführung [Brügge 2004].
Die einzelnen Phasen können nach verschiedenen Vorgehensmodellen abgearbeitet werden. Bei einer sukzessiven Abarbeitung dieser Phasen spricht man vom Wasserfall-Modell. Es bringt Vorteile bei der Projektorganisation und -planung und ist sinnvoll bei kleineren Projekten mit überschaubaren, gut definierbaren Zielen. Werden die einzelnen Phasen in mehreren Zyklen abgearbeitet handelt es sich um das iterativ-inkrementelle Vorgehensmodell. Es verleiht dem Projekt einen höheren Innovationsgrad und muss bei großen Projekten, in denen Projektziele durch die erreichten Zwischenergebnisse modifiziert werden, zum Einsatz kommen. Das iterativ-inkrementelle Vorgehensmodell zwingt die Projektorganisation und - planung, im Verlauf des Projekts flexibel auf neue Randbedingungen zu reagieren. Der Entwicklungsprozess lebt hier maßgeblich von Rückkopplungen der einzelnen Projektphasen untereinander. Eine populäre Umsetzung dieses Modells ist der Rational Unified Process.
Wenig Erfahrung bei der kommerziellen Softwareentwicklung gibt es mit Vorgehensmodellen, in denen sich der Entwicklungsprozess im Verlauf des Projekts den aktuellen Rahmenbedingungen anpasst (adaptives Vorgehensmodell). Das adaptive Vorgehensmodell stellt den kreativen Anteil der Softwareentwicklung in den Mittelpunkt, es orientiert sich an Ergebnissen, weniger an Aktivitäten. Die dabei entstehenden leichtgewichtigen Entwicklungsprozesse werden auch als agile Prozesse bezeichnet. Planung im traditionellen Sinne tritt hier in den Hintergrund in dem Sinne, dass Abweichungen von einem vermeintlichen Plan nicht als kritisch betrachtet werden. Die im Moment populärste Umsetzung eines agilen Prozesses ist das Extreme Programming (XP). Beim XP versucht man unter anderem möglichst viele Zwischenschritte bei allen anfallenden Aktivitäten zu vermeiden, indem man Ergebnisse ohne Umwege in den Quellcode einbringt. Der sich entwickelnde Quellcode ist das wichtigste Ergebnis aller Aktivitäten.
4.1. Der OSS Entwicklungsprozess
OSS Entwicklungsprozesse tendieren stark zu adaptiven Vorgehensmodellen. Getrieben durch den Grundsatz der Freiwilligkeit unterstützen OSS Projekte in erster Linie die Kreativität der beteiligten Entwickler und vielleicht liegt hier der Schlüssel zum Erfolg vieler OSS Projekte. Die geografische Trennung aller am Projekt Beteiligten erfordert ein Vorgehen, das softwaretechnisch wünschenswerte Strukturprinzipien wie lose Kopplung und Modularisierung quasi erzwingt. Unabdingbare Voraussetzung ist ein stringentes Konfigurationsmanagement. Jeder Beteiligte muss jederzeit in der Lage sein, den aktuellen Projektstand einzusehen. Der Build-Prozess muss einfach gestaltet und duplizierbar sein. Die Kommunikation zwischen den einzelnen Akteuren wird als fester Bestandteil des Entwicklungsprozesses betrachtet, jede Art von Kommunikation erzeugt reproduzierbare Ergebnisse. Das sind im einfachsten Fall Wortmeldungen in Foren, in denen über das weitere Projektgeschehen abgestimmt wird, es können Einträge in einem Fehlerverfolgungssystem sein, aber auch konkrete Vorschläge für Änderungen im Entwurf, im Design oder im Sourcecode gehören dazu. Die damit etablierten Rückkopplungen garantieren einen lebendigen Innovationszyklus im Prozess, der alle Bereiche und Phasen betrifft.
Zentrale Entscheidungen werden oft von einem Maintainer in Zusammenarbeit mit Key-Entwicklern getroffen. Dennoch ist die Verantwortung für das Lösen von Problemen nicht fest vergeben, die Entwickler teilen sich diese, ihren Neigungen und Qualifikationen entsprechend selbst zu. Alle Ergebnisse sind von allen einsehbar und überprüfbar (peer-review). Das Lösen von Problemen erfolgt dabei nach vereinbarten Regeln, die den Gesamtprozess der Produktentwicklung transparent gestalten.
Dieser Abschnitt will sich mit der Frage auseinander setzen, wie die unübersehbaren Erfolgsfaktoren der OSS Entwicklungsprozesse auf kommerzielle Projekte übertragen werden können. Die hier gemachten Schlussfolgerungen sind dabei sicherlich oft diskussionswürdig und sollen als Inspiration gedacht sein. Vorweg muss eingestanden werden, dass sich in kommerziellen Projekten die völlige Freizügigkeit in der Verteilung von Aufgaben und Verantwortung nicht realisieren lässt. Sie funktioniert nur mit unbegrenzten Entwicklerressourcen.
Effizientes Konfigurations- und Buildmanagement
Wie bereits beschrieben bedingt die gewissermaßen maximale geografische Verteilung der Beteiligten im OSS Entwicklungsprozess hocheffizientes Konfigurations- und Buildmanagement (KM, BM). Das Überleben des OSS Projekts hängt davon ab. In kommerziellen Projekten können Lücken oder Fehler im KM/BM kompensiert werden, wenn sich die Zusammenarbeit der Projektbeteiligten informell regelt. Dabei werden Vereinbarungen zwischen wenigen Akteuren getroffen, alle übrigen Projektteilnehmer können diese jedoch nicht wahrnehmen und moderieren. Im weiteren Projektverlauf kommt es dann zwangsläufig zu Abstimmungsschwierigkeiten und das Projekt zahlt einen Preis, der oftmals gleichzeitig hoch und dennoch unaufgedeckt ist.
Machen Sie die Probe: Wie viel Aufwand hat ein Entwickler in der Einarbeitungsphase, sich eine funktionierende Entwicklungsumgebung bereit zu stellen und wie viel Unterstützung braucht er dabei? Wie viel Zeit braucht ein projekterfahrener Entwickler eine defekte Arbeitsumgebung zu reparieren? Wie zuverlässig kann ein historischer Projektstand komplett reproduziert werden? Wo steckt das Wissen über den Funktionsablauf des Buildprozesses, in einigen wenigen Köpfen erfahrener Projektteilnehmer oder ist es zentral und aktuell dokumentiert? Welche Aussagekraft hat das Projekthandbuch?
Hier ein Vorschlag für eine Metrik bezüglich der Effizienz Ihres KM und BM. Messen Sie die Zeit, die ein Entwickler als Projektneuling braucht, sich eine funktionierende Arbeitsumgebung mit dem aktuellen Projektstand zu beschaffen. Dabei soll diese Aufgabe ohne fremde Hilfe geschafft werden.
Agiles Vorgehensmodell, XP
OSS Projekte haben flache Hierarchien. Änderungen und Anpassungen am Entwicklungsprozess sind im Bereich OSS die Regel und werden aufgrund von Mehrheitsentscheidungen durchgeführt. Kennzeichnend ist ein hoher Grad an Verantwortungsteilung in allen Phasen der Entwicklung. Notwendige Anpassungen und Erweiterungen manifestieren sich so ohne Umwege in Form von Änderungen im betreffenden Programmcode.
In kommerziellen Projekten gibt es nur wenig Erfahrung mit agilen Vorgehensmodellen. Klassische Formen des Projektmanagements planen Aktivitäten statt Entitäten, den eigentlichen Ergebnissen eines Projekts. Das bevorzugte Planen von Aktivitäten hängt sicher mit dem allgegenwärtigen Termindruck in kommerziellen Projekten zusammen und ist grundsätzlich auch nicht nachteilig. Dennoch muss eine geleistete Aktivität immer am dabei entstandenen Zwischen- oder Endprodukt gemessen werden. Besitzt dieses nicht die geforderte Funktionalität in einer zu definierenden Mindestqualität, so ist der Erfolg einer Aktivität ein Trugschluss und führt im weiteren Verlauf zu Folgeaktivitäten und damit zu ungeplanten Mehraufwänden.
Kommunikation
OSS Projekte besitzen eine Infrastruktur zur Kommunikation, da informelle Kommunikation zwischen den Konstituenten im Projekt nicht möglich ist. Eine solche Infrastruktur macht Informationen persistent und damit potenziell für alle anderen Projektteilnehmer zugänglich. Diese wiederum können die Information moderieren und den Informationsgehalt verdichten. Die essenziellen Bestandteile der Kommunikations-Infrastruktur sind dabei a) Foren, b) ein Fehlerverfolgungssystem und c) der Programmcode. Alles weitere ist Eigendynamik.
Sie glauben nicht, dass es so einfach ist? Dann stellen Sie sich für Ihr Projekt einmal folgende Fragen: Gibt es im Projekt genau eine zentrale Anlaufstelle für persistente Informationen und kann jeder Projektteilnehmer diese Informationen einsehen und moderieren? Wenn nicht, wo werden im Moment Anmerkungen, Hinweise, der Verdacht auf Risiken, Mängel oder Probleme hinterlegt? Gibt es nichtpersistente Informationen im Projekt und wenn ja wie wichtig und wie umfangreich sind sie? Gibt es ein Fehlerverfolgungssystem und haben wirklich alle darauf Zugriff, nutzen alle diese Informationsquelle? Welche Rolle spielt der Programmcode bei der Informationsweitergabe? Sind Ihre Entwickler mit der Technik von Programm-Patches vertraut und nutzen sie diese? Wie hilfreich bewerten Ihre Entwickler die Code-Dokumentation?
Umfassendes Anforderungsmanagement
Anforderungsmanagement wird von allen Beteiligten mitgestaltet und es existieren Regeln, die eine Vereinnahmung durch einen oder wenige Akteure verhindern. Konkrete Vorgaben gibt es für die Ergebnisse von Arbeit, nicht jedoch für deren Zustandekommen.
Kommerzielle Projekte müssen hier eine Transformation in mehreren Schritten gestalten. Beginnend bei einer Sammlung von definierten und wenig strukturierten Anforderungen (zum Beispiel in Form eines Pflichtenheftes mit vielleicht juristisch-formalem Charakter) werden über eine fachliche Analyse, einen System- und Architekturentwurf und ein Design letztlich Artefakte in Form von Programmcode erzeugt. Traditionell werden diese Transformationen von dedizierten Rollen durchgeführt und in größeren Projekten sind diese Rollen auf verschiedene Projektgruppen aufgeteilt. Mit jeder Transformation geht nun ein Stück Information verloren und neue Information kommt hinzu. Das Ergebnis kann nunmehr von der ursprünglichen Anforderung soweit entfernt liegen, dass der Anwender nicht deren Umsetzung wiedererkennt.
Zur Vermeidung dieses Phänomens ist es notwendig, allen Beteiligten dieses Prozesses die Möglichkeit zu geben, alle Phasen der Transformation zu beobachten und darauf Einfluss nehmen zu können. Die dabei entstehende Kakophonie wird wirksam unterdrückt, wenn diese Einflussnahme ausschließlich über persistente Kommunikationskanäle abgewickelt wird.
Codereview, Coderefactoring
Die Ursache hoher Qualität von OSS Code begründet sich in dessen Offenlegung. Es ist die zentrale Aktivität der Open Source Community mittels peer-review Schwachstellen aufzuspüren und zu beseitigen. Vorschläge in dieser Richtung können dabei auch ohne äußeren Anlass (zum Beispiel ohne dass eine spezielle Anforderung vorliegt oder ein Fehler erkannt wird) gemacht werden. Es erfolgt umgehend eine Begutachtung solcher Verbesserungen durch alle Beteiligten, und im günstigen Fall eine direkte Verwertung. Ganz offensichtlich führt dieses Vorgehen in der Bilanz zu besten Ergebnissen. Wenn man davon ausgeht, dass jeder Mangel ohnehin Aufwände für seine Beseitigung erfordert, ist dieses Vorgehen auch terminlich vorteilhaft.
Moderne Vorgehensmodelle fassen Codereview und Coderefactoring als eigenständige Aktivität auf. In der Realität vieler Projekte werden diese Tätigkeiten jedoch oft nur dann ernst genommen, wenn die laufende Entwicklung aufgrund von Design- und Codeschwächen nicht mehr durchführbar ist. Das verfälscht den eigentlichen Zweck dieser Aktivitäten, nämlich solche Situationen zu vermeiden. Kommerzielle Projekte müssen Codereview und Coderefactoring als eine Investition in die allernächste und ferne Zukunft des Projekts berücksichtigen und Entwicklern ausreichend Zeit für diese Aktivitäten zur Verfügung stellen. Die Ergebnisse von Codereview und Coderefactoring werden dabei einem angemessenen Controlling unterzogen.
[Backschat 2004] Backschat, Martin; Edlich, Stefan: J2EE-Entwicklung mit Open-Source-Tools, 1. Aufl., Spektrum Akademischer Verlag, Elsevier München, 2004
[Brügge 2004] Brügge, Bernd; Harhoff, Dietmar; Picot, Arnold; Creighton, Oliver; Fiedler, Marina; Henkel, Joachim: Open-Source-Software - Eine ökonomische und technische Analyse, 1. Aufl., Springer-Verlag Berlin Heidelberg, 2004
[Eickstädt 2003] Eickstädt, Dieter; Reuhl, Thomas: Java mit Open-Source-Tools - J2EE Projekte mit Tomcat, Struts, ANT und Jboss, Markt+Technik Verlag, München 2003
[nivadis] http://www.nivadis.de
[OSI-Kriterien] http://www.opensource.org/docs/definition.php
[OSS Brasilien] http://www.heise.de/newsticker/meldung/42570
[OSS Bundestag] http://www.heise.de/newsticker/meldung/25230
[OSS England] http://www.ogc.gov.uk/index.asp?id=2190
[OSS Frankreich] http://www.computerwoche.de/index.cfm?pageid=254&artid=57957
[OSS München] http://www.heise.de/newsticker/meldung/37197
[OSS Niedersachsen] http://www.heise.de/newsticker/meldung/40374
[SAGA] http://www.kbst.bund.de/saga
[sourceforge] http://www.sourceforge.net/softwaremap/trove_list.php?form_cat=14