Einsatz von Open Source Software zur Entwicklung kommerzieller Produkte Open Source in Großkonzernen Management Conference 2003
Einsatz von Open Source bei der Entwicklung von Individualsoftware In der Mehrzahl aller Projekte insbesondere im Java-Umfeld kommen Open Source-Bibliotheken und Infrastrukturkomponenten zum Einsatz Beispiele: Jakarta-Struts, JBoss, Apache HTTPD,... Die Entscheidung erfolgt in der Regel mehr der weniger bewusst für oder gegen den Einsatz von Open Source In der Regel erfolgt sie pro Lizenzbedingungen spielen eine untergeordnete Rolle Wo kein Kläger, da kein Richter große Anzahl von Lizenzen, die sich teilweise nur marginal unterscheiden 2
Kommerzielle Produkte und Open Source Auch bei der Entwicklung von Standard-Software spricht vieles für den Einsatz von Open Source-Software Wiederverwendung bereits verfügbarer Lösungen Pflege durch die Community Konzentration auf die Kernaufgaben Bei der Entwicklung von Standard-Produkten ergeben sich auch rechtliche Konsequenzen: Das Unternehmen, das eine kommerzielle Software erwirbt, erhält Open Source-Software quasi durch die Hintertür Für Software-Hersteller bekommen Lizenzbedingungen entscheidende Bedeutung Der Software-Hersteller haftet gegenüber dem Anwender auch für evtl. Mängel in den Open Source-Komponenten 3
Beispiel: Systinet WASP Systinet ist ein Anbieter von Infrastruktur-Software für Web Services auf Basis von XML, SOAP, WSDL, UDDI Das Produkt WASP benötigt als Ablaufumgebung eine HTTP- Engine oder einen Servlet Container bzw. Application Server Der Anwender kann einen beliebigen J2EE-Server einsetzen WASP Server beinhaltet allerdings einen eingebetteten Jetty- Container, um auch Stand-Alone ablaufen zu können WASP UDDI beinhaltet eine Hypersonic SQL-Datenbank als Stand-Alone-Alternative zu Oracle, DB2, SQL Server & Co. Das Produkt ist sehr erfolgreich, die Akzeptanz auch der eingebetteten Open Source-Lösungen ist groß 4
Beispiel: Systinet WASP (2) Beurteilung Es besteht eine geringe Abhängigkeit von den eingebetteten Open Source-Lösungen aufgrund der Standard-Konformität sie können jederzeit durch (reichlich verfügbare) Alternativen abgelöst werden Die Jetty-Community ist sehr aktiv, das Produkt hat eine hohe Qualität Für Systinet hatte die Entscheidung, an dieser Stelle auf Open Source zu setzen, ausschließlich positive Konsequenzen 5
Beispiel: innoq iqgen iqgen ist ein Code-Generator nach dem Prinzip der Model Driven Architecture (MDA) iqgen liest UML-Modell im XMI-Format ein und generiert Software-Artefakte auf Basis von JSP-Templates Für den XMI-Import/ Metamodel wird die Open Source Novosoft UML Library (nsuml) eingesetzt Die JSP-Templates werden von der Open Source Servlet-Engine jo! verarbeitet Das Produkt wird erfolgreich in verschiedenen Projekten eingesetzt, der Einsatz der Open Source-Komponenten ist für Kunden i.d.r. irrelevant 6
Beispiel: innoq iqgen (2) Beurteilung jo! hat sich sehr gut bewährt und ist aufgrund der Standard- Konformität ggf. leicht zu ersetzen Die nsuml-community ist sehr klein und nicht sehr aktiv Die Bibliothek wurde von innoq umfangreich erweitert, angepasst und korrigiert Es gibt eine hochgradig inkompatible und schlecht dokumentierte Nachfolge-Version iqgen wird daher auf eine Eigenentwicklung umgestellt Dennoch ist die Entscheidung für beide Open Source-Produkte positiv zu bewerten in Bezug auf jo! uneingeschränkt, in Bezug auf nsuml eingeschränkt 7
Weitere Beispiele... IBM WSAD basiert auf Eclipse IBM WebSphere enthält den Apache HTTP Server und Apache Axis als Web Services-Lösung Apple Mac OS X setzt auf dem Betriebssystem Darwin auf MID Innovator verwendet die Skript-Sprache TCL zur Automatisierung Zahlreiche Java-basierte Software-Produkte verwenden XML- Bibliotheken wie Xerces und Xalan Die meisten HTML-Editoren verwenden HTML Tidy 8
Fazit Selbst bei einer grundsätzlichen Entscheidung gegen Open Source führt für Anwender kaum ein Weg daran vorbei, sie zumindest indirekt einzusetzen Für Anbieter kommerzieller Software sind verschiedene Faktoren bei der Entscheidung für oder gegen OSS relevant: Lizenzbedingungen (GPL vs. LGPL, ASD, BSD...) Standardkonformität und Austauschbarkeit Stärke der Community Akzeptanz durch den Kunden Empfehlung: Anwender sollten OSS akzeptieren, aber den durch den kommerziellen Anbieter geschaffenen Mehrwert kritisch hinterfragen 9