Praxisbericht Open Science: Diese Tools fördern die Zusammenarbeit

im Interview mit Lukas Galke

Tools für die digitale Kollaboration sind ein zentraler Baustein von Open Science. Doch die Vielfalt an verfügbaren Tools ist kaum zu überblicken; das Zusammenstellen eines geeigneten Portfolios ist komplex. In unserem Interview gibt Lukas Galke einen Einblick in seine Projektpraxis und erläutert Kriterien für die Auswahl geeigneter Tools. Er ist wissenschaftlicher Mitarbeiter im Projekt „Q-Aktiv“ an der ZBW. In dem Projekt werden Dynamiken des Wissenschafts- und Innovationssystems analysiert und Forschungsfragen bearbeitet wie: Wie verschmelzen bestehende Wissenschafts- und Technologiebereiche? Oder: Welche Fusion von Wissensgebieten und Technologien kann vorhergesagt werden? Verbundpartner der ZBW sind der Lehrstuhl für Technologiemanagement an der Universität Kiel und die ZB MED – Informationszentrum Lebenswissenschaften.

Wie organisierst du deinen Projektalltag in Q-Aktiv?

Wir sind im Projekt drei wissenschaftliche Mitarbeiterinnen und Mitarbeiter, die räumlich an verschiedenen Plätzen arbeiten. Sich hier auszutauschen und Zwischenergebnisse zu diskutieren, gemeinsam zu arbeiten und sich zu koordinieren, ist essenziell. Wir setzen hier sehr intensiv auf kollaborative Werkzeuge. Grob kann man diese Werkzeuge hinsichtlich ihres Zwecks unterteilen: Kommunikation, Kooperation und Koordination.

Könntest du uns im Detail erläutern, welche Tools ihr einsetzt?

Zur Gruppe „Kommunikation“ gehören zum einen die asynchronen Werkzeuge, mit denen ich zeitversetzt Nachrichten übermitteln kann. In Q-Aktiv benutzen wir natürlich E-Mails, aber auch Issues in GitLab. Zum anderen gehören in diese Gruppe die synchronen Werkzeuge für Audio- und Videokonferenzen. Hierfür verwenden wir vorzugsweise Jitsi-Meet statt beispielsweise Skype.

Zur Gruppe „Kooperation“ gehören solche Tools, die verteilte Zusammenarbeit ermöglichen. Die wesentlichen Eigenschaften dieser Tools sind Zugriffs- und Versionskontrolle. Während die Zugriffskontrolle eben jenen verteilten Zugriff für die teilnehmenden Akteure erlauben sollte, ist die Versionskontrolle hierbei wichtig, um unterschiedliche Versionen der jeweiligen Akteure bestmöglich zusammenzuführen und gegebenenfalls auch Änderungen rückgängig machen zu können.

In Q-Aktiv verwenden wir je nach Anwendungsfall verschiedene kollaborative Werkzeuge zur Kooperation. Für wissenschaftliche Artikel verwenden wir Overleaf. Overleaf ist ein Latex-Editor im Browser, der auch synchrone Bearbeitung unterstützt. Die Versionskontrolle wird durch Git umgesetzt, sodass es auch möglich ist, den Latex-Code lokal zu bearbeiten und die Änderungen zeitversetzt einzuspielen. Um Overleaf zu nutzen, ist keine lokale Latex-Installation notwendig. Zusammen mit automatischem Kompilieren und Hinweisen auf Fehler im Latex-Code, erleichtert dies das Arbeiten mit und den Einstieg in Latex ungemein.

Wenn es hingegen darum geht, gemeinsam am Quellcode für Programme oder Experimente zu arbeiten, verlassen wir uns auf Git. Als Plattform für Git verwenden wir GitLab. GitLab verhält sich zu Git wie Overleaf zu Latex. Es stellt ein zentrales Hosting zur Verfügung und bietet diverse Convenience-Features, um sich beispielsweise die Änderungen zwischen zwei Versionen anzuschauen und diese zu kommentieren.

Im Bereich der „Koordination“ sind insbesondere das Definieren von Action-Items und Meilensteinen relevant. Auch hierfür gibt es kollaborative Werkzeuge wie zum Beispiel Atlassians Jira oder Trello. In Q-Aktiv verwenden wir jedoch auch für die Koordination GitLab. In GitLab können Issues angelegt, gegebenenfalls einzelnen Akteuren zugewiesen sowie Meilensteinen zugeordnet werden. Insbesondere können auch weitere Details innerhalb des Issues diskutiert werden. Zudem verwenden wir Git oder GitLab auch, um gemeinsam an Agenden für Projekttreffen oder Workshops zu arbeiten, deren Protokolle festzuhalten, relevante Literatur auszutauschen, ein gemeinsames Vokabular festzuhalten und Präsentationsfolien zu teilen. Hierfür haben wir innerhalb der Projektgruppe ein spezielles, separates Repositorium angelegt.

Warum spielt GitLab eine zentrale Rolle bei der Kollaboration in eurem Projekt?

Der große Vorteil von Plattformen wie GitLab ist, dass sie gleichzeitig viele verschiedene Anforderungen abdecken. Dies empfinde ich als sehr angenehm, da es einen zentralen Einstiegspunkt darstellt, sodass ich nicht manuell die Verbindung zwischen E-Mails, Quellcode, To-do-Items und Meilensteinen herstellen muss. Stattdessen ist dies übersichtlich auf einer einzigen Plattform zusammengefasst und es können nach Belieben Querverweise erzeugt werden.

Ein weiterer Vorteil von GitLab ist, dass es in der Community-Edition unter der MIT Lizenz steht. Dies bedeutet nicht nur, dass der Quellcode von GitLab transparent einsehbar ist, sondern auch, dass eine Institution oder auch eine Privatperson ihre eigene GitLab-Instanz aufsetzen kann und somit auf keinen externen Hosting-Provider angewiesen ist. Dies ist ein Alleinstellungsmerkmal gegenüber der jüngst von Microsoft akquirierten Konkurrenzplattform GitHub. Obwohl dies ein zentraler Platz – vermutlich aktuell der größte – für Open-Source-Software ist, ist der Quellcode von GitHub selbst nicht offen.

Bei den anderen Werkzeugen, die wir im Projekt verwenden, hatten wir bei der Auswahl ähnliche Beweggründe: Overleaf basiert auf freier Software (Git, Latex, ShareLatex). Wenn die zentrale Overleaf-Instanz ausfällt, kann man nahtlos auf Git und Latex umsteigen. Natürlich braucht man dann gegebenenfalls die lokale Tex-Installation, falls nicht vorhanden. Bezüglich virtueller Projekttreffen oder Treffen im Arbeitskreis haben wir uns für Jitsi Meet entschieden. Jitsi Meet steht auch unter einer Open-Source-Lizenz (Apache 2.0) und bietet gleichzeitig eine komfortable Oberfläche (ohne Login), um Videokonferenzen abzuhalten.

An welchen Punkten stoßen eure aktuellen Werkzeuge an ihre Grenzen?

Hauptsächlich bei Word- und Powerpoint-Dateien. Diese lassen sich zwar wunderbar über Git austauschen, jedoch ist hier die Versionskontrolle problematisch. Git vergleicht Dateien üblicherweise Zeile für Zeile. Word und Powerpoint-Dateien sind allerdings im gespeicherten Zustand nicht so strukturiert, dass sie sich Zeile für Zeile vergleichen lassen. Auch LibreOffice-Dokumente würden unter dem Aspekt nicht besser abschneiden. Git selbst stößt hier an seine Grenzen. Während bestimmte Muster für Zwischenberichte oder Präsentationsfolien oft nur als Word/Powerpoint- Templates vorhanden sind, schreiben wir wissenschaftliche Artikel vorzugsweise mit Latex. Latex ist eine Turing-vollständige Programmiersprache und der Quellcode lässt sich einwandfrei Zeile für Zeile vergleichen. Auf der anderen Seite verwenden wir Markdown als flexibles Format für kleinere Dokumente.

Was müssen Tools können, um Kollaboration gut zu unterstützen?

Wie bei allen Werkzeugen ist es wichtig, dass der Aufwand das Werkzeug zu verwenden („Kosten“) nicht größer ist als der Nutzen, den das Werkzeug erbringt. Bei Kollaborationswerkzeugen ist der Nutzen im Allgemeinen die Zusammenarbeit, zum Beispiel zwischen Projektpartnern. Diese Kollaboration manifestiert sich jedoch in verschiedenen Aspekten wie Kommunikation, Kooperation und Koordination. Für jeden dieser Aspekte muss gesondert abgewogen werden, ob sich die Verwendung eines Werkzeugs in Kosten/Nutzen-Relation lohnt.

Gute Kollaborationswerkzeuge sind also solche, bei denen die Kosten möglichst gering sind. Dadurch, dass der Nutzen des kollaborativen Arbeitens üblicherweise hoch ist, sind die Kosten oder der Aufwand oft der kritische Punkt. Wenn die Werkzeuge für mehrere Aspekte in einer Plattform zusammengefasst sind, sinken die „Kosten“, die benötigt werden, um sich mit den jeweiligen Werkzeugen vertraut zu machen und dies zu benutzen. Es entstehen also Synergien zwischen den Werkzeugen. Abgesehen davon sollten gute Kollaborationswerkzeuge auf freier Software basieren. Ansonsten steigen nicht nur die indirekten Kosten bezüglich der Einarbeitung und dem Overhead für die Verwendung eines Werkzeugs, sondern auch direkte Kosten, beispielsweise durch zusätzliche Lizenzgebühren bei proprietärer Software oder gegebenenfalls durch die Anpassung der Partnersysteme. Freie Software bedient sich üblicherweise etablierter und vor allem nicht proprietärer Standards, wodurch stetig Synergieeffekte gefördert werden. Auch ein Linux-System basiert auf tausenden einzelnen Programmen, die so gut harmonieren, dass ein vollfunktionsfähiges Betriebssystem entsteht, obwohl jedes dieser Programme nur einem klar definierten Zweck dient und jeweils von einem anderen Programmierer entwickelt wurde.

Zurück zu Kollaborationswerkzeugen: Aus den Zutaten von vielen kleinen Werkzeugen entsteht also durch Synergien eine Art Menü für das kollaborative Arbeiten. Verpackt wird dieses Menü in Convenience-Tools wie GitLab und Overleaf. Es gibt natürlich auch andere Convenience-Tools, jedoch gilt hier der gleiche Grundsatz wie beim Essen. Convenience ist nur so gut wie die enthaltenen Zutaten. Beim Essen sind gute Zutaten womöglich pflanzenbasiert und natürlich; bei Software sind gute Zutaten entsprechend freie und offene Software sowie etablierte Standards.

Was ist dir persönlich bei der Nutzung kollaborativer Werkzeuge wichtig?

Bei kollaborativen Werkzeugen ist mir wie auch bei allen anderen Programmen wichtig, dass sie frei sind. Freie Software bedeutet nicht nur, dass diese kostenlos verwendbar ist oder der Quellcode offenliegt, sondern insbesondere, dass “die Benutzerinnen und Benutzer die Freiheit haben, das Programm auszuführen, zu kopieren, zu verteilen, zu studieren, zu verändern und zu verbessern [, also] frei wie in freie Rede, nicht wie in Freibier.” – Richard Stallman.