Ed Merks: „Nur echte Entwickler, die echten Code schreiben, lösen Probleme“ - JAXenter


EMF-Lead Ed Merks im Gespräch mit dem Eclipse Magazin

Ed Merks: „Nur echte Entwickler, die echten Code schreiben, lösen Probleme“

Sebastian Meyen

Ein Gespräch über das Eclipse Modeling Framework, die Perspektiven von Modellierung jenseits der Softwareentwicklung, die Zusammenarbeit mit Microsoft sowie über das Verhältnis von Modellierung und Code.

Eclipse Magazin: Ed, du bist der Leiter des Eclipse Modeling Framework (EMF) und des Eclipse Modeling Projekts. Was genau ist Deine Rolle in diesem Kontext und was ist der Unterschied zwischen den beiden Projekten?

Ed Merks: Das Eclipse Modeling Framew

ork ist ein Unterprojekt des Eclipse Modeling Toplevel-Projekts. EMF wird seit 2002 bei Eclipse gehosted und war vorher Teil des Toplevel-Projekts Tools. Ich war von Anfang an der technische Leiter von EMF. In dieser Rolle bin ich ein Committer und habe z.B. Zugriff auf das CVS-Repository, um für EMF Änderungen vorzunehmen. Außerdem habe ich den Überblick über die Aktivitäten aller anderen EMF-Committer.

EMF wird von einer großen und weiterhin wachsenden Zahl anderer Projekte bei Eclipse genutzt, beispielsweise von XML Schema Definition (XSD), von Unified Modeling Language (UML) und von dem Web Tools Project (WTP). Deshalb ist es wichtig, sich auf Qualität und Stabilität zu konzentrieren, wenn wir an Erweiterungen arbeiten, die EMF noch flexibler und effizienter machen sollen. Im Laufe der Zeit entstanden verwandte Projekte wie das Graphic Modeling Framework (GMF) und das Generative-Modeling-Tools- (GMT-)Projekt, und es wurde schnell klar, dass ein übergeordnetes Toplevel-Modeling-Projekt wichtig sein würde, um all diese verwandten Unterprojekte überblicken zu können. Rich Gronback von Borland und ich, damals bei IBM beschäftigt, wurden die Co-Leiter (PMC – Project Management Committe) des neuen Dachprojekts. Man kann sich das Modeling-Projekt als Zwiebel mit vielen Schalen vorstellen, wobei EMF das Kernstück bildet.

In der Rolle des PMC-Leiters nahmen Rich und ich am Eclipse Architecture Council und dem Eclipse Planning Council teil. Wir veranstalteten monatlich offene Treffen mit anderen Modeling-Projektleitern, um Themen zu diskutieren, die alle unsere Projekte betrafen, und um verschiedene Arbeiten des Projektmanagements durchzuführen. Die Rolle des EMF-Leiters ist vorwiegend eine technische Rolle, während die des PMC-Leiters vorwiegend das Management betrifft. Ich bin außerdem gewählter Committer Representative im Eclipse Board of Directors und habe als solcher Einfluss auf viele Aktivitäten bei Eclipse, angefangen bei den technischen Details von EMF bis hin zu den großen Richtungsentscheidungen der Eclipse Foundation. Es ist wirklich spannend, bei Eclipse zu sein, und ich finde es toll, dass ich hier als Einzelperson all diese Rollen innehaben kann. Auch als ich IBM nach 16 Jahren verlassen habe und begann, eng mit den innovativen Leuten bei itemis zusammenzuarbeiten, hat sich an meiner Rolle bei Eclipse nichts geändert.

Eclipse Magazin: Du hast das jetzt schon eine sehr lange Zeit gemacht und mit jedem Jahr ist EMF noch erfolgreicher geworden. Was denkst du, ist EMFs Schlüssel zum Erfolg?

Ed Merks: EMF begann intern bei IBM als Implementierung der von der Object Management Group (OMG) entwickelten Meta-Object-Facility- (MOF-)Spezifikation. EMF sollte in IBM-Projekten genutzt werden um sicherzustellen, dass eine große Zahl von geografisch verstreuten Teams eine integrierte und geschlossene Sammlung von miteinander verknüpften Modellen entwickeln würde. Natürlich war es ein langer Weg bis dorthin, denn das MOF-Modell war sehr groß und komplex und die Code Generation Patterns sollten generierten und handgeschriebenen Code sauber auseinanderhalten. Sie erzeugten deshalb riesige Mengen an kompliziertem Code, der völlig anders aussah als das, was jemand mit einem sauberen, handgeschriebenen Design produzieren würde. EMF wurde also im Großen und Ganzen als komplex, aufgeblasen und schwerfällig wahrgenommen, sodass die Kunden immer unglücklicher damit wurden.

Frank Budinsky und ich wurden damit beauftragt, klaren Tisch zu machen. Wir haben das MOF-Meta-Modell, d.h. Ecore, drastisch vereinfacht und haben die Runtime mit einem geradezu manischen Fokus auf Einfachheit und Performance neu geschrieben. Auch die Generator Patterns haben wir überarbeitet, um einfachen, sauberen Code zu erhalten, der Merging unterstützt, damit die Kunden bedenkenlos generierten und handgeschriebenen Code mischen konnten. Unsere Ecore-Vereinfachungen führten letztlich zu einer Aufspaltung von MOF in Essential MOF (EMOF) und Complete MOF (CMOF). Ecore ist tatsächlich isomorph zu EMOF, sodass wir Standard-EMOF-Serialisierungen schreiben und lesen können. Der Runtime Jar Footprint wurde um zwei Drittel reduziert, und die Performance des generierten Codes war wohl optimal.

Beispielsweise ist die reflektive Suche nach dem Wert eines Objekt-Features schneller als eine Hash-Map-Suche. All das zeigt uns, dass Flexibilität, Qualität und Performance die entscheidenden Ausgangspunkte auf dem Weg zum Erfolg sind. Die Arbeit an EMF im Kontext einer überwiegend negativen Wahrnehmung zu beginnen, die ja teilweise auch gerechtfertigt war, hat die Sache natürlich zu einer noch größeren Herausforderung werden lassen. Menschen ändern ihre Wahrnehmung nicht so schnell, nicht einmal, wenn sich vor ihren Augen drastische Veränderungen abspielen. Es ist einfach, einen guten Ruf zu ruinieren, aber sehr schwierig, ihn wieder herzustellen. Wenn man eine Basisinfrastruktur bereitstellt, wird man auch sehr schnell zum Sündenbock für schlechte Designs gemacht, die auf der Infrastruktur aufbauen. Beispielsweise wird ein Design mit Listen, die eine Million Elemente enthalten, keine gute Performance aufweisen, egal ob man EMF benutzt oder nicht.

Leider ist es so, dass es bezüglich Modeling im Allgemeinen viele Missverständnisse gibt. Es hat viele Jahre gedauert, mehr Leute von den Vorteilen zu überzeugen, und es scheint so, als würde diese Aufgabe niemals enden. Die zurückliegenden Herausforderungen bewältigt zu haben, hat mich auf jeden Fall stärker gemacht: Probleme werden einfach aus dem Weg geräumt. Mit anderen Worten: Stößt man auf ein Hindernis, ist es wichtig, Entschlossenheit zu zeigen, will man auf dem Weg des Erfolgs bleiben. Vielleicht ist das Hindernis sogar nötig für den Erfolg. Zeige den Leuten, die behaupten, etwas ließe sich nicht machen, dass es doch geht. Eigentlich sagen sie nur, dass sie nicht wissen, wie sie etwas machen sollen – also musst du es ihnen zeigen.

Und zu guter Letzt: Unterschätze niemals die Kraft deiner Community! Höre den Leuten gut zu und lerne von ihnen – dein Erfolg ist eng mit dem ihrigen verbunden. Höre aufmerksam ihren Problemen zu und nutze ihre kollektive Stimme als Leitfaden für deine Bemühungen. Vergiss aber trotz allem nicht, dass du die Community leitest und nicht umgekehrt – es bringt nichts, sich mit jeder Kleinigkeit zu beschäftigen. Zeige Entschlossenheit durch deine Taten. Mache es zur obersten Priorität, Bugs schnell zu beheben. Die Art, wie du deine Kommunikationswege gestaltest, wird immer auf dich persönlich und generell auf dein Projekt zurückwirken. Beim Eclipse Summit Europe sagten mir einige Ph.D.-Studenten aus München: „Wenn wir zur EMF-Newsgroup kommen und du unsere Fragen beantwortest, wissen wir, dass du dich um unsere Probleme kümmerst, aber wenn wir zu einer anderen Newsgroup gehen und keine Antwort erhalten, fühlen wir uns einfach nicht willkommen.“ Die Wahrnehmung ist die Realität.

[ header = Seite 2 ]

Eclipse Magazin: Aus der Perspektive der Softwareentwicklung geht es beim Modeling immer um modellgetriebene Softwareentwicklung. Kennst du vielleicht interessante oder vielleicht auch „exotische“ Projekte aus der Industrie oder aus der akademischen Forschung, die Eclipse-Modeling-Technologien nutzen, aber nichts mit Softwareentwicklung zu tun haben?

Ed Merks: Ein interessantes Beispiel, das mir einfällt, ist Daniel Ford mit seiner Arbeit in der IBM-Forschung am Spatiotemporal Epidemiological Modeler (STEM). STEM nutzt EMF, um verschiedene Faktoren zu modellieren, die bei der Ausbreitung von Krankheiten beteiligt sind, z.B. das Wetter oder Verkehrsmuster, Inkubationszeiten, Infektionsraten und so weiter. Diese Modelle werden dann zusammengesetzt, um die wahrscheinliche Ausbreitung einiger hypothetischer Krankheitsereignisse zu simulieren. Entscheidungsträger können STEM einsetzen, um sich auf Ereignisse wie eine globale Grippeepidemie oder Terroranschläge mit biologischen Waffen vorzubereiten. EMF hilft nicht nur, Software effektiver zu entwickeln, sondern sogar um Krankheiten vorzubeugen und die Welt sicherer zu machen. Fehlt nur noch, dass es mir hilft, meinen Garten zu jäten!

Eclipse Magazin: Vor ein paar Jahren gab es diese große Vision der „Model Driven Architecture“, angetrieben von der OMG und der Software-Tools-Industrie. Die Idee basierte auf dem starken Glauben, dass es möglich sei, ein vollständiges Softwaresystem auf einem hochabstrakten Level zu entwickeln, um dann quasi per Knopfdruck alle relevanten technischen Artefakte abzuleiten. Warum ist diese Vision fehlgeschlagen?

Ed Merks: Vielleicht ist sie gar nicht fehlgeschlagen und wir sind tatsächlich noch immer auf dem Weg dorthin. Ich glaube durchaus, dass MDA viel zu früh viel zu viel versprochen hat, und ich mache diesen unangemessenen Hype verantwortlich für viele der Missverständnisse, die die Zukunft des Modeling betreffen. Eclipse-Modeling war erfolgreich, weil wir uns darauf konzentriert haben, klein anzufangen, aber dabei Großes zu planen. Wir haben als Kernstück ein solides Metamodell gebaut – Ecore ist die De-facto-Referenzimplementierung von EMOF – und haben dann eine Reihe von darüberliegenden Modellen entwickelt wie UML, XSD, OCL, BPMN.

Wenn man darüber nachdenkt, taucht vieles aus der OMG-Landschaft allmählich bei Eclipse auf. Vielleicht schaut die OMG auf Eclipse und betrachtet Eclipse als Beweis des Erfolgs ihrer Vision. Ich würde das nicht bestreiten, obwohl ich persönlich denke, dass es noch lange Zeit nötig sein wird, Programme in universellen Programmiersprachen zu schreiben. Ich sehe das Modeling eher als Ergänzung. Wenn wir damit weitermachen, bessere Abstraktionsmöglichkeiten zu finden, werden Domain Specific Languages (DSLs) immer attraktiver werden. Aber ich glaube nicht, dass es so wichtig ist vorauszusehen, wo wir am Ende stehen werden. Stattdessen sollten wir uns darauf konzentrieren, kleine Schritte in die richtige Richtung zu machen.

Eclipse Magazin: Wie schätzt du die heutige Rolle der OMG und ihrer Modeling-Standards ein?

Ed Merks: Ich denke, die OMG muss nach vorne schauen. Die Welt verändert sich schnell. Open Source entwickelt eine große Kraft und die Personen, die Open Source vorantreiben, werden mehr Einfluss haben als erwartet. Referenzimplementierungen sagen mehr als Worte. Sie sind übrigens auch „grüner“, d.h. sie fällen viel weniger Bäume, weil niemand in Versuchung gerät, sie auf Papier zu drucken. Standardisierte Apparate tappen nur allzu leicht in die Falle, sich zu sehr mit politischen Bemühungen von Komitees, die voller Kompromisse sind, auseinanderzusetzen und letztendlich nur Kompromisslösungen zu produzieren. Schlimmstenfalls können Standards zur Waffe gegen Innovationen werden, indem die kleinen, agilen Mitspieler ausgeschlossen werden und Mittelmäßigkeit produziert wird. Standards sollten darauf konzentriert sein, Best Practices festzulegen. Meiner Meinung nach ist Open Source das Werkzeug, innovative Best Practices zu etablieren und die Zuverlässigkeit und Effizienz der entwickelten Standards zu demonstrieren.

Eclipse Magazin: Es scheint, dass Innovation im Modeling-Umfeld nun von Projekten vorangetrieben wird, die echten Code abliefern, so wie z.B. EMF, und nicht von Organisationen, die sich um Standards kümmern. Siehst du eine generelle Verlagerung von Spezifikationen zu Code?

Ed Merks: Ja, das ist genau der Punkt. Genauso wie es das Pferd ist, das den Karren zieht, kommt zuerst die Innovation und dann folgen die Standards. Bei einem Treffen mit Leuten, die daran interessiert waren, eine Industry Vertical Working Group bei Eclipse aufzubauen, schlug ich vor, sich darauf zu konzentrieren, eine lebendige, funktionierende Referenzimplementierung zu bauen, um einen De-facto-Standard zu etablieren. Dafür sollten sie lieber ihre fähigsten Softwareingenieure schicken als ihre besten politischen Ingenieure. Echte Entwickler, die echten Code schreiben, werden sich auf echte Probleme konzentrieren und diese wirklich lösen. Was dringend nötig ist, ist ein Realitäts-Check.

Eclipse Magazin: Kürzlich ist Microsoft der OMG beigetreten. Gleichzeitig investieren die Redmonder in irgendetwas namens „Oslo“, das sehr wie die .NET-Version von Eclipse Modeling aussieht. Was hältst du von diesen Initiativen? Wie kann Oslo EMF beeinflussen oder umgekehrt?

Ed Merks: Ich warte immer noch darauf, mit diesen Leuten von Microsoft wie Don Box und Douglas Purdy eine Diskussion zu beginnen. Auf dem Eclipse Summit Europe hatte ich das Glück, Steve Sfartz zu treffen, der mich anschließend beim MD-Day in Paris Jean-Marc Prieur vorstellte. Jean-Marc und ich haben die Gelegenheit genutzt, uns über unser gemeinsames Interesse an Modeling zu unterhalten, und er demonstrierte mir ausführlich Microsofts grafische DSL-Technologie. Die Bemühungen von Microsoft und Eclipse möchte ich wie folgt vergleichen: Microsofts grafische DSL-Technologie ist das Gegenstück von generierten EMF-Modellen, angereichert durch GMF. So wie ich es verstehe, existiert das Microsoft Domain Metamodell nur in Development Time, nicht in Runtime, also gibt es keinen Reflection Support wie bei MOF. Microsofts textuelle DSL-Technologie ist das Gegenstück von Xtext (d.h. MGrammar), Ecore (d.h. MSchema) und EObject (d.h. MGraph). Während wir also bei Eclipse Ecore/EMOF als das allgemeine, standardbasierte Metamodell bieten, um sowohl grafische als auch textuelle DSLs zu unterstützen und deshalb modellbasierte abstrakte Reflection für alle Domainmodelle bereitstellen, gibt es bei Microsoft zwei verschiedene Technologien, um diese beiden eng miteinander verbundenen Aspekte abzudecken. Ich bin davon überzeugt, dass Eclipse so mit einer soliden technischen Grundlage ausgestattet ist, die nur schwer zu schlagen ist.

Letztendlich ist der Erfolg der Modellierung eines meiner persönlichen Ziele, sodass ich sehr glücklich wäre, wenn Microsofts Anstrengungen von Erfolg gekrönt wären. Ich glaube, das würde helfen, die Aufmerksamkeit des amerikanischen Marktes wieder mehr auf das Modeling zu lenken. Jetzt schon stellen Analysten Fragen nach der etablierten Eclipse-Technologie, wenn sie mit Reviews über Microsofts neuste Entwicklungen beginnen. Viele von uns glauben fest daran, dass Modeling eine Schlüsseltechnologie ist, um die Softwareindustrie vorwärts zu bringen. Also sollten diejenigen von uns, die diese Vision teilen, zusammenarbeiten.

[ header = Seite 3 ]

Eclipse Magazin: Wenn wir heute über modellgetriebene Softwareentwicklung sprechen, geht es stets vor allem um pragmatische Ansätze. Wie können Leute lernen, wann MDSD Sinn macht und wann nicht?

Ed Merks: Es ist definitiv wie bei dieser alten Weisheit: Man sollte für jede Aufgabe das richtige Werkzeug benutzen! Ich hätte Schwierigkeiten, mir etwas wirklich Wichtiges vorzustellen, bei dem Modeling nicht wenigstens eine kleine Rolle spielen würde. Ich sage das nicht, weil ich ein Fanatiker bin – obwohl einige da wohl nicht zustimmen würden –, sondern weil alle Daten modelliert werden können, ich würde sogar sagen: sollten. Aus der Tatsache, dass die meiste Software es mit Datenmanipulation zu tun hat, folgt, dass Modelle überall eine wichtige Rolle spielen. Wenn Praktiker Erfahrungen durch die ihnen zur Verfügung stehenden Werkzeuge und Technologien sammeln, lernen sie, diese immer effektiver einzusetzen. Es ist besser, etwas zu versuchen und aus den gemachten Fehlern zu lernen, als niemals einen Versuch zu starten. Durch unsere Fehler lernen wir genauso viel wie durch unsere Erfolge.

Eclipse Magazin: Was die Produktivität in der Softwareentwicklung angeht, sehen wir momentan einen großen Trend in Richtung textueller Domain Specific Languages. Wie verhalten sich deiner Meinung nach DSLs und die Welt der Modelle zueinander?

Ed Merks: Ich sehe nur Modelle! Auf dem Eclipse Summit Europe konzentrierte sich Dave Thomas in seiner provokativen Keynote auf viele Dinge, die er als technologische Barrieren ansieht, die unsere Industrie ausbremsen würden. Beispielsweise schimpfte er über die Komplexität des Modeling und die Schrecken des Meta-Meta-Nonsens, und er sprach auch über DSLs als den Schlüsseltechnologien, die uns in eine „Schöne Neue Welt“ führen würden. Ich fand das unangebracht, deshalb fragte ich ihn anschließend: „Was ist der Unterschied zwischen einem Modell und einer DSL?“ Er antwortete: „Sie sind das Gleiche.“ Verflixt, ich dachte, ich hätte ihn in die Falle gelockt, aber er ist zu schlau für mich!

Ich erinnere mich, dass mir vor ein paar Jahren jemand bei IBM sagte: „Ecore ist keine Sprache, sondern nur ein Modell.“ Ich war verblüfft und fragte deshalb: „Warum ist Ecore keine Sprache?“ Man sagte mir: „Weil es keine konkrete Syntax hat, und die XML-Serialisierung zählt nicht.“ Er nahm meine nächste Frage vorweg! Nach dieser Argumentation wäre Ecore also eine Sprache, sobald Chris Daly die Emfatic Syntax für Ecore definieren würde. Das scheint mir ein ziemlich oberflächlicher Standpunkt zu sein.

Auf dem MD-Day gab ich den Kommentar ab, dass XML eine sehr dürftige Entschuldigung für eine menschenlesbare Syntax sei und deshalb nichts tauge. XML sei großartig für den maschinellen Austausch und es sei großartig, dass Entwickler das Schreiben von Lexern und Parsern vermeiden könnten. Aber wir sollten nicht das menschliche Element in all dem vergessen! Die Leute applaudierten, ich bin also offenbar nicht der einzige, der so denkt. Deshalb bin ich so froh, Projekte wie Xtext und Oslos MGrammar auftauchen zu sehen und ich kann nur hoffen, dass wir uns von dem nuklearen XML-Winter entfernen, der diesen Planeten heimgesucht hat. Wir sollten das Ziel verfolgen, Menschen zufriedenzustellen, nicht Maschinen.

Ich liebe Sprachen sehr, das habe ich immer getan. Ich liebe auch XML, aber ich denke, es ist fast zu Tode geliebt worden. Ich bin davon überzeugt, dass Modeling-Technologien wie Xtext uns helfen werden, schnell all die spezialisierten Sprachen zu entwerfen, die wir brauchen.

Eclipse Magazin: Was sind die größten ungelösten Probleme, denen sich die Modeling Community stellen muss?

Ed Merks: Probleme? Wir haben keine Probleme. Naja, das größte Problem, das ich konkret sehe, ist das ganze Thema rund um die Skalierbarkeit. Natürlich packen die Leute immer mehr Daten in ihre wunderschönen Modelle, wenn sie über klare, einfache APIs für den Datenzugriff verfügen. Und natürlich ist es immer möglich, so viele Daten zu verwenden, dass schließlich der Platz dafür nicht mehr ausreicht. Deshalb suchen wir nach Wegen, den Speicherverbrauch zu reduzieren. Aber natürlich kann man jeden Speicher mit zu vielen Daten überlasten, wenn man den Footprint nicht bis auf null Byte reduziert. Auf diesem Gebiet könnten einige spannende Technologien wie Connected Data Objects (CDO) eine wichtige Rolle spielen. Mit CDO verhält sich ein Objekt wie eine Fassade, und der Datenzugriff wird an ein Hintergund-System delegiert, das typischerweise auf einem Server liegt und verantwortlich dafür ist, die Daten zu verwalten. Die Fassaden-Objekte tragen keine festen Objektreferenzen und landen im Papierkorb, wenn die Applikation nicht länger auf sie referenziert. Eike Stepper hat ein großartiges Blog geschrieben mit dem Titel „How Scalable are my Models„, das wirklich lesenswert ist.

Am erfreulichsten finde ich, dass es für all die ungelösten Probleme Leute gibt, die aktiv an Lösungen arbeiten. Die Eclipse-Community ist ein Ort, an dem sich etwas bewegt, und es ist ein großes Privileg, ein kleiner Teil davon zu sein. Letztendlich ist eines der größten ungelösten Probleme nicht einmal ein technologisches, sondern ein soziologisches, nämlich die überall vorhandenen Missverständnisse bezüglich Modeling.

Eclipse Magazin: Hast du eine Vision, wie Modelle und Code künftig zusammenarbeiten könnten?

Ed Merks: Ich glaube, die Zukunft ist hier und jetzt. Schau dir Eclipse an und was Leute dort mit Modellieren und Kodieren vollbringen. Sie mischen generierten und handgeschriebenen Code, weil der Generator von EMF Merging unterstützt. Entwickler können, wenn nötig, zwischen Modellieren und Kodieren hin und her wechseln, deshalb profitieren sie von beidem gleichermaßen. Schau dir auch die Arbeit an, die in DSLs gesteckt wird und erinnere dich an die frühere Diskussion darüber, ob DSLs Modelle seien. Modellieren ist Kodieren, und mit den DSLs verschwimmt die Grenze zwischen beidem weiter.

Oder betrachte folgendes Beispiel: Wenn ich ein Interface X mit einer getY-Methode in Java schreibe, ist es klar, dass ich kodiere. Aber wenn ich eine EMF-Klasse X mit einem Feature Y entwerfe, kann man da wirklich sagen, dass ich nicht kodiere? Für mich ist das dasselbe. Die Trennlinie zwischen Modellieren und Kodieren besteht nur zum Schein und verschwindet bei näherer Betrachtung.

Was uns heute am meisten fehlt, ist ein komplettes Repertoire von High-End-Modellierungs-Tools. Die Java Development Tools (JDT) von Eclipse setzen einen extrem hohen Standard für produktives Kodieren in Java. Das ist die Benchmark, die Modellierungstechnologien erreichen müssen, um die gestiegenen Erwartungen der Entwickler-Community zu erfüllen. Zum Beispiel sind Dinge wie eine automatisierte Unterstützung des Refactorings von Ecore-Modellen, welche die Wirkung auf den generierten Code berücksichtigt und so das Java-Refactoring als integrierten Aspekt des allgemeinen Refactorings behandelt, wichtig für das Erstellen richtig großer modellbasierter Projekte.

Oft richtet sich die Kritik an der Modellierungstechnologie weniger auf das Modellieren selbst, sondern auf die ungeeigneten Tools zur Unterstützung des Modeling. Doch Not macht erfinderisch, und so bin ich überzeugt, dass auch diese bald kommen werden. Wenn du dir die Community anschaust, die sich rund um Eclipse entwickelt – die großen und kleinen Organisationen, die Individuen, die Forscher – dann ist klar, dass wir alle den Weg bereiten für eine produktivere Zukunft.

Eclipse Magazin: Ed, nach so vielen Jahren Arbeit in Open-Source-Projekten und im Modeling-Umfeld: Was hast du persönlich daraus gelernt?

Ed Merks: Ich habe gelernt, dass ich nicht nur ein abgefahrener Freak bin, der in seiner kleinen Ecke bleiben und sich hinter seinem großen Monitor verstecken muss, weil Programmieren das ist, was er am besten kann. Es hat sich gezeigt, dass ich erstaunlich viele Dinge ganz gut kann. Ich habe gelernt, wie befriedigend es ist, mit anderen zu arbeiten, und besonders, dass sich der Erfolg anderer so anfühlt wie mein eigener, wenn ich in irgendeiner Weise behilflich sein konnte. Ich habe gelernt, dass es am besten ist, sich nicht selbst zu unterschätzen – das machen andere schon sehr gerne für mich. Und ich habe gelernt, dass ich mich immer in die richtige Richtung bewege, wenn ich das tue, was ich denke, wenn ich mich auf meinen eigenen Weg konzentriere, geleitet von der Stimme der Community.

Eclipse Magazin: Ed, wir danken dir für das Gespräch.

Die Fragen stellten Sven Efftinge und Sebastian Meyen.

Ed Merks ist Projektleiter des Eclipse Modeling Projects sowie des Eclipse Modeling Frameworks. Nach Tätigkeiten bei IBM und im IBM Rational Toronto Lab ist er zurzeit bei der itemis AG engagiert. Ed Merks ist Absolvent der Simon Fraser Universität und Doktor der Informatik.
Geschrieben von
Sebastian Meyen
Sebastian Meyen
Sebastian Meyen ist Chefredakteur des Java Magazins sowie des Eclipse Magazins. Außerdem trägt er die Verantwortung für Programm und Konzept sämtlicher JAX-Konferenzen weltweit. Er begleitet so die Java-Community journalistisch schon fast seit ihren Anfängen. Bevor er zur Software & Support Media GmbH kam, studierte er Philosophie in Frankfurt.
Kommentare

Schreibe einen Kommentar

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