Herausforderung „Globales Software Engineering“
Der Begriff „Globales Software Engineering“ bezeichnet die Herausforderung, Software räumlich und zeitlich verteilt über Organisations- und Kulturgrenzen hinweg zu entwickeln. Begibt man sich auf die Suche nach Lösungsansätzen, tauchen hin und wieder Verweise auf die „Open Source Community“ auf, die sich schon lange mit global verteilter Entwicklung in lose koordinierten Teams beschäftigt. Außerdem findet man unter dem Titel „Corporate Open Source“ eine Reihe von Initiativen, die Open-Source-Vorgehen in die kommerzielle Softwareentwicklung und IT übertragen. In unserer ersten Meinungsecke möchten wir uns mit der Frage befassen: Inwieweit sind Ansätze aus dem Open Source und Corporate Open Source geeignet für den Einsatz beim Globalen Software Engineering? Gemeinsam ist beiden Ideen die verteilte Entwicklung, viele Rahmenbedingungen unterscheiden sich jedoch – eine Übertragung der Prinzipien scheint somit nur begrenzt sinnvoll.
Besonderheiten von GSE und FLOSS
Die verteilte Entwicklung von Software, das „Global Software Engineering“ (GSE), ist möglich geworden auf Basis der weltweiten Vernetzung mittels des Internets. Gründe für die globale Arbeitsteilung sind der Druck, Kosten einzusparen, und der Mangel an Fachkräften im eigenen Land. Diese Themen wurden früher häufig unter den Begriffen „Offshoring“ und „Outsourcing“ zusammengefasst, mit denen vor allem auf die Chancen und Schwierigkeiten auf rechtlicher und finanzieller Ebene verwiesen wurde. „Global Software Engineering" erweitert diese Betrachtung um die Frage, wie sich die verteilte Arbeit auf das Projektmanagement und die Entwicklung auswirkt.
In verteilten Teams zu entwickeln, schafft neue und mitunter schwierige Probleme, die in ihrer Summe die angestrebten Vorteile mehr als aufwiegen können. Herbsleb [1] betont, dass Schwierigkeiten, die die Koordination von Entwicklungsvorhaben betreffen, verstärkt auftreten. Bedingt durch die Entfernung tauschen sich die Teams weniger aus und die Güte des Austausches (der nicht mehr direkt von Person zu Person stattfindet) ist im Vergleich zu lokalen Projekten schlechter. Ebert [2] hat eine breitere Sicht auf die Probleme. Sie reichen seiner Ansicht nach von mangelnder Qualität und verspäteter Fertigstellung über häufigere späte Änderungen, einer hohen Personalfluktuation und einem damit verbundenen Verlust an Projektwissen bis zur Abhängigkeit von einzelnen Herstellern und kulturellen Unterschieden.
Die Entwicklung von quelloffener und freier Software („Free / Libre / Open Source Software“ = FLOSS) erfolgte schon immer unter verteilten Bedingungen. Außerdem sind daran hauptsächlich Freiwillige beteiligt. In verschiedenen Projekten haben sich somit Strukturen herausgebildet, die sowohl der Koordination des Projektes dienen, als auch der Festlegung des Produktes und der Rollenverteilung im Projekt. Bekannte Beispiele für große, weltweit verteilte Projekte, die quelloffen und mithilfe der Partizipation von Freiwilligen entstanden sind, sind der Linux-Kernel oder der Apache Web Server. Mittlerweile gibt es aber Beispiele für FLOSS-Produkte ganz verschiedener Anwendungsbereiche und Größenordnungen.
Grundlagen von GSE und FLOSS im Vergleich
Um besser zu verstehen, welche Gemeinsamkeiten und Unterschiede es zwischen GSE und FLOSS gibt, sind in der folgenden Tabelle die projektkritischen Merkmale der beiden Ansätze gegenübergestellt und bewertet.
Die beiden Welten haben vor allem eines gemeinsam: die verteilte Entwicklung und die damit verbundenen Herausforderungen sowie vergleichbare technische Lösungen. Darüber hinaus existieren viele Unterschiede. Hauptsächlich solche, die damit zu tun haben, dass geschäftlich organisierte Softwareentwicklung vertraglich geregelt ist und damit konkrete Kosten- und Zeitgrenzen sowie Anforderungen an das Produkt und die Qualifikation der Mitarbeiter gestellt werden. Diese Bindung ist in der wesentlich offeneren Organisationsstruktur der FLOSS-Projekte in dieser Weise nicht gegeben.
Corporate Open Source
Schaut man auf die wenigen aber vorhandenen Beispiele von Initiativen, bei denen sich Konzerne mit dem Thema Open Source auseinandergesetzt haben, dann stellt man fest, dass dort andere Bereiche als der eigentliche Realisierungsprozess von Software im Fokus stehen. Einige Beispiele von „Corporate Open Source" sind in der folgenden Tabelle aufbereitet:
Hier ist zu erkennen, dass vor allem der Wissensaustausch über Software befördert werden soll. Oftmals machen Firmen dafür den Code einzelner Projekte unternehmensweit verfügbar, sodass er zum einen in anderen, späteren Projekten weiter genutzt werden kann und zum anderen auch Nicht-Projektmitglieder Fehler beheben können. Ein anderer Nutzen der Quelloffenheit im Unternehmen ist die Entwicklung von querschnittlichen Anwendungen oder solchen, die von mehreren Domänen und Abteilungen genutzt werden.
Diese Ansätze lassen sich allerdings nur begrenzt auf die Realitäten des Global Software Engineering übertragen. Die „Corporate Open Source“-Initiativen beziehen sich auf einzelne Unternehmen, die interne Probleme lösen wollen, indem der Quellcode „öffentlich“, also zugänglich gemacht wird. Beim Global Software Engineering sind üblicherweise zwei verschiedene juristische Einheiten beteiligt, die in einem konkreten Entwicklungsprojekt miteinander arbeiten und ohnehin gemeinsam Zugriff auf den Quellcode haben.
Fazit
Im Ergebnis lässt sich sagen, dass FLOSS beziehungsweise „Corporate Open Source“und Global Software Engineering nicht viel voneinander lernen können. Auf den ersten Blick sind Techniken und Arbeitsweisen ähnlich, aber auch schon an die unterschiedlichen Bedürfnisse angeglichen. Die Verwendung von Wikis oder Code Repositories ist Alltag in beiden Welten. In allen anderen Belangen ist die Zielsetzung, sind die Randbedingungen zu verschieden, um erwarten zu können, dass sich Konzepte übertragen lassen. Die Ansätze des Corporate Open Source mögen interessant für die interne Entwicklung sein, sind aber nicht ohne Weiteres für das GSE nutzbar zu machen. Für den IT-Entscheider, der sich mit GSE auseinandersetzt, ist es daher aus unserer Sicht nicht zwingend notwendig, sich mit den Entwicklungen in FLOSS und Corporate Open Source zu befassen.
Ihr LPZ IT-Radar-Team
References
[1] James D. Herbsleb: Global Software Engineering: The Future of Socio-technical Coordination. FOSE '07: 2007 Future of Software Engineering, International Conference on Software Engineering, 2007, pp. 188-198. http://portal.acm.org/citation.cfm?id=1254718
[2] Cristof Ebert et al.: Managing Risks in Global Software Engineering: Principles and Practices. IEEE International Conference on Global Software Engineering, 2008, pp. 131-140. http://www2.computer.org/portal/web/csdl/doi/10.1109/ICGSE.2008.12
