Langzeitunterstützung bei Eclipse

Eclipse Long-Term-Support

Jutta Bindewald, Pat Huff
©Shutterstock.com/mtkang

Je mehr Mainstreamanwendungen auf Open-Source-Lösungen setzen, desto wichtiger wird es, über den gesamten Lebenszyklus einer solchen Anwendung hinweg einen entsprechenden Support für den quelloffenen Code bereitzustellen. Das gestaltet sich allerdings oft schwierig, da Open-Source-Communitys ihr Augenmerk tendenziell eher auf neue Funktionen und weniger auf die Wartung älterer Releases legen.

Was haben viele kommerzielle Anwendungen mit Designtools für Flugzeuge gemeinsam? Beide sind geschäftskritisch, beide bestehen teilweise aus Open-Source-(oft Eclipse-)Komponenten, und beide müssen über viele Jahre hinweg funktionstüchtig sein. Diese langfristigen Lösungen in Betrieb zu halten, ist einerseits von entscheidender Bedeutung, andererseits aber auch eine große Herausforderung. Veränderungen in der Umgebung oder in der Datenstruktur können Bugs zum Leben erwecken, die zuvor jahrelang friedlich vor sich hin schlummerten. Durch Eingriffe in den oberen Schichten der Software können unentdeckte Probleme in den unteren Schichten akut werden. Dann stürzt selbst eine Anwendung, die jahrelang verlässliche Dienste geleistet hat, plötzlich ab. Wenn Ihr Unternehmen professionelle Software bauen, verkaufen und verwenden möchte, stehen Sie vor der Aufgabe, Ihrem Angebot einen entsprechenden Support zur Seite zur stellen, der sich über den gesamten Lebenszyklus der Software erstreckt. Liegt das Problem in Ihrem eigenen Code, sind Sie möglicherweise imstande, den Fehler selbst zu analysieren und zu beheben. Es besteht noch das entsprechende Know-how in Ihrem Unternehmen, Sie sind im Besitz des Quellcodes, haben noch immer Zugriff auf die Build-Skripte und eine Testumgebung zur Verfügung. Es besteht also Hoffnung. Was aber, wenn sich herausstellt, dass das Problem durch einen Fehler in einer Open-Source-Komponente hervorgerufen wird, die Sie in Ihrer Lösung verwenden? Eclipse ist bekannt als Open-Source-Community, die bemerkenswerte Entwicklertools und Laufzeitumgebungen hervorbringt, aber auch eine kommerzielle Anwendung der unter ihrem Dach entwickelten Technologie begrüßt und fördert. Mehr noch: Ihr Umgang mit wichtigen Aspekten der kommerziellen Anwendung, z. B. geistiges Eigentum (Intellectual Property, IP) und die Klärung rechtlicher Fragen, sind in der Open-Source-Welt einzigartig. Dieses Angebot erweitert Eclipse nun und wendet es auch auf den Support seiner Anwender an. Da diese Anwender auf Eclipse-basierte Produkte angewiesen sind, wird die Fähigkeit, diese Produkte über den gesamten Lebenszyklus eines kommerziellen Angebots instand zu halten, ein weiterer essenzieller Teil ihres Wertversprechens den Kunden gegenüber.

Das Problem mit der Lebensdauer

Die offizielle Unterstützung der Version eines Eclipse-Projekts endet nach neun Monaten mit der Veröffentlichung des zweiten Servicerelease. Wenn Sie also einen Fehler in einer – aus Committer-Sicht – uralten Version entdecken, wird dieser in der aktuellen Version, die bei Eclipse entwickelt wird, entweder behoben sein, oder man wird Ihnen mitteilen, dass er im nächsten Supportrelease oder der nächsten Hauptversion ausgemerzt sein wird. Oft ist es nicht möglich, das eigene Produkt auf die neueste Version zu aktualisieren. Risiko und die Kosten für den Austausch von Komponenten innerhalb einer in Produktion befindlichen Lösung sind hoch – und viele Kunden nicht bereit, ein solches Risiko einzugehen, ohne einen klaren Nutzen vor Augen zu haben. Darüber hinaus verbieten es nicht selten regulatorische Anforderungen, die mehrere Jahre Stabilität garantieren sollen, sich bei der Migration auf neuere Versionen am Tempo und an der Frequenz einer lebendigen Open-Source-Community wie Eclipse zu orientieren. Die Software von Luftfahrtunternehmen etwa muss oft über mehrere Jahrzehnte hinweg gewartet werden.

Die Optionen

Wie behebt man also Fehler in möglicherweise sehr alten Versionen von Eclipse-Projekten? Es gibt grundsätzlich zwei Möglichkeiten: Entweder, Sie kommen alleine zurecht, oder Sie ziehen Fachkräfte zu Rate. Die Do-it-yourself-Option stellt Sie vor eine Reihe von Herausforderungen, die es zu überwinden gilt. Sie werden zwar den Quellcode in den Eclipse-Repositories finden – aber verstehen Sie ihn gut genug, um entscheidende Änderungen darin vorzunehmen? Können Sie den Build und eine angemessene Testumgebung reproduzieren? Sind Sie imstande, die Binärdateien zu signieren? Darüber hinaus gibt es rechtliche Überlegungen zu treffen. So erfordert es die Eclipse Public License, alle Änderungen am Quellcode öffentlich zugänglich zu machen. Die Option, auf professionelle Hilfe zurückzugreifen, ist auch nicht so einfach, wie sie klingt. Hier gilt es, möglichst rasch den richtigen Anbieter für ein spezifisches Problem zu finden. Im besten Fall stehen mehrere Anbieter zur Auswahl. Aber wie vergleicht man sie am besten? Und wenn Sie sich dann einmal festgelegt haben, müssen Sie darauf achten, dass kein Lock-in-Effekt mit diesem Anbieter entsteht, sprich: Was passiert mit dem Sourcecode, den Binaries etc., wenn Sie zu einem anderen Anbieter wechseln?

Eclipse LTS

Hier kommt Eclipse’ Long-Term-Support-(LTS-)Arbeitsgruppe ins Spiel. Die LTS-Arbeitsgruppe wurde gegründet, um für eine langfristige Unterstützung von Eclipse-Technologien zu sorgen, die kommerziell verwendet werden. LTS stellt die Infrastruktur und einen Marktplatz an erforderlichen Fähigkeiten zur Verfügung, damit Sie Ihren Kunden über die vielen Jahren eines Produktlebenszyklus hinweg Unterstützung bieten können. Zusätzlich ist LTS für Wartungsanbieter („Maintenance Provider“) vorgesehen, also Unternehmen oder Personen, deren Hauptgeschäft in der professionellen Unterstützung von Eclipse-Projekten besteht. Hier sind einige der Bestandteile von LTS:
• Der Marktplatz: Hier bewerben Wartungsanbieter ihre Angebote und geben an, wo ein potenzieller Anwender dieser Dienste die Fachkräfte finden kann, die ihm bei der Problembehebung zur Hand gehen können.
• Die technische Infrastruktur: Diese gemeinsame Infrastruktur bietet den Maintenance Providern alle notwendigen Komponenten, von Quellcode-Repositories bis hin zu signierten Binärdateien. Mehr dazu weiter unten.
• Die Organisation: LTS ist als Eclipse-Arbeitsgruppe organisiert. Wartungsanbieter müssen der Arbeitsgruppe beitreten, um die LTS-Infrastruktur nutzen.

Aufmacherbild: message on keyboard enter key, for online support concepts. von Shutterstock / Urheberrecht: mtkang

[ header = Seite 2: Wie funktioniert´s? ]

Wie funktioniert’s?

Wenn Sie ein potenzieller Anwender von LTS-basierten Supportdiensten sind, brauchen Sie kein Mitglied der LTS-Organisation zu sein. Sie besuchen einfach den LTS-Marktplatz (Abb. 1), um einen entsprechenden Wartungsanbieter zu finden. Der Anbieter wird dann die Bedingungen, Kosten und Details mit Ihnen besprechen. In der Regel werden Sie die Updates in Form von signierten Binärdateien erhalten. Der Quellcode ist als Open Source unter der Lizenz des ursprünglichen Projekts (in der Regel unter der Eclipse Public License) verfügbar. Wenn Sie ein Wartungsunternehmen sind, treten Sie der LTS-Organisation bei, um von den gemeinsamen Services und der Infrastruktur zu profitieren.Werfen wir einen genaueren Blick auf diese Infrastruktur und darauf, wie ein Wartungsanbieter sie verwenden würde. Sie besteht im Wesentlichen aus einem Git Repository, einem Gerrit-Code-Review-System, der Maven/Tycho-Build-Infrastruktur und einem Hudson-Server für die kontinuierliche Integration.Wenn ein Fehler in einer älteren Version des Eclipse- Projekts gemeldet wird, können Sie den Quelltext aus dem LTS Git Repository holen. Nach der Anwendung der erforderlichen Quellcodeänderungen senden Sie die Änderungen zum Codereview an Gerrit, womit Sie auch einen Rebuild Ihrer Komponente auslösen. Wenn der Build erfolgreich ist, erhalten Sie die erste Zusage von einem Hudson-Wähler.

Aber eine Zusage reicht nicht aus; andere Wartungsanbieter sind ebenfalls aufgefordert, Ihre Änderungen zu überprüfen und ihre Stimme abzugeben. Wenn mindestens ein anderer Anbieter Ihre Änderungen annimmt und sie niemand ablehnt, haben Sie es geschafft, und die Sourcecodeänderungen können ans zentrale LTS Repository gepusht werden. Sie können nun Ihre Komponente mit Maven/Tycho bauen und die signierten Binärdateien an Ihren Kunden liefern.

Abb. 1: Übersicht über den Eclipse-LTS-Prozess

Eigentlich ganz einfach und verständlich, oder? Dennoch ist vielleicht noch die eine oder andere Frage offen geblieben:
Ist Maven/Tycho obligatorisch, wenn man am LTS-Programm teilnimmt? Nein, alle Projekte können an LTS teilnehmen. Wenn Sie eine andere Build-Infrastruktur als Maven/Tycho nutzen, sind Sie allerdings verpflichtet, Ihre Build-Skripte einzuchecken, um einen reproduzierbaren Build zu gewährleisten.
Wer hat Zugang zu meinen Bugfixes? Der Sourcecode ist als Open Source (in der Regel unter der EPL) öffentlich zugänglich, gemäß den Open-Source-Lizenzbedingungen. Der Zugang zu den Binärdateien, um diese zu signieren, ist LTS-Mitgliedern vorbehalten.
Wie kann ich „private“ Fehlerkorrekturen erstellen, die erst ab einem bestimmten Zeitpunkt für die Öffentlichkeit zugänglich sein sollen, z. B. Sicherheitsupdates? LTS-Wartungsanbietern wird ein eigener Git Fork gewährt. Nur der Anbieter hat darauf Zugriff und kann Rechte an diesem Branch verteilen. Codeänderungen in diesem Bereich müssen keinem öffentlichen Gerrit-Code-Review unterzogen werden.

Der LTS-Marktplatz

Wie Sie sehen, bietet Eclipse LTS Maintenance Providern eine einfache Möglichkeit, Fehler in älteren Versionen zu beheben. Bleibt die Frage, wie potenzielle Kunden erreicht werden können. Ein entscheidender Vorteil einer LTS-Mitgliedschaft ist der gerade ins Leben gerufene Eclipse-Marktplatz für LTS-Anbieter. Dieser ermöglicht Wartungsanbietern und ihren Kunden einen leichten Einstieg. Hier können Anbieter ihre Dienstleistungen zur Verfügung stellen. Das tun sie, indem sie alle Projekte aufführen, die sie unterstützen. Für potenzielle Anwender dieser Dienste ist der LTS-Marktplatz ideal, um in Frage kommende Serviceanbieter zu finden und denjenigen auszusuchen, der ihnen mit ihren Problemen am besten helfen kann. Besuchen Sie einfach http://marketplace.eclipse.org. Unter „Markets“ wählen Sie „Long Term Support“ aus, um eine aktuelle Liste an LTS-Wartungsanbietern angezeigt zu bekommen.

Eclipse LTS: Wer ist dabei?
Mitglieder des Führungskomitees: IBM, SAP, Innooopract, PolarSys und CA Technologies
Premiummitglieder: Atos, Codetrails, itemis, Boundless, Ericsson, Obeo, Airbus und CEA LIST
Weiterer Interessent: Bosch

Kollaborativ und offen

Zum Schluss möchten wir einen Aspekt besonders hervorheben: Eclipse LTS verfolgt einen kooperativen Ansatz, der sich auf Open-Source-Prinzipien beruft. LTS-Mitglieder und Wartungsanbieter kooperieren in einer gemeinsamen Infrastruktur, die von Eclipse gehostet wird. Bugfixes in LTS und den zugehörigen Binärdateien sind allen LTS-Mitgliedern zugänglich. Das bedeutet insbesondere, dass Anbieter ihren Kunden nicht nur eigene Bugfixes zur Verfügung stellen können, sondern auch solche, die andere Anbieter beigesteuert haben. Für den Kunden minimiert sich dadurch das Risiko eines Anbieter-Lock-ins. Wenn Sie nicht mehr mit Ihrem Anbieter zufrieden sind oder er die Unterstützung eines Projekts einstellt, können Sie zu einem anderen wechseln. Dank der gemeinsamen Infrastruktur und des kooperativen Ansatzes geht kein Update, das Sie von Ihrem ursprünglichen Anbieter erhalten haben, verloren.

Aus dem Englischen von Diana Kupfer.

Geschrieben von
Jutta Bindewald
Jutta Bindewald
Dr. Jutta Bindewald ist Development Manager bei SAP, Eclipse-Vorstandsmitglied und Kovorsitzende der LTS-Arbeitsgruppe.
Pat Huff
Pat Huff
Pat Huff ist Programmdirektor bei IBM Rational und dort verantwortlich für Open Source und Eclipse. Er koordiniert die Beziehungen zwischen der IBM-Produktentwicklung und Eclipse und ist ebenfalls Eclipse-Vorstandsmitglied und Kovorsitzender der LTS-Arbeitsgruppe.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: