Version Control

Zur softwarebasierten Koordination von Ko‑laboration

Die Feststellung, dass digital vernetzte Medien ihren Nutzern Teilhabe ermöglichen, ist mittlerweile kaum mehr als ein Gemeinplatz. Dabei ist das Teilen – von Entdeckungen, Ereignissen, Beobachtungen, Nachrichten, Meinungen, Bewertungen, Überzeugungen, Informationen, Daten, Geheimnissen, Zeit, Entwicklungen, Ressourcen usw. – zum Imperativ in der Ökonomie digitaler Plattformen geworden. „[S]haring is caring“, ließ Dave Eggers (2013, S. 301) die Protagonistin Mae in seinem Roman The Circle proklamieren und eben hierfür dürfen und sollen alle Nutzer Sorge tragen. Als Infrastrukturen medialer Teilhabe eröffnen digital vernetzte Medien im Allgemeinen und Social Media-Plattformen im Besonderen jedoch unterschiedliche, mehr oder weniger festgeschriebene (Spiel‑)Räume des Mitteilens und Mitwirkens, in deren Rahmen sich die oft gelobten und immer häufiger verfluchten Potenziale digitaler Teilhabe praktisch, d.h. in vielfältigen, heterogenen und mitunter unvorhergesehenen medialen Praktiken entfalten. Zugleich verspricht die Free and Open Source-Bewegung an der technischen Ausgestaltung der digitalen Welt partizipieren zu können, indem beispielsweise Code mitentwickelt oder Dokumentationen mitverfasst werden können.

Als Gravitationszentrum der ko‑laborativen[1] Verfertigung von Software hat sich im vergangenen Jahrzehnt die Plattform GitHub etabliert, die basierend auf der Versionsverwaltungssoftware Git einen Online-Dienst für das Hosting von und das (ko‑laborative) Arbeiten an Softwareprojekten anbietet. Ursprünglich als Plattform für das Management von Quellcode konzipiert, findet GitHub auch in anderen Bereichen Einsatz. Sei es als Hosting-Plattform von Webseiten (GitHub o. J.), als Archiv deutscher Gesetze (Bundesgesetze und -verordnungen [2012] 2017) oder als Tool zum Sammeln von Urlaubsempfehlungen (Egan [2012] 2017). Dennoch steht Software und ihre Entwicklung im Zentrum von GitHub. Und auch wenn viele Open Source-Projekte auf der Plattform gehostet, gepflegt und weiterentwickelt werden, ist GitHub selbst nicht als Free and Open Source-Softwareservice zu betrachten. Vielmehr entfaltet und befördert die Plattform ein Modell von Open Collaboration, wie von Ben Balter (2014), Mitarbeiter von GitHub und Open Source Evangelist, nahegelegt wird.

Die Idee einer kollaborativen sozialen Praxis artikuliert sich im Rahmen der Plattform als Problem der Koordination von (Mit‑)Arbeit an digitalen Artefakten, wie dem Source Code von Programmen. GitHub als Plattform digitalen Ko‑laborierens reiht sich dabei in eine Geschichte von Techniken und Praktiken des (gemeinsamen) Erstellens, Bearbeitens, Kommentierens, Redigierens und Überarbeitens von medialen Konstellationen ein.[2] Diese reichen von improvisierten bis hin zu hoch formalisierten und medientechnisch vermittelten Verfahren, wie z.B. der händischen Korrektur von Papiermanuskripten, Techniken der Aktenführung, dem Austausch von Textvarianten via Email, der manuellen Versionierung von digitalen Dokumenten und eben auch der softwaregestützten Verwaltung von Softwarecode mit Version Control Systemen (VCS).

Wenn im Folgenden das Augenmerk auf Softwaresysteme zur Versionsverwaltung gelegt wird, dann soll danach gefragt werden, wie diese auf je unterschiedliche Weise die Handhabung und Zirkulation von Dokumenten kodieren und hierdurch spezifische Kooperationsbedingungen schaffen. Diese resultieren, so die These in unterschiedlichen Modellen, Formen und Formaten des Ko‑laborierens, d.h. des parallelen, teils koordinierten bzw. unkoordinierten, teils geplanten bzw. ungeplanten Laborierens an Source Code, die in deren Horizont praktiziert werden können und praktisch umgesetzt werden. Versionsverwaltungssysteme determinieren dabei jedoch keineswegs ko‑laborative Praktiken, sondern legen bestimmte Nutzungsformen nahe, die in der Praxis durch Richtlinien, Leitfäden und Verhaltensregeln kodifiziert werden.

Im Spannungsfeld von Softwarecode und Verhaltenskodex entfalten sich so vielfältige Praktiken der Koordination kooperativen Arbeitens ohne Konsens. Trotz dieser praktischen Vielfalt gilt es danach zu fragen, wie Versionsverwaltungssysteme als logistische Medien die (ko‑laborative) Arbeit an Code rahmen und strukturieren.[3] In den Blick genommen werden dabei die Kontroversen, Konfliktlinien und alternativen Lösungsansätze, die für Versionsverwaltungssysteme in den „[r]ecursive publics“ (Kelty 2008, S. 7) von Softwareentwicklern diskutiert, implementiert und praktiziert werden.[4] Die Frage wie die ko‑laborative Entwicklung von Software durch Versionsverwaltungssysteme koordiniert werden kann bzw. soll, ist Gegenstand zum Teil heftiger Debatten darüber was eine ‚gute‘ oder sogar die ‚beste‘ Software für den Zweck der Versionsverwaltung auszeichnet. Diskutiert werden hierbei weniger konkrete Organisationsmodelle der Zusammenarbeit, als vielmehr unterschiedliche Vorstellungen darüber was Dokumente, Versionen und Versionsgeschichten sind und wie deren parallele Weiterentwicklung gewährleistet werden kann. Das Problem der ko‑laborativen Entwicklung von Software artikuliert sich in diesem Zusammenhang als Frage nach der Materialisierung von Dokumenten und ihren Historien sowie nach den elementaren Operationen einer (ko‑laborativen) Entwicklungspraxis. Dies wird im Folgenden durch einen Vergleich zentralisierter und distribuierter Versionsverwaltungssysteme nachgezeichnet, wobei sowohl Gemeinsamkeiten als auch Unterschiede zwischen diesen herausgearbeitet werden. In dieser vergleichenden Perspektivierung von Anwendungen zur Versionsverwaltung werden die Spielräume der softwaretechnischen Unterstützung ko‑laborativer Zusammenarbeit lesbar.

Kontroverse Entwicklungslinien

Die Geschichte digitaler Version Control Systeme (VCS) reicht bis in die Ära von Mainframecomputern zurück. Als das erste VCS gilt das 1972 von Mark J. Rochkind an den Bell Labs entwickelte Source Code Control System (SCCS), welches die lokale Versionskontrolle einzelner Dateien auf einem Computer erlaubte (vgl. Raymond 2008). Ganz ähnlich funktionierte auch das in den 1980er Jahren von Walter F. Tichy an der Purdue Universität entwickelte Revision Control System (RCS). Im Zentrum stand dabei gerade nicht die Koordination der gemeinsamen Arbeit an Entwicklungsprojekten, sondern die Unterstützung der individuellen Programmier- und Entwicklungstätigkeit. Neben der Implementierung neuer Funktionen für neue Programmversionen beinhaltet diese etwa auch die Behebung von Fehlern in bereits veröffentlichten Programmversionen oder die Optimierung des implementierten Quellcodes. Der Code einer Softwareanwendung ist in der Programmierpraxis stets multipel und diese Vielfalt gilt es zu koordinieren, indem Änderungen implementiert, dokumentiert, getestet und in verschiedene Entwicklungslinien integriert werden. Die Variabilität von Code im Prozess der Programmierung und die synchrone Multiplizität unterschiedlicher Instanziierungen derselben Anwendung für unterschiedliche Programmversionen, Betriebssysteme, Hardwarekonfigurationen etc. bilden noch vor der Frage der Koordination ko‑laborativen Arbeitens an Code den Problemhorizont, in dem die Entwicklung von Versionsverwaltungsanwendungen situiert ist – auch wenn frühe VCS nur bedingt Lösungen für diese praktischen Herausforderungen bereithielten.

Der leicht überschreib- und veränderbare Computerspeicher bekam durch SCCS und RCS ein Langzeit- und Archivgedächtnis, das nicht nur das aktuelle Dokument kennt, sondern auch alle früheren Versionen desselben Dokuments. Jedoch verfügen Versionsverwaltungssysteme keineswegs über ein absolut vollständiges Gedächtnis früherer Änderungen, sondern über ein selektives Gedächtnis von für wichtig erachteten Punkten in der Entwicklungsgeschichte. Dies hat Tichy in einem Aufsatz zum Design von RCS in aller Deutlichkeit unterstrichen:

[I]ndiscriminately storing every change produces too many revisions, and programmers have difficulties distinguishing them. The proliferation of revisions forces programmers to spend much time on finding and deleting useless files. […] An alternative approach is to separate editing from revision control. The user may repeatedly edit a given revision, until freezing it with an explicit command. Once a revision is frozen, it is stored permanently and can no longer be modified. (In RCS, freezing a revisions is done with ci.) Editing a frozen revision implicitly creates a new one, which can again be changed repeatedly until it is frozen itself. (Tichy 1985, S. 651)

Dass Änderungen an einem Dokument nicht automatisch in dessen Versionshistorie aufgenommen werden, sondern durch den sogenannten Commit-Befehl explizit instruiert werden müssen, ist ein grundlegendes Prinzip, auf dem auch heutige Versionsverwaltungssysteme noch beruhen.

Versionierung ist somit kein Automatismus, sondern eine Praxis im Prozess der Programmierung, welche im Fall von SCCS und RCS die Programmierpraxis auf einem Computer zu unterstützen vermochte. Dies änderte sich mit der Einführung vernetzter VCS, wie zum Beispiel dem Concurrent Versions System (CVS) Mitte der 1980er Jahre, einem zentralisierten Versionsverwaltungssystem, welches sich vor allem auch in der Open Source-Entwicklergemeinde großer Beliebtheit erfreute, heute aber weitgehend durch andere Anwendungen, wie zum Beispiel Apache Subversion (2000) abgelöst wurde.[5] Zentralisierte VCS beruhen auf einem Client-Server-Modell der Verwaltung von Softwareprojekten, d.h. die Versionsgeschichte wird zentralisiert in einem autoritativen Repositorium gespeichert, aus dem Entwickler bestehende Versionen auschecken und an das sie ihre Änderungen übergeben (siehe Abb. 1).

Als Alternativmodell zu zentralisierten VCS wurden insbesondere seit Ende der 1990er Jahre sogenannte distribuierte VCS entwickelt, bei denen es kein einzelnes, von allen Mitwirkenden gleichermaßen genutztes, zentralisiertes Repositorium mehr gibt, sondern jeder Entwickler über ein eigenes Repositorium der Versionsgeschichte eines Softwareprojekts verfügt, welches mit jedem anderen Repositorium abgeglichen und zusammengeführt werden kann. BitKeeper, eines der ersten distribuierten Versionsverwaltungssysteme*,* entstand Ende der 1990er Jahre in Reaktion auf die wachsende Komplexität und Dynamik der ko‑laborativen Entwicklung des Linux-Kernels. Im Zentrum dieser Entwicklungstätigkeit stand und steht Linus Torvalds, der nicht nur die erste Version des Betriebssystems implementiert hat, sondern auch die offizielle, stabile Codebasis des Kernels pflegt, an der sich alle anderen Entwickler orientieren und zu deren Weiterentwicklung sie beitragen. Wie Christopher Kelty in *Two Bits* rekonstruiert, barg die zentrale Stellung Torvalds jedoch Konfliktpotenzial, welches im Spätsommer 1998 offen zutage trat, als Torvalds für einige Zeit aufhörte, die an ihn gesandten Änderungen in die offizielle Codebasis einzupflegen (vgl. Kelty 2008, S. 232ff.). Dass Torvalds schlichtweg nur im Urlaub war, besänftigte seine Kollaborateure, doch zugleich wuchs das Problembewusstsein, welches Larry McVoy auf die konzise Diagnose gebracht hat: „Linus doesn’t scale“ (McVoy 1998a). McVoy schlug vor den wachsenden Herausforderungen bei der Weiterentwicklung des Linux-Kernels durch ein distribuiertes Versionsverwaltungssystem zu begegnen, an dessen Umsetzung er bereits seit einiger Zeit arbeitete (McVoy 1998b) und das 2000 als BitKeeper unter einer proprietären Lizenz veröffentlicht wurde. Bei dessen Realisierung konnte sich McVoy auf Konzepte stützen, die er bereits Anfang der 1990er Jahre bei seiner Mitarbeit an dem wahrscheinlich ersten distribuierten VCS *TeamWare* der Firma Sun kennenlernte (vgl. Hacker News Contributors 2016). Heute weit verbreitete distribuierte VCS sind zum Beispiel *Git* und *Mercurial*.

Zwischen den Proponenten des zentralisierten und des distribuierten Lagers herrschte und herrscht ein quasi-religiöser Streit darüber, welcher der Ansätze in Theorie und Praxis der bessere für VCS sei. So finden sich online unzählige Beiträge, Diskussionen und Kommentare, die die unschlagbaren Vorteile des einen oder des anderen Ansatzes preisen und die Nachteile des jeweils anderen unterstreichen. Sieht man von den unermüdlich geführten Diskussionen über technische Detailfragen ab, so treten in diesen Debatten vor allem unterschiedliche Haltungen, Geschmäcke und Vorstellungen über die Handhabung von Informationen, Dokumenten und Versionen sowie über die Realisierung von Kollaboration in ko‑laborativen Entwicklungsprojekten zu Tage. In den Diskussionen finden sich daher zahlreiche Variationen des Arguments, dass es die Grundideen des jeweiligen Ansatzes zu verstehen gilt, um dessen Vorteile wirklich schätzen lernen und folglich überzeugt werden zu können (siehe exemplarisch Chacon und Straub 2014, S. 31f.).

Ähnlich verhält es sich mit der ebenfalls überaus kontroversen Debatte darüber, ob Systeme zur Versionsverwaltung sich eher an der Denkfigur des Snapshot oder an der des Changeset orientieren sollen. Die Schnappschussmetapher verweist auf den momentanen Gesamtzustand eines Projekts nach einem Commit, d.h. das ‚Abbild‘ der Inhalte aller im Repositorium enthaltenen Dateien zu einem bestimmten Zeitpunkt (siehe Abb. 2). Demgegenüber stellt die Denkfigur des Changeset die in jedem Überarbeitungsschritt vorgenommenen Änderungen in den Vordergrund. Das Repositorium erscheint dabei nicht als Abfolge von Versionen, sondern von Überarbeitungsschritten. Proponenten dieses Ansatzes sprechen daher häufig auch eher von Revision Control Systemen (vgl. Lord 2002). Auch wenn aus verschiedenen Snapshots die entsprechenden Changesets abgeleitet werden können und umgekehrt aus einer Folge von Changesets der Inhalt eines Repositoriums errechnet werden kann, gibt es subtile Unterschiede zwischen diesen. So argumentiert Martin Pool dafür, dass Changeset-Systeme über ein feiner granuliertes ‚Gedächtnis‘ verfügen und somit ‚mächtiger’ als Snapshot-Systeme wie Subversion seien (vgl. Pool 2004). Befürworter des Snapshot-Ansatzes stellen hingegen heraus, dass derartige Systeme für Nutzer leichter zu verstehen seien (vgl. Chacon und Straub 2014; Collins-Sussman, Fitzpatrick, und Pilato 2011).

Ko‑laborieren mit Subversion

Die Kontroversen über das richtige Design von Softwareanwendungen zur Versionsverwaltung erscheinen abstrakt, sehr technisch und wenig nachvollziehbar, wenn man allein den Aspekt der Bewahrung von Versionsgeschichten in den Vordergrund rückt. Der Aufbau eines digitalen Langzeitgedächtnisses früherer Versionen eines Softwareprojekts erfüllt jedoch keineswegs nur einen archivarischen Zweck, sondern dient der Koordination synchronen, verteilten Arbeitens an einem Projekt. Zentrale und distribuierte VCS stehen dabei vor ähnlichen Herausforderungen, lösen diese aber auf unterschiedliche Weisen. Im Folgenden soll zunächst auf zentrale VCS und die diesen eingeschriebenen Formen des Zusammenarbeitens eingegangen werden. Als paradigmatisches Beispiel wird hierbei Apache Subversion genauer betrachtet, ein zentrales Versionsverwaltungssystem, das im Jahr 2000 eingeführt wurde und aktuell noch immer über eine breite Nutzerbasis verfügt.

Der Zugang zu einem zentralen Repositorium wie Subversion wird normalerweise reglementiert, wobei es Subversion erlaubt, Lese- und Schreibrechte feingranular zuzuweisen. Entscheidend ist in diesem Zusammenhang jedoch weniger, wem Einsicht in den Programmcode gewährt wird, als vielmehr die Entscheidung, wem das Recht gegeben wird, welche Teile des Codes zu verändern. Arbeitsteilung in der Programmierpraxis aber auch unterschiedliche Formen der Organisation arbeitsteiliger Entwicklungspraktiken finden hier in der Verwaltung von Schreibrechten in das Repositorium ihre formale Artikulation. Neben der Regulierung von Mitarbeit müssen zentralisierte VCS mit dem Problem umgehen, dass verschiedene Programmierer zur selben Zeit an gleichen Programmteilen arbeiten können, wobei sichergestellt werden muss, dass Änderungen weder verloren gehen noch in Konflikt zueinanderstehen (siehe Abb. 3).

Diese Probleme lösen sich auf, wenn jeweils nur eine Person an einer bestimmten Datei eines Entwicklungsprojekts arbeiten darf. Dateien, die ein Entwickler aus dem zentralen Repositorium ausgecheckt hat, werden bei diesem Lösungsansatz mit einer Zugriffssperre versehen, so dass der Entwickler die bearbeitete Datei erst wieder ins Repositorium übergeben (der sog. Commit) muss, bevor ein anderer auf diese zugreifen kann. Hinsichtlich ko‑laborativer Entwicklungsarbeit ist hierdurch schon einiges gewonnen, doch durch die Linearisierung des Entwicklungsprozesses wird dieser Ansatz gemeinhin als unpraktisch erachtet. Insbesondere in großen Softwareentwicklungsprojekten erweist sich dieser File Locking-Ansatz als zu restriktiv und unflexibel, wenn eine große Zahl ggf. global verstreut arbeitender Programmierer und Programmiererinnen zeitgleich an vielen unterschiedlichen Aufgaben arbeitet, wie z.B. an der Beseitigung von Bugs, der Implementierung neuer Features oder der Portierung der Anwendung für eine Plattform.

Gelöst werden die Probleme der Koordination der ko‑laborativen Arbeit an Source Code-Dateien aber auch dadurch, dass ein Versionsverwaltungssystem nicht nur neue Versionen speichert, sondern auch erinnert auf welcher Versionsgrundlage gearbeitet wurde und Funktionen bereitstellt verschiedene Dateiversionen zu vergleichen und miteinander zu kombinieren. Subversion vergleicht hierfür bei jedem Commit, ob die vom Nutzer ausgecheckte und veränderte Version einer Datei noch aktuell ist. Sollte diese Datei im Repositorium mittlerweile in einer neueren Version vorliegen, muss der Nutzer diese zunächst laden und mit der vorliegenden veralteten und zugleich bearbeiteten Fassung zusammenführen (vgl. Collins-Sussman, Fitzpatrick, und Pilato 2011, S. 10). Erst nach der erfolgten Zusammenführung kann die Datei in das Repositorium übertragen werden.

Diese Integrationsleistung ist keineswegs ein Automatismus – auch wenn bestimmte Änderungen automatisch vom System zusammengeführt werden können –, sondern erfordert oftmals zusätzliche Programmierarbeit, die Konflikte zwischen den Versionen aus dem Wege räumt. Doch anstelle sich kommunizierend koordinieren zu müssen, ist es Aufgabe der Programmiererin die verschiedenen Dateiversionen zusammenzuführen und hierbei Konflikte auszuschließen.

Das Auschecken (checkout), Updaten (update), Zusammenführen (merge) und Einchecken (commit) von Dateien sind die elementaren Interaktionsformen von Nutzern mit dem zentralen Repositorium von Subversion, welche es ihnen erlauben – sofern sie über die entsprechenden Zugriffsberechtigungen verfügen – direkt an einem Entwicklungsprojekt mitzuwirken. Die von Subversion bereitgestellten Möglichkeiten der Koordination des verteilten Lesens, Schreibens und Umschreibens stellen jedoch allein noch keine erfolgreiche Kollaboration sicher. Hierauf weisen auch die Autoren des Subversion-Handbuchs hin:

Subversion provides the ultimate flexibility in terms of how you arrange your data. Because it simply versions directories and files, and because it ascribes no particular meaning to any of those objects, you may arrange the data in your repository in any way that you choose. Unfortunately, this flexibility also means that it’s easy to find yourself ‚lost without a roadmap’ as you attempt to navigate different Subversion repositories which may carry completely different and unpredictable arrangements of the data within them. (Collins-Sussman, Fitzpatrick, und Pilato 2011, S. 17)

Neben den technisch implementierten Möglichkeiten der Koordination ko‑laborativer Entwicklungsarbeit bedarf es somit zusätzlicher projektspezifischer, sozial etablierter sowie praktisch realisierter Regeln und Routinen, welche nicht die Handhabung von Dateien, sondern deren Organisation im Repositorium betreffen. Diese Regeln der Anordnung von Dateien werden in Richtlinien, Empfehlungen und Best Practices kodifiziert, welche auch die Entwickler von Subversion den Nutzern des Systems nahelegen.[6] Für jedes Projekt sollen demnach drei Ordner angelegt werden: der sogenannte Trunk- sowie ein Branches- und ein Tags-Ordner. Diese Struktur wird nicht technisch ‚erzwungen‘, sondern basiert auf Konventionen der ‚guten‘ Zusammenarbeit, die zum de facto Standard der Organisation von Dateien in Subversion geworden sind. Auch wenn die Software auf dieser Ebene zwar keine spezifische Praxis vorschreibt, so bildet sie doch den Rahmen in dem ko‑laborative Praktiken administrativ diszipliniert werden können und müssen.

In der Struktur von Trunk, Branches und Tags können wiederum zwei unterschiedliche Formen der ko‑laborativen Entwicklungsarbeit realisiert werden. In der ersten Form wird der Trunk als der Hauptentwicklungsbereich genutzt, an den sämtliche Änderungen von z.B. Bug Fixes oder neuen Features übergeben werden.

Im Branches-Ordner werden dabei Kopien des Projekts gespeichert, die auf den Entwicklungsstand der Software zu einem bestimmten Zeitpunkt verweisen (siehe Abb. 4). Es handelt sich um Abzweigungen des Projekts, die losgelöst vom Trunk weiterentwickelt werden können. Das Anlegen eines Branches oder Entwicklungszweigs bereitet in diesem Ko‑laborationsmodell die Veröffentlichung einer offiziellen Version einer Software vor, die vor dem eigentlichen Release aber noch getestet werden muss. Nach Abschluss dieser Tests wird ein Tag auf die zur Veröffentlichung vorgesehene Version des Entwicklungszweigs gesetzt, d.h. eine spezifische Revision markiert und ein Snapshot dieser Version in den Tags-Ordner kopiert. In diesem Ordner finden sich schließlich die unterschiedlichen veröffentlichten Versionen einer Software. Da in diesem Entwicklungsmodus die Hauptentwicklungsarbeit im Trunk stattfindet, enthält dieser Ordner zwar die aktuellste Version einer Software, welche aber zugleich relativ unstabil ist. In dem zweiten Ko‑laborationsmodell enthält der Trunk die stabilste Version, wobei die Entwicklungsarbeit an neuen Features bzw. Releases in Entwicklungszweige ausgelagert wird. Diese Weiterentwicklungen werden, sobald sie getestet und für ausreichend stabil befunden wurden, in den Trunk integriert. Die Revision, die eine offiziell veröffentlichte Softwareversion darstellt, wird infolgedessen auch nicht in einem der Entwicklungszweige, sondern im Trunk markiert.

Die Wahl des Entwicklungsmodells und somit des Modells ko‑laborativer Arbeit an Softwarecode wird von Subversion nicht vorgegeben, sondern muss praktisch etabliert und erfüllt werden. Um dies zu erreichen werden typischerweise Richtlinien der Mitarbeit formuliert, die jedoch gemeinhin nicht aus der Entwicklungspraxis heraus entstehen, sondern vom Administrator des Repositoriums oder einem Projektleiter vorgegeben werden. Die Einhaltung dieser Regeln kann jedoch wiederum von der Software unterstützt werden, indem beispielsweise Schreibrechte für Entwickler gemäß ihrer Aufgabe begrenzt werden. Auch können spezifische Richtlinien zum übergeben und einpflegen von Änderungen in Programmroutinen formalisiert werden, die es dem Versionsverwaltungssystem ermöglichen zu prüfen, ob die Praktiken der Programmierer und Programmiererinnen den gewünschten Nutzungsformen des Systems entsprechen.

Festzuhalten bleibt an dieser Stelle, dass Versionsverwaltungssysteme im Allgemeinen und Subversion als zentralisiertes VCS im Besonderen ko‑laborative Praktiken also keineswegs determinieren. Vielmehr eröffnen sie spezifische Spielräume, in denen sich kontingente Praktiken der Koordination von Zusammenarbeit etablieren können. Die ko‑laborative Zusammenarbeit wird hierbei auf mindestens zwei Weisen kodifiziert: Erstens durch die in Software implementierten Modi der Handhabung von Dokumenten und zweitens durch die in Richtlinien explizierten spezifischen Nutzungsformen der Software, welche als Best Practice-Ansätze durch die Entwicklercommunities zirkulieren, in Handbüchern bzw. Tutorials beschrieben und in Foren diskutiert werden. Spezifisch für zentralisierte VCS ist hierbei, dass Versionsverwaltung selbst als eine soziale Praxis begriffen und entworfen wird, die sich um das zentrale Repositorium herum gruppiert. Wenn Repositorien, anknüpfend an den Begriffsvorschlag von Susan Leigh Star und James Griesemer (1989), als Grenzobjekte zu verstehen sind, dann vermittelt das Coderepositorium eines zentralen VCS in erster Linie aber keineswegs zwischen verschiedenen Praxisgemeinschaften. Den Vermittlungen und Übersetzungen von Wissenspraktiken zwischen heterogenen Praxisgemeinschaften galt jedoch das zentrale Interesse von Star und Griesemer. Vor diesem Hintergrund definierten die Autoren Repositorien wie folgt:

These are ordered ‚piles‘ of objects which are indexed in a standardized fashion. Repositories are built to deal with problems of heterogeneity caused by differences in unit of analysis. An example of a repository is a library or museum. It has the advantage of modularity. People from different worlds can use or borrow from the ‘pile’ for their own purposes without having directly to negotiate differences in purpose. (Star und Griesemer 1989, S. 411)

Repositorien werden hier als geteilte Informationsressource begriffen, die den unterschiedlichen Informationsbedürfnissen und Interpretationsmustern heterogener Anspruchsgruppen genügen. Coderepositorien konstituieren im Vergleich dazu keine geordneten ‚Haufen‘ von Objekten, die auf unterschiedliche Weisen genutzt und analysiert werden können. Vielmehr dienen die Coderepositorien zentraler VCS der Etablierung und Koordination einer Praxisgemeinschaft, indem sie die ko‑laborative Arbeit an Medienobjekten strukturieren. Das Repositorium fungiert somit weniger als Informationsressource denn als logistisches Medium. Und als solches setzt es die „terms in which everyone must operate“ (Peters 2015, S. 37).

Die Praxisgemeinschaften von Entwicklern laufen zumindest bei Open Source-Projekten jedoch immer auch Gefahr auseinanderzubrechen, wenn nämlich das Projekt geforkt, d.h. das Repositorium dupliziert wird und sich die Entwicklercommunity infolgedessen aufspaltet. Im Kontext zentralisierter VCS ist der Fork ein Ereignis, das ausschließlich negativ konnotiert ist, da es Zusammenarbeit unterbricht. Dies ändert sich bei distribuierten Versionsverwaltungssystemen grundlegend, da in deren Kontext ein Fork nicht am Ende, sondern am Anfang einer ko‑laborativen Praxis steht.

Ko‑Laborieren mit Git

Während alle Entwickler im Kontext zentralisierter Versionsverwaltungssysteme an einem gemeinsamen Repositorium arbeiten, verfügen distribuierte VCS wie bereits erwähnt über kein zentrales Repositorium, aus dem alle Entwickler Dateien auschecken und an das sie Änderungen übergeben müssen. Vielmehr hat jeder Entwickler ein eigenes Repositorium, welches die Versionsgeschichte der Software sowie seiner eigenen Entwicklungstätigkeit enthält (siehe Abb. 5). BitKeeper war vielleicht eines der ersten distribuierten VCS, dem vor allem durch seinen Einsatz von den Entwicklern des Linux-Kernels zwischen 2002 und 2005 eine medienhistorische Bedeutung zukommt, doch bestimmen vor allem Git und die auf der Software aufbauende Plattform GitHub das Bild distribuierter Versionsverwaltungssysteme. Dabei ist die Geschichte von Git ähnlich, wie es schon bei BitKeeper der Fall war, aufs Engste mit der Entwicklung von Linux und dessen Erfinder Linus Torvalds verbunden. Das aktuell wohl am weitesten verbreitete distribuierte Versionsverwaltungsanwendung ist das Resultat eines Bruchs zwischen BitKeeper und der Linux-Entwicklercommunity. Als der Anbieter der proprietären Versionsverwaltungssoftware sich 2005 entschied BitKeeper den Linux-Entwicklern nicht länger kostenfrei zur Verfügung zu stellen, begann Linus Torvalds mit der Entwicklung von Git, einem distribuierten VCS, welches vor allem auf die verteilte, nicht institutionell gerahmte Entwicklungslogik des Linux-Kernels zugeschnitten ist, in deren Zentrum ein Maintainer, Linus Torvalds, die Verantwortung hat die Entwicklungsarbeit einer unentgeltlich arbeitenden Community zusammenzuführen aber auch die Macht zu entscheiden, was zum Teil der Software wird und was nicht.

Der Vorteil nicht nur den verteilten Zugriff auf Dateien zu erlauben, sondern das Repositorium selbst zu verteilen, besteht Befürwortern von distribuierten VCS wie Git, zufolge nicht nur in der erhöhten Ausfallsicherheit, sondern auch in der Möglichkeit komplexere Formen des Ko‑laborierens zu ermöglichen, wie zum Beispiel hierarchische Entwicklungsworkflows: „Unlike Centralized Version Control Systems (CVCSs), the distributed nature of Git allows you to be far more flexible in how developers collaborate on projects“ (Chacon und Straub 2014, S. 151). Preis dieser Flexibilisierung ist die wachsende Komplexität bei der Etablierung und Aufrechterhaltung ko‑laborativer Entwicklungsarbeit, insbesondere auch weil distribuierten VCS kein explizites Modell der Zusammenarbeit an einem Repositorium eingeschrieben ist. Im Zentrum von Git oder genauer eines Git-Repositoriums steht die individuelle Entwicklungspraxis. Zugleich stellt die Software umfangreiche Funktionen zur Verfügung, um die Resultate der individuell geleisteten Arbeit am Code eines Projekts in andere Repositorien zu integrieren. Anders als bei Subversion entfaltet sich das Problem ko‑laborativer Zusammenarbeit hier also nicht als Frage der Koordination der gemeinsamen Arbeit an einem Repositorium, sondern als Frage der Zirkulation von Code zwischen Repositorien, wobei sich nicht zuletzt auch immer die Frage der Einheit eines Entwicklungsprojekts stellt.

Distribuierten VCS ist keine spezifische Form der Zirkulation von Überarbeitungen eingeschrieben. Diese müssen als Workflows praktisch etabliert werden, wobei sich die distribuierte Entwicklungsarbeit gemeinhin auch an einem autoritativen Repositorium orientiert, welches gewissermaßen als Zentrum ohne Zentrum fungiert und von der Entwicklercommunity als sogenanntes „blessed repository“ anerkannt wird, an dem sie sich orientieren.[7] Das Recht Änderungen an dem gesegneten Repositorium vorzunehmen bleibt dem oder den Besitzern des Repositoriums vorbehalten, die mal als Integrationsmanager (siehe Abb. 6) mal als gutmütige Diktatoren (siehe Abb. 7) bezeichnet werden.

Mitwirkung beginnt mit dem Fork eines Projekts, d.h. dem Erstellen einer Kopie des gesegneten Repositoriums. Jedes Mitglied der Entwicklercommunity erstellt seinen eigenen Fork, an dem er oder sie individuell arbeiten, d.h. Änderungen vornehmen und diese online in einem öffentlichen Repositorium zur Verfügung stellen kann. Um die Integration vorgenommener Änderungen in das zentrale Repositorium zu erreichen, müssen diese vom Integrationsmanager aus dem Repositorium des Entwicklers gezogen (pull) und dem Hauptrepositorium hinzugefügt werden. Hierfür, so schreiben die Autoren des Handbuchs Pro Git, solle man eine E-Mail an den Integrationsmanager des Repositoriums senden: „The contributor sends the maintainer an email asking them to pull changes“ (Chacon und Straub 2014, S. 153).[8] Der Vorschlag distribuierte Entwicklungspraxis mittels E-Mail und Mailinglisten zu organisieren hat ein Vorbild in der Linux-Entwicklercommunity, die die Zirkulation von Code von Anfang an durch die Zirkulation von E-Mail bewirkte und koordinierte (vgl. Kelty 2008, S. 232f.).

Der im Integrationsmanager-Workflow dargestellte Entwicklungsprozess kann auch mehrstufig gestaltet werden, wenn der Betreuer eines Projekts die Verantwortung für Teile des Projekts an Lieutenants überträgt. Den Stellvertretern werden dabei jedoch keine Schreibrechte am „blessed Repository“ eingeräumt. Vielmehr prüfen sie die vorgeschlagenen Änderungen und empfehlen ihre Übernahme in das autoritative Repositorium, indem sie die Änderung in ihr eigenes Repositorium integrieren und einen Pull Request in Form einer Email an den „gutmütigen Diktator“ des autoritativen Repositoriums senden. Delegation von Aufgaben gestaltet sich hierbei nicht als Übertragung von Rechten, sondern als Aufbau einer mehr oder weniger formalisierten und mehr oder weniger explizierten Vertrauensstruktur, die die mehrstufige Evaluation der zirkulierenden Änderungsvorschläge ermöglicht (siehe Abb. 7).

Entscheidend sind an dieser Stelle weniger die feinen Unterschiede zwischen den diskutierten Workflows im Detail, als vielmehr die grundlegende Beobachtung, dass Git selbst keine spezifische Form der Zirkulation von Änderungen eingeschrieben ist. Daher erfordert der ko‑laborative Einsatz von Git nicht nur die Formulierung von Regeln der Zusammenarbeit (wie dies bei Subversion der Fall war), sondern die Etablierung einer begleitenden soziotechnischen Infrastruktur der Kommunikation und Zirkulation ko‑laborativer Änderungen, deren Dokumentation und Integration von dem distribuierten Versionsverwaltungssystem Git unterstützt wird.

Git vs. GitHub: Ko‑laborative Plattformpolitiken

Im Fall von Linux im Besonderen und der Open Source-Community im Allgemeinen war die Form der Organisation von ko‑laborativer Zusammenarbeit mittels Email bereits wohletabliert, was ein Grund dafür ist, warum sich die Open Source-Software in diesen Kontexten rasch einiger Beliebtheit erfreute. Es muss in Anbetracht der dargestellten Komplexität der Etablierung ko‑laborativer Zusammenarbeit jedoch mindestens als verwunderlich erscheinen, dass Git in den vergangenen Jahren auch weit über Grenzen der Open Source-Community hinaus Verbreitung fand und auch für die Zusammenarbeit in vielfältigen anderen Kontexten als Softwareentwicklungsprojekten genutzt wird. Einen maßgeblichen Beitrag hierzu hat die Plattformisierung von Git durch GitHub geleistet.[9]

Die Plattform GitHub baut auf der Software Git auf und erlaubt es ihren Nutzern relativ einfach, Git-Repositorien zu erstellen, online zu hosten sowie ihr lokales Arbeitsrepositorium mit dem online Repositorium zu synchronisieren, indem lokal vorgenommene Änderungen in das öffentliche Online-Repositorium übertragen (der sog. Push) werden. Zugleich schafft GitHub einen Rahmen in dem sich die distribuierte und ko‑laborative Arbeit an Projekten leichter etablieren lässt, da es Git um Funktionen zur Organisation ko‑laborativer Zusammenarbeit (losgelöst von Mailinglisten) ergänzt, wie z.B. die Issues-Funktion zur Kommunikation bzw. Diskussion von Problemen, Wünschen, Entwicklungsperspektiven. Wichtiger noch für die Etablierung ko‑laborativer Zusammenarbeit ist aber die Formalisierung von Pull Requests durch die formularhafte Kodierung der vormals informellen Zirkulation von Änderungen via Email in die Funktionslogik und das Interface der Plattform[10]:

GitHub is designed around a particular collaboration workflow, centered on Pull Requests. This flow works whether you’re collaborating with a tightly-knit team in a single shared repository, or a globally-distributed company or network of strangers contributing to a project through dozens of forks. […] Here’s how it generally works:

1. Create a topic branch from master.

2. Make some commits to improve the project.

3. Push this branch to your GitHub project.

4. Open a Pull Request on GitHub.

5. Discuss, and optionally continue committing.

6. The project owner merges or closes the Pull Request. (Chacon und Straub 2014, S. 202)

Die genannten Schritte bilden die elementare Grammatik ko‑laborativen Arbeitens mittels GitHub. Anstelle via E-Mail Änderungen an einem Softwareprojekt vorzuschlagen und um deren Integration in das Projekt zu bitten, stellt die Plattform eine Funktion dafür bereit, um die sich Zusammenarbeit via GitHub organisiert. Realisiert werden können in diesem Rahmen eine Reihe von unterschiedlichen Workflows, wie z.B. der bereits diskutierte Integrationsmanager-Workflow sowie der Diktator und Leutnants-Workflow. Im Vergleich zu zentralisierten VCS bei denen Mitarbeit durch die Vergabe von Schreibrechten ins Repositorium reguliert wird, können auf GitHub flüchtigere und informellere Formen ko‑laborativer Zusammenarbeit entstehen, die sich auf einen einzigen ggf. minimalen Änderungs- bzw. Korrekturvorschlag an einem Projekt beschränken kann.

Von großer Bedeutung ist hierbei die standardisierte Form, in der Pull Requests direkt, d.h. ohne Umweg über E-Mail oder andere Kommunikationskanäle an das Repositorium gerichtet werden können. Jenseits aller Unterschiede der Organisation von Zusammenarbeit in auf GitHub gehosteten Projekten, bildet der Pull Request die kleinste Einheit ko‑laborativer Praxis, die auf der gesamten Plattform Gültigkeit besitzt. Dies reduziert zwar die Komplexität bei der Etablierung ko‑laborativer Praktiken, garantiert aber nicht die Zufriedenheit aller Nutzer mit der konkreten Implementierung des Pull Requests auf GitHub. Linus Torvalds zum Beispiel kommentierte am 11. Mai 2012 einen Pull Request des Nutzers WNeZRoS wie folgt:

I don’t do github pull requests.

github throws away all the relevant information, like having even a valid email address for the person asking me to pull. The diffstat is also deficient and useless.

Git comes with a nice pull-request generation module, but github instead decided to replace it with their own totally inferior version. As a result, I consider github useless for these kinds of things. It’s fine for hosting, but the pull requests and the online commit editing, are just pure garbage. (Torvalds in GitHub 2012)

Torvalds zufolge verfügt Git über eine native Funktion der Erzeugung von Pull Requests, welche der Funktion von GitHub überlegen sei. Die „request-pull“-Funktion von Git fasst jedoch nur Informationen zu vorgenommenen Änderungen in einem standardisierten Text zusammen. Angefragt wird die Integration der Änderung in ein Repositorium jedoch nicht. Vielmehr muss die ausgegebene Nachricht kopiert und an den Betreuer des Projekts gesandt werden: „you can run the git request-pull command and email the output to the project maintainer manually“ (Chacon und Straub 2014, S. 171). Der Pull Request von GitHub hingegen automatisiert diesen Prozess. Dies konstituiert vielleicht nur einen kleinen, aber doch entscheidenden Unterschied für ko‑laborative Praktiken. Torvalds Ablehnung von GitHubs Pull Requests steht deshalb die große Popularität der Plattform mit 24 Millionen Nutzern und 67 Millionen gehosteten Repositorien (25.3 Millionen darunter wertet GitHub als aktiv) gegenüber. Seit September 2016 wurden innerhalb eines Jahres 47 Millionen Pull Requests in Projekte integriert (vgl. GitHub 2017).[11] Diese Nutzungsstatistiken sind ein guter Indikator für die zentrale Rolle, die GitHub als Plattform für Softwareentwicklungsprojekte spielt. Jedoch auch wenn sich die von der Plattform bereitgestellten Möglichkeiten gemeinsam an Projekten zu arbeiten großer Beliebtheit erfreuen, äußerten 2016 eine Reihe von Entwicklern Kritik in einem offenen Brief an GitHub. Gegenstand waren vor allem die von der Plattform bereitgestellte Issues-Funktion sowie der Pull Request. Anders als Torvalds äußerten die Entwickler jedoch keine fundamentale Ablehnung, sondern den Wunsch, die genannten Funktionalitäten projektspezifisch anpassen zu können, um den Informationsfluss bei der Meldung von Problemen und dem Vorschlag von Änderungen zu optimieren (vgl. dear-github 2016). Die Betreiber der Plattform reagierten auf diese Kritik, indem sie Nutzern mittlerweile die Möglichkeit gibt, Templates zu definieren, mit denen jeder Betreuer eines Projekts das Mindestmaß an erforderlicher bzw. erwünschter Information für Pull Requests sowie Problemmeldungen definieren kann.

Schluss

In Anbetracht der Popularität von GitHub bei Softwareentwicklern schlug Adrian MacKenzie (2017) vor die auf der Plattform gehosteten Repositorien als Ressource zu nutzen, um die Konturen der digitalen Infrastrukturen nachzuzeichnen, die uns unsichtbar umgeben. Im Unterschied dazu hat der vorliegende Text den Versuch unternommen Versionsverwaltungssysteme selbst als Infrastrukturen der ko‑laborativen Produktion digitaler Infrastrukturen lesbar zu machen. Wenn die Communities von Softwareentwicklern in Anlehnung an Kelty (vgl. 2008, S. 7) als rekursive Öffentlichkeiten zu verstehen sind, welche die digitale Welt mitgestalten, in der sie selbst leben, dann können Versionsverwaltungssysteme als rekursive Infrastrukturen verstanden werden, die als digitale Infrastrukturen die Entwicklung digitaler Infrastrukturen rahmen.

Ko‑laborative Praktiken etablieren sich dabei im Zusammenspiel technischer Codes und sozialer Richtlinien, in deren Horizont Kollaboration in einem emphatischen Sinn realisiert werden kann. Versionsverwaltungssysteme determinieren dabei keineswegs wie Zusammenarbeit stattfindet. Sie strukturieren diesen Prozess jedoch, indem sie elementare mediale Formen des Umgangs mit und der Zirkulation von Dokumenten vorschreiben, die sich in konkreten ko‑laborativen Arbeitszusammenhängen fortschreiben und in diese eingepasst werden. Kollaboration entfaltet sich hier als eine Praxis, die zugleich sozial und medial geprägt ist. Wie im Vergleich zentraler und distribuierter VCS deutlich geworden ist, legen die unterschiedlichen Softwarearchitekturen verschiedene Formen der Organisation von ko‑laborativer Zusammenarbeit nahe. Wenn diese im vorliegenden Text einander als idealtypische Kooperationsmedien gegenübergestellt wurden, dann ging es nicht um die Frage, ob distribuierte VCS besser seien als zentralisierte VCS oder umgekehrt. Das Ziel war es vielmehr freizulegen, wie durch Software je unterschiedliche Kooperationsbedingungen geschaffen werden und danach zu fragen wie diese praktisch auf verschiedene Weisen aktualisiert werden.

Keines der Softwaresysteme schafft dabei einen Raum reibungsloser oder sogar hierarchiefreier Zusammenarbeit, wie es die Bezeichnung distribuierter VCS vielleicht nahelegt. Denn auch hier ist Ko‑laboration auf ein Zentrum angewiesen, welches zwar nicht in der Architektur der Software eingeschrieben ist, sondern in der Entwicklungspraxis etabliert werden muss und von der Gutmütigkeit des „Diktators“ abhängt, der das „blessed“ Repositorium betreut. Ebenso wurde deutlich, dass die Frage der Kollaboration im Kontext von Versionsverwaltungssystemen als Problem der Koordination individueller Arbeitspraktiken Gestalt annimmt. Kollaboration ist dabei das Resultat der Koordination der ko‑laborativen, d.h. verteilten und parallelen Arbeit an Dokumenten. Diese Koordinationsleistung ist keineswegs ein Automatismus, sondern das Ergebnis der Arbeit mit und der Arbeit an Versionsverwaltungssystemen, die immer auch Potenzial für Konflikte bietet ebenso wie sie Anlass zu Weiterentwicklungen gibt.

Literatur

Balter, Ben. 2014. „Open Source, Not Just Software Anymore“. Ben Balter. 27. Januar 2014. https://ben.balter.com/2014/01/27/open-collaboration/.

Bundesgesetze und -verordnungen. (2012) 2017. bundestag. https://github.com/bundestag/gesetze.

Burkhardt, Marcus. 2015. Digitale Datenbanken: Eine Medientheorie im Zeitalter von Big Data. Bielefeld: Transcript.

Chacon, Scott, und Ben Straub. 2014. Pro Git: Everything You Need To Know About Git. 2. ed. New York: Apress. https://git-scm.com/book/en/v2.

Collins-Sussman, Ben, Brian W. Fitzpatrick, und C. Michael Pilato. 2011. „Version Control with Subversion: For Subversion 1.7 (Compiled from r5228)“. 2011. http://svnbook.red-bean.com/en/1.7/svn-book.pdf.

dear-github. 2016. dear-github: An Open Letter to GitHub from the Maintainers of Open Source Projects. dear-github. https://github.com/dear-github/dear-github.

Egan, Dylan. (2012) 2017. Some sort of travel log. Ruby. https://github.com/dylanegan/travel.

Eggers, Dave. 2013. The Circle: A Novel. New York: Alfred A. Knopf.

GitHub. 2012. „Add support for AR5BBU22 [0489:e03c] by WNeZRoS · Pull Request #17 · torvalds/linux“. GitHub. 2012. https://github.com/torvalds/linux/pull/17.

———. 2017. „GitHub Octoverse 2017“. GitHub. 2017. https://octoverse.github.com/.

———. o. J. „GitHub Pages“. GitHub Pages. Zugegriffen 18. Oktober 2017. https://pages.github.com/.

Hacker News Contributors. 2016. „Show HN: BitKeeper – Enterprise-Ready Version Control, Now Open-Source“. 2016. https://news.ycombinator.com/item?id=11667494.

Kelty, Christopher M. 2008. Two Bits: The Cultural Significance of Free Software. Experimental Futures. Durham: Duke University Press.

Lenglet, Marc. 2011. „Conflicting Codes and Codings: How Algorithmic Trading Is Reshaping Financial Regulation“. Theory, Culture & Society 28 (6): 44–66. https://doi.org/10.1177/0263276411417444.

Lord, Tom. 2002. „Re: svn diff, svn merge, and vendor branches (long)“, 2002. https://svn.haxx.se/dev/archive-2002-12/0822.shtml.

Mackenzie, Adrian. 2017. „Infrastructures in Name Only?: Identifying Effects of Depth and Scale“. In Infrastructures and Social Complexity: A Companion, herausgegeben von Penny Harvey, Casper Brunn Jensen, und Atsuro Morita, 379–90. London: Routledge.

McVoy, Larry. 1998a. „A Solution for Growing Pains“. Linux Kernel Mailing List. 1998. https://lkml.org/lkml/1998/9/30/122.

———. 1998b. „BitSCCS - SCCS compatible revision control system“. 1998. http://www.bitmover.com/bitsccs/.

Niewöhner, Jörg. 2014. „Perspektiven der Infrastrukturforschung: care-ful, relational, ko-laborativ“. In Schlüsselwerke der Science & Technology Studies, herausgegeben von Diana Lengersdorf und Matthias Wieser, 341–53. Wiesbaden: Springer VS.

Peters, John Durham. 2015. The Marvelous Clouds: Toward a Philosophy of Elemental Media. University of Chicago Press.

Pool, Martin. 2004. „Integrals and Derivatives“. Martin Pool’s blog (blog). 2004. http://sourcefrog.net/weblog/software/vc/derivatives.html [archived verion: https://archive.fo/ctWmx].

Raymond, Eric. 2008. „Understanding Version-Control Systems (DRAFT)“. 2008. http://www.catb.org/esr/writings/version-control/version-control.html.

Star, Susan Leigh, und James R. Griesemer. 1989. „Institutional Ecology, ‚Translations’ and Boundary Objects: Amateurs and Professionals in Berkeley’s Museum of Vertebrate Zoology, 1907-39“. Social Studies of Science 19: 387–420.

Tichy, Walter F. 1985. „RCS: A System for Version Control“. Software: Practice and Experience 15 (7): 637–54. https://doi.org/10.1002/spe.4380150703.

Vogel, Matthias. 2001. Medien der Vernunft: Eine Theorie des Geistes und der Rationalität auf Grundlage einer Theorie der Medien. Frankfurt a.M.: Suhrkamp.

[1] Bei der Einfügung des Bindestrichs zwischen „ko“ und „laborieren“ folge ich Jörg Niewöhner (2014). Hierdurch soll dem Begriff der Kollaboration die Emphase genommen werden und der Blick auf die Formen der Organisation von Mit- und Zusammenarbeit gelegt werden.

[2] In Medien der Vernunft schlägt Matthias Vogel vor mediale Konstellationen als diejenigen „Weltzustände oder Ereignisse [zu verstehen, M.B.], die Performation elementarer medialer Tätigkeitstypen entstehen oder hervorgebracht werden“ (Vogel 2001, S. 220f.). Im Vergleich zu ähnlichen Begriffen wie Medienprodukt oder Medienobjekt, rückt der Begriff der medialen Konstellation nicht den Werk- oder Objektcharakter in den Mittelpunkt, sondern die Praktiken der Erstellung oder Aufführung sowie Nutzung von Medienobjekten; siehe hierzu auch Burkhardt (2015, S. 50ff.)

[3] Ich verwende den Begriff logistische Medien in Anlehnung an John Durham Peters, der mit diesem die koordinative Funktion von Medien jenseits ihrer kommunikativen Funktion in den Vordergrund rückt: „They add to the leverage exerted by recording media that compress time, and by transmitting media that compress space. The job of logistical media is to organize and orient, to arrange people and property, often into grids. They both coordinate and subordinate, arranging relationships among people and things. Logistical media establish the zero points where the x and y axes converge” (Peters 2015, S. 37).

[4] Kelty definiert rekursive Öffentlichkeiten wie folgt: „Recursive publics are publics concerned with the ability to build, control, modify, and maintain the infrastructure that allows them to come into being in the first place and which, in turn, constitutes their everyday practical commitments and the identities of the participants as creative and autonomous individuals” (Kelty 2008, S. 7).

[5] CVS war das wohl erste unter einer Open Source-Lizenz veröffentlichte zentrale VCS. Erste proprietäre Anwendungen zur Verwaltung von Softwarecode auf der Grundlage eines Client-Server-Modells entstanden jedoch bereits in den 1970er Jahren, wie z.B. Panvalet oder Software Change Manager.

[6] Zur Verflechtung von Softwarecodes und sozialen bzw. juristischen Richtlinien im Bereich des Hochfrequenzbörsenhandels siehe Lenglet (2011).

[7] Etabliert werden können aber auch Workflows, die für zentralisierte VCS wie Subversion charakteristisch sind, indem ein zentrales Git-Repositorium auf einem Server zugänglich gemacht wird und sämtlichen Entwicklern Schreibrechte eingeräumt werden.

[8] Alternativ können die Änderungen auch direkt via Email in Form eines Patches an den Betreuer des autoritativen Repositoriums gesandt werden, damit dieser den Patch auf seinem Repositorium ausführt und hierdurch die vorgeschlagenen Änderungen übernimmt.

[9] Neben GitHub gibt es heute eine Reihe weiterer Plattformen sowie Open Source-Softwareanwendungen, die etwas Ähnliches leisten, wie z.B. Gitorious, Bitbucket und Gitlab.

[10] Git verfügt im Unterschied dazu nur über eine Funktion „request-pull“, welche zentrale Informationen über vorgenommene Änderungen in einem standardisierten Text zusammenfasst. Durch den Befehl wird die eigentliche Integration der Änderung jedoch nicht angefragt. Vielmehr muss die ausgegebene Nachricht kopiert und an den Maintainer des Projekts gesandt werden: „you can run the git request-pull command and email the output to the project maintainer manually“ (Chacon und Straub 2014, 171).

[11] In GitHubs Bericht The State of the Octoverse 2017 weisen die Plattformbetreiber auch süffisant darauf hin, dass Linus Torvalds im zurückliegenden Jahr seinen ersten Pull Request durchgeführt hat (vgl. GitHub 2017).