Suche
Aufzucht und Pflege eines Eclipse-Projekts

The Making of an Eclipse Project

Achim Lörke

Haben Sie sich schon einmal gefragt, was eigentlich hinter den Kulissen eines Eclipse-Projekts passiert? Welche Entscheidungen sind zu treffen, welche Bedingungen zu erfüllen, wie läuft das alles? Das Eclipse-Jubula-Team berichtet in der neuen Eclipse-Magazin-Kolumne „The Making of an Eclipse Project“ über seine Erfahrung beim Open-Sourcing von Jubula [1]. Dabei geht es nicht nur um Technik, sondern auch um Strategien, Abläufe und schwierige Entscheidungen.

Was hat uns dazu gebracht, ein Open-Source-Projekt zu beginnen? Nun, es war nicht die Aussicht auf das nette Gefühl, mehrere 100.000 Euro pro Jahr der Allgemeinheit zu vermachen. Wie bei der Mehrheit der Eclipse-Projekte standen hinter der Entscheidung durchaus kommerzielle Interessen.

Bei der Vermarktung eines kommerziellen Produkts entstehen viele Zwänge, die mit dem Produkt und seiner Weiterentwicklung eigentlich nichts zu tun haben. Kunden machen sich Sorgen über langfristige Wartung, Verkäufe brauchen eine lange Zeit bis zum Abschluss und Etliches mehr. Schließlich stellt man fest, dass ein Werkzeug allein die Probleme des Kunden nicht unbedingt löst. Beratung und direkte Unterstützung bei Einführung und Weiterführung von Testprozessen sind viel wichtiger.

Es war deshalb nur natürlich, dass wir, d. h. die BREDEX GmbH, zunehmend im Beratungsgeschäft für Testautomatisierung unterwegs waren. Um die Basis dafür zu verbreitern, reifte in uns die Entscheidung, den Löwenanteil unseres Eclipse-basiertenTestwerkzeugs GUIdancer kostenlos zur Verfügung zu stellen und unsere Brötchen im Umfeld von Beratung, Erweitung, Wartung und Schulung zu verdienen. Durch unsere Mitgliedschaft in der Eclipse Foundation war dann klar, dass dieses Open-Source-Projekt unter dem Namen „Jubula“ als Eclipse-Projekt starten sollte.

Die Eclipse Foundation hat eine schöne Grafik veröffentlicht, die gut auf den Werdegang der BREDEX GmbH angewendet werden kann:

Open-Source-Entwicklungsschritte
Wir benutzen Eclipse seit vielen Jahren, haben über die Zeit etliche Contributions beigesteuert und unser kommerzielles Testwerkzeug GUIdancer [2] auf Basis von Eclipse RCP umgesetzt. Wir wurden 2007 Eclipse Solution Member, haben Stammtische und Demo-Camps organisiert und waren auf einschlägigen Konferenzen mit Vorträgen [3] vertreten. Damit haben wir uns wohl immer mehr der Stufe des „Champions“ angenähert.

Da wir von Anfang an vorhatten, mit dem GUIdancer-Team die Jubula-Entwicklung weiter zu betreiben, war auch der letzte Schritt für uns klar: Um unser Engagement zu dokumentieren, haben wir unseren Mitgliederstatus bei der Eclipse Foundation auf Strategic Developer Member [6] erhöht. Wir wollten damit klarstellen, dass wir in Zukunft den Bereich Testautomatisierung und Requirements Management im Eclipse-Ökosystem aktiv voranbringen wollen.

Auch Open Source leistet sich Bürokratie

Die Eclipse Foundation verfügt über klare Richtlinien für ihre Projekte. Werfen wir einen Blick auf die Anforderungen, die an ein neues Eclipse-Projekt gestellt werden. Als Erstes muss ein Proposal eingereicht werden, in dem die Projektziele beschrieben werden. In dem Proposal soll knapp und klar dargestellt werden, um was es sich im vorgeschlagenen Projekt handelt (Background). Die Faustregel dazu lautet, dass fünf beliebig herausgesuchte Eclipse-Committer verstehen können müssen, worum es geht. Zusätzlich muss der Umfang (Scope) des Projekts definiert werden: Was gehört dazu, was bleibt außerhalb und wo gibt es eventuell Überschneidungen mit anderen Projekten?

Ein wesentlicher Punkt ist auch das Zusammenspiel mit anderen Projekten im Eclipse-Katalog. Wie passt das Projekt zum bestehenden Ökosystem? Ist eine Kollaboration mit anderen Eclipse-Projekten möglich und angestrebt? Welche Vorteile würde das Projekt dem Ökosystem bringen, welche den Vorschlagenden?

Da die Eclipse Foundation sich nicht als Halde für Open-Source-Projekte sieht, muss im Proposal auch schon erläutert werden, wie stark und in welcher Form sich die Vorschlagenden engagieren wollen. Dies beinhaltet natürlich im Wesentlichen die Angabe über die Anzahl der vorgesehenen Committer zum Projekt, aber auch Angaben zu Infrastruktur, Öffentlichkeitsarbeit sowie die Bereitschaft, im erweiterten Bereich des Projekts Mitarbeit zu leisten und/oder Leitungsfunktionen zu übernehmen.

Schlussendlich soll das Projekt herstellerneutral sein. Es sollte sich auch nicht auf spezielle Betriebssysteme beschränken. Da Proposals häufig von einem oder wenigen kommerziellen Anbietern erstellt werden, muss begründet werden, warum das Projekt trotzdem herstellerneutral entwickelt werden kann.

Zur Unterstützung des Projekts werden mindestens zwei Mentoren benötigt. Dies sind Mitglieder des Eclipse Architecture Council und sollen dafür sorgen, dass neue Projekte sich gut in das doch sehr komplexe System der Eclipse-Projekte einfügen. Rein formal braucht man die Mentoren erst nach der Project Creation, es ist aber doch hilfreich, sich schon vorher mit erfahrenen Leuten zu beraten.

Eine Hilfestellung sind Proposals bestehender Projekte, die zeigen, wie man es richtig macht (oder machen kann) [8]. Und natürlich helfen auch die Mitglieder der Eclipse Management Organisation (EMO), allen voran Wayne Beaton.

Ein Proposal muss mindestens zwei Wochen öffentlich auf der Eclipse-Website „ausgehängt“ werden [4]. Dazu muss man nur das als HTML-Dokument vorliegende Proposal an die EMO schicken.

Parallel dazu sollte die Werbetrommel gerührt werden, um Interessenten und Mitstreiter zu gewinnen. Dies ist besonders dann relevant, wenn ein Projekt völlig neu beginnt. Sollte es sich nämlich zeigen, dass kein großes Interesse an dem Projekt besteht, kann ein Proposal auch formlos zurückgezogen werden – was auch schon häufiger passiert ist. Projekte mit einer existierenden Code- und Nutzerbasis haben es hier natürlich leichter.

Mittel zum Zweck sind Veröffentlichungen in Blogs, Zeitschriften, Konferenzen usw. Die Eclipse Foundation unterhält eigene Foren [9], eines davon (General/Proposals) ist speziell für die Diskussion von Proposals vorgesehen.

Ist man dann der Meinung, alles Notwendige getan zu haben, kann ein Creation Review [5] beantragt werden, der zurzeit formlos abläuft und normalerweise in einer Zustimmung endet. Auf die früher notwendige Dokumentation für den Review wird verzichtet und ein wirklicher Termin mit Diskussion findet nur auf Wunsch statt. Dies ist die Folge des geringen Interesses der Community an Creation Reviews.

Nach der Zustimmung zum Projekt fangen die ersten entwicklungsrelevanten Abläufe an. Committer müssen benannt und für alle Committer muss bestätigt werden, dass sie ihre Arbeit unter der Eclipse Public License (EPL) veröffentlichen dürfen. Die ersten Committer werden formlos aus dem Proposal übernommen. Hierzu hat der Project Lead die Möglichkeit, über eine Webseite Basisinformationen einzugeben. Die Committer müssen dann das „Paper Work“ [10] einreichen. Der wesentliche Punkt hierbei ist die Verpflichtung, sämtlichen Code und alle weiteren Dokumente unter der Eclipse Public License (EPL) beizusteuern. Für angestellte Committer muss außerdem der Arbeitgeber der Verpflichtung zustimmen.

Mailing-Listen, Foren, Webseiten und Projektdaten werden durch die EMO (Eclipse Management Organisation), hier speziell durch den Webmaster, eingerichtet. Die Mailing-Listen dienen im Wesentlichen der Kommunikation zwischen den Entwicklern. Jedes Projekt erhält auch mindestens ein Forum zur Kommunikation mit den Anwendern. Die Webseiten www.eclipse.org/&#60project&#62 dienen als schnelle Übersichten zu den Projekten (siehe [1]) und enthalten Links auf Mailing-Listen, Foren, Downloads, Dokumentation und alle anderen (mehr oder minder) interessanten Informationen.

Damit ist dann das Gerüst für alle weiteren Arbeiten erstellt.

Geschrieben von
Achim Lörke
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.