Entwicklung

Vor einem guten Jahr habe ich Ihnen mit Jitterbit eine Open-Source-Lösung für die Integration von (Open-Source-)Applikationen vorgestellt. Während Jitterbit eine US-Entwicklung ist, existiert mit Talend Open Studio eine Open-Source-Alternative zu Jitterbit, die ihren Ursprung in Frankreich hat. Und spätestens mit der Version 3.0, die vor einigen Tagen vorgestellt wurde, hat Talend Open Studio Jitterbit hinsichtlich der Funktionalität überholt. Daher und dank reichlich Venture Capital für allerhand Marketing-Aktivitäten gewinnt Talend Open Studio in Europa derzeit rasant an Verbreitung.

Talend Open Studio ist ein leistungsfähiges ETL-Tool (Extract, Transfer, Load), wird in Java entwickelt und setzt auf Eclipse auf, so dass die prinzipielle Bedienung vielen Entwicklern bereits bekannt sein dürfte. Standardmäßig erzeugt Talend Open Studio im Backend Java-Code, optional ist aber auch Perl möglich.

Talend Open Studio bietet zahlreiche Features wie Iteratoren, Lookups/Joins, Filter, Trigger, String-Manipulationen sowie reguläre Ausdrücke und verarbeitet eine Vielzahl von Formaten - darunter nicht nur Standardformate wie CSV oder XML, sondern auch Applikations-spezifische Formate wie Excel, SugarCRM, SAP und diverse Datenbankformate. All diese Formate werden über modulare Connectoren gelesen und geschrieben. Die Dokumentation zur Software ist umfangreich, professionell gestaltet und aktuell - was man bei Open-Source-Software nicht unbedingt erwarten kann.

Die Installation erfolgt Eclipse-typisch durch Entpacken der Download-Datei in das gewünschte Verzeichnis. Anschließend empfiehlt es sich noch, ein Desktop-Symbol für die Startdatei des Open Studio anzulegen (die richtige Datei für Ihr Betriebssystem erschließt sich aus den Dateinamen). Beim ersten Start muss nur noch ein Repository definiert und ein neues Projekt erzeugt werden - fertig!

Talend Open Studio bietet gegenüber der Entwicklung von individuellen Skripten folgende Vorteile:

• Die Erstellung und Darstellung der ETL-Prozesse erfolgt per grafischer Benutzeroberfläche, was die Übersichtlichkeit erhöht und Fehler reduziert


• Der Talend-Codegenerator erzeugt nicht proprietären Programmcode, sondern Standard-Java-Code oder auch Perl-Code, der beliebig nachbearbeitet und verfeinert werden kann


• Es existieren bereits jede Menge vordefinierter Connectoren für Datenbanken wie Microsoft SQL Server, MySQL, Oracle DBMS, PostgreSQL und Sybase sowie für CRM-Systeme wie Salesforce, SugarCRM, vTiger und Centric


• Während damit für viele populäre Datenbanken und Applikationen bereits Connectoren vorhanden sind, kann man natürlich auch weitere selbst entwickeln (und ggf. der Open-Source-Community zur Verfügung stellen)

Abschließend jedoch auch noch etwas Kritik: Nervig ist, dass die Talend-Website bei jedem Download-Besuch ohne jegliche Begründung nach persönlichen Daten wie Name, E-Mail-Adresse und Telefonnummer fragt und auch darauf besteht, dass alle Felder ausgefüllt werden. Natürlich kann man hier Nonsens-Angaben machen, aber meiner Meinung widerspricht solch eine Zwangsregistrierung dem Open-Source-Gedanken von der Freiheit der Software-Nutzung.

Ebenfalls etwas störend ist die Größe der Software, die auch auf die Nutzung von Eclipse als Plattform zurückzuführen ist. So hat der Download des Prorammcodes einen Umfang von etwa 300 MByte! Als Folge aus der Mächtigkeit des Codes ist auch die Performance manchmal etwas schleppend. Der Client, auf dem mit Open Studio Projekte bearbeitet werden, sollte daher mit reichlich Arbeitsspeicher und CPU-Power ausgestattet sein (mindestens 2 GByte RAM und 2 GHz Dual Core).

Jedes größere Open-Source-Projekt basiert auf Open Source Libraries und Frameworks. Und so, wie sich Betriebssysteme, Tools und Applikationen weiterentwickeln (müssen), ist dies auch bei den zugrundeliegenden Libraries und Frameworks der Fall. Doch kann es natürlich auch einmal passieren, dass die Weiterentwicklung einer bestimmten Bibliothek oder eines Framework eingestellt wird.

Dies ist zunächst kein Problem, wenn die aktuellste Version stabil ist und keine oder nur unwesentliche Bugs aufweist. Doch die technische Entwicklung bleibt nicht stehen und eine Software-Komponente, die nicht weiter entwickelt wird, veraltet mit der Zeit. Und während sich dieser Umstand bei Closed-Source-Software elegant im nicht zugänglichen Quellcode verstecken lässt, tritt er bei Open-Source-Software für jedermann offen zutage!

Daher muss das Entwicklerteam irgendwann in den sauren Apfel beißen und das sterbende Framework durch ein lebendes, modernes Produkt ersetzen. Im Idealfall wirkt sich solch ein Wechsel nicht nur positiv auf die Architektur der Software aus, sondern macht mittelfristig die Weiterentwicklung der Software sogar einfacher und schneller.

Für Zeitpunkt und Art des Umstiegs gibt es jedoch kein Patentrezept. Stattdessen im folgenden ein Beispiel aus der Praxis:

Für unser Open-Source-Projekt OpenEMM nutzen wir unter anderem das Struts-Framework für die Umsetzung des MVC-Entwurfsmusters im Rahmen einer Web-Applikation. Das Struts-Framework war im Jahr 2000 das erste Open-Source-MVC-Framework, wird jedoch seit zwei Jahren nicht mehr nennenswert weiterentwickelt (die letzte 1.3.9-Beta ist deutlich über ein Jahr alt).

Der Struts-Gründer Craig McClanahan (derzeit bei SUN beschäftigt) hat 2004 mit JavaServer Faces (JSF) ein neues Framework gestartet, das mittlerweile als echter Java-Standard sogar im Wettbewerb zu Struts steht. Darüber hinaus sind im Laufe der Jahre mit Spring MVC, Tapestry und WebWork weitere MVC-Frameworks für Web-Applikationen entstanden, die Struts Konkurrenz machen, und teilweise moderner sind.

Und dann gibt es da natürlich noch die - eigentlich naheliegende - Alternative Struts2. Kurioserweise baut Struts2 allerdings nicht auf Struts(1) auf, sondern auf WebWork2, so dass Struts2 nicht abwärtskompatibel zu Struts ist. Damit erfordert der Wechsel von Struts auf Struts2 genauso ein Refactoring des vorhandenen Quellcodes, wie der Wechsel zu jedem anderen Web-MVC-Framework.

In unserem Fall war nach reiflicher Überlegung trotzdem Struts2 die beste Wahl als Nachfolger für Struts, denn Struts2 bietet gegenüber Struts eine ganze Reihe von Vorteilen:

1. Es ist viel weniger Infrastruktur-Code erforderlich, weil
   
   
   
   1. die Devise "Convention over Configuration" gilt
   
   
   2. keine FormBeans-Klassen erforderlich sind (die Setter und Getter sind direkt in den Actions und selbst das lässt sich vermeiden)
   
   
   3. zahlreiche vordefinierte und -implementierte Interceptors (für Exception, I18n, Logging, etc.) und Validatoren vorhanden sind
   
   
   4. die Struts2-Tags HTML-Code mit generieren können (der sich über Themes der Tag-Templates beeinflussen lässt)
   
   
2. Das Struts2-Framework kümmert sich automatisch um den Datentransfer (inkl. Typ-Konvertierung) zwischen Model und View


3. Struts2 lässt sich über existierende Plugins für Struts, Spring, Tiles, etc. konfigurationsfrei erweitern


4. Struts2 (*.action) lässt sich parallel zu Struts (*.do) einsetzen und erlaubt damit die Migration Schritt für Schritt


5. Die AJAX-Integration ist/wird durch AJAX-Plugins mit Tag-Extensions und AJAX-Templates verbessert

Andererseits sind diese Vorteile für uns nicht so spektakulär, dass sie den Zusatzaufwand für einen sofortigen Umstieg rechtfertigen. Außerdem sind die Struts2-Vorteile - wie bei jedem neuen Framework - nur nutzbar, wenn man sich im Vorfeld intensiv mit dessen Architektur und Funktionsumfang auseinandersetzt, um die neuen Features auch tatsächlich nutzen zu können.

Daher haben wir beschlossen, die Migration von Struts auf Struts2 ganz in Ruhe anzugehen, indem wir jeweils die Teilbereiche, die ohnehin grundlegend überarbeitet werden müssen, im Rahmen des Refactoring auf Struts2 migrieren. Das "alte" Struts ist zwar inzwischen zu einer Sackgasse geworden, aber es handelt sich dabei um ein solides und äußerst stabiles Framework, das bei uns zuverlässig seinen Dienst verrichtet ohne unangenehm aufzufallen. Daher besteht beim Umstieg überhaupt kein Grund zur Eile.

Nichts ist für einen Entwickler unangenehmer, als mit großem Tamtam eine neue Software-Version zu veröffentlichen, die noch einen dicken Bug enthält. Eine sehr beliebte Möglichkeit der Software-Branche, diese Peinlichkeit zu umgehen, ist die Veröffentlichung von Release Candidates (RC). Allerdings haben erfahrungsgemäß die meisten Nutzer kein Interesse daran, eine potenziell fehlerhafte Software zu installieren, zu konfigurieren und zu testen.

Anbieter von kommerzieller Software haben wenigstens die Möglichkeit, ihre Kundschaft zum Testen zu motivieren, indem sie die RC-Versionen kostenlos zur Verfügung stellen. Bei Open-Source-Software kann dies jedoch naturgemäß nicht funktionieren. Entsprechend gering ist oft die Zahl der Nutzer, die sich zum Testen einer RC-Version von Open-Source-Software entscheidet und entsprechend spärlich die Anzahl der Rückmeldungen.

Eine aus meiner Sicht akzeptable Alternative zur Veröffentlichung von Release Candidates ist eine Variante, die ich als Staged Release bezeichne. Staged ("abgestuft") bedeutet, dass die neue Version nicht sofort der ganzen Welt verkündet und zugänglich gemacht wird, sondern dass man versucht, das neue Release Schritt für Schritt einzuführen.

Bei der Version 5.5.0 unseres OpenEMM, die wir derzeit in einem Staged-Release-Prozess veröffentlichen, sehen die Schritte wie folgt aus (wobei die Schritte jeweils im Abstand von zwei bis drei Tagen erfolgen):

Der erste Schritt besteht darin, die neue Version heimlich, still und leise auf SourceForge einzustellen. Wenn Sie den Kreis der ersten Nutzer noch stärker reglementieren möchten, können Sie die Software alternativ nur ausgewählten Kunden und Interessenten über einen eigenen Download-Server anbieten. In beiden Fällen können Sie, wenn die Early Adaptors Probleme feststellen, das Release kurzfristig für den Download sperren, verbessern und ersetzen.

Im zweiten Schritt wird die neue Version für das Online-Update freigeschaltet (sofern Ihre Software über solch eine Funktionalität verfügt), damit ein bestehender Nutzer, der das neue Release auf SourceForge entdeckt, bequem per Online-Update upgraden kann.

Als nächsten Schritt kommunizieren Sie die Verfügbarkeit der neuen Version an die Nutzer Ihrer Software, und zwar (sofern technisch möglich) zuerst an Nutzer einer Uralt-Version, dann an die Nutzer von älteren Versionen und am Schluss an die Nutzer von neueren Versionen. Bei unserem OpenEMM ist das einfach möglich, weil bei jedem Aufruf der Software ein Online-Update-Check durchgeführt wird und sich die Update-Meldung abhängig von der Version der abfragenden Software variieren lässt.

Sind Ihre Kunden informiert, können Sie im anschließenden Schritt die Verfügbarkeit der neuen Version per Newsletter an Ihre Community kommunizieren. Um den Kreis noch mehr zu erweitern, folgt im vorletzten Schritt die Ankündigung der neuen Version auf Ihrer Projekt-Website sowie als Projekt-News auf SourceForge und abschließend im letzten Schritt via freshmeat.net, Xing und ggf. per Pressemeldung an den Rest der Welt.

Sollten Sie im Rahmen des Staged Release tatsächlich eine Bugfix-Version veröffentlichen müssen, so machen Sie bitte kein Silent Update, das die Nutzer verwirrt (weil es unterschiedliche Versionen mit gleicher Bezeichnung gibt), sondern hängen Sie zumindest einen Buchstaben an die verbesserte Version an, z.B. 5.5.0a.

Eine grundsätzliche Frage, die sich den Entwicklern einer Open-Source-Software immer wieder stellt, ist: Wie oft sollen wir die Software in einer neuen Version veröffentlichen und auf welche Weise diese Aktualisierungen planen?

Das Open-Source-Mantra in diesem Zusammenhang lautet "release early, and release often". Das bedeutet, dass Releases häufig, d.h. mit kleineren Versionssprüngen in einem frühen (Beta-)Stadium veröffentlicht werden sollen, statt die Nutzer lange Zeit auf den großen Wurf warten zu lassen. Denn bei den "großen" Versionen kann die Wartezeit zwischen zwei Releases - wie leidgeprüfte Debian-Nutzer aus eigener Erfahrung wissen - statt Monaten durchaus auch einmal Jahre betragen!

In meinem Beitrag Release-Management für Open-Source-Software bin ich bereits kurz auf den feature-based- und den time-based-Ansatz bei der Planung der zu veröffentlichenden Software-Versionen eingegangen.

Wir haben bei AGNITAS Anfang dieses Jahres entschieden, für unser Open-Source-Projekt OpenEMM den Release-Plan nicht mehr nach Features sondern nach der Zeit auszurichten (also time based), wie es mittlerweile bei vielen Open-Source-Projekten üblich ist. Das bedeutet konkret, dass wir uns nicht länger einen Satz neuer Funktionen für die nächste Version überlegen und dann warten, bis dieser fertig entwickelt ist.

Stattdessen führen wir eine Roadmap mit einem "Vorrat" an funktionalen und nicht-funktionalen Verbesserungen für die nächsten 12 bis 18 Monate, der ständig aktualisiert wird. Die Punkte auf der Roadmap sind nach Priorität sortiert, lose einem geplanten Release zugeordnet (wie ein Wunschzettel) und werden nacheinander abgearbeitet. Der Zeitpunkt für ein Release wird unabhängig vom Status der Roadmap festgelegt. Zwei bis drei Wochen vor dem definierten Release-Termin erfolgt der Feature Freeze (Einfrieren des Funktionsumfangs) und ein bis zwei Wochen vor dem Release-Termin der GUI Freeze (Einfrieren der Oberflächengestaltung), damit noch genügend Zeit vorhanden ist, um neue Screenshots für die Dokumentation anzufertigen.

Nur die Funktionen, die bis zum Feature Freeze komplett fertiggestellt sind, kommen in das geplante Release, und die letzte Zeit bis zum Release-Termin wird für Betatests und Debugging genutzt. Kann eine Funktion innerhalb dieses Zeitraums nicht von allen Fehlern befreit werden, wird sie wieder aus dem Code entfernt und für das darauf folgende Release eingeplant.

Doch das Zeit-basierte Release-Management ist nicht nur für Open-Source-Software geeignet. Nachdem sich das Verfahren beim OpenEMM im letzten Dreiviertel-Jahr bestens bewährt hat (zugegeben: Hier stehen uns auch keine zahlende Kunden auf den Füßen, die bestimmte Feature fordern), sind wir im Sommer dazu übergegangen, auch für unsere kommerzielle Software EMM mit festen Release-Terminen zu arbeiten (allerdings ohne "release early"). Tatsächlich haben wir es diese Woche zum ersten Mal seit Jahren geschafft, dass eine Software exakt zum geplanten Zeitpunkt fertig geworden ist. Nur ein einziges Feature vom Wunschzettel fehlt, aber das wird dann eben mit der nächsten Version, die schon bald erscheinen wird ("release often"), nachgereicht.

Ein wichtiger Faktor für die Beurteilung, ob ein Open-Source-Projekt für den ernsthaften geschäftlichen Einsatz geeignet ist, ist die Qualität des Quellcodes. Die Quellcode-Qualität sagt meiner Meinung nach viel darüber aus, wie professionell ein Projekt betreut und geführt wird und damit auch, wie hoch die Wahrscheinlichkeit ist, dass es auch in Zukunft weiterentwickelt wird.

Doch nach welchen Kriterien lässt sich die Qualität von Quellcode beurteilen? Ein erstes starkes Kriterium, das sich darüber hinaus sehr einfach überprüfen lässt, ist die Dokumentation des Quellcodes und Kommentierung im Code. Das ist genau die Arbeit, die den Entwicklern oft lästig ist und daher gerne vernachlässigt wird. Doch wenn nur der jeweilige Entwickler selbst seinen Code versteht, ist das Projekt von genau diesem Entwickler und seiner Motivation abhängig. (Wobei die Praxis zeigt, dass schwache Programmierer eher wenig dokumentieren, weil sie wissen, dass ihre Konzepte unausgegoren und ihre Algorithmen umständlich oder zumindest unelegant formuliert sind.)

Untersuchen Sie daher den Quellcode des Projektes, für das Sie sich interessieren: Ist dokumentiert, für welche Aufgaben die verschiedenen Quellcode-Dateien zuständig sind? Sind Klassen, Interfaces und Methoden so weit kommentiert, dass deren Funktion klar ist? Existieren vernünftige Namenskonventionen für die Bezeichner im Quellcode? Ist der Code übersichtlich und einheitlich formatiert? Arbeitet das Projekt mit Coding Conventions, die öffentlich verfügbar sind? Erfahrungsgemäß signalisiert eine gute Dokumentation eine hohe Wahrscheinlichkeit, dass auch der Rest des Projektes in Ordnung ist.

Weitere Kriterien für die Qualität des Quellcodes - die allerdings deutlich mehr Recherche-Aufwand erfordern - sind:

• Programmiersprachen, Entwurfsmuster ("Design Pattern"), Frameworks und Bibliotheken, die verwendet werden


• Unterteilung in logische Architekturschichten für Presentation, Controller, Business Model, Data Access, etc. (horizontal)


• Kopplungsgrad der Schichten (je geringer die Kopplung, desto höher die Flexibilität; im Idealfall erfordern Code-Änderungen in einer Schicht keine Änderungen in den angrenzenden Schichten)


• ggf. fachliche vertikale Schnitte (z.B. für Kundenverwaltung, Content Management, Reporting, etc.)


• Zyklenfreiheit der Schichten und Schnitte (d.h. keine ringförmigen Abhängigkeiten über mehrere Subsysteme hinweg, die die Komplexität erhöhen und das isolierte Testen der Module verhindern würden)


• Anzahl der Anweisungen pro Klasse, Methode oder Funktion (der Klassiker unter den Code-Metriken)

Natürlich gibt es zur Beurteilung der Quellcode-Qualität noch viele weitere Metriken wie z.B. zyklomatische Komplexität, relationale Kohäsion, Grad der Abstraktheit oder Vererbungstiefe, doch die oben aufgelisteten Kriterien dürften in der Regel für die vernünftige Beurteilung eines Open-Source-Projektes ausreichen.

Ein ausgezeichnetes Architektur-Tool, das Ihnen dabei helfen kann, die Einhaltung diverser Code-Kriterien und -Metriken zu prüfen und laufend zu überwachen, ist SonarJ. Auf der Website des SonarJ-Entwicklers hello2morrow finden Sie auch einen ausführlichen Artikel, der das Thema Code-Architektur und -Metriken vertieft.

SonarJ wird beispielsweise von den Entwicklern des für Java-Applikationen überaus populären Spring Framework genutzt. Übrigens: Entwickler von Open-Source-Software dürfen SonarJ laut hello2morrow für ihr Projekt sogar kostenlos verwenden!

Letzte Woche hatte ich für ADAMATIS einen Termin bei einem größeren Telekommunikationsunternehmen, das bereits einige E-Selfservice-Angebote betreibt, u.a. mit Hilfe einer proprietären Software-Suite. Zu meiner Überraschung bestand die prinzipielle Bereitschaft, diese Software durch Open-Source-Software zu ergänzen oder sogar komplett abzulösen. Doch genau hier liegt das Problem mit Open Source: Es gibt zwar mittlerweile für fast alle Teilaspekte von E-Selfservice gute bis sehr gute Open-Source-Applikationen. Was bislang jedoch fehlte, ist eine flexible Integrationsschicht, die die Kommunikation dieser Komponenten untereinander koordiniert und zu einer Best-of-Breed-Plattform zusammenfasst.

Zwar lassen sich fast alle Open-Source-Projekte, die ein DBMS erfordern, auf MySQL aufsetzen - das ist jedoch nur der kleinste gemeinsame Nenner. Die Kommunikation der verschiedenen MySQL-Datenbanken untereinander zur Synchronisation, zum Datenaustausch oder für Transformationen musste bislang für jeden Einzelfall mühsam neu programmiert werden. Es gab in der Open-Source-Welt für die Zusammenführung der Applikationen kein übergreifendes Integrations-Framework, keine einheitliche Webservices-Schnittstelle oder ähnliches - und eine ausgewachsene ESB-Lösung (Enterprise Service Bus) wie Mule oder Open ESB ist für die meisten Anwendungsfälle wiederum eine Nummer zu groß.

Doch seit kurzem gibt es mit der - bislang noch relativ unbekannten - Open-Source-Software Jitterbit eine Lösung, die Entwickler und Integratoren um den größten Teil der manuellen Integrationsarbeit entlastet. Jitterbit besteht aus einem Integrations-Tool, das auf dem Server läuft, und einem Client mit grafischer Oberfläche, über den sich die Server-Komponente sehr benutzerfreundlich und flexibel konfigurieren lässt. Da die Client-GUI auf Java Swing basiert, ist sie Plattform-unabhängig und setzt lediglich das Vorhandensein des JRE ab Version 1.5 voraus.

Der Jitterbit-Client erlaubt für den Jitterbit-Server die Definition von Datenquellen und -zielen, von Zeitplänen für Synchronisationen und von Transformations-Regeln - letztere auch als Wrapper für den Aufruf von Webservices. Um noch mehr Flexibilität zu bieten, stellt Jitterbit mit der neuen Version 1.2 auch eine Plugin-Schnittstelle zur Verfügung, die es Nutzern erlaubt, die Software ohne Eingriffe in den bestehenden Quellcode um eigene Funktionalitäten zu erweitern. Außerdem hat Jitterbit mit dem 1.2-Versionszweig mittlerweile einen Grad der Fehlerfreiheit erreicht, der den Einsatz für kommerzielle Projekte zulässt.

Einen ausführlichen Screencast, der demonstriert, wie sich mit Jitterbit Daten aus der Oracle-Datenbank eines ERP-Systems extrahieren lassen, in ein gewünschtes Textformat konvertiert werden und das Ergebnis als Datei auf einem FTP-Server abgelegt wird, finden Sie hier. (Übrigens: Mit Jitterbit lassen sich natürlich auch Closed-Source-Applikationen integrieren, sofern die erforderlichen Schnittstellen vorhanden und angemessen kommentiert sind bzw. zumindest das Datenbank-Schema ausreichend dokumentiert ist.)

Ein kleiner Wermutstropfen beim praktischen Einsatz von Jitterbit ist, dass es nicht mit MySQL arbeitet, sondern eine PostgreSQL-Installation (derzeit 7.4.11 bis 8.0.x) voraussetzt, was die Installation etwas aufwändiger gestalten kann. Ein Apache Webserver, über den der Jitterbit-Server per SSL-gesicherte Webservices mit seinem Client kommuniziert, wird von Jitterbit automatisch lokal mitinstalliert und benutzt einen speziellen Port, um einem eventuell bereits vorhandenen Webserver für Port 80 nicht in die Quere zu kommen. Lassen Sie sich diesbezüglich von den dürftigen Installationsinformationen auf der Jitterbit-Website nicht abschrecken. Wenn Sie den Tarball für die Server-Komponente erst einmal geladen und entpackt haben, finden Sie in der Datei Install.html eine sehr ausführliche Anleitung und auch das interaktive Installationsskript install.sh ist recht auskunftsfreudig.

Ich bin aufgrund meiner Erfahrungen als Anbieter und Nutzer von Open-Source-Software mittlerweile der festen Überzeugung, dass Open-Source-Code in der Regel besser ist als Closed-Source-Code. Warum? Weil sich bei Open-Source-Software jedermann den Quellcode selbst ansehen und ihn analysieren kann. Das ist so, als ob Sie bei einem neuen Restaurant erst in die Küche gehen und in jeden Topf und jeden Kühlschrank schauen können, bevor Sie sich entscheiden, ob Sie etwas bestellen.

Welche Auswirkungen der Schritt von Closed Source zu Open Source hat, kann ich Ihnen an einem eigenen Beispiel beschreiben: So haben wir bei AGNITAS fast ein halbes Jahr mit Refactoring verbracht, um den in sechs langen Jahren organisch gewachsenen Quellcode unseres kommerziellen Produktes "E-Marketing Manager" für die Open-Source-Version so zu gestalten, dass er vorzeigbar ist: Potenzielle Sicherheitslücken (z.B. schwache Verschlüsslungen und Möglichkeiten für SQL-Injections) wurden beseitigt, die logischen Schichten der Architektur sauberer voneinander getrennt, neue Frameworks integriert, um den Kopplungsgrad der Architekturschichten zu reduzieren, bestehende Bibliotheken aktualisiert, Coding Conventions strikter eingehalten und eine (zumindest minimale) Dokumentation vorgenommen. (Von all diesen Maßnahmen hat natürlich auch unser kommerzielles Produkt profitiert.)

Obwohl der Nutzer der Software all diese Änderungen nicht sehen kann, sondern allenfalls indirekt in Form von höherer Stabilität, größerer Flexibilität und schnellerer Erweiterbarkeit erfährt, ist die Motivation für diesen Aufwand klar: Ein Entwickler der Open-Source-Code schreibt, weiß, dass andere Entwickler sich diesen Code anschauen und ihn (mit "ihn" ist sowohl der Code als auch der Entwickler gemeint) beurteilen werden. Ist der Code klar strukturiert, sind die Algorithmen elegant formuliert und ist das ganze Projekt auf dem aktuellen Stand der Technik?

Ergänzend dazu haben wir bei ADAMATIS, wo wir viele verschiedene Open-Source-Projekte für den praktischen Einsatz getestet und bewertet haben, gelernt, dass eine starke Korrelation zwischen der Qualität des Quellcodes und der Qualität des Endproduktes bezüglich Stabilität, Sicherheit und Performance besteht. D.h. ein Quellcode, der einen guten Eindruck macht, generiert in der Regel auch ein qualitativ hochwertiges Programm. Einzige Ausnahme scheint die Usability, d.h. die Gebrauchstauglichkeit der Software, zu sein. Hier hapert es oft an einem einfachen Installationsprozess, einer bedienungsfreundlichen Benutzeroberfläche und einer verständlichen Anwendungsdokumentation. (Warum das so ist, werde ich in einem späteren Beitrag untersuchen.)

Das Linux Magazin enthält in seiner aktuellen Ausgabe 8/07 auf Seite 94 und 95 einen sehr interessanten Artikel mit dem Titel "Diktat des Kalenders". In dem Artikel berichtet das Linux Magazin über die Dissertation "Quality Improvement in Volunteer Software Projects" von Martin Michlmayr, der Projektleiter bei Debian war.

Während die (feature based) Release-Politik von Debian bekanntermaßen "Debian, veröffentlicht, wenn die Zeit gekommen ist" lautet, kommt Martin Michlmayr in seiner Doktorarbeit laut Linux Magazin zu dem Ergebnis, dass "im Jahr 2007 diese flapsige Bemerkung kein guter Wahlspruch mehr für qualitätsbewuste Softwareprojekte ist".

Begründet wird dies damit, dass zum einen das Debian-Motto immer wieder zu Verzögerungen bei einer geplanten Veröffentlichung geführt hat, was für Entwickler und Anwender gleichermaßen frustrierend war. Zum anderen bricht aufgrund der zeitlich großen Abstände zwischen zwei Releases bei einem plötzlichen Einfrieren des Funktionsumfangs (Feature Freeze) für das nächste Release Panik unter den Entwicklern aus. Jeder möchte noch schnell seine Features einbringen (damit er/sie nicht auf die nächste Version warten muss). Dies führt wiederum zu Code, der in aller Eile geschrieben wird und entsprechend fehlerbehaftet ist. Und die Bugs im Code führen wiederum zu Verzögerungen beim Release.

Martin Michlmayr empfiehlt daher time based Releases, d.h. die Releases werden veröffentlicht, wenn ein festgelegter Zeitpunkt - und nicht ein bestimmter Funktionsumfang - erreicht ist.

In einem späteren Beitrag werde ich berichten, was wir bei AGNITAS durch unsere Open-Source-Software OpenEMM über Release-Management gelernt und welche Konsequenzen wir daraus - auch für unser kommerzielles Produkt - gezogen haben.