Über den Charakter des Eclipse-Ökosytems

Inhaltsverzeichnis

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.

Perspektiven

heise developer: Ihr habt von Anfang an viel dazu beigetragen, Eclipse zu dem werden zu lassen, was es heute darstellt. Was gibst du Firmen, die überlegen, sich in den Eclipse-Kosmos einzubringen, mit auf den Weg, ein erfolgreiches Geschäftsmodell auf Basis von Eclipse zu entwickeln?

Krause: Zuerst einmal gibt es unterschiedliche Modelle, wie man mit Eclipse Geld verdienen kann. Ich unterscheide das Geschäft mit Werkzeugen (Lizenzen, Abonnements) von dem mit Services (Beratung, Schulung, Entwicklung) und dem mit Runtime-Techniken (Wartung, Support). Am einfachsten ist es, mit Eclipse-Services Geld zu verdienen. Gutes Know-how von Basis-Techniken und vielleicht ein kleines Framework zur Beschleunigung der Entwicklung eines bestimmten Typs von Applikationen reichen hierfür aus. Als Eclipse-Mitglied erhält man eine gewisse Sichtbarkeit und Unterstützung durch die Foundation und andere Eclipse-Mitglieder. Die projektorientierte Natur dieses Geschäfts führt zu den üblichen Vor- und Nachteilen.

Der Bereich Werkzeuge, aus dem Eclipse stammt, galt schon immer ein schwieriges Terrain zum Geldverdienen. Risikokapitalgeber scheuen "Developer Tools" seit Jahren, und mit Eclipse haben wir den Trend, für Werkzeuge kein Geld auszugeben, sicherlich weiter bestärkt. Wer demnach daran denkt, mit einem neuen innovativen Werkzeug Geld zu verdienen, sollte einen langen Atem mitbringen. Für viele interessant ist natürlich die große installierte Basis von Eclipse (nach Evans Data circa 60 bis 70 Prozent der neun Millionen Java-Entwickler) und die mit Helios neu eingeführte Möglichkeit, über eine Art App-Store (Eclipse Marketplace) seine Werkzeuge an die Entwickler zu bringen.

Aus unserer Erfahrung ist die Bereitschaft der Entwickler, für Werkzeuge Geld auszugeben, derzeit im Steigen begriffen, allerdings auf einem deutlich niedrigeren Preisniveau als vor fünf Jahren. Beliebt sind Software-Services, die einige Euro pro Monat kosten. Meine Einschätzung ist, dass sich der Trend noch verstärken wird. Das allumfassende Wunderwerkzeug für mehrere tausend Euro pro Entwickler zu verkaufen gelingt heute dagegen nur noch selten.

Das Thema Runtime und die damit einhergehenden Verdienstmöglichkeiten Wartung und Support haben ein großes Potenzial. Eclipse ist hier breit aufgestellt und fokussiert Themen wie Modularität, SOA, Persistenz und UI. Ich gehe von der Annahme aus, dass es bei Eclipse innerhalb der nächsten zwölf Monate einen modularen App-Server geben wird. Die Einbindung weiterer Runtime-Dienste in einen solchen Server eröffnet völlig neue Perspektiven. Wer sich dafür interessiert, sollte sich das Eclipse-Runtime-Projekt einmal genauer anschauen.

Das Board of Directors hat schließlich vor Kurzem beschlossen, ein "Long Term Support"-Programm zu etablieren, dass im Open-Source-Markt einmalig ist. Da Einzelheiten hierzu aber noch verhandelt werden, kann ich im Moment nicht mehr zu dem Programm sagen, außer dass Unternehmen wie IBM, SAP, EclipseSource und andere an der Etablierung des Programms mitarbeiten.

Wer Interesse an dem Thema hat, kann sich gerne mit der Eclipse Foundation in Verbindung setzen, in Deutschland ist Ralph Müller der richtige Ansprechpartner.

heise Developer: Mit Eclipse 4 ist die nächste Generation der Eclipse-Entwicklungsumgebung erschienen. Mit ihr versuchen die Entwickler, die teilweise in die Jahre gekommene IDE auf innovative Weise zu erneuern. Wo liegen die Hoffnungen für die Eclipse-Community?

Krause: Eclipse 4 enthält für die Entwicklung von Werkzeugen interessante Neuerungen, zum Beispiel Dependency Injection, ein neues serviceorientiertes Konzept für die Workbench, eine Modell-Abstraktion der Workbench und Verbesserungen im Ressourcen-Management. Mit dieser modernisierten Plattform schafft Eclipse alle Voraussetzungen, in den kommenden Jahren der Marktführer im Bereich Entwicklungsplattform zu bleiben: Bestehende Tools lassen sich über den Kompatibilitätsmodus einfach weiternutzen, und neue Werkzeuge finden eine attraktive und moderne Plattform vor.

Man sollte in dem Zusammenhang aber auch erwähnen, dass die Code-Basis von Eclipse 4 eher dem Status einer Version 1.0 entspricht als dem eines Eclipse 4.0. Wenn wir uns Eclipse als Plattform für Geschäftsapplikationen auf dem Desktop und im Web anschauen, gibt es mit Eclipse 4 eine weitere Konvergenz von Desktop (SWT) und Web (RAP). Beispielsweise kann das Styling der Applikationen einheitlich mit CSS erfolgen. Eclipse ist damit eine der wenigen ernstzunehmenden Plattformen, die sowohl Desktop- als auch Web-Applikationen auf Basis einer einheitlichen Code-Basis ermöglicht. Der letzte Punkt gilt aber nicht nur für Eclipse 4, sondern ist bereits mit dem aktuellen Helios-Release gegeben.

heise Developer: Inwiefern siehst du in den mehr und mehr auf spezifische Anforderungen ausgerichteten Eclipse-Distributionen auf eclipse.org eine starke Konkurrenz zu etablierten Konfektionen unterschiedlicher Eclipse-Distributeure?

Krause: Wer sich als Hersteller auf Open Source einlässt – und noch dazu in einer herstellerneutralen Organisation wie Eclipse – läuft permanent Gefahr, dass ein Teil seiner kommerziellen Wertschöpfung durch die Open-Source-Community kostenlos bereitgestellt wird. Der Innovationsdruck ist daher im Allgemeinen sehr hoch. Auf der anderen Seite profitiert man von allen Errungenschaften der Community und kann seine Wertschöpfung darauf aufbauen. Dieser "Wettbewerb" ist aus unserer Sicht immanent und auch langfristig zielführend. Problematisch wären dagegen Situationen, in denen nicht ein Projekt oder die Community, sondern die Eclipse Foundation als Organisation selbst in Konkurrenz mit ihren Mitgliedern tritt.

Die "Eclipse-Distributionen" bei Eclipse werden maßgeblich von EclipseSource erstellt, von daher machen wir uns damit selbst Konkurrenz. Die Wertschöpfung bei unserer Distribution liegt aber im übertragenen Sinne nicht im Bereitstellen von Konfektionen, sondern in der Herstellung von Nähmaschinen und Kleiderbügeln, der Auswahl von Stoffen sowie in einem Lieferservice. Wer diese Services nicht nutzen will oder kann, ist mit den Eclipse-Paketen gut bedient. Neugierige sollten sich die neue Version von Yoxos anschauen, die zahlreiche Fähigkeiten für den Team-Einsatz mitbringt.

Es ist aber durchaus richtig, dass die Eclipse Foundation immer wieder in Versuchung kommt, mit ihren Mitgliedern in Konkurrenz zu treten, und im Bereich der Veranstaltung von Konferenzen ist das auch schon geschehen. Ich sehe es als eine meiner wichtigsten Aufgaben, im Board of Directors darauf zu achten, dass die Foundation ein Katalysator für das Geschäft seiner Mitglieder ist. Mit den neuen Programmen "Eclipse Marketplace" und dem "Long Term Support" geht die Eclipse Foundation eindeutig in diese Richtung. Damit wird der Ökosystem-Ansatz von Eclipse weiter gestärkt, und das Potenzial für Kunden, professionell mit Open Source zu arbeiten, erhält einen neuen Schub.

heise Developer: Jochen, vielen Dank für die Beantwortung der Fragen.

Die Fragen stellte "heise Developer"-Redakteur Alexander Neumann.

Siehe dazu auch:

• Eclipse: SOA- und Runtime-Techniken auf einem guten Weg; News auf heise Developer
• "Rückblickend betrachtet war der Einstieg bei Eclipse eine hervorragende Entscheidung": Über lohnendes Investment in die Eclipse-Community; Interview auf heise Developer
  
  

(ane)