Eclipse & Academia: Ein Gespräch mit Stephan Herrmann

Man sollte früh den Spirit der Community einatmen

In der Serie Eclipse & Academia berichten Projektleiter an deutschsprachigen Universitäten von ihren universitären Eclipse-Projekten und der Herausforderung, den Übergang vom rein akademischen Projekt hin zum kommerziell vermarktbaren Produkt zu schaffen. Stephan Herrmann, Entwickler des Modularisierungsprojektes Object Teams an der TU Berlin, spricht über die Wichtigkeit des Community Spirits und über Unterschiede bei der Auffassung darüber, was Innovation ausmacht.

JAXenter: Hallo Herr Herrmann! Wie wird Eclipse an Ihrer Universität eingesetzt?

Stephan Herrmann: Mir ist es wichtig, hier zu unterscheiden, ob Eclipse als IDE in der Lehre eingesetzt wird oder ob Eclipse als Plattform für Werkzeugentwicklung in Forschungsprojekten genutzt wird.

Sehr viele Lehrveranstaltungen überlassen die Wahl der Werkzeuge den Studierenden, die darauf reagieren, indem sie selbstorganisierte Kurse zu Eclipse durchführen. Geht dann doch mal ein Dozent auf Eclipse ein, sind die Studierenden i.d.R. dankbar und sehr interessiert.

Bzgl. der Forschung bekommt man insbesondere auf Konferenzen mit, dass wirklich sehr viele Werkzeugprototypen als Eclipse Plug-ins entwickelt werden. Jedoch überwiegt in der Diskussion die thematische Arbeit, so dass Eclipse-bezogene Gemeinsamkeiten nicht in der großen Öffentlichkeit, sondern eher in der Konferenzpause beim Kaffee besprochen werden.

Genau genommen gibt es noch eine dritte Sparte: die Gruppe von Forschungsprojekten, die die Eclipse-Codebasis als Fallstudie benutzen, z.B. um neue Codeanalysen auszuprobieren.

In allen drei Sparten ist Eclipse sehr präsent.

JAXenter: Was charakterisiert Ihr eigenes Eclipse-basiertes Universitätsprojekt?

Stephan Herrmann: Das Object-Teams-Projekt begann etwa 2002 mit einigen Diplomarbeiten, wurde von 2003-2006 durch das BMBF gefördert und ist seit 2010 offizielles Eclipse-Projekt. In diesem Projekt haben wir quer durch alle Schichten die objekt-orientierte Softwareentwicklung „modernisiert“: Die Sprache OT/J ergänzt Java um Konzepte wie Rollen usw. Das Object Teams Development Tooling ergänzt Eclipse JDT derart, dass alle Sichten und Funktionen von JDT nun intelligent mit OT/J umgehen können, und OT/Equinox erweitert das Komponentenframework Equinox um die Möglichkeit, Bundles/Plug-ins mit OT/J zu entwickeln.

Als solches steht das Object-Teams-Projekt mit vielen anderen Eclipse-Projekten in zum Teil enger Beziehung. Es ist unsere besondere Situation, dass wir unsere eigene Technik (OT/Equinox) nutzen, um existierende Plug-ins zu adaptieren. Ich bin überzeugt, dass dieser Ansatz auch für andere Forschungsprojekte sehr interessant ist, da somit neue Konzepte viel schneller in eine vorzügliche IDE integriert werden können, als es mit anderen Mitteln möglich wäre.

JAXenter: Welche Hürden gibt es auf dem Weg vom akademischen Projekt hin zum regulären Eclipse-Projekt?

Stephan Herrmann: Auf diesem Weg sind natürlich einige Qualitäten gefragt, die im Forschungsalltag kaum berücksichtigt werden. Wer z.B. viel Mühe in sein Buildmanagement investiert, dem fehlt diese Zeit für Veröffentlichungen etc. Kurz gesagt sind Forschungsprojekte oft auf eine kurze Lebensdauer, in der Größenordnung der Förderungsdauer, konzipiert. Damit ist alles, was der Nachhaltigkeit dient, oft dem Idealismus und persönlichem Einsatz der Forscher anheim gestellt.

Eine wissenschaftliche Karriere wird nicht durch ordentliches Versionsmanagement, gewissenhaftes Bugtracking etc. gewonnen. Und die wenigsten denken während des Forschungsprojektes an Lizenzheader und Urheberschaftsbescheinigungen.

Für kleine Projekte mag es möglich sein, diese Dinge nachzuziehen, aber je größer das Projekt, um so geringer die Chance, dass allein eine prototypische Codebasis in ein nachhaltiges Projekt überführt werden kann. Aber vielleicht noch wichtiger als das Vorhandensein der Projektinfrastruktur und -dokumentation ist die Vernetzung mit der Eclipse-Community: Je mehr andere Eclipse-Entwickler merken, dass ein Projekt sich konstruktiv einmischt – in Bugzilla, Foren etc. -, um so größer natürlich auch die Hilfsbereitschaft dieser Entwickler, Fragen zu beantworten und Bugs zu fixen, sprich mit dem neuen Projekt zusammenzuarbeiten. Wer damit liebäugelt, sein Projekt bei Eclipse zu etablieren, der sollte also so früh wie möglich den Spirit der Community einatmen und verinnerlichen.

JAXenter: Wie können Eclipse Community und Eclipse Foundation hier helfen?

Stephan Herrmann: Sobald man mit Community und Foundation ins Gespräch kommt, bekommt man Hilfestellung (fast) jeglicher Art. Es mag nicht immer offensichtlich sein, von wem man welche Hilfe bekommen kann, aber dafür hat jedes neue Projekt mindestens zwei Mentoren, die teilweise sehr eifrig als Vermittler arbeiten. Die Community (d.h. wir alle) darf nur nicht locker lassen, die Informationen, die ein Projekt in dieser Phase braucht, beständig zu verbessern.

Im Falle von Object Teams wäre der Projektstart um einige Wochen schneller gegangen, wenn wir die Dokumente zur Urheberschaft des Quelltextes bereits parallel zur Entwicklung gesammelt hätten. Damit dies möglich ist, sollte die Foundation irgendeine Art von Anleitung (z.B. ein Template) veröffentlichen, wie solche Dokumente aussehen müssen. Ich denke, diese Anregung ist bei der Foundation bereits auf offene Ohren gestoßen.

Ein anderer Punkt, wie die Eclipse Foundation weiter auf akademische Projekte zugehen kann, wäre ein spezieller Track auf ihren Konferenzen: Da dort naturgemäß diejenigen Projekte bevorzugt werden, die bereits in aller Munde sind, hat ein sehr innovatives akademisches Projekt hier Schwierigkeit, das Programmkomitee zu überzeugen. Ein spezieller Track mit etwas anderen Auswahlkriterien kann diesen Projekten helfen, die Öffentlichkeit zu bekommen, die für den Absprung aus der akademischen Nische so wichtig ist. Ich habe dies bereits mit dem Program-Chair der nächsten EclipseCon, Chris Aniszczyk, diskutiert und bin guter Hoffnung, dass er für diese Idee eine Umsetzung findet.

Und da sich alles um Kommunikation dreht: Das Eclipse Wiki enthält viele Aussagen über Codequalität und Best Practices. Vielleicht sollten wir ein paar dieser Dinge in einer Checkliste sammeln, mit der jedes Projekt seine eigene Lebendigkeit und Gesundheit selbst einschätzen kann. Wer sich selbst auf diese Fragen positive Antworten geben kann, hat sicher auch gute Chancen, ein florierendes Eclipse-Projekt zu etablieren.

Obwohl beide Seiten, Academia und Eclipse, Innovation produzieren, scheint es, dass sie diesen Begriff jeweils sehr unterschiedlich buchstabieren. Ich denke, wir sollten uns auf Gemeinsamkeiten und Unterschiede noch viel stärker einlassen. Da ist noch viel Cooles möglich.

Stephan Herrmann promovierte 2002 an der TU Berlin und leitet seitdem die Entwicklung von Object Teams und dem OTDT.
Kommentare

Schreibe einen Kommentar

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