Ein Gespräch mit Jochen Krause

Innovationsnetzwerk um Eclipse weiter ausbauen

„Quo vadis Eclipse?“ hatten wir im Eclipse Magazin 4.10 und auf JAXenter gefragt [1], und eine kritische Bestandsaufnahme der Situation des Eclipse-Ökosystems und der Eclipse Foundation vorgenommen. Wie steht es um die Wertschöpfungspotenziale, die das Eclipse-Ökosystem einem Unternehmen heute noch bietet? Welchen Mehrwert bringt eine Mitgliedschaft in der Eclipse Foundation tatsächlich? Jochen Krause darf als Geschäftsführer von EclipseSource und langjähriges Mitglied im Eclipse Board of Directors als ausgesprochener Kenner der Szene gelten. Im Gespräch mit dem Eclipse Magazin stellt er ein persönliches Resümee des gerade zu Ende gegangenen Helios-Jahres an.

Eclipse Magazin: Hallo Herr Krause. Die Jahreswende fällt im Eclipse-Kalender bekanntlich auf Ende Juni, wenn eine neue Eclipse-Version das Licht der Welt erblickt. Und Jahreswenden sind immer gute Anlässe, ein wenig in sich zu gehen und zurückzublicken: Wie lautet Ihr persönliches Eclipse-Resümee im gerade zu Ende gegangenen Helios-Jahr?

Jochen Krause: Die Eclipse-Community hat ein schwieriges (Release-)Jahr zu einem hervorragenden Ende gebracht. Mitte letzten Jahres befanden wir uns noch mitten in der Finanzkrise, die Eclipse Foundation hatte einen Rückgang an Mitgliedern zu verzeichnen und das Thema Eclipse als Runtime war noch wenig bekannt. Ein Jahr später sind die Perspektiven wieder viel freundlicher.

Es gibt zwar im Jahresvergleich immer noch einen Rückgang an Mitgliedern, aber wir haben als Eclipse Foundation jetzt eine Reihe interessanter Vorteile für Mitglieder geschaffen. Ein gutes Beispiel ist der so genannte „Eclipse Marketplace“ [2], der mit Helios in die Eclipse-Pakete Einzug gehalten hat. Der Marketplace erlaubt, ähnlich einem App-Store, Zusatzfunktionen für Eclipse sehr einfach zu finden und zu installieren. Das schafft einen großen Nutzen für Endanwender, aber auch für Toolhersteller und Distributionen. Endanwender erhalten einen einfachen Zugang zum inzwischen riesigen Universum der Plug-ins. Toolhersteller bekommen neue Kanäle, ihre Produkte Entwicklern zu präsentieren. Und dank der offenen Struktur des Marktplatzes können Distributionen ihre Inhalte als eigene Kataloge einbinden und den Benutzern ihres Katalogs einen Mehrwert bieten.

EclipseSource bietet beispielsweise mit der Yoxos-Distribution [3] einen extrem schnellen und auf Wunsch sicheren Zugriff auf alle Plug-ins sowie die Möglichkeit, sehr einfach eigene Plug-ins in privaten Marktplätzen bereitzustellen. Und der Zugang zu der Funktionalität des Marktplatzes ist bereits in jedem von Eclipse bereitgestellten Download enthalten – ganz ohne Installation zusätzlicher Software.

Eclipse als Plattform für Runtime ist für die Eclipse Foundation und auch für uns als Teil der Eclipse-Community ein strategisch wichtiges Thema. Vor diesem Hintergrund kann man die beiden neuesten Projekte bei EclipseRT – Virgo [4] und Gemini [5] – gar nicht hoch genug bewerten.

Der Spring DM Application Server hat als Projekt Virgo sein neues Zuhause bei Eclipse gefunden und damit einen Platz, an dem er sich herstellerneutral und unter der Obhut einer erfahrenden OSGi-Community weiterentwickeln kann. Das ist ein großes Plus für alle interessierten Nutzer und potenziellen Kontributoren. Ich bin der Meinung, dass Virgo unter diesen Voraussetzungen schon bald zu einem sehr ernstzunehmenden Spieler im Bereich der Applikationsserver wird.

Das Gemini-Projekt stellt Implementierungen für die Konvergenz von JEE und OSGi bereit und ist damit ein weiterer wichtiger Wegbegleiter für die Verbreitung von OSGi bei den Applikationsservern.

Die Chancen für Eclipse, einen weiteren Siegeszug für Modularität zu erringen und nach der IDE auch die Domäne der Applikationsserver nachhaltig zu verändern, könnten aus meiner Perspektive kaum besser stehen.

Eclipse Magazin: Mit Java EE 6 steht der Java-Community bereits ein Runtime-Stack für Enterprise- und Webanwendungen zur Verfügung, der mittlerweile die Kriterien von Leichtgewichtigkeit, Modularität, Skalierbarkeit und Entwicklerfreundlichkeit erfüllt. In Bezug auf EclipseRT stellt sich die Frage: Wozu brauchen wir noch einen alternativen Runtime-Stack?

Jochen Krause: JEE ist ein weit verbreiteter und inzwischen gereifter Standard, der aus der Unternehmens-IT heute nicht mehr wegzudenken ist. Es sind inzwischen auch zahlreiche Open-Source-Implementierungen für JEE verfügbar, die eine gute Performance bieten. Da ist die Frage nach der Existenzberechtigung für EclipseRT durchaus verständlich.

In der Praxis gibt es nach unserer Erfahrung aber durchaus einen Bruch in der JEE Welt: Entweder werden reine Servlet-Container (Tomcat, Jetty) genutzt oder ausgewachsene JEE-Container mit allen verfügbaren Standards. Wer Leichtgewichtigkeit im Fokus hat, beschränkt sich häufig auf den Servlet-Container, muss dann aber die Persistenz manuell hinzufügen. Im Gegensatz dazu lassen sich mit EclipseRT genau die benötigten Komponenten zu einem Server zusammenstecken: Servlet plus JPA, oder Servlet plus JEE. Was vielleicht noch wichtiger ist: Das Modulkonzept erlaubt auch die einfache Integration von Diensten, die über JEE hinausgehen. Und Eclipse Runtimes gibt es von B wie BIRT (Business Intelligence and Reporting) bis V wie Virgo (OSGi exposing App Server).

Es gibt noch einen zweiten schlagkräftigen Grund für App Server mit OSGi-Unterstützung: das Handling des Classpath in den klassischen App Servern. Mir ist kein JEE-Entwickler bekannt, der nicht schon über das Problem unterschiedlicher Versionen genutzter Libraries gestolpert ist. Besonders unschön an diesem Problem ist die Tatsache, dass es sich in der Regel erst durch ein Deployment offenbart. Hier bietet OSGi einfach signifikante Vorteile.

Auf das Thema Modularität möchte ich auch noch eingehen. Auch JEE definiert Modularität, diese ist aber an Server (bzw. JEE) gebunden. Die Modularität von OSGi kann für Server, Desktops oder sogar Mobile bzw. Embedded Devices einheitlich genutzt werden. Applikationsplattformen wie Riena oder Scout machen davon regen Gebrauch. Abseits der Diskussion um Granularität, Features und APIs ist das einheitliche Programmiermodell für mich ein schlagendes Argument für die Nutzung von OSGi.

Mit EclipseRT stellt Eclipse eine Umgebung bereit, welche die sanfte Migration zu OSGi ermöglicht. Bestehende JEE-Funktionalität kann weiter genutzt werden, neue Funktionalität kann sich die Vorteile von OSGi zu nutze machen.

[ header = Seite 2: Eclipse Marketplace ]

Eclipse Magazin: Sie erwähnten den neuen Eclipse Marketplace. Ist der Eclipse Marketplace eine Infrastrukturverbesserung, die nur den Eclipse-Foundation-Mitgliedsfirmen oder aber prinzipiell allen zur Verfügung steht? Oder anders gefragt: Generiert der Marketplace dezidiert einen Mehrwert bei einer Mitgliedschaft in der Eclipse Foundation oder ist er eine Serviceleistung für alle Player im Eclipse-Ökosystem?

Jochen Krause: Der Eclipse Marketplace steht grundsätzlich dem gesamten Ökosystem zur Verfügung. Wir sollten hier zwei Dinge unterscheiden: Den Eclipse Marketplace Client und den Eclipse.org-Katalog. Beim Eclipse.org-Katalog (marketplace.eclipse.org) haben Mitglieder Vorteile in Bezug auf die Sichtbarkeit ihrer Lösungen. Beispielsweise stammen alle „Featured Solutions“ von Mitgliedsfirmen. Der Eclipse-Katalog wird nicht nur als Webseite bereitgestellt, sondern auch im Eclipse Marketplace Client und erlaubt von dort die direkte Installation von Plug-ins in die Entwicklungsumgebung.

Der Eclipse Marketplace Client ist ein Stück Software, der mit allen Eclipse-Paketen ausgeliefert wird. Dieser Client ermöglicht den Zugriff auf einen oder mehrere Kataloge, und hier gibt es dann auch einen Mehrwert, der nur Mitgliedsfirmen vorbehalten ist. Eigene Kataloge können nämlich nur „strategische Mitglieder“ der Eclipse Foundation als Teil der Eclipse-Pakete bereitstellen. Das ist durchaus nicht nur für Distributionen interessant, sondern auch für Firmen mit einem umfangreichen Portfolio an Eclipse-basierten Werkzeugen. Der Marketplace löst für diese Mitglieder das Problem der initialen Installation, da der Zugang zu den Katalogen in den Eclipse-Downloads bereits enthalten ist.

Eclipse Magazin: Welche Entwicklungen gab es in der Helios-Version der Rich Ajax Platform [6]?

Jochen Krause: RAP hat mit Helios einen Durchbruch erzielt, der nicht auf der technischen Ebene zu suchen ist. RAP wird inzwischen nämlich von zahlreichen anderen Projekten als Infrastruktur adaptiert. EMF ist sicher das prominenteste Beispiel, aber auch Riena, Scout oder RedView sorgen mit ihrer Unterstützung von RAP für eine zweite Welle der Verbreitung.

Aber natürlich gibt es auch technisch gesehen zahlreiche interessante Neuerungen. Im Fokus stand für uns die bessere Unterstützung für das „Single Sourcing“, die Nutzung einer einheitlichen Codebasis für Desktop- und Webapplikationen. Besonders hervorheben möchte ich die neue Unterstützung für Drag and Drop, die Implementierung eines Subsets des Graphics Context, und die Einführung der Standardkonstruktoren für Ressourcen wie etwa Images, Fonts, Color und Cursor. Daneben haben sich die Möglichkeiten zum Stylen der Applikationen noch einmal deutlich verbessert. Neben abgerundeten Kanten gibt es jetzt auch Gradienten, d. h. Farbverläufe, und die Unterstützung der Einstellung der Deckkraft oder Opacity für noch mehr Oberflächenelemente. Eine Liste aller nennenswerten Neuerungen findet sich im Dokument New & Noteworthy [7].

Wer RAP schon seit Längerem nicht mehr ausprobiert hat, sollte wieder einmal einen Blick auf das Projekt werfen und testen, wie weit das „Single Sourcen“ für das eigene Projekt funktioniert.

Eclipse Magazin: Es scheint, dass das bekannte Google Web Toolkit ein ganz ähnliches Ziel wie RAP verfolgt: UIs mit Java-Mitteln bauen. Im Falle von GWT geschieht das vornehmlich auf Basis von Swing, um automatisiert Web-Frontends zu generieren. Wie unterscheidet sich der RAP-Ansatz davon oder wo liegen ggf. auch Gemeinsamkeiten?

Jochen Krause: Die Gemeinsamkeit liegt in der Verwendung von Java APIs zur Definition der Benutzerschnittstelle. Die Unterschiede liegen zum einen in der Architektur, zum anderen im Umfang der Lösungsbausteine. Mit letzterem möchte ich beginnen.

GWT liefert ein Widget Toolkit, nicht mehr und nicht weniger. Auch RAP liefert ein Widget Toolkit, dies ist aber nur ein kleiner Teil der Lösung, da RAP auch eine Applikationsinfrastruktur (RCP) mitliefert. Es ist ähnlich wie bei Swing versus SWT. Hier lässt sich lange über Sinn und Unsinn eines weiteren Widget Toolkits, über Performance und API diskutieren, ohne zu eindeutigen Ergebnissen zu kommen. Bezieht man aber die Applikationsinfrastruktur (Platform, RCP, OSGi) mit ein, sieht das Bild ganz anders aus. Wer eine lose gekoppelte, erweiterbare Präsentationsschicht braucht, und wenn das Eclipse-Workbench-Modell zu den Anforderungen der Applikation passt, dann ist man mit SWT (in Wirklichkeit aber RCP) viel näher an seinem Ziel.

Zurück zu RAP vs. GWT. Wer einen Taschenrechner im Web in Java schreiben will, ist mit GWT sicher besser bedient als mit RAP. Wer eine Applikationsplattform etablieren möchte, die sowohl auf dem Desktop als auch im Web nutzbar ist, der ist mit der Kombination von RCP und RAP im Vorteil.

Von Seite der Architektur und des Programmiermodells gibt es ebenfalls nennenswerte Unterschiede. GWT erstellt ein Kompilat des Programms, das dann auf den Browser geladen und dort lokal ausgeführt wird. Alle Datenzugriffe müssen als Remote Access ausgeführt werden. Dies eröffnet eine hohe Flexibilität und fast unendliche Skalierbarkeit, ist aber mit dem Preis einer recht hohen Komplexität verbunden. RAP wird dagegen im Kern auf dem Server ausgeführt, und nur das UI wird per AJAX an den Client transportiert und synchronisiert. Dadurch geschehen Datenzugriffe lokal auf dem Server, sind einfacher zu implementieren und inhärent sehr schnell. Auf der anderen Seite verbraucht dieses Vorgehen je Benutzer Speicher auf dem Server. Der minimale Footprint liegt bei ca. 1 MB pro Benutzer. Für die meisten Anwendungen ist dies im Verhältnis zum Speicherbedarf der Daten ein eher kleiner Anteil am gesamten Speicherbedarf – und in Zeiten von 64 Bit, Clustern und Cloud auch für eine große Benutzerzahlen eine beherrschbare Rahmenbedingung.

Eclipse Magazin: Wieder ist im Eclipse-Helios-Release eine Steigerung der Anzahl von Projekten gelungen, die ihre Entwicklungsprozesse aufeinander abstimmen. Und auch außerhalb des Helios-Release ist auffallend, dass sehr viele neue Eclipse-Projekte als Proposals eingereicht werden. Wie schätzen Sie hier die Gefahr der Kommoditisierung ein, in dem Sinne, dass eine Geschäftsidee eines Unternehmens irgendwann einmal von der Eclipse-Community oder der Foundation aufgegriffen und als quelloffenes Eclipse-Projekt weiterentwickelt wird, wodurch die ursprüngliche Geschäftsidee für das Unternehmen nicht mehr vermarktbar ist?

Jochen Krause: Es ist ein Beleg für die Vitalität und den Reifegrad des Eclipse-Ökosystems, dass immer mehr Projekte die Anforderungen für die Teilnahme am Release Train erfüllen können. Und der Nachschub an neuen Projekten zeigt, dass das „Innovationsnetzwerk“ Eclipse immer noch sehr gut funktioniert. Man muss sich natürlich fragen, ob dies negative Auswirkungen auf die Chancen hat, mit Eclipse eine Geschäftsidee umzusetzen.

Die Gefahr der Kommoditisierung hat bei Eclipse schon immer bestanden, bei so gut wie jedem Treffen des Eclipse Board of Directors, an dem ich teilgenommen habe, wurde über dieses Thema diskutiert. Aufgrund der Offenheit von Eclipse für neue Projekte und der Offenheit bestehender Projekte für neue Beteiligte gibt es keinen Schutz für die kommerziellen Interessen einzelner Mitglieder. Diesen hat es auch nie gegeben und wird es aus meiner Sicht auch nie geben, da wir sonst die Möglichkeiten zur Innovation in einem Maße beschneiden, das Eclipse ernsthaft schaden würde.

Ein vergrößertes Risiko für die erfolgreiche Etablierung eines Geschäfts auf Basis von Eclipse besteht heute aber dennoch. Der Markt für kommerzielle Entwicklungswerkzeuge ist nämlich im Schrumpfen begriffen. Daran hat auch Eclipse einen erheblichen Anteil. Die Vision, mit Eclipse eine Plattform zu verbreiten und dann Zusatznutzen in Form von Werkzeugen zu verkaufen, hat sich nicht in dem gewünschten Umfang erfüllt. Das führt zu dem Paradox, dass heute für neue Sprachen und Frameworks ein Mangel an qualitativ hochwertigen Werkzeugen entsteht, obwohl der Aufwand für deren Implementierung durch die Möglichkeiten von Eclipse wesentlich geringer geworden ist. Die heute verfügbare Unterstützung für JavaScript spricht Bände. Aus meiner Sicht entsteht hierdurch ein volkswirtschaftliches Problem. Da die Nutzer der Werkzeuge in der Regel keine finanzielle Gegenleistung für die Nutzung entrichten, sind die Anreize für Softwareentwickler, in diesen Bereich einzusteigen, gering. Wer das mit dem Markt für Apps für mobile Geräte vergleicht, wird seine eigenen Schlüsse ziehen können. Ein App-Store für Eclipse ist hier ein erster Schritt in die richtige Richtung, aber es sind darüber hinaus Anstrengungen erforderlich, neue Wege zur Finanzierung der Entwicklung von Softwarewerkzeugen zu etablieren. Wir planen hierzu unter anderem ein Programm für den Long Term Support bei Eclipse.org einzuführen, das Herstellern und großen Nutzerorganisationen Verlässlichkeit auf Basis von vertraglichen Regelungen ermöglichen wird. Das Eclipse-Ökosystem ist hier also durchaus in Bewegung und könnte neue Maßstäbe für die Interaktion zwischen Open Source und Business setzen.

[ header = Seite 3: Investitionsmangel ]

Eclipse Magazin: Im Community-Survey der Eclipse Foundation [8] wird der Trend festgestellt, dass Unternehmen zwar zunehmend Open-Source-Software nutzen, allerdings immer weniger Freiräume für Entwickler zur Verfügung stellen, um aktive Beiträge zurück in die Community zu leisten. Bedeutet das, dass Open Source zunehmend nur noch konsumiert wird und damit die klassischen Open-Source-Businessmodelle gefährdet sind?

Jochen Krause: Aus meiner Erfahrung sind Unternehmen heute dabei, den Einsatz von Open Source zu professionalisieren. Dazu kann auch gehören, dass aktive Beiträge zu Open Source untersagt werden. Das ist in vielen Fällen wahrscheinlich nicht die beste Lösung, aber Open Source ist nun einmal in der Art der Nutzung nicht einzuschränken. Auf der anderen Seite muss man festhalten, dass die unkontrollierte Nutzung von Open Source zu einem Wildwuchs führen kann, der ähnlich schwer beherrschbar ist, wie die Verbreitung von Software auf Basis von Access, Visual Basic und Excel im letzten Jahrtausend. Traditionell werden in Unternehmen zur Vermeidung von Wildwuchs bei der Infrastruktur Einkaufsprozesse und Richtlinien eingesetzt, diese Mechanismen greifen jedoch kaum noch für Open Source. Entwickler finden fast immer Mittel und Wege, Open-Source-Projekte zu nutzen.

Vor diesem Hintergrund scheint das klassische Open-Source-Geschäftsmodell „Wartung und Support“ vor einer großen Zukunft zu stehen. Damit lassen sich nämlich die Nutzung von Open Source mit den Interessen der Unternehmen symbiotisch verbinden. Idealerweise sollten sich dabei die Freiheit der Entwickler bei der Auswahl der „richtigen“ Tools und das berechtigte Interesse der Unternehmen (und des Einkaufs) an Nachhaltigkeit in einem ausgewogenen Verhältnis befinden. Hier gibt es noch einige Hausaufgaben für die Eclipse- (und andere) Open-Source-Community zu machen, um für eine Standardisierung in diesem Bereich zu sorgen.

Eclipse Magazin: Wir haben im letzten Eclipse Magazin die These formuliert, dass die Eclipse-Plattform heute im Grunde etabliert und qualitativ so hochwertig ist, dass viele Unternehmen keinen Anlass mehr sehen, große Investitionen in ihre Weiterentwicklung zu tätigen. Dies könnte sowohl den Rückzug einiger großer Tooling-Unternehmen in der Eclipse Foundation erklären als auch die Zurückhaltung der Industrie gegenüber dem Eclipse-e4-Projekt. Ist da etwas Wahres dran?

Jochen Krause: Es gibt eine Reihe neuer Trends in der Softwareindustrie, vor allem das Cloud Computing und die Bereitstellung von Softwareservices stehen hier ganz oben auf der Agenda. Der Browser als Runtime-Umgebung ist ein heiß gehandelter Kandidat als Nachfolger des klassischen Betriebssystems. Auch eine etablierte Plattform muss sich solchen Trends stellen können und kann nur dann bestehen, wenn sie einen klaren Mehrwert liefern kann. Externe Anlässe für Investitionen in Eclipse gibt es also genügend. Die Zurückhaltung scheint mir von daher eher in anderen Bereichen zu liegen. Der Zustand des Markts für Softwarewerkzeuge spielt hier sicher eine Rolle, wie oben beschrieben bestehen hier aber durchaus Einflussmöglichkeiten für Eclipse, diesen Trend umzudrehen.

Eclipse Magazin: Welche Zukunftschancen sehen Sie für das Projekt e4 bzw. Eclipse 4.0?

Jochen Krause: Ich denke, zum jetzigen Zeitpunkt ist es sehr schwierig, über die Chancen von Eclipse 4.0 konkrete Aussagen zu treffen. Das für Juli geplante Release des Eclipse SDKs 4.0 hat einen Zusatz, der „Early Adopter“ lautet. Und das Release definiert noch keine API. Es ist also immer noch ein früher Zeitpunkt im Lebenszyklus von Eclipse 4. Ich traue Eclipse 4 aber durchaus zu, in den nächsten Jahren einen signifikanten Anteil der Eclipse-Entwickler zu gewinnen, denn es bringt interessante neue Konzepte und kann die Implementierung von Plug-ins an vielen Stellen einfacher und konsistenter machen. Wir haben Eclipse 4 von Anfang an als Parallelentwicklung zu 3.x positioniert, ähnlich Apache Webserver 1.x und 2.x. Der Marktanteil von Apache 2 hat sich nur langsam entwickelt, aber nach inzwischen zehn Jahren spielt Apache 1.3 nur noch eine untergeordnete Rolle. Diese Entwicklung erwarte ich auch bei Eclipse. Es könnte durchaus passieren, dass mit Eclipse 4.0 noch nicht der große Durchbruch gelingt, oder dass es eine Spanne an Jahren braucht, bis der Anteil der Nutzer von 4.x den von 3.x übersteigt. Aber in einigen Jahren wird es soweit sein, und der überwiegende Teil der Nutzer wird mit 4.0 oder 4.2 oder 5.0 noch zufriedener sein als heute mit Eclipse 3.x.

Eclipse Magazin: Jahreswenden sind nun auch immer Anlässe, nach vorne zu blicken: Welche Herausforderungen sehen Sie für die Eclipse-Community und die Foundation im kommenden Release Train „Indigo“?

Jochen Krause: Mit Indigo stehen wir vor einer Reihe von Herausforderungen. Wir müssen dafür sorgen, dass wir im Bereich Runtime eine umfangreiche, verlässliche und leicht konsumierbare Plattform bereitstellen. Darüber hinaus müssen wir die aktuellen Java-Entwicklungen durch geeignete Werkzeuge unterstützen. Bei der Vielzahl der Projekte lassen sich allerdings kaum noch einzelne technische Ziele definieren, ohne Gefahr zu laufen, in die Beliebigkeit abzudriften. Wir sollten uns auf unsere Stärken besinnen und das Innovationsnetzwerk rund um Eclipse weiter ausbauen. Eclipse hat seit seiner Gründung neben der technischen Exzellenz eine Vorreiterrolle bei der Kombination von Open Source und kommerziellen Interessen eingenommen. Diese Rolle muss teilweise an die neuen Gegebenheiten angepasst werden. Die neuen Programme „Eclipse Marketplace“ und „Long Term Support“ sind bereits wichtige Schritte auf diesem Weg.

Darüber hinaus gibt es noch die Herausforderung der Eclipse.org-Webssite. Sie ist nach wie vor schwer navigierbar und bietet keine konsolidierte Suche über alle Inhalte aus verschiedenen Quellen wie Bugzilla, News, Wiki und Webseite. Die Eclipse-RAP- und Xtext-Webseiten halte ich für wegweisend, was den Aufbau und die Navigation angeht. Wir sollten die weitere Verbreitung dieses Konzepts bei Eclipse.org forcieren und eine bessere Infrastruktur für die Suche bereitstellen. Diese Dinge mögen auf den ersten Blick nebensächlich erscheinen, sind für die weitere Verbreitung von Eclipse aber nicht zu unterschätzen.

Auch wenn der Hype um Eclipse etwas nachgelassen hat, ist Eclipse eine beeindruckende und einzigartige Umgebung, die auch in Zukunft noch viele Erfolge – z.B. mit Indigo – erzielen wird.

Eclipse Magazin: Vielen Dank für dieses Gespräch!

Jochen Krause ist Gründer und CEO von EclipseSource, Gründungsmitglied der Eclipse Foundation und in verschiedenen Rollen seit 2002 in der Eclipse-Community aktiv. Er hält einen Sitz im Board of Directors der Eclipse Foundation, ist Co-Lead der EclipseRT- und RAP-Projekte sowie Mitglied im Eclipse Architecture Council und Mentor mehrerer Eclipse-Projekte. Seine Interessen liegen in Softwareplattformen und in der nachhaltigen Verbindung von Open Source und Business.
Kommentare

Schreibe einen Kommentar

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