Zur Situation des Eclipse-Ökosystems und der Eclipse Foundation

Teil 2: Quo vadis Eclipse?

Kontroverse Community-Diskussionen über die Zukunft von Eclipse – bis hin zur Schicksalsfrage der Eclipse Foundation – stehen im Zentrum des zweiten Teils unserer kritischen Bestandsaufnahme zur Situation des Eclipse-Ökosystems und der Eclipse Foundation.

Community-Diskussionen

Erste kritische Diskussionen wurden in Community-Blogs 2009 geführt, als verschiedene Eclipse-Aktivisten die Frage stellten, wie der Wert einer Mitgliedschaft in der Eclipse Foundation wieder gesteigert werden könne und mehr Unternehmen zu einer Beteiligung am Ec

lipse-Ökosystem bewegt werden könnten. Auslöser der Diskussionen war der damalige Community-Direktor Björn-Freeman Benson, der in seiner Blog-Serie „State-of-Ecl

ipse“ [1] die Frage stellte:

Fewer resources, more to do, and a larger user base – change is upon us, so what are we going to do about it? Björn-Freeman Benson

Dass diese Diskussionen dann abdrifteten und nach der Entlassung von Freeman-Benson sowie dessen Ausschluss vom Organisationsteam der EclipseCon 2010 sich mehr und mehr zu einer polemischen Auseinandersetzung zwischen Freeman-Benson und Mike Milinkovich entwickelten, dürfte den meisten bekannt sein. Das folgende Possenspiel, in dessen Verlauf Milinkovich seinen ehemaligen Angestellten als „Jerk“ (laut LEO: „Dummkopf, Narr, Trottel, Knilch“) bezeichnete und öffentlich aufforderte, Eclipse zu verlassen („Dear Bjorn: Go away“ [2]), verwischt allerdings die Ernsthaftigkeit der damaligen Diskussionen, an denen sich etliche Protagonisten des Eclipse-Ökosystems produktiv beteiligten.

Im Kern wurden damals einige wunde Punkte angesprochen, in die Freeman-Benson wohl zu deutlich den Finger gelegt hat, die beileibe aber nicht nur von ihm als verbesserungswürdig wahrgenommen wurden und im Grunde bis heute im Raum stehen.

Diversität

Die meisten Eclipse-Projekte werden von einem einzigen Unternehmen vorangetrieben. Gleichungen wie: Eclipse JDT = IBM, BIRT = Actuate, EclipseLink = Oracle stimmen zum Großteil auch heute noch. Problematisch ist dies u.a. deshalb, weil gerade in wirtschaftlich schwierigen Zeiten Unternehmen dazu tendieren, solche offenen Projekte entweder zu vernachlässigen oder allein den eigenen Bedürfnissen anzupassen. Bei einem Rückzug der „Sugar Daddies“, der alleinigen Projektunterstützer also, verlieren solche nicht wirklich von einer pluralistischen Community getriebenen Projekte ihre Dynamik und drohen den langsamen Open-Source-Tod zu sterben. Doug Schaefer drückt dies im Interview mit dem Eclipse Magazin (Ausgabe 1.10) [3] folgendermaßen aus:

Ich habe zu viele Projekte gesehen, die von einem einzigen Anbieter getragen werden und es dann schwer haben, Mitstreiter zu finden, da diese sich nicht über die Absichten des Anbieters im Klaren sein können. Doug Schaefer

Hohe Zugangshürden: IP-Prozesse

Ein zweiter Kritikpunkt: Die strikt einzuhaltenden IP-Richtlinien führen zwar zu den verlässlichen, kommerzialisierungsfreundlichen Quellcode-Basen, welche Unternehmen für den Aufbau ihrer Produkte benötigen. Allerdings verursachen diese zähen IP-Prozesse auch erhebliche Mehraufwände, die allein auf der Seite der Committer liegen.

Greg Wilkins, Mastermind von Jetty, im Interview mit dem Eclipse Magazin (Ausgabe 6.09) [4]:

Bezüglich des Umzugs zu Eclipse war[en die IP-Prozesse] eine schmerzliche Angelegenheit für uns, weil jedes Byte, das bei Eclipse zum Download angeboten wird, unter den Bedingungen der Eclipse Foundation steht und wir keine Abhängigkeiten mehr integrieren konnten, die wir etwa nur zu Testzwecken oder für optionale Komponenten eingeführt haben. Greg Wilkins

Die IP-Prozesse verhindern den einfachen Einstieg ins Eclipse-Ökosystem, was insbesondere für kleine, innovative Community-Projekte zum Problem werden kann. In diesem Punkt hat die Eclipse Foundation indes bereits reagiert: Im Mai 2010 wurde der neue Service „Eclipse Labs“ als Untersektion von Google Code eingerichtet, als Ort, an dem neue Eclipse-Projekte ihren Platz finden können, ohne den strengen Richtlinien genügen zu müssen. Das Los der „Eclipse-Juwelen“, die jahrelang quasi unbemerkt auf SourceForge liegen, scheint sich langsam zum Guten zu wenden.

Distributionen

Ein dritter Kritikpunkt der Community-Diskussionen: Eclipse steht heute in 10 verschiedenen, je nach Einsatzzweck vorkonfigurierten Distributionen zum Download bereit: von der „IDE for Java EE Developers“ über die „SOA Platform for Java and SOA Developers“ bis zur „Pulsar-Distribution for Mobile Java Developers“. Diese Distributionen wirken in ihrer Form wie fertig konsumierbare Produkte, enthalten aber im Grunde nur lose miteinander in Zusammenhang stehende Frameworks. Sie erwecken den Anschein, wohl aufeinander abgestimmte Komponenten wie bei professionell vermarkteten IDEs à la IntelliJ oder kommerziellen Eclipse-Distributionen à la MyEclipse bereit zu stellen, bieten aber kaum den Standard, den man von einer kommerziellen Distro erwartet: Komponenten müssen manuell angepasst werden, Plug-ins zusätzlich eingerichtet werden, etc.

Gerade auf dem freien Plug-in-Markt sieht man sich einer Unzahl von Eclipse-Erweiterungen gegenüber, die völlig unterschiedliche Qualitätsstandards und Release-Zyklen aufweisen. Klagen über die „Plug-in Hell“, die man sich bei der Installation von Eclipse-Plug-ins einhandelt, sind an der Tagesordnung (siehe z.B. Interaktiver IDE-Vergleich auf JAXenter [5]). Das Problem liegt also darin, dass man die Erwartungshaltung geschaffen hat, mit den freien Eclipse-Distributionen ein fertiges und kostenfreies Produkt zu erhalten. Das hat mindestens drei gravierende Konsequenzen:

  1. Die Idee wird propagiert: Eclipse gibt es für umsonst („Free as in Free Beer“). Weshalb dann noch für kommerzielle Distros bezahlen?
  2. Die Erwartungshaltung, ein fertiges Produkt zu erhalten, wird enttäuscht. Viele wenden sich von Eclipse ab – in der Tat gewinnt NetBeans immer mehr Anhänger [6].
  3. Durch die Bereitstellung der Distros begibt sich die Eclipse Foundation im Grunde selbst in einen Wettbewerb mit den eigenen Mitgliedsunternehmen. Vor allem das Business-Modell, aufeinander abgestimmte Eclipse-Distributionen wie MyEclipse (Genuitec) oder Yoxos (EclipseSource) anzubieten, wird deutlich korrumpiert.

Doug Schaefer [1]:

Das Hauptproblem, das ich sehe, ist, dass die Eclipse-Mitglieder tatsächlich mit dem freien Eclipse konkurrieren. Doug Schaefer

Mik Kersten, CEO Tasktop Technologies [1]:

Ich glaube, wir sollten danach streben, mehr Klarheit in der Frage zu schaffen, was Leute kostenlos bekommen und wohin sie sich wenden können, wenn sie mehr wollen. Dies beinhaltet beispielsweise, die Support-Erwartungen in Download-Seiten, E-Mail-Listen und Newsgruppen zu integrieren. Mik Kersten

[ header = Seite 2: Die Schicksalsfrage der Eclipse Foundation ]

Die Schicksalsfrage der Eclipse Foundation

Eine größere Diversität der Projekte, flexiblere IP-Prozesse, eine bessere Distributionsstrategie, die nicht auf Kosten der Mitglieder geht. Dies waren die drei Hauptforderungen der Community- Diskutanten, die in erlebtem Problembewusstsein um Lösungsansätze bemüht waren – Lösungsansätze im Grunde für die eine entscheidende Frage, die sich in der Tat als Schicksalsfrage der Eclipse Foundation herausstellen könnte: Was haben die Mitglieder der Foundation heute noch davon, Mitglieder zu sein? Werfen wir einen ein Blick auf den Entstehungsprozess des Eclipse-Ökosystems: Weshalb wurden Unternehmen früher Mitglieder der Foundation?

In einem interessanten Kommentar erinnert Richard Gronback (Co-Leader des Modeling PMC und Project Lead der Eclipse-Projekte GMF und Amalgam) an die Anfangszeiten von Eclipse, als es den strategischen Mitgliedern nicht so sehr um Marketing-Werte durch den Brand „Eclipse“ ging, da die Namen der Unternehmen ohnehin viel prominenter waren als das noch unbekannte Eclipse. Die Mitglieder „zahlten ihre Beiträge, um die Kosten für die Entwicklung und die Pflege einer qualitativ hochwertigen Plattform für ihre kommerziellen Produkte zu teilen.“ [7].

Heute hat sich die Situation allerdings geändert. Diese gemeinsam geschaffene Plattform ist bereits etabliert und kann auch ohne eine weitere Mitgliedschaft in der Eclipse Foundation genutzt werden. Zudem hat die Eclipse-Technologie bereits eine solch große Verbreitung gefunden und auch qualitativ einen hohen Standard erreicht, dass sich viele zu fragen trauen: Was bietet mir die Eclipse Foundation außer den ohnehin kostenlos verfügbaren Diensten eigentlich zusätzlich an?

Doug Schaefer [8]:

Eine weitere gute Frage: Wenn die Mitglieder damit aufhören würden, die Foundation zu finanzieren und diese verschwinden würde, würde Eclipse dann weiterbestehen? Ich denke, die Antwort wäre: Ja. Und ich glaube, dass dies das wahre Problem ist, das hier auf dem Spiel steht. Doug Schaefer

In der Tat laufen die Eclipse-basierten Produkte auf einer stabilen Plattform, die auch ohne die Aktivitäten der Eclipse Foundation einfach einmal da ist. Was würde es einem Großunternehmen wie z.B. Siemens, gewiss einer der ganz großen Eclipse-User, wirklich bringen, sich stärker in der Eclipse Foundation zu engagieren? Worin lägen die Vorteile für ein kleines Unternehmen wie „Powerflasher“, die mit FDT ein interessantes Eclipse-basiertes Produkt, eine Eclipse-IDE für Flash, anbieten, Mitglied der Eclipse Foundation zu werden?

Die lapidare Antwort der Eclipse Foundation besteht typischerweise in dem Hinweis, dass man als strategisches Mitglied in der Eclipse Foundation einen größeren Einfluss auf die Richtung erhält, die das Eclipse-Ökosystem nehmen soll. Was in vielen Gesprächen mit Eclipse-Unternehmen allerdings deutlich herauszuhören ist, ist eher die Einstellung, dass man mit der bestehenden Plattform im Grunde zufrieden ist und deshalb gar kein Interesse daran besteht, sich an der Weiterentwicklung der Plattform zu beteiligen. Dazu kommt die Schwierigkeit, sich bei einem Engagement in der Foundation mit den vielen Partikularinteressen innerhalb der Foundation abzustimmen zu müssen und, wie man immer wieder hört, sich gegen die Überzahl der „IBMler und Oracle-Leute“ durchzusetzen.

Was also, wenn ich als Unternehmensleiter nach langer Evaluierungsphase zu der Konklusion komme: Am besten fahre ich mit meinem Geschäftsmodell, wenn ich Eclipse, so wie es ist, kostenlos nutze, und ich mir die Beiträge und Verpflichtungen der Mitgliedschaft in der Eclipse Foundation spare?

„Clash of Cultures“ oder „Tragedy of Commons“?

Verrat! Aus Egoismus der Individuen wird ein gemeinsam gepflegtes Gut zu Grunde gerichtet – so hört man des Öfteren eingefleischte Open-Source-Verfechter auch aus dem Eclipse-Lager schreien, die auf die „Tragedy of Commons“ verweisen [9] . Doch ganz so einfach ist es nicht!

Der Lebenszyklus von Eclipse-Projekten kann in etwa folgendermaßen beschrieben werden:

  1. Committer entwickeln Projekte
  2. Auf Basis dieser Projekte entstehen kommerzialisierbare Produkte für Endverbraucher
  3. Endverbraucher generieren Gewinne für die Unternehmen
  4. Unternehmen finanzieren Committer

In der Theorie wird dieses Schema idealerweise zirkulär durchlaufen, was zu einer Verbreitung der Eclipse-Technologie, zu einem Wachstum des Marktes um Eclipse und damit zu immer größeren Gewinnaussichten der beteiligten Unternehmen führen sollte. Immer häufiger ist aber nun zu beobachten, dass der Übergang von Stufe drei zu vier ausbleibt. Niemand hindert schließlich ein Unternehmen daran, die qualitativ hochwertige Codebasis von Eclipse herzunehmen und seine Produkte damit zu vermarkten, ohne der Community auch nur einmal irgendetwas zurück zu geben.

Es stimmt zwar, dass die Finanzierung von Eclipse-Committern dem Gedeihen des Eclipse-Ökosystems zu Gute kommt. Fraglich ist allerdings, ob die Unternehmen wirklich automatisch vom Wachstum des Eclipse-Ökosystems profitieren – und wenn überhaupt, dann eher langfristig. Gerade in ökonomisch schwierigen Zeiten, tendiert man dazu, kurzfristig zu optimieren, um überhaupt einigermaßen schadlos aus der Krise zu kommen.

Hier hilft es auch gar nicht, an den „Open-Source-Geist“ im Sinne einer Grassroot-Bewegung zu appellieren. Die Eclipse Foundation selbst funktioniert ja eher so, Open-Source-Projekte durch die starken Governance-Prozesse von einer Grassroot-Bewegung weg hin zum ernstzunehmenden Business-Faktor zu machen. Auf dieser Ebene hat man es dann nicht mehr mit idealistischen Freiheitsbildern einer kollektiv erstellten Plattform zu tun, sondern mit knallhart kalkulierten Eigeninteressen der untereinander konkurrierenden Unternehmen. In der Tat sind unternehmensübergreifende Kooperationen immer noch selten (schon die Eclipse Roadmap 2008 [10] nennt als strategisches Ziel die Gründung von Industrie-Working-Gruppen, bis heute gibt es allerdings erst zwei IWGs, Pulsar und Eclipse SOA).

Es geht hier also nicht so sehr um die Vernachlässigung eines gemeinsam gepflegten Guts (Tragedy of Commons), sondern um massive kulturelle Unterschiede beim Zusammenstoß von Open-Source-Ideologie und Business-Interessen.

Ein belegter Fall aus der heutigen Praxis: Ein Unternehmen A nutzt ein frei zugängliches Eclipse-Projekt produktiv. Eine zweite Firma B evaluiert dasselbe Eclipse-Projekt und bittet die ursprünglichen Projekt-Entwickler, die viele Mannjahre Arbeit in die Entwicklung des Projekts investiert hatten, um Auskunft, die freizügig gewährt wird. Als die ursprünglichen Projekt-Entwickler allerdings Unternehmen A bitten, ihre Erfahrungswerte auch der Firma B zur Verfügung zu stellen, erhalten sie die Antwort: Für einen Tagessatz von 2 500 Euro sind wir gerne zu einem Briefing bereit!

Es stellt sich hier die Frage: Wer profitiert eigentlich wirklich von Open Source? In diesem Fall jedenfalls nicht die ursprünglichen Open-Source-Entwickler.

Auch wenn Open Source Software eine immer größere Akzeptanz und Verbreitung findet (siehe Mike Milinkovich im Interview mit dem Eclipse Magazin 4.09: „Open Source hat gewonnen.“), so könnte es sich herausstellen, dass sich mit den Open-Source-Geschäftsmodellen gar nicht so viel Geld verdienen lässt. Hatte man früher vielleicht geglaubt, das neue Eclipse-Governance Open-Source-Modell sei unwiderstehlich und könne nicht aufgehalten werden, so macht sich heute die ernüchternde Einsicht breit, dass das Ökosystem stagniert und tatsächlich immer weniger Unternehmen ihr Geld deshalb verdienen, weil sie selbst Open-Source-Software beitragen oder weil sie Mitglied der Eclipse Foundation sind.

[ header = Seite 3: Marketing-Bonus „Eclipse“? ]

Marketing-Bonus „Eclipse“?

Wie sieht es mit den möglichen Werbeeffekten durch die Marke „Eclipse“ aus, die auch im offiziellen Dokument der Eclipse Foundation „Membership Benefits“ [11] angepriesen werden:

The exclusive members only logo and supporting artwork can be used on marketing material such as your web site, signs at trade shows, product collateral, etc.

Nun ist es sicherlich so, dass zu Zeiten des Eclipse-Booms das Prädikat „Eclipse-basiert“ bzw. „Mitglied der Eclipse Foundation“ tatsächlich alleine schon Marketingpotential hatte und in der Lage war, die Sichtbarkeit eines Unternehmens bzw. Produktes deutlich erhöhen. Die Eclipse Foundation musste in den Goldgräberzeiten hier eigentlich nicht viel unternehmen, die Marke „Eclipse“ sprach gewissermaßen für sich.

Es häufen sich die Anzeichen, dass die Marke „Eclipse“ beginnt, ihren magischen Nimbus als schlagendes Verkaufs- bzw. Marketingargument zu verlieren. Eclipse ist etabliert, trägt nicht mehr die Konnotation des „Neuen“, „Innovativen“, „Zukunftweisenden“ mit sich. Bei verschiedenen Eclipse-Unternehmen kann man Bestrebungen feststellen, sich aus der Eclipse-Ecke zu emanzipieren. Actuate wirbt z.B. kaum noch mit lauten Eclipse-Botschaften und auch in der Ecke der modellgetriebenen Entwicklung wird betont, dass die Technologien ja auch außerhalb der reinen Eclipse-Umgebung zum Einsatz taugen. Auch Toolhersteller reagieren eher gelassen, wenn man sie auf die Eclipse-Krise anspricht. So sagte ein Eclipse-Unternehmer kürzlich im Gespräch mit dem Eclipse Magazin: „Mein Produkt läuft zwar auf Eclipse-Basis, kann bei Bedarf aber auf andere Technologien aufgesetzt werden. Wenn es Eclipse nicht mehr geben sollte, dann eben etwas anderes.“ Die Industrie rüstet sich für die Nach-Eclipse-Zeit.

In diesem Bereich ist nun die Eclipse Foundation – quasi ungewohnter Weise – plötzlich gefragt, von sich aus eine bessere Unterstützung für Marketing bereitzustellen. Angesichts des beschränkten Mitarbeiterstabs sind die Möglichkeiten allerdings tatsächlich eher bescheiden und beziehen sich in den aktuellen Diskussionen lediglich auf Verbesserungen der IT-Infrastruktur, von denen einige ja bereits umgesetzt sind: Der neue Eclipse-Marketplace ist eingerichtet, ein Marketplace-Client soll die Verbindung zwischen IDE und Marketplace herstellen und die Unternehem so direkt einbinden. Perspektivisch soll hier wohl so etwas wie ein Eclipse App Store entstehen, wie dieser allerdings aussehen könnte, darüber wird derzeit noch kontrovers diskutiert [12].

Projekt e4

Vor dem Hintergrund der bisher diskutierten Punkte wird auch der Gegenwind von Seiten der Industrie verständlich, der dem Projekt e4 entgegen bläst. Eclipse als Entwicklungsplattform und als Rich Client Platform hat sich bereits dermaßen etabliert, dass Veränderungen an den Fundamenten der Plattform potentiell die in Millionenhöhe getätigten Investitionen gefährden. So sehr man sich einig darüber ist, dass die Plattform in die Jahre gekommen ist, so unklar scheint zu sein, ob das e4-Projekt tatsächlich die Zeiten zurückbringen wird, als „Eclipse“ den Geschmack des Aufregenden, Innovativen, Neuen mit sich führte. Wo ist das „Killer-Feature“ in e4, fragte deshalb Elias Volanakis in seinem Blog: „Is e4 a lemon?„[13] Auffällig ist jedenfalls, dass dem ursprünglichen Aufruf an alle Parteien, sich am e4-Projekt zu beteiligen, außer IBM nur wenige gefolgt sind (von den 20 aktiven Committern stammen 11 von IBM). Bezeichnend für die IBM-Dominanz ist zudem, dass es fast ausschließlich die IBM-geführten Komponenten in das vorliegende Eclipse 4.0 SDK geschafft haben – XWT, Toolkit-Model und weitere verbleiben vorerst im e4-Inkubator.

Bleibt also die Frage: Wird Eclipse nochmals ein Coup gelingen wie einst mit Eclipse 3.0 (und der Einführung der OSGi-basierten Equinox-Plattform)? Oder ist e4 eher aus der Not geboren, der Community etwas Neues präsentieren zu müssen, um den Eclipse-Ball weiter im Spiel zu halten?

Geschrieben von
Kommentare

Schreibe einen Kommentar

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