Noch Fragen?

Neues Projekthandbuch: Wie startet man ein Eclipse-Projekt?

Michael Thomas

© Shutterstock.com/chuangz

Wayne Beaton, Director of Open Source Projects bei der Eclipse Foundation, hat die letzten Monate mit einer kompletten Überarbeitung der Dokumentation für Projekte und Committer verbracht. Der nun vorgestellte erste Entwurf, so Beaton, kommt der inhaltlichen Vollständigkeit bereits sehr nahe. Wir stellen einige Auszüge des Regelwerks vor.

Wie startet man ein quelloffenes Eclipse-Projekt? Welche Voraussetzungen müssen beachtet werden, welche Aufgaben und Pflichten haben die Committer zu erfüllen, was muss im Hinblick auf das geistige Eigentum beachtet werden, wie gestaltet sich der Release-Prozess? Wer Antworten auf diese und ähnliche Fragen sucht, hat nun die bislang vielleicht beste Gelegenheit, seinen Wissensdurst zu stillen: Wayne Beaton, Director of Open Source Projects bei der Eclipse Foundation, hat ein bereits seit längerem angedachtes Projekt verwirklicht und die Dokumentation für Projekte und Committer komplett überarbeitet.

Beispielhaft und in Auszügen werden im Folgenden zwei zentrale Abschnitte vorgestellt: „Overview/Principles“ und „Starting an Open Source Project at Eclipse“.

Prinzipien

Die vier wichtigsten Prinzipien des Eclipse-Entwicklungsprozesses, an denen sich jedes Projekt ausrichten muss, lauten Transparenz, Offenheit, Meritokratie und Anbieterneutralität. „Transparenz“ bedeutet, dass sämtliche das Projekt betreffenden Informationen, wozu auch Projektpläne und Pläne für neue Features, der Öffentlichkeit zugänglich gemacht werden müssen. „Offenheit“ geht demgegenüber in eine andere Richtung und besagt, dass die Mitarbeit an einem Projekt prinzipiell jedem offen steht; für alle Committer gelten dieselben Regeln, keiner kann ausgeschlossen werden. Ein weiterer wichtiger Punkt – und zugleich die letzte der drei „open source rules of engagement“ – ist die Verpflichtung zu einer meritokratischen Struktur, was in diesem Falle heißt: Je mehr ein Committer zum Projekt beiträgt, desto mehr Verantwortung kann er übernehmen, was auch die Führungsrollen einschließt. Die Leistung wird dabei von Gleichrangigen im Rahmen von öffentlich zugänglichen Foren bewertet. Neue Committer und Projektleiter werden dem Projekt per Wahl hinzugefügt.

In Anlehnung an die Verpflichtung zur Offenheit besagt die zur Anbieterneutralität schließlich, dass kein einzelner Anbieter ein Projekt dominieren darf. Anderseits darf, entsprechend dem Prinzip der Offenheit, kein Committer wegen seiner Anstellung bei einem bestimmten Unternehmen vom Projekt ausgeschlossen werden.

Ein quelloffenes Projekt ins Rollen bringen

Jedes quelloffene Eclipse-Projekt startet mit einem Proposal, das von der Community einem Review unterzogen wird. Nach Ende des Community Review-Phase folgt ein Creation Review und eine Zuteilung der Projektressourcen.

Für die Erstellung eines Proposal steht ein entsprechendes Web-Formular zur Verfügung. Alle Proposals werden im Draft– (also Entwurfs-)Modus erstellt und können nur vom ursprünglichen Autor sowie den benannten Projektleitern und Committern eingesehen werden. Nur die Projektleiter können Änderungen vornehmen.

Ein Proposal muss mindestens eine Beschreibung des Projekts, seine Tragweite, sowie eine Liste potentieller Projektteilnehmer aufweisen, bevor es von der Eclipse Management Organization (EMO) Community überprüft und in die Review-Phase überführt wird. Die EMO gibt den Beginn dieser Phase über diverse Online-Kanäle bekannt und öffnet einen Eintrag im Issue Tracker der Eclipse Foundation, um den Fortschritt des Proposals, das sich mindestens zwei Wochen in der Community Review-Phase befindet, zu verfolgen.

Die Eclipse Foundation hält die Schutzmarke für alle Eclipse-Projekte; da die Markenzuordnung ein recht langwieriger Prozess sein kann, muss diese bereits vor dem Start eines Projekts unternommen werden. Besteht bereits eine Marke, muss sie mittels Trademark Transfer Agreement übertragen werden. Einer der letzten Schritte der Proposal-Phase besteht in der Benennung zweier Mentoren aus den Reihen des Architecture Council. Diese verfügen in der Regel über umfassende Erfahrungen mit den Abläufen innerhalb der Eclipse Foundation und dem Eclipse-Entwicklungsprozesses. Die Mentoren begleiten das Projekt, bis es die Incubation-Phase verlässt.

Sind alle bislang genannten Schritte abgeschlossen, setzt das EMO ein Creation Review an. Diese laufen mindestens eine Woche, finden zweimal im Monat statt und können sich mit der Community Review-Phase überschneiden. Im Anschluss an das Creation Review startet das EMO den Provisioning-Prozess, in dessen Rahmen sich potentielle Committer für die Mitarbeit anmelden können. Nach Ende des Provisioning-Prozesses muss, bevor dem Projekt-Repository Code hinzugefügt werden kann, der offiziell erste Beitrag zum Projekt sowie eine Liste der Drittanbieter-Bibliotheken dem Intellectual Property(IP)-Team zum Review vorgelegt werden. Sobald das IP-Team grünes Licht gibt, können Meilensteine erstellt und ein erster Release vorbereitet werden. Bevor es zum ersten offiziellen Release kommen kann, muss das IP-Team den ersten Beitrag zum Projekt sowie die Drittanbieter-Bibliotheken absegnen.

Alle neuen Projekte starten in der Incubation-Phase. Diese sagt nichts über den Entwicklungsstand oder die Qualität eines Projekts, sondern vielmehr darüber aus, wie weit das Team die offenen und öffentlichen Prozesse vorangetrieben hat, die zur Etablierung der drei Communities (Developers, Adopters, Users) rund um das Projekt vonnöten sind. Projekte in der Incubation-Phase müssen entsprechend gekennzeichent werden: Durch Logos auf den Projekt- und Downloadseiten ebenso wie durch Einfügen des Wortes „Incubation“ in den Namen der herunterladbaren Datein und – falls technisch möglich – in Features. Incubation-Projekte, die diesen Anforderungen gerecht werden, können den Parallel IP Process in Anspruch nehmen, Meilensteine und Releases erstellen und sich um den Ausbau ihrer Community kümmern.

Verfügt das Projekt über stabile APIs und hat sich sein Team mit dem Eclipse Development Process vertraut gemacht, geht es in die Mature-Phase über, in der es den Großteil seines Daseins verbringt. Ein Mature-Projekt folgt im Idealfall den eingangs beschriebenen Grundsätzen der Transparenz, Offenheit und Meritokratie, produziert von Fragen des geistigen Eigentums unberührte Software und kümmert sich um die Pflege der Developer-, Adopter- und User-Communities.

Weitere Inhalte

Neben den in diesem Artikel vorgestellten Abschnitten befasst sich das neue Eclipse-Projekthandbuch ausführlich mit folgenden Themenbereichen:

  • Project Resources and Services
  • Committer Paperwork
  • Intellectual Property
  • Elections
  • Releases
  • Project Management Infrastructure (PMI)

Abgerundet werden die einzelnen Kapitel durch erläuternde Kommentare sowie durch Abschnitte, die häufig gestellte Fragen behandeln. Insgesamt stellt es eine bereits recht ausgereifte Dokumentation dar, die nach Lektüre wenn überhaupt  nur wenige Fragen offen lassen dürfte.

Aufmacherbild: Ring Binder notebook with pencil on wooden von Shutterstock / Urheberrecht: chuangz

Verwandte Themen:

Geschrieben von
Michael Thomas
Michael Thomas
Michael Thomas studierte Erziehungswissenschaft an der Johannes Gutenberg-Universität Mainz und arbeitet seit 2013 als Freelance-Autor bei JAXenter.de. Kontakt: mthomas[at]sandsmedia.com
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: