Eclipse muss frei bleiben

Hartmut Schlosser

Die Frage um die vermeintliche Ressourcen-Knappheit für die Pflege der Eclipse-Plattform wird weiter im Netz diskutiert. Nachdem Chris Recoskie vom CDT-Projekt die Idee einer Abgabe für bestimmte, von Unternehmen finanzierte Committer ins Spiel gebracht hatte, wagt Michael Scharf einen neuen Vorstoß. Sein Vorschlag: Eclipse sollte mit einem Preisschild versehen werden.

„Stellt Euch vor, die Eclipse IDE würde 300 US-Dollar kosten“, titelt Scharf wohl bewusst provokativ. Die Idee dabei ist allerdings nicht, Eclipse generell zu einem kommerziellen Produkt zu machen. Statt Eclipse aber wie bisher als kostenlose IDE zu präsentieren und auf Spenden für die gemeinnützige Eclipse Foundation zu hoffen, soll der Spieß umgedreht werden: Eclipse soll erst einmal als Produkt gelten, für das man Geld bezahlen muss; allerdings sollen User die Möglichkeit haben, über vielfältige Discount-Optionen auch weiterhin kostenlos an die Downloads zu kommen.

Der Unterschied ist also ein psychologischer: Muss derzeit eine Hürde überwunden werden, um Geld – etwa im Rahmen des „Friends of Eclipse“ Programmes – zu spenden,  so soll eine gedankliche Hürde für bloße Profiteure, die der Community nichts zurückgeben, eingebaut werden. Scharf stellt sich vor dem Download einen Dialog vor, in dem Checkboxen anzukreuzen wären, etwa: „Ich bin ein Committer (100% Discount)“,  „Ich nutze Eclipse nur für Open-Source-Projekte“ (bis zu 100%), „Mitgliedsunternehmen der Eclipse Foundation sollten bezahlen“ (100% Discount).

Kreuzt man nichts an, so muss man bezahlen – beispielsweise 300 US-Dollar. Dieses Geld könnte der Käufer dann zur Hälfte auf bestimmte Eclipse-Projekte verteilen. Die andere Hälfte würde von der Eclipse Foundation verwendet, um selbst Entwickler für die Verbesserung der gemeinsamen Eclipse-Plattform einzustellen.

Eclipse als Produkt

Neben dem psychologischen Moment – „Freeloader“ müssten sich quasi rechtfertigen – sieht Scharf einen Vorteil seines Vorschlages darin, dass Ausgaben für Produkte in Unternehmen üblicherweise routinemäßig abgewickelt werden. Hingegen stellt es eine große Ausnahme im Unternehmensalltag dar, den eigenen Entwicklern Zeit für die Verbesserung von Eclipse-Projekten zuzugestehen – noch dazu von Projekten, die dem Allgemeingut und damit auch dem Konkurrenten nutzen.

Scharfs Fazit:

As employee to make your company to donate or asking for time to contribute might be difficult. Getting approval for a software purchase might be simple.

Eclipse muss frei bleiben

Kann man sich vorstellen, dass ein kostenloses Open-Source-Projekt von heute auf morgen Geld kostet? Eigentlich nicht – Folge wäre wohl ein Fork oder ein massiver Rückgang der User. Für Scharf scheint das aber kein wirklich großes Problem zu sein. Im Gegenteil hätten dann andere, kommerzielle IDEs  wieder Chancen, auf dem Markt Fuß zu fassen, schreibt er. Damit kritisiert Scharf die Wirkung, die Eclipse Anfang der 2000er auf den Markt der Entwicklungstools gehabt hat.  Der Fakt, dass mit Eclipse plötzlich eine mächtige Entwickler-Plattform frei zur Verfügung stand, hat schließlich dazu geführt, dass so gut wie alle kommerziellen Java IDEs vom Markt verschwunden sind. Neben einigen kommerziellen Eclipse-Distributionen ist IntelliJ IDEA vom tschechischen Tool-Anbieter JetBrains hier eigentlich die einzige Ausnahme. 

Scharfs Vorschlag regt sicherlich zum Denken an (Eclipse ist eben nicht für alle das Gemeingut gewesen, das es jetzt zu retten gilt), Wirkung wird er allerdings nicht zeigen. Zu offensichtlich würde das bisherige Credo der Eclipse Foundation aufgegeben, Unternehmen für die kollaborative Entwicklung von frei zugänglicher Infrastruktur-Software zu gewinnen, auf deren Basis ein kommerzielles Ökosystem entstehen kann.

Nimmt man dies als Kernaufgabe der „Non-Profit-Organisation“ Eclipse Foundation, so kommt man zu dem Schluss, dass es geradezu anmaßend wäre, von den Committern oder den Usern eine Abgabe zu fordern. Genauso würde der Verlust eines Teiles der Community vielen Eclipse-Dienstleistern die Kundenbasis entziehen – die kommerziellen Potenziale des Eclipse-Ökosystem, die die Foundation etwa mit der EPL und den relativ strikten IP-Richtlinien stets im Auge hat und die sicherlich einer der Gründe für den Erfolg von Eclipse sind, würden beschädigt.

Die Überlegungen der Eclipse Foundation werden deshalb in die Richtung gehen, die Mitgliedsunternehmen (vornehmlich die strategischen) stärker an der Plattform-Pflege zu beteiligen. Hier weist möglicherweise die Long Term Support Initiative in die richtige Richtung, in der Unternehmen ja auch mit Extra-Zahlungen gemeinsam einen langfristigeren Support für gewisse Eclipse-Versionen organisieren.

Lassen sich die strategischen Mitglieder (derzeit: IBM, Google, Oracle, SAP, CA Technologies, Actuate, Bredex, Innoopract, itemis und Obeo) nicht von der Abstellung oder Finanzierung je eines Plattform-Entwicklers überzeugen? Zur Erinnerung: Strategische Mitglieder sind jetzt schon entweder dazu verpflichtet, mindestens acht Vollzeit-Entwickler für Eclipse-Projekte zu beschäftigen (Strategic Developers), oder, je nach Umsatz, zwischen 50.000 und 500.000 US-Dollar zu bezahlen (Strategic Consumers).

Recht hat Scharf sicherlich mit der Aussage, dass das unkoordinierte Abstellen von mehr Ressourcen nicht so effektiv sein kann, wie das Beschäftigen einer kleinen Spezialisten-Gruppe, die die Eclipse-Plattform in- und auswendig kennt. Ob und in welcher Form das nötig ist, hat die Foundation in ihren verschiedenen Gremien zu entscheiden.

Möglicherweise ist hier die Karte der Diplomatie noch nicht ganz ausgespielt.

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
  1. Marcel Bruch2013-10-15 11:21:44

    Passend zum Thema:
    Die Diskussion um die IDE Working Group:

    http://dev.eclipse.org/mhonarc/lists/ide-dev/msg00128.html

Schreibe einen Kommentar

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