Eclipse IDE Working Group: Crowd-Coding-Experiment oder gutmütige Diktatur?

Hartmut Schlosser

Eclipse braucht mehr Ressourcen für die Weiterentwicklung der gemeinsamen Plattform – soweit scheint man sich selbst in den inneren Kreisen der Eclipse Community einig zu sein. Die Diskussionen der letzten Tage, hauptsächlich geführt auf der ide-dev-Mailing-Liste, haben nun zu einem ersten Entwurfspapier für eine IDE Working Group (IDEWG) geführt.

Im vorliegenden Proposal wird als Ziel der IDEWG ausgegeben, die zukünftige Relevanz der Eclipse IDE sicherzustellen. Hierfür soll eine priorisierte Roadmap erstellt werden, die die wünschenswerten Arbeiten an der IDE beschreibt. Anschließend soll sich die IDEWG um Realisierung bzw. Finanzierung der Entwicklungsarbeiten kümmern, indem sie entweder Entwickler aus den eigenen Reihen abstellt oder Implementierungspartner engagiert.

Die Beteiligung an der IDEWG kostet Geld bzw. Entwicklerressourcen, die unabhängig von den laufenden Mitgliedsgebühren zu entrichten wären. Der Erfolg einer solchen Initiative hängt also davon ab, wie viele Unternehmen sich tatsächlich dafür begeistern ließen. Gunnar Wagenknecht, der Verfasser des Proposals, beschreibt auf seinem Blog einen möglichen Motivationsgrund für den Beitritt in eine solche Working Group:

Viele Unternehmen tätigen heute Investitionen in kommerzielle Desktop IDEs, schreibt Wagenknecht. Wäre es für diese Unternehmen nicht interessanter, diesen Betrag (oder auch weniger) in eine Eclipse IDE Working Group zu investieren, die – nach dem Motto gemeinsam ist man stärker – für die Verbesserung der Eclipse-Plattform sorgt? Vorteil wäre zudem, dass man selbst an den Entscheidungen über die Zukunft der IDE teilhaben könnte.

Das Proposal ist als erste Diskussionsgrundlage gedacht, und so werden auf der Mailing-Liste viele offene Fragen diskutiert:

  • Das Problem der Roadmap: Wer bestimmt, was entwickelt werden soll? Die zahlenden Unternehmen, die Community oder ein unabhängiges Gremium?
  • Das Problem der Committer-Rechte: Sollen Mitglieder der IDEWG anders behandelt werden als reguläre Committer?
  • Das Problem der Codereviews: Viel Zeit müsste auf Reviews verwendet werden, um sicherzustellen, dass die gemachten Patches eine gute Qualität aufweisen.
  • Das Problem der Meritokratie: Soll man einem unbefleckten, von einem IDEWG-Mitglied finanzierten Studenten gleiche Rechte einräumen wie verdienten Eclipse-Urgesteinen?
  • Das Problem der Langfristigkeit: Was passiert mit Features, die beigetragen wurden, dann aber nicht mehr gepflegt werden? Kann man diese einfach wieder entfernen?
  • Das Problem der Demokratie: Laufen wir nicht Gefahr, eine Zweiklassengesellschaft zu errichten, in der Mitglieder der IDEWG schnell Reviews und Fixes erhalten, andere nicht?
  • Das Problem der Kohärenz: Wie stellt man bei den unterschiedlichen Interessen der Mitglieder tatsächlich sicher, zumindest so etwas wie eine gemeinsame Vision zu verfolgen? Ist hier nicht eine Art zentrales Entscheidungsgremium nötig („wohlwollende Diktatur“), das die Richtung festlegt?

Mike Milinkovich greift nur einmal in die Diskussion ein, indem er bemerkt:

The whole point of having an IDE working group would be to empower the influencers in our community, not shut them out.

Crowd Coding

Was in der Debatte auffällt, ist der Fokus auf den verteilten Kollaborationsprozess. Es geht nicht darum, ein fixes, zusätzliches Büro, etwa in Ottawa (dem Sitz der Eclipse Foundation), aufzumachen, in dem – sagen wir – vier Kern-Plattform-Entwickler eingestellt würden, um die Roadmap der IDEWG umzusetzen. Diese Idee war im Vorfeld von CDT-Leiter Chris Recoskie ins Spiel gebracht worden, scheint aber auf wenig Ressonanz zu stoßen. Der Ansatz ist eher der, dass die Implementierungen von einer diversen Entwickler-Gruppe durchgeführt werden, die von den IDEWG-Mitgliedern gestellt bzw. finanziert werden sollen.

Ebenso wird die Frage der Kommerzialisierung von Eclipse nicht weiter verfolgt. Marcel Bruch von Codetrails hatte als eine Option 2 beschrieben, die Eclipse Foundation könne kommerzielle Addons für Eclipse promoten, um kleinen bis mittleren Unternehmen Geschäftsmodelle zu eröffnen. Momentan sind diese Modelle unattraktiv, da es aufgrund des Open-Source-Images von Eclipse keine wirkliche Kaufbereitschaft für kommerzielle Addons gibt (obwohl diese Addons die Qualität der IDE deutlich steigern könnten und so dem Image-Verlust von Eclipse entgegenwirken würden). Zweitens kann ein Unternehmen niemals sicher sein, dass das JDT-Entwickler-Team von Eclipse nicht bald eine dem kommerziellen Addon vergleichbare Funktion als kostenloses Feature in Eclipse einbaut.

Wie es scheint, folgt Eclipse also dem Schwarmmodell – und unterscheidet sich damit von Oracles NetBeans und IntelliJ IDEA, wo alles aus einer Hand geliefert wird. Oder von der Linux Community, in der Linus Torvalds ja das letzte Wort über seinen Micro Kernel hat.

Brauchen wir den guten Diktator?

Industry Working Groups sind bei Eclipse entstanden, um das ursprüngliche Erfolgsrezept der Plattform auf andere Branchen zu übertragen. Der Gründungsmythos von Eclipse lautet so: IBM stellt die Plattform Anfang 2000 zur freien Verfügung. Viele mächtige Industrie-Player erkennen das Wertschöpfungspotenzial der Plattform und entschließen sich, gemeinsam deren Weiterentwicklung zu finanzieren – die Geburtsstunde der Eclipse Foundation, die genau diesen Kollaborationsprozess steuert.

Nun war in Realität aber auch bei der Eclipse-Plattform vor allem ein Player die treibende Kraft: IBM. Und Big Blue hat sich in den letzten Jahren immer weiter zurückgezogen. Es steht noch der Beweis aus, ob es mit einem Crowd-Coding-Ansatz gelingen kann, eine treibende Kraft wie IBM zu ersetzen und in Eclipse eine Kohärenz wie das 1-House-Produkt IntelliJ IDEA zu erreichen. Oder braucht es tatsächlich eine Art „gutmütige Diktatur“ (Doug Schaefer), die dann aber von der Kontrollinstanz Community überwacht werden müsste?

Auf der EclipseCon Europe sind verschiedene Treffen geplant, in denen diese und weitere Fragen zur Eclipse IDE Working Group vertieft werden sollen.

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare

Schreibe einen Kommentar

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