Seite 2: Mentorensicht

Inhaltsverzeichnis

Die Erfahrung als Mentor – Ausgangssituation

Andreas Sewe (Mentor für Eclipse Code Recommenders): "Um am GSoC teilzunehmen braucht es vor allem zwei Dinge: Neben ausreichend personellen Ressourcen für eine umfassende Betreuung der Studierenden auch über die Sommermonate wird eine Projektidee benötigt, die zu begeistern vermag, denn schließlich kann sich jeder GSoC-Teilnehmer auf maximal drei Projekte bewerben. An Ideen mangelte es zumindest bei Eclipse Code Recommenders nicht, sodass von neun Bewerbern auf sechs Projektideen in Absprache mit anderen, auch unter dem Dach der Eclipse Foundation als Mentoring Organisation vereinten Open-Source-Projekten letztlich fünf Bewerber, verteilt auf vier Mentoren, akzeptiert werden konnten.

Die Bandbreite der umgesetzten Ideen ist dabei durchaus repräsentativ für die Art von Projekten, die beim GSoC anzutreffen sind: Von einem völlig neuen Tool, dass zwar auf Code Recommenders aufbaut, aber ansonsten für sich allein steht, bis hin zu umfangreichen Umbauten an der GUI des mit gut 100.000 Zeilen Quellcode nicht eben kleinen Projekts selbst fand sich alles dabei. Eine Besonderheit 2013 war aber, dass zwei der beteiligten Studierenden an der gleichen Komponente, einer Codesuche und -vervollständigung für Code Snippets names Snipmatch, arbeiteten; in den Vorjahren gab es keine solche Überscheidungen zwischen den Projekten. Es wurde deshalb im Fall von Snipmatch im Vorfeld darauf geachtet, dass sich die Projektideen (ein groß angelegtes Refactoring der Snippet-Suche und ein neuer Editor für Code Snippets) sauber voneinander abgrenzen ließen. Auch wurden alle Änderungen an APIs oder Datenformaten frühzeitig auf der Entwickler-Mailingliste angekündigt und diskutiert.

Überhaupt ist es für das Gelingen eines GSoC-Projekts wesentlich, nicht nur mit den Mentoren zu kommunizieren, sondern mit der gesamten Community, seien es nun Entwickler oder Endnutzer. Für Fragen wurde im Fall von Code Recommenders die Mailingliste benutzt und für Ankündigungen ein Blog der Firma Codetrails, die einen Großteil der Entwicklermannschaft von Code Recommenders stellt. Neben Werbung für das Code-Recommenders-Projekt als solches dienen diese Blog-Posts auch dafür, die Motivation der Studierenden hochzuhalten. Es ist schließlich etwas ganz anderes, wenn man bereits im Juli interessierte Benutzer einer frühen Testversion hat, die nicht mit Lob oder Kritik sparen, als wenn man einfach nach Ablauf der drei Monate seinen Code abgibt.

Die Erfahrung als Mentor – Infrastruktur

So gilt das Open-Source-Credo von "release early, release often" insbesondere für den GSoC. Um allen Beteiligten aber Einarbeitung zu ersparen, sollten möglichst früh die etablierten Build- und Release-Prozesse des Hauptprojekts zum Einsatz kommen. Im Fall von Code Recommenders bedeutete das ein Zusammenspiel von Git, Maven und Hudson. Dieses Trio sorgt seit geraumer Zeit zuverlässig dafür, dass neue Versionen von Code Recommenders automatisch gebaut, getestet und zum Download bereitgestellt werden. Es ist daher nur folgerichtig, die GSoC-Projekte möglichst früh auf die gleiche Infrastruktur zu setzen.

Darüber hinaus verwendet das Code-Recommenders-Projekt Gerrit, ein auf Git basierendes Tool für Code-Reviews. Gerade während des GSoC zahlen sich solche Reviews aus, bieten sie doch nicht nicht nur die Möglichkeit, auf bestehende Code-Konventionen hinzuweisen, sondern auch auf die ein oder andere nützliche Hilfsfunktion, die in den vielen Zeilen des Mutterprojekts gerne übersehen wird. Wichtig ist aber, dass Reviews nie zum Flaschenhals werden; nichts ist frustrierender, als erst lange auf das OK eines Committers warten zu müssen. Bei Eclipse Code Recommenders hat man daher frühzeitig dafür gesorgt, dass die GSoC-Teilnehmer Herr im eigenen Reich werden; jedes GSoC-Projekt ist im Laufe des Sommers in ein eigenes Incubator-Projekt überführt worden, für das die Teilnehmer selbst als Committer verantwortlich waren.

Durch die strengen IP-Prozesse der Eclipse Foundation ließ sich dieser Schritt allerdings nicht schon im Frühsommer umsetzen; jeder substanzielle externe Codebeitrag zum Eclipse-Projekt ist zuvor vom "Legal Team" der Foundation auf etwaige Rechteverletzungen zu prüfen. Da das ein bis zwei Wochen in Anspruch nimmt, sind die GSoC-Projekte vorübergehend auf GitHub gelandet.

Die Hosting-Plattform ist zwar äußerst unkompliziert, allerdings macht es die Integration in die restliche Projektinfrastruktur (Gerrit für Code-Reviews, Hudson für Continuous Integration) nicht unbedingt einfach. Sicherlich existieren in beiden Fällen Alternativen (z. B. Travis), die aber wieder Einrichtungsaufwand verlangen, der für den kurzen Zeitraum bis zum bestandenen IP-Check nicht immer gerechtfertigt ist. Letztlich haben aber alle GSoC-Projekte wohlbehalten den Sprung in den Incubator und auf die von der Eclipse Foundation unterhaltene Infrastruktur geschafft.

Aus Sicht des Code-Recommenders-Projekt war der GSoC 2013 ein Erfolg. Zwar ist die Zahl der Commits, die die GSoC-Absolventen in ihrem jeweiligen Incubator-Reich eingebracht haben, seit September merklich zurückgegangen, doch verglichen mit anderen Projekten entspricht der derzeitige Stand immer noch einer guten Quote, zumal zwei von ihnen so aktiv wie im Summer of Code sind."