Die jungen Wilden: Googles Summer of Code #2

Bei Googles Summer of Code können Studenten bei Open-Source-Projekten mitarbeiten. Heute spricht Marcin Copik über seine Erfahrungen als Teilnehmer.

Know-how  –  0 Kommentare
Die jungen Wilden: Googles Summer of Code #2

Vor einigen Wochen hatten wir im Rahmen der jungen Wilden mit einem Mentoren des Google Summer of Code (Link zur News) gesprochen. Heute unterhalten wir uns mit Marcin Copik, der den Summer of Code als Student, aber auch als Mentor durchlaufen hat.

heise Developer: Hallo Marcin! Stell dich doch bitte vor.

Marcin Copik: Ich bin Marcin und Doktorand an der ETH Zürich. Meine Forschung ist im Bereich High Performance Computing und Heterogeneous Computing. Genauer ist das Thema meiner Promotion Performance Modeling.

Während meines Studiums habe ich zu der C++ Library for Parallelism and Concurrency HPX, die die STE||AR group entwickelt, beigetragen. Zuerst als Student im Rahmen von Google Summer of Code (GSoC)und nach dem erfolgreichen Abschluss des Projekts auch in meiner Freizeit. Letzten Sommer war ich selbst Mentor und betreue auch in diesem Jahr wieder einen Studenten.

heise Developer: Wie hast du zum ersten Mal vom Summer of Code erfahren?

Copik: Meine erste Interaktion mit Summer of Code hatte ich während meiner Arbeit in einem Forschungsinstitut. Ich habe an einer Erweiterung von PRISM gearbeitet, einem quelloffenen probabilistischen Modell-Checker. Mein Betreuer hat vorgeschlagen, dass wir unsere Idee als ein GSoC-Projekt einreichen könnten, weil PRISM als Organisation teilgenommen hat. Leider hatte Google mein Projekt nicht ausgewählt, aber ich habe es trotzdem als meine Bachelorarbeit abgeschlossen.

Diese Erfahrung und die Zusammenarbeit mit der PRISM-Gemeinschaft haben mir geholfen, im nächsten Jahr eine weitere Projektidee, die 2014 zu einem erfolgreichen Projekt wurde, zu formulieren. 2015 wurde mein Projekt für GSoC von der STE||AR group ausgewählt. Nach dem erfolgreichem Abschluss des GSoC-Projekts, blieb ich in der Community aktiv und war dann letztes Jahr selbst Mentor für ein GSoC-Projekt.

heise Developer: Hattest du vorher schon praktische Erfahrung in der Softwareentwicklung gesammelt?

Copik: Ich arbeitete als studentische Hilfskraft an Forschungsprojekten an der Uni Aachen und an einem Forschungsinstitut. Zusätzlich habe ich Bugfixes für diverse Open-Source-Projekte bereitgestellt.

heise Developer: Wie lief für dich der Auswahlprozess ab? War er transparent?

Copik: Vieles hängt von der Organisation ab. In der STE||AR group ist die Kommunikation zwischen Mentoren und potenziellen Studenten öffentlich, meist auf dem IRC-Kanal oder über eine Mailing-Liste. Nur Entwürfe der Projektvorschläge teilt man privat mit allen Mentoren, um Verbesserungen vorzuschlagen. Dadurch können Studenten sehen, wie viele andere sich für ein bestimmtes Projekt interessieren. Die Diskussion über die Projektidee und Tipps von Mentoren sind für jeden Kandidaten sichtbar.

Ich glaube, dass der öffentliche Charakter der Diskussion Transparenz und Objektivität garantiert, da Mentoren keinem Favoriten zuspielen können oder wertvolles Wissen nur mit ausgewählten Kandidaten teilen könnten.

heise Developer: Was genau waren deine Aufgaben? Wie verlief die Arbeit?

Copik: Die Aufgaben waren in beiden Projekten vergleichbar. Im Projektvorschlag habe ich einen Zeitplan und Meilensteine für mein Projekt vorgeschlagen. Jede Woche hatte ich einen Skype-Chat mit meinem Mentor. Wir diskutierten Fortschritte, Schwierigkeiten und änderten den Zeitplan bei Bedarf. Außerdem musste ich einen wöchentlichen Bericht an die Mailing-Liste schreiben, damit die Community einen Fortschritt sehen konnte und die Möglichkeit hatte, diesen zu kommentieren.

Bei meinem ersten Projekt habe ich an einer java-basierten Simulation von stochastischen Prozessen gearbeitet. Zusammen mit der PRISM-Community habe ich diese Software optimiert und neue Funktionen hinzugefügt. Mein zweites Projekt bei der Ste||ar group war etwas experimenteller. Dort evaluierte ich C++ AMP und Khronos SYCL, zwei Standards für die Single-Source-GPU-Programmierung in C++, für die Integration in HPX.