GitHub und ‚Social Coding‘: Neue Formen der Softwareentwicklung und -distribution als Chance

Immer mehr Bibliotheken, Informations- und Infrastruktureinrichtungen entdecken das ‚Social Coding‘. Die Erfolgsprinzipien der Coding-Plattform GitHub – Niedrigschwelligkeit und Sichtbarkeit individueller Beiträge –  könnten sogar zur Basis eines künftigen ‚GitHub for Science‘ werden. Worauf basiert dieser Trend und welche Chancen bieten sich? 

Der Wunsch, Software im Sinne von Quellcode nicht nur zu entwickeln, sondern auch zu verbreiten und Dritten zur Nachnutzung zur Verfügung zu stellen, stand schon seit jeher im Raum – viel früher übrigens, als dies neuerdings beispielsweise bei Forschungsdaten der Fall ist. Lange Zeit scheiterte er an praktischen und technischen Gründen.

Sozio-technische Entwicklungen öffnen geschlossene Codeverwaltung

Systematische Codeverwaltung hielt praktisch schon mit Ende der 80er Jahre Einzug. Einschlägige Systeme waren Subversion (SVN), Concurrent Versions System (CVS) oder Mercurial. Diese Systeme dienten in erster Linie dazu, in geschlossenen Softwareprojekten von verschiedenen Entwicklerinnen und Entwicklern produzierten Quellcode möglichst effizient zu verwalten – oder den einzelnen Entwicklerinnen und Entwicklern einfach nur dazu, den eigenen Quellcode für sich selbst möglichst gut zu organisieren.

Drei neuere sozio-technische Entwicklungen haben die traditionelle Sourcecode-Verwaltung allerdings auf neue Füße gestellt – oder gar revolutioniert -, mit bis heute noch gar nicht absehbaren Auswirkungen.

Agile Softwareentwicklung

Die erste dieser Entwicklungen war die stärkere Verzahnung von Projektmanagement und Softwareentwicklung vor dem Hintergrund, dass Projekte in Industrie und Forschung mittlerweile fast schon standardmäßig einen mehr oder weniger großen Anteil an Softwareentwicklung beinhalten. So unterstützt beispielsweise die Anwendung JIRA mit ihrem “Agile“-Modul die sogenannte „Agile Softwareentwicklung“, die gleichzeitig eine Form von Teamorganisation und Projektmanagement bedeutet: Projekt- bzw. Produktanforderungen lassen sich gleich als softwaretechnische Entwicklungsaufgaben (‚Issues‘) formulieren, die im Zuge geplanter Intervalle (‚Sprints‘) abgearbeitet und mit dem jeweils dazu entwickelten Quellcode verknüpft werden können.

Git für dezentrale LINUX-Entwicklung

Die zweite dieser Entwicklungen war die Einführung von Git durch Linus Torvalds, den Erfinder des LINUX-Betriebssystems. Torvalds stand vor der Frage, wie die Entwicklung insbesondere des LINUX-Kernels dezentralisiert, d.h. auf örtlich und zeitlich voneinander getrennte Personen verteilt werden  könnte. Damit sollte das weltweit verteilte Arbeiten am LINUX-Kernel praktisch ermöglicht werden. Im Rückblick, anlässlich des zehnjährigen Bestehens von Git, resümierte Torvalds:

“I’m very happy with Git. It works remarkably well for the kernel and is still meeting all my expectations. What I find interesting is how it took over so many other projects, too. Surprisingly quickly, in the end. There is a lot of inertia in switching source control systems; just look at how long CVS and even RCS have stayed around, but at some point git just took over.” (Quelle)

Git beruht auf wenigen Kernfunktionen, die die Codeverwaltung einfach und überschaubar halten sollen: So wird ein Softwareprojekt bzw. sogenanntes Git-Repository über ‚Init‘ erzeugt. Einzelne Änderungen werden jeweils über ein ‚Commit‘ bestätigt und größere Erweiterungen über ‚Fetch‘-, ‚Pull‘- oder ‚Push‘-Befehle in eigene oder fremde Code-Repositorien übernommen. Gegenüber den klassischen Codeverwaltungssystemen neu hinzugekommen sind Möglichkeiten, den eigenen Quellcode auf andere Projekte zu beziehen (‚Fetch‘/‚Pull‘) und die Änderungen an einem Projekt anderen zur Verfügung zu stellen (‚Push‘).

Social Coding wird praxistauglich

Diese Funktionen bilden die Grundlage für die dritte wesentliche sozio-technische Entwicklung, nämlich das sogenannte ‚Social Coding‘ auf Basis des World Wide Web (WWW). Systeme zur Codeverwaltung waren im Prinzip schon immer auch für die Verteilung und den Austausch von Software gedacht. Jedoch scheiterte dies an praktischen oder technischen Gründen wie  zum Beispiel einem verlässlichen Austauschprotokoll oder einer durchgängigen Versionierung – Quellcode wurde bis dato, wenn überhaupt, über separate Datenträger und E-Mail-Anhänge ausgetauscht. Mit Sourceforge wurde Ende des letzten Jahrtausends eine Internetplattform ins Leben gerufen, über die bis heute wesentliche Open Source Software-Pakete verteilt werden.

Individualismus, Transparenz und Hosting setzen sich durch

Jedoch führte erst die Einführung von GitHub zu einem neuen, öffentlicheren und gleichzeitig stärker personalisierten Verständnis von Softwareentwicklung. Hierzu trugen im Wesentlichen drei Maßnahmen bei:

1.

Der Wechsel von einer projekt- oder produktorientierten Sichtweise hin zu einer stärker nutzer- oder entwicklerorientierten Sichtweise. GitHub macht den individuellen Beitrag von Nutzerinnen und Nutzern gerade in ihrer Rolle als ‚Contributor‘ wesentlich sichtbarer, so dass diesbezüglich bereits Impactmessungen analog zur wissenschaftlichen Publikationstätigkeit vorgeschlagen wurden (Thung et al. (2013), “Network Structure of Social Coding in GitHub“, DOI).

Über Einstiege wie „Trending Repositories“ steigert GitHub darüber hinaus die ‚Awareness‘ von Entwicklungen, und Entwickler und Entwicklerinnen bzw. deren Repositorien erhalten über ‚Stars‘ ein besseres Ranking.

2.

Klassische Operationen bei der Sourcecodeverwaltung wie das Auschecken, die Aktualisierung oder die Integration von eigenem und fremdem Code (‚Merging‘) können innerhalb und außerhalb einer Community über GitHub leicht beobachtet werden – sie vollziehen sich quasi öffentlich im Web.

3.

Über sein ursprüngliches Profil als Hostingplattform für Softwarecode hinaus wird GitHub inzwischen auch für die Verwaltung und Verbreitung von Forschungsdaten, Lernmaterialien und kollaborativ erstellten Publikationen genutzt – und spätestens damit eröffnet sich auch ein potentielles Handlungsfeld für Bibliotheken.

Bibliotheken, GitHub und Open Science

Auch Bibliotheken, Informationszentren und Infrastruktureinrichtungen haben mittlerweile GitHub als Plattform erkannt, und zwar in verschiedener Hinsicht:  Erstens stellen Einrichtungen wie der Gemeinsame Bibliotheksverbund, die British Library oder die Library of Congress ihre Softwareentwicklungen unter institutionellen Accounts über GitHub ins Netz, darüber hinaus aber beispielsweise auch ihre digitalen Kollektionen.

Zweitens bewegen sich Mitarbeiterinnen und Mitarbeiter der genannten Einrichtungen insbesondere in ihrer Rolle als Software-Entwickler aktiv auf GitHub, wie ein von Hendrik Bunke (Twitter) angelegtes Verzeichnis zeigt.

Und  drittens kann GitHub angesichts der Tatsache, dass sich dort unter anderem mittlerweile über 34.000 Repositorien mit Bezug zu der Statistik-Software R befinden, durchaus als Plattform für „Open Science“ betrachtet werden. Darunter verstanden wird „the conduction of science in a way that others can collaborate and contribute, where research data, lab notes and other research processes are freely available, with terms that allow reuse, redistribution and reproduction of the research“.

Niedrigschwelligkeit und Sichtbarkeit: Basis für ein ‚GitHub for Science‘?

War GitHub also ursprünglich als Webversion der von Linus Torvalds entwickelten Codeverwaltung eingeführt worden, so hat sich die Plattform allein aufgrund ihrer Dynamik zu einer Anlaufstelle für wissenschaftliche oder wissenschaftsbezogene Softwareentwicklung entwickelt. Niedrigschwelligkeit bei gleichzeitiger Sichtbarkeit lauten die Konzepte, mit denen Nutzerinnen und Nutzer aus verschiedenen Einrichtungen und Domänen, ferner auch nicht-professionelle Softwareentwicklerinnen und -entwickler an GitHub herangeführt werden. Es bleibt abzuwarten, ob daraus, wie bereits gefordert wurde, letztlich ein eigenes ‚GitHub for Science‘ hervorgehen wird, das gleichermaßen Quelle und Zielpunkt auch für wissenschaftliche Infrastruktureinrichtungen wäre.