Über den Charakter des Eclipse-Ökosytems
Die Karlsruher Softwarefirma Innoopract ist schon seit Jahren maßgeblich an der Strategie der Eclipse-Plattform beteiligt. heise Developer wollte von Jochen Krause, Geschäftsführer der Firma, wissen, was die Eclipse-Community auszeichnet.
- Alexander Neumann
Jochen Krause ist Geschäftsführer von Innoopract (international EclipseSource), einem Unternehmen, das sich im Eclipse-Umfeld einen Namen gemacht und einen nicht unerheblichen Teil dazu beigetragen hat, dass die Eclipse-Plattform zu dem werden konnte, was es heute darstellt. heise Developer wollte anlässlich des Helios-Release und des von Eclipse 4 von ihm wissen, was die Eclipse-Community auszeichnet und wo sich noch Potenzial findet, das Geschäftsmodell auf Eclipse auszurichten.
heise Developer: Jochen, wie ist dein Unternehmen in die Eclipse Foundation eingebunden, und wie kam es zum Beitritt zum Eclipse-Konsortium?
Jochen Krause: Innoopract ist Gründungsmitglied der Eclipse Foundation und wurde 2003 nach SuSE und SAP drittes deutsches Mitglied des Eclipse-Konsortiums. 2007 sind wir dem Kreis der Strategic Member der Eclipse Foundation beigetreten. Als "strategisches Mitglied" tragen wir mit mindestens acht Entwicklern zur Weiterentwicklung der Eclipse-Codebasis bei und sind im Board of Directors der Foundation vertreten, das die Strategie von Eclipse bestimmt.
Ursprünglich wurden wir bei Eclipse Mitglied, weil eines unserer Werkzeuge Eclipse-basiert war und wir den sogenannten Ökosystem-Ansatz von Eclipse sehr interessant fanden. Heute sind wir komplett auf Eclipse fokussiert, und unser gesamtes Geschäft ist an Eclipse geknüpft. Unser besonderes Interesse gilt den Themen Distribution (p2, Yoxos) und Server-Runtimes (Equinox, RAP, Virgo). Durch die Beteiligung an beziehungsweise die Leitung von mehreren Eclipse-Projekten wie Equinox, RAP, RCP, e4, p2 sind wir sehr tiefgehend in die Weiterentwicklung von Eclipse involviert.
heise Developer: Mehr und mehr Projekte suchen und finden Ihre Heimat innerhalb des Eclipse-Kosmos. Wie ist es deiner Meinung nach überhaupt noch zu realisieren, ein Projekt angemessen betreuen zu können beziehungsweise dessen Qualität zügig zu überprüfen?
Krause: Ob es bei Eclipse viele oder wenige Projekte gibt, hängt vom Standpunkt des Betrachters ab. Verglichen mit SourceForge oder anderen Open-Source-Communitys hat Eclipse eine verschwindend kleine Anzahl an Projekten. Verglichen mit Eclipse im Jahr 2002 sind es aber sicherlich eine Menge. Alle Projekte müssen den Regeln gehorchen, die in der Satzung der Eclipse Foundation festgelegt sind. Hier sind zum einen Anforderungen an die Technik definiert wie "... provides extensible frameworks and examplary tools". Zum anderen gibt es Anforderungen an die Governance von Projekten im Eclipse-Entwicklungsprozess, was sich in der Formulierung "vendor neutral, open source rules of engagement" ausdrückt. Auf beides möchte ich näher eingehen.
Die "erweiterbaren Rahmenwerke und beispielhaften Werkzeuge" definieren einen eindeutigen Qualitätsanspruch an Eclipse-Projekte. Wer erweiterbar sein will, muss (stabile) APIs bereitstellen, und die Implementierung von Werkzeugen soll anderen als Beispiel dienen können, um eigene Werkzeuge zu implementieren. Die Einhaltung der Regeln wird durch den Eclipse-spezifischen Release-Prozess gewährleistet. Das bedeutet, dass natürlich nicht jede Zeile Code geprüft, aber die Einhaltung der Regeln bezüglich stabiler APIs sehr ernst genommen wird. Wer professionell Software entwickelt hat, kennt die Zwänge, in die man sich mit der Bereitstellung einer API begibt. Aus meiner Sicht ist das ein wichtiges Alleinstellungsmerkmal von Eclipse: Wir fühlen uns nicht nur Anwendern, sondern auch den Nutzern unserer APIs verpflichtet.
Unter den "Open Source Rules of Engagement" fassen wir die Begriffe "Openness", "Transparency" und "Meritocracy" zusammen. Durch die Verpflichtung zur Herstellerunabhängigkeit bei gleichzeitiger Offenheit und Transparenz gewährleisten wir umfassende Mitwirkungsmöglichkeiten und letztlich die Kontrolle durch die Community.
Die Überprüfungen hinsichtlich Qualität und die Betreuung der Projekte durch die Eclipse Foundation erfolgen im Wesentlichen anhand der oben genannten Kriterien. Unsere bisherige Erfahrung zeigt, dass wir dadurch eine hohe Qualität sicherstellen können. Für Anwender gibt es ein wichtiges Kriterium hinsichtlich des Reifegrads eines Projekts. Ist die Projektversion höher als 1.0, müssen die oben genannten Kriterien erfüllt sein. Noch höhere Anforderungen gibt es für die Projekte, die am jährlichen gemeinsamen Release teilnehmen. Beispielhaft sei hier auf das Ende Juni veröffentlichte Eclipse Helios verwiesen, an dem rund 40 Projekte teilgenommen haben.
heise Developer: Wo siehst du noch Potenzial für Verbesserungen bei den Strukturprozessen?
Krause: Im Großen und Ganzen halte ich die Eclipse-Community hinsichtlich der Prozesse für die fortschrittlichste Open-Source-Community. Beim Thema "Build" haben wir noch das meiste Verbesserungspotenzial. Ein zentraler Build-Service wird schon seit Längerem diskutiert, und es gibt inzwischen auch einige Fortschritte.
heise Developer: Wie sehen die denn aus?
Krause: Beispielsweise hat Cloudsmith, ebenfalls ein strategisches Eclipse-Mitglied, eine Reihe von Eclipse-Projekten (Modeling, Mylyn, Runtime) mit einem standardisierten "Buckminster"-Build versehen und erst kürzlich verlauten lassen, dass sich auch die Eclipse-Plattform mit Buckminster bauen lässt.
