Einleitung

Als netzbasierte Hosting-Plattform für Softwarecode entwickelte sich das 2008 gegründete und zehn Jahre später von Microsoft übernommene GitHub, zu einer der relevantesten Plattformen für die kollaborative Softwareproduktion und Versionenverwaltung von Softwarecode. Als größte Plattform der Branche gilt GitHub als „‚kulturelles Epizentrum‘ für das exponentielle Wachstum der Open Source [Softwareproduktion]“ (O’Neil et al., 2022, 6) (Daigle, 2023; Dohmke, 2023; Elliot, 2021; Kochhar et al., 2021, 1838). Zudem wird GitHub mittlerweile von mehr als 90 % aller ‚Fortune 100‘-Firmen zur Entwicklung ihrer Software genutzt (Build Software Better, Together, o. D.).

Deswegen versuche ich in diesem zweiteiligen Blogeintrag GitHub in den Kontext des digitalen Kapitalismus einzuordnen. Spezifisch gehe ich dabei auf die Herstellung von Software und die Produktion von Mehrwert mittels GitHub und seiner 2021 veröffentlichten Künstlichen Intelligenz GitHub Copilot ein. Die Basis meiner Analyse bilden Karl Marx‘ Mehrwerttheorie, seine Maschinentheorie, sein Konzept des General Intellect und Klaus Dörres Landnahmetheorem. Im ersten Teil widme ich mich der Beschreibung und Analyse von GitHub, während ich mich im zweiten Teil auf GitHub Copilot konzentriere.

Anmerkung: Englische Zitate wurden vom Autor ins Deutsche übersetzt.

Produktion von Mehrwert mittels GitHub

Was ist GitHub?

GitHub basiert auf dem Versionenverwaltungssystem Git. Die Entwicklung von Git geht auf Linus Torvalds zurück, der vor allem als Initiator der Linux Kernel bekannt ist. Seit der Veröffentlichung im Jahre 2005 ermöglicht Git seinen Nutzer:innen, Softwarecode nicht nur kollaborativ und dezentral, sondern auch kostenfrei zu entwickeln (Lederer, 2021, 5). Auf Basis dieser Technologie wurden verschiedene Plattformen, wie beispielsweise GitLab oder GitHub entwickelt, die sich darin auszeichnen, dass der mittels Git hergestellten Code nicht dezentral, sondern zentral auf den Servern der Plattformfirmen gespeichert wird. Sie bieten zudem einen Zugang zu den auf ihren Servern gespeicherten Softwareprojekten über das Internet, eine anwendungsfreundliche Git-Nutzungsoberfläche und als Social-Media-Plattformen auch Kommunikationsmöglichkeiten zwischen den Nutzer:innen (Kochhar et al., 2021, 1838; Kula et al., 2021, 1; Lederer, 2021, 2-5; Microsoft Corporate Blogs, 2018; Perez-Riverol et al., 2016, 9).

GitHub ermöglicht so einerseits die Produktion von Free- and Open-Source-Software (FOSS), also Software, deren Code öffentlich zugänglich entwickelt wird und die als fertiges Produkt frei und unentgeltlich zur Nutzung und Weiterverbreitung zur Verfügung steht (Feller et al., 2005, xvii). Andererseits nutzen auch Softwarefirmen vermehrt GitHub für die Entwicklung von kommerzieller Open-Source-Software (OSS), also Software, deren Code ebenfalls öffentlich zugänglich ist und kollaborativ entwickelt wird, die jedoch nicht zwangsläufig frei zur Verfügung steht, sondern auch gewinnbringend verkauft werden kann (Kochhar et al., 2021, 1838).

Die Entwicklung sowohl kommerzieller als auch freier OSS ist auf GitHub identisch. Sie beginnt damit, dass ein:e Nutzer:in oder ein Softwareunternehmen einen Ordner anlegt, in dem alle Dateien des Quellcodes und die Metadaten über den Verlauf der Änderungen an diesem gespeichert werden. So können beispielsweise erste Quellcodezeilen in diesem Ordner veröffentlicht werden, die bei der Entwicklung einer Software programmiert werden. Ein solcher Ordner wird auch Remote-Repository bezeichnet. Dieses besteht aus einem Main-Branch und mehreren Feature-Branches.

Ersterer ist der Hauptstrang des Quellcodes. Eine gespeicherte und von den Eigentümer:innen des Repository akzeptierte Änderung an diesem Quellcode, die auch Commit genannt wird, wird nicht direkt in den Main-Branch integriert, sondern erscheint als abweichende Version in einer mit dem Main-Branch verwandten Feature-Branch. Noch nicht an dem Projekt beteiligte GitHub-Nutzer:innen können auf dieses Repository zugreifen und einen Klon des Remote-Repository als ein auf ihrem Computer befindliches Local-Repository speichern. Innerhalb dieses Local-Repository kann der Quellcode des Klons mittels Commits erweitert oder verändert werden. Um diesen veränderten Quellcode zu veröffentlichen, muss das Remote-Repository geforked werden, wodurch eine online verfügbare Kopie aller Dateien des Remote-Repository, eine sogenannte Fork, entsteht. Dadurch besteht die Möglichkeit, den geänderten Quellcode eines Local-Repository in die Fork zu pushen, also zu integrieren. Somit ist die veränderte Version des Quellcodes online verfügbar, jedoch noch nicht in dem Remote-Repository integriert. Die Veränderungen des Quellcodes in der Fork können jedoch über einen Pull-Request in das Remote-Repository hinzugefügt werden. Dabei fragt die externe Entwicklerin an, ob die Änderungen des Quellcodes in ihrer Fork in den Quellcode des Remote-Repository der Eigentümer:in integriert, also gemerged, werden soll. Dabei ist es den externen Entwickler:innen überlassen, ob sie diese Änderung in den Main-Branch des Remote-Repository integrieren oder mit diesen Änderungen einen neuen Feature-Branch erstellen will. Die Entscheidungsgewalt, den Pull-Request abzulehnen oder anzunehmen, liegt jedoch bei den Eigentümer:innen des Remote-Repository (Blischak et al., 2016, 1-17; Lederer, 2021, 26-31, 44-61, 128-134; O’Neil et al., 2022, 5-8).

Wie wird Mehrwert mittels GitHub produziert?

Aufgrund der Bereitstellung dieser Funktionen für eine kollaborative Softwareproduktion sowie der Marktführerschaft in diesem Bereich befindet sich GitHub in einer strategischen Position, in der die Softwareproduktion anderer Unternehmen von GitHub abhängig ist. (Birkinbine, 2020, 68-71; Srnicek, 2017/ 2018, 37-41). Als Plattform generiert GitHub durch eine solche strategische Position einen Umsatz, indem sie Renten, also Nutzungsgebühren, von den auf GitHub produzierenden Akteuren einfordert (Get the complete developer platform, o. D.). Da die Produktion von Mehrwert jedoch nicht in der „Extraktion ökonomischer Renten“ (Staab, 2019, 259), sondern im Produktionsprozess, also in der Herstellung von Software stattfindet, stellt der Umsatz von GitHub „für Marx […] letztlich Abzüge andernorts erwirtschafteten Profits und daher eine Form von inner-ökonomischer Umverteilung“ (Sevignani, 2019, 303) dar. Der Mehrwert wird also in der Herstellung von Software auf GitHub produziert, weswegen dieser Herstellungsprozess und GitHubs Funktion in diesem für die Analyse der Mehrwertproduktion von Bedeutung ist.

GitHub hat als „Plattform[…] zweifellos viele Maschinenelemente[, kann] […] jedoch nicht [vollständig] als Maschine[…] erklärt werden“ (Mackenzie, 2018, 37-38). Industrielle Maschinen werden als Produktionsmittel dazu eingesetzt, ein „Produkt zu […] materialisieren“ (Gnisa, 2019, 282), wohingegen der Arbeitsprozess auf Plattformen immateriell ist (Srnicek, 2017/ 2018, 40). Im Gegensatz zu identisch hergestellten materiellen Waren, die sich bei ihrem Gebrauch abnutzen, muss immaterieller Code bei GitHub einmalig entwickelt werden, dieser kann dann mit minimalem Arbeitsaufwand reproduziert werden und nutzt sich bei seiner Benutzung nicht ab. Somit existiert im „kommerziellen Internet zu großen Teilen […] [eine] Ökonomie[…] der Unknappheit“ (Staab, 2019, 150). Der klassische Arbeitsprozess, in dem Waren nach einem vorgegebenen Plan materialisiert werden, wird demnach obsolet (Eder, 2023, 24-25).

Um einen Mehrwert zu produzieren, muss jedoch die Ausbeutung menschlicher Arbeitskraft innerhalb eines Arbeitsprozesses stattfinden. Demnach muss sich der Arbeitsprozess wandeln, weswegen „Plattformtechnologien eine grundlegend andere Produktivitätsform als [dem] industrielle[n] Maschinensystem“ (Gnisa, 2019, 282) zugrunde liegt. „Weder Auftraggeberin noch Management […] wissen, wie ein Code für ein bestimmtes Programm […] aussehen soll“ (Gnisa, 2019, 283), das auf GitHub von einer Firma veröffentlicht wurde. Der Arbeitsprozess der Programmierer:innen besteht somit nicht daraus, „nur das schon vorhandene ideelle Konzept eines Produktes seriell [zu] materialisieren“ (Gnisa, 2019, 284), sondern sie entwerfen „das Produkt erst konzeptionell“ (Gnisa, 2019, 284), indem sie nicht-standardisierten Code generieren und somit neues Wissen produzieren.

GitHub als Plattform fungiert dabei in Abgrenzung zu anderen Produktionsmitteln wie beispielsweise Computern oder Software, mit denen digitale Produkte unmittelbar hergestellt werden können, als ein „allokatives Produktionsmittel“ (Gnisa, 2023, 282), also ein Produktionsmittel, das im Produktionsprozess eingesetzt wird, um Arbeit, Ressourcen und Fähigkeiten passend zuzuordnen. So können Entwickler:innen beispielsweise freie Softwarecodes finden und diese in eigene Softwareprojekte integrieren, oder Softwarefirmen können für ihr Softwareprojekt spezifische Entwickler:innen mit bestimmten Fähigkeiten wie beispielsweise Kenntnissen in einer schwierigen Programmiersprache finden und in ihre Softwareentwicklung einbeziehen. Wie im kommenden Abschnitt erläutert, ermöglicht diese allokative Funktion GitHubs die „Produktion von Mehrwert […] [durch] äußere und innere ‚Landnahmen‘, d. h. äußere und innere Zugriffe auf noch nicht kommodifizierte Entitäten“ (Vogl, 2021, 83).

Innere Landnahme

Landnahme kann als eine „fortwährende[…] ursprüngliche[…] Akkumulation“ (Dörre, 2019, 960) betrachtet werden, also als ein sich wiederholender „Scheidungsprozeß von Produzent und Produktionsmittel“ (Marx, 1993, 742). Während der Prozess der inneren Landnahme eine direkte Integration der nun von ihren Produktionsmitteln getrennten Produzenten der nichtkapitalistischen Bereiche in das kapitalistische Verwertungssystem, beispielsweise durch die Ausweitung von Lohnarbeitsverhältnissen, beschreibt, umschreibt die äußere Landnahme die Einbeziehung der nichtkapitalistischen Bereiche in das kapitalistische Verwertungssystem, ohne die dort stattfindende Arbeit in das Lohnarbeitssystem zu integrieren (Amlinger, 2017, 474; Luxemburg, 1975, 314).

Zwar hat auf GitHub keine für eine Landnahme charakteristische vollständige „Scheidung[…] von Produzent und Produktionsmittel“ (Marx, 1993, 742) stattgefunden. Denn auf GitHub existieren immer noch FOSS-Projekte, bei denen Programmierer:innen mit ihren eigenen Computern und freier Programmiersoftware, also ihren eigenen oder freien Produktionsmitteln, Software erstellen können. Eine vollkommene Trennung ist für einen inneren Zugriff auf die Entwickler:innen der GitHub-Community, also deren Integration in die Lohnarbeit zur Produktion von firmeneigener Software, dabei gar nicht notwendig, da FOSS, wie der Name schon sagt, frei für alle ist.

Die Entwickler:innen von FOSS können diese somit nicht verkaufen und mit dem dafür erzielten Kaufpreis ihre Arbeitskraft reproduzieren. FOSS-Entwickler:innen haben somit genau wie die von ihren Produktionsmitteln vollkommen enteigneten Arbeiter:innen „nichts zu verkaufen […] außer ihre Arbeitskraft“ (Marx, 1962, 130-131). Da der Großteil aller wirtschaftlichen Sektoren jedoch kapitalistisch organisiert sind und die darin hergestellten Waren, die zur Reproduktion ihrer Arbeitskraft notwendig sind, nicht frei zugänglich sind, sondern über einen Markt verkauft werden, müssen sie, um sich diese leisten zu können, ihre Arbeitskraft zum Beispiel zur Produktion firmeneigener Software auf GitHub verkaufen.

Auf GitHub ist diese Produktion firmeneigener Software in den letzten Jahren stetig gewachsen und ist im Vergleich mit der Produktion von FOSS dominant. Diese Entwicklung begann in den frühen 2010er Jahren, indem Firmen begonnen haben, ihre firmeninternen Versionenverwaltungssysteme durch GitHub zu ersetzen und somit „Open Source Projekte und Prozesse in […] Unternehmensstrukturen integrier[t]“ (Birkinbine, 2020, 71) und proprietäre Softwareentwicklungsprojekte öffentlich zur Verfügung gestellt wurden (Kochhar et al., 2021, 1838). Die generelle Unternehmensbeteiligung an Softwareentwicklungsprojekten auf GitHub nahm folglich zu (Kalliamvakou et al., 2015, 574; O’Neil et al., 2022, 27). Gegen Ende der 2010er Jahre hat sich dieser Prozess dahin entwickelt, dass die firmeneigene Softwareentwicklung eine dominante Stellung auf GitHub erreichte. So haben O’Neil et al. (2022) in einer Analyse der 20 meistbearbeiteten GitHub-Repositorien zwischen Januar 2015 und April 2019 festgestellt, dass 16 dieser 20 Repositorien „entweder vollständig von Unternehmen (über ihre Angestellten) entwickelt […] oder von Industriekonsortien, deren Vorstände von Unternehmen kontrolliert [wurden], verwaltet“ (O’Neil, 2022, 9) wurden.

Diese Auslagerung der firmeneigenen Softwareproduktion auf GitHub ermöglicht eine „innere Landnahme[…]“ (Dörre, 2012, 113), da sie mit einer Erweiterung der Lohnarbeit auf GitHub, also einer Erweiterung des kapitalistischen Milieus, einhergeht. Im Gegensatz zu der auf GitHub hergestellten FOSS, bei der Software aufgrund ihres Gebrauchswertes hergestellt wird, wird firmeneigene Software auf GitHub zum Großteil entwickelt, um einen Tauschwert und über die zur Produktion aufgewandte Lohnarbeit einen Mehrwert zu erzeugen. Dadurch ist „[d]ie Entwicklung von OSS […] zu einer […] kommerziellen Aktivität geworden“ (Riehle et al., 2014, 3286).

Dies zeigt auch eine andere Studie von O’Neil et al. (2021), in der dargelegt wird, dass die Lohnarbeit von firmeninternen Entwickler:innen innerhalb der zuvor erwähnten 20 meistbearbeiteten GitHub-Repositorien einen signifikanten Faktor der Produktion von Softwarecode auf GitHub darstellt. Denn der von diesen Lohnarbeiter:innen über firmeneigene Mailadressen produzierte Softwarecode hat einen Anteil zwischen 36,96 % und 91,58 % an den gesamten Commits dieser Repositorien (O’Neil et al., 2021, 22-23). Zweitens legten sie dar, dass die Zahl der lohnarbeitenden Entwickler:innen zwischen 2015 und 2019 angewachsen ist (O’Neil et al., 2021, 26). Dies kann mit der Auslagerung von bereits angestellten Entwickler:innen von firmeninternen Plattformen auf GitHub, aber auch durch das „[A]nziehen talentierter Entwickler:innen [aus der GitHub-Community] auf dem hart umkämpften IT-Einstellungsmarkt“ (O’Neil et al., 2022, 30) seitens auf GitHub präsenter Softwarefirmen und deren Integration in die Lohnarbeit erklärt werden.

Ein Mehrwert entsteht bei dieser, wie bei jeder anderen Lohnarbeit, über die Differenz zwischen der gesamten Arbeitszeit (notwendige Arbeitszeit und Mehrarbeit) und der (geringeren) notwendigen Arbeitszeit eines:einer Entwickler:in. GitHubs Funktion in diesem Prozess ist es, den Softwarefirmen einen Zugang zu qualifizierten Entwickler:innen, also einer „digitale[n] Reservearmee“ (Nachtwey & Staab, 2015, 14), bereitzustellen, um schnellstmöglich ihre Produktion auf Konjunkturschwankungen anpassen und bestmöglich ihre Produktion und somit auch die „Anzahl der gleichzeitig beschäftigten Arbeiter“ (Marx, 1993, 429) erweitern zu können (Dörre, 2019,962).

Äußere Landnahme

Neben einer wachsenden Anzahl von bei Softwarefirmen angestellten Lohnarbeiter:innen auf GitHub gibt es zudem einen weiteren „kontinuierliche[n] Zustrom von neuen Entwickler:innen“ (Kochhar et al., 2021, 1848), die firmeneigene Software herstellen. Diese Entwickler:innen sind Teil der GitHub-Community, werden jedoch nicht als lohnarbeitende firmeninterne Entwickler:innen in das kapitalistische Milieu direkt integriert, sondern befinden sich als externe Entwickler:innen in einem Austausch mit diesem Milieu.

Dieser Austausch ist auf GitHub vor allem dadurch gekennzeichnet, dass externe Entwickler:innen Pull-Requests bei firmeneigenen Softwareentwicklungsprojekten einreichen. So haben bei den von Kochhar et al. (2021) untersuchten firmeneigenen Repositorien externe Entwickler:innen im Vergleich zu firmeninternen Entwickler:innen zwischen 23,41 % und 45,36 % aller Pull-Requests eingereicht (Kochhar et al., 2021, 1848). Diese Tätigkeit ist für die Produktion von fertiger Software relevant, da die meisten ihrer „Pull-Requests […] akzeptiert und [damit in das Remote-Repository] gemerged“ (Kochhar et al., 2021, 1848) werden. Weitergehend haben O’Neil et al. (2021) gezeigt, dass der Anteil der von externen Entwickler:innen eingereichten und akzeptierten Pull-Requests, also durchgeführten Commits, bei den von ihnen untersuchten Repositorien zwischen 8,42 % und 63,04 % der gesamten Commits ausmacht (O’Neil et al., 2021, 22). Externe Entwickler:innen stellen somit neben firmeninternen Entwickler:innen „auch eine signifikante Rolle“ (O’Neil et al., 2021, 29) in der Entwicklung des kommerziellen Softwarecodes auf GitHub dar.

Diese Auslagerung der Produktion aus dem Unternehmen und die Einbeziehung Externer in die firmeneigene Produktion ist charakteristisch für Plattformen und kann als „[O]utsourcing“ (Fuchs, 2021, 88; Rodríguez Miglio, 2018, 119; Srnicek, 2017/ 2018, 77; Vogl, 2021, 76) oder „Hyperexternalisierung von Arbeitskräften“ (Vogl, 2021, 76) beschrieben werden.

Wie in den folgenden Abschnitten dargelegt, stellt dieser Austausch eine „äußere[…] Landnahme[…]“ (Dörre, 2019, 10) dar, da die GitHub-Entwickler:innen-Community als „nicht marktförmige Region […] in den Kapitalisierungsprozess“ (Vogl, 2021, 84), also zur Produktion firmeneigener Software mit dem Ziel der „Extraktion von Mehrarbeit“ (Vogl, 2021, 76) einbezogen wird. Spezifisch wird evaluiert, ob diese Einbeziehung der externen Entwickler:innen wie bei anderen äußeren Landnahmen, durch „Dominanzverhältnisse[…]“ (Dörre, 2019, 963) und „Disziplinierung“ (Dörre, 2019, 963) charakterisiert ist, einen sekundären Ausbeutungsmechanismus inklusive „ungleiche[n] Tausch“ (Dörre, 2019, 963) darstellt und durch einen „äußerökonomische[n] Zwang“ (Dörre, 2019, 963) ermöglicht wird.

Dominanzverhältnis und Disziplinierung

Der kooperative Charakter von GitHub ermöglicht es, dass „[firmeninterne] Entwickler:innen […] regelmäßig mit externen Entwickler:innen zusammen[arbeiten]“ (Kochhar et al., 2021, 1852) können. Diese Möglichkeiten der Kollaboration sind jedoch, wie in diesem Abschnitt gezeigt wird, ungleich verteilt, wodurch ein „Dominanzverhältnis“ (Dörre, 2019, 964) entsteht. Denn eine Gruppe von firmeninternen Entwickler:innen fungiert als Management eines firmeneigenen Repository. Sie hat die Entscheidungsgewalt darüber, welche externen Entwickler:innen an dem Repository mitarbeiten dürfen, da sie die Beitrittsanfragen von externen Entwickler:innen akzeptieren oder ablehnen können (Kochhar et al., 2021, 1847-1848). Es ist ebenfalls gängige Praxis, dass dieses Management die Funktionsweisen von GitHub so ändert, dass firmeninterne Entwickler:innen den Quellcode von ihrem Local-Repository direkt auf das Remote–Repository pushen können. Externe Entwickler:innen hingegen müssen „[t]ypischerweise […] eine Genehmigung über Pull-Requests einholen“ (O’Neil et al., 2022, 30), um den auf die Fork gepushten Quellcode mit dem Remote-Repository zu mergen.

Bei einem Fehlverhalten wie beispielsweise dem Ignorieren von Stilrichtlinien können Codevorschläge im Sinne einer „Disziplinierung“ (Dörre, 2019, 963) abgewiesen werden und der Account kann für das Repository sogar gesperrt werden (Kochhar et al., 2021, 1847, 1850; O’Neil et al., 2022, 30). Der Zugriff auf und die Kontrolle über den Softwarecode auf dem Repository ist demnach nicht für alle Entwickler:innen gleich, sondern wird vom Management selektiert. Die Software „ist daher im Sinne der Codelizenz“, also den formalen Rechten, auf den Code zuzugreifen und zu bearbeiten, „‚Open Source‘, aber sie [wird] nicht nach einem offenen oder geteilten Führungsmodell entwickelt, bei dem Entwickler:innen von unterschiedlichen Firmen [oder Entwickler:innen, die bei keiner Firma arbeiten] kollaborativ über ihre zukünftige Entwicklung entscheiden“ (O’Neil et al., 2022, 30) (Kochhar et al., 2021, 1845, 1847).

Sekundärer Ausbeutungsmechanismus

Da die von externen Entwickler:innen mitproduzierte firmeneigene Software gegen Geld oder andere Waren der digitalen Ökonomie wie Nutzer:innen-Daten oder Aufmerksamkeit getauscht wird, erscheint die Software auf dem Markt mit einem bestimmten Tauschwert als „qualitative[s] Verhältnis“ (Marx, 1993, 50) zu anderen Waren. Dieser Tauschwert ist einerseits direkt mitbestimmt durch die für ihre Produktion notwendigen Produktionsmittel wie Computerhardware oder Software, deren Wert in „Wertteil[en]“ (Marx, 1993, 408) durch Abnutzung oder „moralischen Verschleiß“ (Marx, 1993, 426), also einen Wertverlust durch technischen Fortschritt und damit einhergehende Überholung der Hard- und Software, an die hergestellte Ware übertragen wird. Andererseits ist der Tauschwert mitbestimmt durch die in ihr verwirklichte „abstrakt[…] menschliche[…] Arbeit“ (Marx, 1933, 61) (Hardt & Negri, 2017/2018, 160-161; Lange, 2019, 42; Sevignani, 2019, 300).

Externe Entwickler:innen werden für ihre Mitarbeit an firmeneigenem Softwarecode nicht entlohnt, weswegen ihre komplette Arbeitszeit, genau wie beispielsweise Sklavenarbeit, als unbezahlte Arbeit erscheint (Berger, 2019, 124-125; Frings, 2019, 436-237; Marx, 1993, 563). Die Bezeichnung des durch diese Arbeit produzierten Werts als Mehrwert scheint, da außerhalb eines Lohnarbeitsverhältnisses erzeugt, der lohnarbeitzentrierten Analyse Marx’ zu widersprechen. Jedoch stellt Marx selbst fest, dass „[d]as Kapital […] die Mehrarbeit nicht erfunden [hat]“ (Marx, 1993, 249) und auch ein Anteil der in sekundären Ausbeutungsmechanismen stattfindenden Arbeit, Mehrarbeit darstellen kann. Christian Fuchs legt in Bezug auf Marx dar, dass unbezahlte digitale Arbeit, wie die Arbeit externer Entwickler:innen eine Mehrarbeit darstellt, da die in ihr entstandenen Arbeitsprodukte durch Softwarefirmen angeeignet werden (Fuchs, 2014, 109). Die Mehrarbeit erzeugt dabei jedoch nicht nur ein solches „Mehrprodukt“ (Marx, 1993, 243), also einen Gebrauchswert, der von einer Softwarefirma angeeignet wird, sondern auch einen Mehrwert, da die Mehrarbeit zu einem Produkt beiträgt, das als Tauschwert gewinnbringend verkauft wird (Frings, 2019, 434, 440; Marx, 1993, 248-249). Externe Entwickler:innen sind somit ausgebeutete, Mehrwert produzierende Arbeiter:innen „unabhängig davon, ob [sie] dafür einen Lohn [erhalten] oder nicht“ (Fuchs, 2014, 109).

Indem Fuchs daraus jedoch schlussfolgert, dass die „Mehrarbeit 100 % ihrer Arbeitszeit ausmacht“ (Fuchs, 2014, 109), widerspricht er Marx, der argumentiert, dass „[d]ie Mehrarbeit […] nie 100 % erreichen [kann]“ (Marx, 1993, 554), da sie nur die wertschöpfende Funktion der zur Reproduktion der Arbeitskraft notwendigen Arbeit darstellt. Wenn die Mehrarbeit 100 % erreichen würde, würde dementsprechend die Arbeitskraft nicht mehr reproduziert werden können und folglich nicht mehr existieren.

Bei externen Entwickler:innen wird deutlich, dass es nur den Anschein erweckt, dass ihre gesamte Arbeitszeit Mehrarbeit ist. Denn ihre externe Entwickler:innenarbeit stellt nur einen Teil ihrer gesamten Arbeitszeit dar. Abseits von GitHub arbeiten sie in einem Lohnarbeitsverhältnis, in dem sie den Wert ihrer Arbeitskraft, die sie sowohl für diese Lohnarbeit als auch für die Entwickler:innenarbeit verausgaben, gegen einen Lohn eintauschen und damit ihre gesamte Arbeitskraft reproduzieren (Zhang et al., 2022, 3). Das Verhältnis zwischen dieser Lohnarbeit abseits von GitHub und externer Entwickler:innenarbeit an firmeneigenen Softwareprojekten auf GitHub verhält sich dabei ähnlich wie die Subsistenzarbeit zu der Gratisarbeit von Fronbauern (Frings, 2019, 436-437; Marx, 1993, 562).

Marx erläutert, dass ein Fronbauer „z. B. 3 Tage für sich auf seinem eignen […] Felde [arbeitet], und die drei folgenden Tage verrichtete er zwangsweise Gratisarbeit auf dem herrschaftlichen Gut“ (Marx, 1962, 135). Im Gegensatz zu der nicht erkennbaren Differenz zwischen dem bezahlten und unbezahlten Teil der Lohnarbeit findet bei der Fronarbeit „der bezahlte und der unbezahlte Teil der Arbeit sichtbar getrennt“ (Marx, 1962, 135) voneinander statt (Marx, 1993, 593). Während die Subsistenzarbeit in gewisser Weise bezahlt ist, da die Bauern ihre Arbeitsprodukte zur Reproduktion ihrer Arbeit nutzen können, stellt der unbezahlte Teil dieser Arbeit, also die Arbeit auf den Feldern des Gutsherrn, „die Mehrarbeit in der Fronarbeit“ (Marx, 1993, 251) dar. Das Produkt dieser Arbeit bestand jedoch nicht nur aus „eine[r] gewisse[n] Masse nützlicher Produkte“ (Marx, 1993, 250), wie die Produkte der Subsistenzarbeit der Fronbauern. Die Mehrarbeit „galt […] der Produktion des Mehrwerts selbst“ (Marx, 1993, 250), da die Arbeitsprodukte im Austausch mit dem kapitalistischen Milieu verkauft wurden.

Eine solche sichtbare Trennung zwischen bezahlter und unbezahlter Arbeit zeigt sich auch bei den externen Entwickler:innen. Sie arbeiten ebenfalls einen bestimmten Anteil ihrer Arbeitszeit abseits von GitHub, um ihre Arbeitskraft reproduzieren zu können, und den restlichen Teil unentgeltlich an firmeneigener Software auf GitHub. Letztere stellt demnach die den Mehrwert erzeugende Mehrarbeit dar, die außerhalb eines Lohnarbeitsverhältnisses stattfindet und somit als sekundärer Ausbeutungsmechanismus fungiert. Dabei unterscheiden sich die externen Entwickler:innen von den Fronbauern darin, dass der Teil ihrer Arbeitszeit, in dem sie nicht firmeneigene Software entwickeln, nicht wie bei den Fronbauern vollkommen zur Reproduktion ihrer Arbeitskraft dient. Stattdessen ist dieser Teil ihrer Arbeitszeit innerhalb eines Lohnarbeitsverhältnisses außerhalb von GitHub organisiert, in dem sie neben der ihre Arbeitskraft reproduzierenden Arbeit, für die sie einen Lohn erhalten, auch eine Mehrarbeit leisten, die nicht von den Softwareunternehmen, sondern von anderen Kapitalist:innen angeeignet wird.

Außerökonomischer Zwang oder außerökonomische Anreize

Bisher blieb in dieser Analyse offen, warum die externen Entwickler:innen überhaupt als solche arbeiten, da sie dafür keine Kompensation in Form von Lohn erhalten. Bei Prozessen der äußeren Landnahme werden die Arbeiter:innen typischerweise über einen „außerökonomischen Zwang“ (Dörre, 2019, 964) zur Produktion, wie es ihn beispielsweise bei der Fronarbeit gab, gedrängt (Marx, 1962, 135). Bei GitHub existiert kein solcher Zwang zur nicht entlohnten Produktion firmeneigener Software, denn wie zuvor dargelegt, müssen Entwickler:innen nicht als externe Entwickler:innen arbeiten und können auch nicht firmeneigene FOSS auf GitHub erstellen, ohne daran durch einen außerökonomischen Zwang gehindert zu werden (O’Neil et al., 2022, 9-10). Trotzdem „investieren externe Entwickler:innen […] Zeit und Anstrengungen, um an [firmeneigenen] Projekten“ (Kochhar et al., 2021, 1852) mitzuarbeiten. Diese Mitarbeit wird, wie im Folgenden erläutert, „im heutigen Kapitalismus […] ohne […] direkte[…] äußere[…] Gewalt“ (Fuchs, 2014, 126), also einen außerökonomischen Zwang, sondern durch außerökonomische „Anreize“ (Fuchs, 2014, 126), ermöglicht.

Genau wie die Fronarbeit, die sich aus ihrer „ursprüngliche[n] Produktionsweise […] [, die] auf Gemeineigentum gegründet [war]“ (Marx, 1993, 252), erst durch Privatisierungen des Landes zu dieser entwickelt hatte, diente die Arbeit an OSS in ihrer Entstehungsgeschichte „in erster Linie zum Nutzen einer Gemeinschaft“ (O’Neil et al., 2022, 31), weswegen Entwickler:innen als Teil dieser Gemeinschaft für diese Arbeit auch nicht bezahlt wurden. Obwohl firmeneigene Software nicht mehr über ihren Gebrauchswert als freie Software ohne Konditionen der Gemeinschaft dient, sondern als Tauschwert gewinnbringend verkauft wird, versuchen Softwareunternehmen immer noch, in der firmeneigenen OSS-Produktion das in der FOSS-Produktion existierende Gemeinschaftsgefühl aufrechtzuerhalten. So gewinnen externe Entwickler:innen „[d]urch aktive Beiträge [zum firmeneigenen Repository] […] Anerkennung in der Community“ (Kochhar et al., 2021, 1849) und ihnen wird „auch ein Zugehörigkeitsgefühl [vermittelt]“ (Kochhar et al., 2021, 1849). Diese Gefühle der Zugehörigkeit und Anerkennung können in einem Softwareprojekt, das zu einem weltweit bekannten Unternehmen mit Tausenden von Mitarbeiter:innen gehört, oft besser erzeugt werden als von kleineren und unbedeutenderen FOSS-Projekten. Zudem kann die Mitarbeit an einer firmeneigenen Software beispielsweise als Steigerung des eigenen Humankapitals verstanden werden.

Die Verbindung der Arbeit externer Entwickler:innen mit Anerkennung und einer Zugehörigkeit zu einer bedeutsamen Gemeinschaft kann als Erwerb dieser im Tausch gegen ihre Arbeitszeit angesehen werden. Dieser Tausch bringt ihnen einen ökonomischen Nachteil, da sie ihre ökonomisch wertvolle Arbeit gegen Anerkennung und Zugehörigkeit eintauschen, die keinen direkten ökonomisch äquivalenten Wert darstellen, mit denen externe Entwickler:innen ihre Arbeitskraft reproduzieren könnten. Es ist rein ökonomisch gesehen demnach nicht in ihrem Interesse, diese Arbeit zusätzlich zu ihrer Lohnarbeit aufzunehmen.

Den externen Entwickler:innen erscheint dieser Tausch jedoch nicht als nachteilig, weil sie sich zusammen mit den „Unternehmen und deren Projekten [als] Teil einer vereinten ‚Software-Entwicklung-Community‘“ (O’Neil et al., 2021, 45) und somit auch als Miteigner:innen der Software oder zumindest als Profiteur:innen der firmeneigenen Softwareproduktion begreifen. Im Vergleich zur Produktion von FOSS findet diese Vereinigung jedoch lediglich im Bewusstsein statt und bedeutet nicht den gemeinschaftlichen Besitz an der produzierten Software und die Gleichstellung aller Entwickler:innen innerhalb dieser Community. Denn wie zuvor dargelegt, stehen firmeninterne und externe Entwickler:innen in einem ungleichen Dominanzverhältnis zueinander und Letzteren wird kein gemeinschaftlicher Besitz an und Zugang zu der produzierten Software, wie bei der Produktion von FOSS, ermöglicht. Dieses Bewusstsein hindert jedoch die externen Entwickler:innen daran, ihre tatsächliche Situierung in der Produktion zu erkennen, da die proklamierte Gemeinschaft dieser Gemeinschaft wiedersprechende ökonomische Verhältnisse verdeckt und folglich die ökonomischen Verhältnisse „in den Diskursen der Entwickler:innen […] vollständig unberücksichtigt bleiben, als wäre[n] [sie] ein Tabuthema“ (O’Neil et al., 2021, 45). Dieses Bewusstsein ist demnach ein „falsches Bewusstsein“ (Lukács, 1968/1971, 64), eine Ideologie, die die ökonomischen Interessen der externen Entwickler:innen mit denen der herrschenden Klasse gleichsetzt und somit die ausbeuterische Mehrwertproduktion verdeckt (Lukács, 1968/1971, 50-51, 62-64). Ein außerökonomischer Zwang ist demnach nicht notwendig, da die Herstellung dieses „Community Mythos“ (O’Neil et al., 2021, 45) und die damit verbundenen außerökonomischen Anreize die äußere Landnahme und die damit einhergehende Erweiterung der Mehrarbeit als ökonomischen Effekt des außerökonomischen Zwangs auch ohne diesen ermöglicht.

Produktion von Mehrwert mittels GitHub Copilot

Was ist GitHub Copilot?

Die zuvor beschriebenen Anwendungen von GitHub können mit Plug-ins erweitert werden. Ein solches Plug-in ist das im Oktober 2021 von GitHub und OpenAI veröffentlichte Künstliche Intelligenz Tool Copilot. Während OpenAI zwar nicht wie GitHub eine direkte Tochterfirma von Microsoft ist, steht OpenAI seit 2019 in einer exklusiven Partnerschaft zu Microsoft, das zudem bereits mehrere Milliarden US-Dollar in OpenAI investierte (Microsoft Corporate Blogs, 2023). Beide Entwicklerfirmen vermarkten GitHub „Copilot […] als Ersatz für das pair-programming […], eine Softwareentwicklungspraxis, bei der zwei Programmierer gemeinsam einen einzigen Code schreiben.“ (Imai, 2022, 319) (GitHub Copilot, o. D.) Dabei wird Copilot eingesetzt, um bereits bestehenden Code zu kontrollieren, zu vervollständigen oder Fehler zu beheben, aber vor allem um neuen Code mittels Eingabeaufforderung in natürlicher Sprache zu generieren (Imai, 2022, 319; Zhang et al., 2023, 11).

Diese Fähigkeit, natürliche Sprache in Softwarecode umzuwandeln, basiert auf Copilots Generativen Vortrainierten Transformer (GPT) Codex der mit dem auf GitHub vorhandenen Code vortrainiert wurde (Chen et al., 2021, 1; Yetistiren et al., 2022, 62). Generativ vortrainierte Transformer basieren auf den neuronalen Netzen großer Sprachmodelle (Large Language Model), also Computerprogrammen, deren „organisatorische Prinzipien eine[m] echten neuronalen Netz[…] (wie dem menschlichen Gehirn)“ (Kaplan, 2016/2017, 45) ähneln. Künstliche Neuronen sind „in einer Reihe von Schichten angeordnet“ (Kaplan, 2016/2017, 46), wobei die niedrigste Schicht die in das Netz eingespeisten Daten aufnimmt und an spezifische Neuronen in höher liegende Schichten weitergibt. Jedes Neuron evaluiert diese Daten mit einem vorgegebenen Rechenprozess, bei dem ein spezifisch gewichteter Aktivierungsgrad des Neurons als Endprodukt erreicht wird. Je nach Aktivierungsgrad werden bestimmte andere Neuronen in höheren Schichten ebenfalls aktiviert. Auf dieser Basis kann Maschinenlernen auf zwei Wegen stattfinden (Alpaydin, 2014, 1, 29; Wolfram, 2023, 47-49):

Zum einen mittels überwachtem Lernen, bei dem „ein Mensch die dem System präsentierten Daten [kennzeichnet]“ (Kjøsen, 2018, 155). So werden beispielsweise mehrere Millionen HTML-Codes von unterschiedlichen Internetseiten jeweils mit der in natürlicher Sprache verfassten Kennzeichnung ‚Internetseite‘ in Codex’ neuronales Netz eingespeist. Da der Code jeder Internetseite verschieden ist, unterscheiden sich auch die Aktivierungsmuster der neuronalen Netze. Durch die auf alle Aktivierungsmuster zutreffende Kennzeichnung ‚Internetseite‘ werden für dieses Konzept Überschneidungen der Aktivierungsmuster zu einer abstrakten Generalisierung des Konzepts ausgemacht und mit der Kennzeichnung ‚Internetseite‘ in Verbindung gesetzt (Kjøsen, 2018, 153; Radford et al., 2018, 3-4; Wolfram, 2023, 36-42, 54-56).

Andererseits kann Maschinenlernen mittels unüberwachten Lernens stattfinden, bei dem das neuronale Netz eigenständig Muster in den ihm bereitgestellten Daten erkennt und diese dementsprechend kennzeichnet (Kaplan, 2016/2017, 47-49; Kjøsen, 2018, 155). Erkennen bedeutet hier beispielsweise, dass ein noch nicht in das neuronale Netz eingespeister HTML-Code einer Internetseite ein Aktivierungsmuster im neuronalen Netz aufzeigt, das zu den Anforderungen an ein Aktivierungsmuster des generalisierten Konzepts ‚Internetseite‘ passt.

Im Trainingsprozess eines neuronalen Netzes wird dieses somit immer besser, je mehr Daten eingespeist werden, da auf Basis von mehr Daten die Generalisierungen des Netzes präziser werden (Wolfram, 2023, 47). Um solche präzisen Generalisierungen zu erreichen, wurde Copilot „auf Milliarden von Codezeilen“ (Zhang et al., 2023, 15) der öffentlichen Repositorien von GitHub trainiert (Babar, 2022, 2721-2723). Dabei kann sich die Generalisierung auch verändern, wenn sich die eingegebenen Daten entsprechend ändern. Ein künstliches neuronales Netz wie das von Codex kann somit als „allgemeine[…] Schablone mit modifizierbaren Parametern“ (Alpaydin, 2014, 1, 17) beschrieben werden. Nachdem Copilots Codex mittels eines überwachten und unüberwachten Trainings vortrainiert wurde, ist es in der Lage, aus in natürlicher Sprache verfassten Eingabeaufforderungen Quellcode zu generieren. Durch die Eingabeaufforderung ‚Erstelle eine Internetseite‘ ist es in der Lage, durch die Generalisierung, die auf den mit dem Konzept ‚Internetseite‘ verbundenen Aktivierungsmustern basiert, und somit als Spiegelbild von Copilots Erfahrung, einen Quellcode einer Internetseite zu generieren (Alpaydin, 2014, 1, 24, 28-30; Kaplan, 2016/2017, 48; Radford et al., 2018, 1-3; Wolfram, 2023, 117-120).

Wie wird mittels GitHub Copilot Mehrwert produziert?

Im Gegensatz zu GitHub, welches zwar „einige Maschinenelemente [besitzt,] […] jedoch nicht [in Gänze] als Maschine erklärt werden kann“ (Mackenzie, 2018, 37-38), liegt, wie in diesem Abschnitt erläutert wird, eine Auslegung von Copilot als Maschine nahe. Dabei kann es als Künstliche Intelligenz mit Bezug auf Ernst Bloch als „vorerst letzte Maschine des Kapitals“ (Daum, 2019b, 325) betrachtet werden (Bloch, 1992, 15-17). Denn obwohl Copilot direkt zur Produktion firmeneigener Software und der damit einhergehenden Mehrwertproduktion eingesetzt wird, wird in diesem Abschnitt erläutert, dass Copilot ebenfalls „eine neue gesellschaftliche Betriebsweise […] konsolidier[t,] in der die Extraktion, Auswertung und Verwertung von Daten ins Zentrum der ökonomischen Aktivität gerät“ (Daum, 2019b, 325) und somit die ursprünglichen Funktionsweisen von Maschinen in der Mehrwertproduktion ergänzt.

Dequalifizierung der Programmierarbeit und Reduktion der benötigten Entwickler:innen

Analog zum industriellen Kapitalismus, in dem „die Maschinerie Muskelkraft entbehrlich macht“ (Marx, 1993, 416), ermöglicht Copilot im digitalen Kapitalismus eine zunehmende Entkopplung der Produktion von den menschlichen Programmierfähigkeiten. Copilot erstellt Softwarecode auf Basis von Eingabeaufforderungen, die im Kontext Künstlicher Intelligenz auch Prompts genannt werden. „[E]in Prompt […] enthält den Funktionsprototyp“, der Informationen über die für das Programm relevanten Parameter enthält, und „die Erklärung des Problems“ (Yetistiren et al., 2022, 63), das mit der gewünschten Ausgabe des Programms gelöst werden soll. Copilot kann diese „Prompts in Codevorschläge für dutzende Programmiersprachen umwandeln[, sodass] Entwickler:innen […] einfacher programmieren“ (Zhang et al., 2023, 15) können (Vaithilingam et al., 2022, 5). Um Programme und Software herzustellen, sind somit nicht mehr ausgereifte Porgrammierfähigkeiten notwendig. Es reicht, lediglich ein grundlegendes Verständnis davon zu haben, welche Probleme von was für Programmen gelöst werden können, und das Wissen über die dafür erforderlichen Parameter zu besitzen, mit denen über in natürlicher Sprache formulierte Prompts Code generiert werden kann. Somit bestimmt Copilot als „vom Kapital eingesetzte[s] Produktionsmittel […] nun die Fähigkeiten der Arbeitenden“ (Lotz, 2014, 20) signifikanter als die Arbeiter:innen, also Entwickler:innen, selbst. Es kommt zu einer „Dequalifizierung” (Kaplan, 2016/2017, 132) der Programmierarbeit.

Im industriellen Kapitalismus führte die Entbehrung der Muskelkraft dazu, dass die „Zahl der Lohnarbeiter […] durch Einreihung aller Mitglieder der Arbeiterfamilie, ohne Unterschied von Geschlecht und Alter“ (Marx, 1993, 416) erweitert wird. Im digitalen Kapitalismus führt die Entkopplung von Programmierfähigkeiten in der Softwareentwicklung dazu, dass „Entwickler:innen mit weniger Programmiererfahrung […] profitieren“ (Peng et al., 2023, 6) und sogar „Nicht-Programmierer:innen [über] das Schreiben von Spezifikationen“ (Chen et al., 2021, 10) Softwarecode erstellen können. Die Anzahl der potenziellen Entwickler:innen wird demnach ebenfalls erweitert.

Trotz dieser „Dequalifizierung“ (Kaplan, 2016/2017, 132) und der damit einhergehenden möglichen Einbindung von Menschen als potenzielle Entwickler:innen im Produktionsprozess kommt es durch den Einsatz von Copilot, wie beim Einsatz industrieller Maschinen, zu einer „Abnahme in der verhältnismäßigen Anzahl exploitierte[r] Arbeiter“ (Marx, 1993, 430), da sie durch die Fähigkeiten von Copilot nicht mehr in der Produktion benötigt werden (Kaplan, 2016/2017, 129). Als „KI pair programmer“ (Zhang et al., 2023, 2) ersetzt Copilot bei dieser Programmiertechnik den:die menschliche:n Treiber:in, der:die den Code schreibt. Dem:Der menschlichen Entwickler:in bleibt die Arbeit als Navigator:in, der:die „die Arbeit des Treibers beobachtet und kritisch über Mängel, strukturelle Probleme und alternative Lösungen nachdenkt und das Gesamtbild betrachtet“ (Imai, 2022, 320). Indem Copilot also dazu befähigt wurde, „dieselbe Arbeit zu verrichten, die früher der Arbeiter verrichtete“ (Marx, 1983, 599-600), treten menschliche Entwickler:innen „vielmehr als Wächter und Regulator zum Produktionsprozeß selbst“ (Marx, 1983, 601) auf.

Im Vergleich zu einem:einer menschlichen Pair-Programmierer:in fallen bei Copilot mit 19 US-Dollar pro Monat bei weitem geringere „Kosten [als] für einen zweiten Programmierer an[…]“ (Imai, 2022, 319) (GitHub Copilot, o. D.). Trotz dieser Lohneinsparungen sinkt der Mehrwert insgesamt, da dieser auf Ausbeutung der lebendigen Arbeit basiert und somit durch „die Rate des Mehrwerts und die Anzahl der gleichzeitig beschäftigten Arbeiter“ (Marx, 1993, 429) bestimmt ist (Lange, 2019, 48). Wird also weniger menschliche Arbeit benötigt, sinkt nicht nur die notwendige Arbeit, die durch die Softwareunternehmen entlohnt wird, sondern auch die mehrwertgenerierende Mehrarbeit. Um das Wegfallen der Entwickler:innen zu kompensieren, muss die Rate des Mehrwerts durch eine absolute oder relative Mehrwertsteigerung erhöht werden. Ersteres kann durch eine Erweiterung des Arbeitstages zu Gunsten einer steigenden Mehrarbeit entstehen, Zweiteres, indem die Arbeit produktiver gestaltet und somit die notwendige Arbeitszeit reduziert wird (Marx, 1993, 425-435).

Während es bisher keine Studien gibt, die sich mit der Auswirkung von Copilot auf den Arbeitstag befassen, ist, wie im folgenden Abschnitt dargelegt, die Produktivitätssteigerung in der Softwareproduktion durch Copilot in verschiedenen Publikationen untersucht worden (Chen et al., 2021; Zhang et al., 2023; Ziegler et al. 2022).

Produktivitätssteigerung und relativer Mehrwert

Eine Steigerung der Produktivität bedeutet, „den Arbeiter [dazu] zu befähigen, mit derselben Arbeitszeitausgabe in derselben Zeit mehr zu produzieren“ (Marx, 1993, 432). Eine solche „höhere Produktivität bei dem pair-programming mit Copilot [wurde] im Vergleich zu menschlichen Pair-Programmierern“ (Imai, 2022, 320) festgestellt. Dies wurde daran festgemacht, dass beim Pair-Programmieren mehr Softwarecode pro Zeit dem Softwareprojekt hinzugefügt wurde (Imai, 2022, 320; Zhang et al., 2023, 10). Es herrscht jedoch kein wissenschaftlicher Konsens darüber, ob die Qualität des mit Copilot generierten Codes gleichwertig, besser oder schlechter ist als die des ohne Copilot generierten Codes (Al Madi, 2022; Babar, 2022; Imai, 2022; Peng et al., 2023; Vaithilingam et al., 2022; Yetistiren et al., 2022; Zhang et al., 2023; Ziegler et al., 2023). Für die Produktivitätssteigerung in der Softwareproduktion durch Copilot ist die Qualität des Codes zwar ein Faktor, der diese negativ oder positiv beeinflussen kann, jedoch ist sie nicht der bestimmende Faktor. So liegt „der zentrale Wert von Copilot […] nicht darin, dass der Benutzer die größtmögliche Anzahl an [korrekten] Codezeilen generieren“ (Ziegler et al., 2022, 8). Vielmehr geht es darum, eine funktionierende Software oder ein Programm zu produzieren. Deswegen kann „ein Vorschlag, der als nützliche Vorlage zum Basteln dient, […] genauso gut oder besser sein als eine vollkommen korrekte (aber offensichtliche) Codezeile, die dem Benutzer nur ein paar Tastenschläge erspart“ (Ziegler et al., 2022, 8). Indem Peng et al. (2023) die Produktivität nicht an den einzelnen Codevorschlägen, sondern am gesamten Herstellungsprozess eines Programms untersucht haben, haben sie diese enge Fokussierung umgangen. Ihre Ergebnisse zeigen, dass die Entwickler:innengruppe, die Copilot benutzt, im Durchschnitt 71,17 Minuten für die Fertigstellung des Programms benötigt, während die Kontrollgruppe ohne Copilot durchschnittlich 160,98 Minuten benötigt. „Dies entspricht einer Verkürzung der Fertigstellungszeit um 55,8 %.“ (Peng et al., 2023, 5) Somit befähigt Copilot Entwickler:innen dazu, vollständige Programme in geringerer Zeit, also produktiver herzustellen.

Bei einer gleichbleibenden Arbeitszeit können daher mehr Softwareprogramme hergestellt werden. Diesem gesteigerten Gesamtprodukt wird jedoch aufgrund der unveränderten Arbeitszeit derselbe Wert zugesetzt wie vor der Produktivitätssteigerung. Der unveränderte Wert verteilt sich demnach auf mehr Softwareprogramme, wodurch „der Wert der einzelnen Ware sinkt“ (Marx, 1993, 43) (Chen et al., 2021, 12). „Der individuelle Wert dieser Ware steht nun unter ihrem gesellschaftlichen Wert, d. h. sie kostet weniger Arbeitszeit als […] [andere vergleichbare Waren, die] unter den gesellschaftlichen Durchschnittsbedingungen“ (Marx, 1993, 336), also ohne Copilot produziert wurden. Da sich der Tauschwert einer Ware an ihrem gesellschaftlich durchschnittlichen Wert misst, kann Software, die mit Copilot von firmeninternen Entwickler:innen hergestellt wurde, über ihrem individuellen Wert verkauft werden (Marx, 1993, 50-51, 336). Somit entsteht hier im Vergleich zur Produktion ohne Copilot ein relativ gesteigerter Mehrwertanteil, ein „Extramehrwert“ (Marx, 1993, 337).

Dieser Extramehrwert ist jedoch nur von kurzer Dauer, da er verschwindet, „sobald die neue Produktionsweise sich verallgemeinert und damit die Differenz zwischen dem individuellen Wert der wohlfeiler produzierten Waren und ihrem gesellschaftlichen Wert verschwindet“ (Marx, 1993, 337). Wenn also alle Softwareunternehmen für die Produktion ihrer Software Copilot einsetzen, verschwindet auch der Extramehrwert, da sich so der durchschnittliche Wert der gesamtgesellschaftlich produzierten Software an den individuellen Wert der Software von Softwareunternehmen angleicht, die als Early Adopter angefangen haben Copilot zu benutzen.

Um eine dauerhafte Steigerung des relativen Mehrwerts zu erreichen, bedarf es einer relativen Steigerung der Mehrarbeit im Vergleich zur notwendigen Arbeit, die durch eine Senkung des Werts der Arbeitskraft, also eine Reduktion des zur Reproduktion der Arbeitskraft notwendigen Arbeitsanteils erzielt wird (Marx, 1993, 333-335). „Um den Wert der Arbeitskraft zu senken, muss die Steigerung der Produktivität allerdings Industriezweige ergreifen, deren Produkte den Wert der Arbeit beeinflussen.“ (Berger, 2019, 112) Die Softwareproduktion stellt mittlerweile einen solchen arbeitswertbeeinflussenden Industriezweig dar, da heutzutage viele Produkte, die zumindest in Deutschland zum durchschnittlichen Lebensstandard gehören, wie Smartphones und die darauf befindlichen Apps, Autos, aber auch Haushaltsgeräte wie Kühlschränke, Staubsauger oder Zahnbürsten, Software enthalten. Durch einen verallgemeinerten Einsatz von Copilot in der Softwareproduktion sinkt somit der gesellschaftlich durchschnittliche Wert dieser Waren, was sich zumindest teilweise auch im Verkaufspreis wiederspiegelt. Die zur Reproduktion der Arbeitskraft und ihrer gesellschaftlich durchschnittlichen Lebensstandards notwendige Arbeitszeit wurde somit bei gleichbleibender Gesamtarbeitszeit relativ zur Mehrarbeit reduziert. Somit findet aufgrund einer Verallgemeinerung der Produktionsweise mittels Copilot eine relative Mehrwertsteigerung statt.

Die Produktion von Mehrwert über den General Intellect

Copilot konsolidiert jedoch auch eine vollkommen neue gesellschaftliche Betriebsweise, in der die Produktion von Mehrwert nicht auf der unmittelbaren Ausbeutung menschlicher Arbeitskraft in der Herstellung von Tauschwerten beruht (Daum, 2019b, 325). Die Entwickler:innenarbeit wird durch den Einsatz von Copilot im Produktionsprozess, wie schon zuvor ausführlich dargelegt, zu einem „subalterne[n] Moment“ (Marx, 1983, 586) in der unmittelbaren Produktion von firmeneigenem Softwarecode, da sie von Copilot teilweise ersetzt wird (Imai, 2022, 319). Die Produktion von firmeneigener Software wird demnach immer weniger abhängig „von der Arbeitszeit […] als von der Macht der Agentien [Copilot], die während der Arbeitszeit in Bewegung gesetzt werden“ (Marx, 1983, 600).

Durch diesen Wegfall der Entwickler:innenarbeit in der unmittelbaren Produktion wird zugleich „disposable time“ (Marx, 1983, 604), also frei verfügbare Zeit dieser Entwickler:innen freigesetzt. Mittels Copilot kann diese frei verfügbare Zeit jedoch auch verwertet werden. Denn jeglicher auf GitHub veröffentlichte Code erweitert das auf den Servern von GitHub in mehr als 74 Millionen Repositorien gespeicherte allgemeine Wissen in Form von Code, Software und Metadaten, das für den überwachten und unüberwachten Trainingsprozess von Copilot benutzt wird (Chen et al., 2021, 13; Kochhar et al., 2021, 1838; Kula et al., 2021, 1-2; Zhang et al., 2023, 15). Die Fähigkeit von Copilot, Code zu produzieren, basiert demnach auf dem auf GitHub vorhandenen und andauernd anwachsenden allgemeinen Wissen und kann als Anwendung dessen, als „vergegenständlichte Wissenskraft“ (Marx, 1983, 602) betrachtet werden. Somit trägt auch die Produktion von nicht firmeneigener Software in der frei verfügbaren Zeit von Entwickler:innen wie beispielsweise die Produktion von FOSS zu dem allgemeinen Wissen auf GitHub bei und stellt somit eine Verbesserung von Copilot, also eine „Produktion von Mitteln zur Wertschöpfung“ (Marx, 1983, 605) dar. Denn Copilot wird nicht nur zur Produktion von FOSS, sondern auch zur Herstellung von firmeneigener Software benutzt, in der ein Mehrwert produziert wird (Daum, 2019a, 149; Wolfram, 2023, 47-48).

In diesem Prozess stellen die Entwickler:innen „Produser[…]“ (Vogl, 2021, 78) dar. Dieser von Axel Bruns eingeführt und von Joseph Vogl übernommene Neologismus setzt sich aus den Wörtern Produzent:in und User zusammen und beschreibt „die unmerklich oder nebenbei verrichtete Produktionstätigkeit im Netzgebaren von Nutzern oder Usern“ (Vogl, 2021, 78). Indem Entwickler:innen GitHub und Copilot zur Produktion von FOSS benutzen, produzieren sie andauernd Daten und Metadaten in Form von Softwarecode und Informationen über diesen Softwarecode und dessen Herstellung. Diese „Informationen und Daten sind vergegenständlichte kognitive Fähigkeiten der Menschen und damit auch Arbeitsprodukte“ (Sevignani, 2019, 298). Als solche können sie, „ohne dass es [den Entwickler:innen] bewusst sein muss, […] einen Wert [schaffen], der erfasst und angeeignet werden kann“ (Hardt & Negri, 2017/2018, 160-161) (Fuchs, 2014, 28, 354; Vogl, 2021, 81). Die Daten und Metadaten stellen dabei zwar keine „unmittelbar realisierbare[n] Tauschwerte“ (Marx, 1983, 603) dar, jedoch werden sie und damit auch ihr Wert in Copilot als „Inkarnation des general intellect“ (Kjøsen, 2018, 170) zentralisiert und zur Produktion von Software eingesetzt, wodurch sich der in ihnen manifestierte Wert in Wertteilen auf die Software überträgt (Birkinbine, 2020, 40; Pasquinelli, 2019; Sevignani, 2019, 279-280).

Die Einführung von Copilot in der Produktion von Software hat demnach einerseits die Tendenz, „disposable time zu schaffen“ (Marx, 1983, 604), indem die für die Produktion von firmeneigener Software benötigte Arbeitszeit auf Kosten des Mehrarbeitsanteils gesenkt wird. „[A]ndererseits to convert it [disposable time] into surplus labour“ (Marx, 1983, 604), indem die nicht für ein Softwareunternehmen in der frei verfügbaren Zeit stattfindende Produktion von FOSS als ‚Produserarbeit‘ für die Produktion von firmeneigener Software mittels Copilot verwertet werden kann. Dabei ist die Mehrwert produzierende Produserarbeit lediglich durch den Anteil „notwendige[r] Arbeitszeit“ innerhalb einer abseits von GitHub stattfindenden Lohnarbeit, die zur Befriedigung der notwendigen „Bedürfnisse[…] des gesellschaftlichen Individuums“ (Marx, 1983, 604) notwendig ist, begrenzt. Demnach ermöglicht Copilot eine Entkopplung der Mehrwertproduktion von der unmittelbaren Herstellung firmeneigener Software und führt hin zu einer Mehrwertproduktion, die durch den Entwicklungsstand des auf GitHub vorhandenen Wissens, also durch jegliche Produktion von Software auf GitHub bestimmt ist.

In seinem Maschinenfragment (Marx, 1983, 590-609) schreibt Marx, dass der General Intellect sich nur in der „disposable time“ (Marx, 1983, 604), also außerhalb der Produktion von firmeneigenen Waren weiterentwickelt. Auf GitHub ist eine solche Weiterentwicklung des General Intellects, also des Codes und der damit verbundenen Daten und Metadaten, jedoch auch während der Produktion firmeneigener Software sowohl bei lohnarbeitenden firmeninternen Entwickler:innen als auch bei externen Entwickler:innen möglich. Es entsteht somit eine Gleichzeitigkeit, die sich darin äußert, dass der von an firmeneigener Softwareproduktion beteiligten ‚Produsern‘ hergestellte Code nicht nur als fertige Software über den Markt verkauft wird, sondern auch als Wissen in die Verbesserung und somit Produktivitätssteigerung von Copilot einfließt. Die „unmittelbare Produktion“ (Marx, 1983, 603) stellt somit paradoxerweise zugleich „die Produktion der Mittel der Produktion“ (Marx, 1983, 603) dar.

 

Literaturverzeichnis

Al Madi, N. (2022, 10-14. Oktober). How Readable is Model-generated Code? Examining Readability and Visual Inspection of GitHub Copilot [Konferenzbeitrag]. 37th IEEE/ACM International Conference on Automated Software Engineering (ASE ’22), Rochester, Vereinigte Staaten von Amerika. doi.org/10.1145/3551349.3560438

Alpaydin, E. (2014). Introduction to Machine Learning (3. Aufl.). O’Reilly Verlag GmbH.

Amlinger, C. (2017). Klaus Dörre: Die neue Landnahme. In K. Kraemer & F. Brugger (Hrsg.), Schlüsselwerke der Wirtschaftssoziologie (1. Aufl., 471-480). Springer Fachmedien Wiesbaden. doi.org/10.1007/978-3-658-08184-3_54

Babar, A. (2022). Programmer’s New Friend: GitHub Copilot. International Journal of Research Publication and Reviews, 3(11), 2721-2725.

Berger, M. (2013). Karl Marx „Das Kapital“ (3. Überarb. Aufl.). UTB.

Birkinbine, B. J. (2020). Incorporating the digital commons: Corporate Involvement in Free and Open Source Software. University of Westminster Press.

Blischak, J. D., Davenport, E. R. & Wilson, G. (2016). A Quick Introduction to Version Control with Git and GitHub. PLoS Computational Biology, 12(1), 1-18. https://doi:10.1371/journal.pcbi.1004668

Bloch, E. (1992). Erbschaft dieser Zeit (2. Aufl.). Suhrkamp.

Build software better, together. (o. D.). GitHub. Abgerufen am 05. Januar 2024, von github.com/about

Daigle, K. (2023, 4. Dezember). Octoverse: The state of open source and rise of AI in 2023 – the GitHub blog. The GitHub Blog. github.blog/2023-11-08-the-state-of-open-source-and-ai/

Daum, T. (2019a). Die künstliche Intelligenz des Kapitals. (1. Aufl.) Edition Nautilus

Daum, T. (2019b). Künstliche Intelligenz als vorerst letzte Maschine des digitalen Kapitals. In F. Butollo & S. Nuss (Hrsg.), Marx und die Roboter: Vernetzte Produktion, Künstliche Intelligenz und lebendige Arbeit (1. Aufl., 311-326). Karl Dietz Verlag Berlin.

Dörre, K. (2012). Landnahme, das Wachstumsdilemma und die „Achsen der Ungleichheit“. Berliner Journal für Soziologie, 22(1), 101–128. doi.org/10.1007/s11609-012-0176-1

Dörre, K. (2019). Kritische Theorie und Krise: Landnahme an den Grenzen kapitalistischer Dynamik. In U. H. Bittlingmayer, A. Demirović & T. Freytag (Hrsg.), Handbuch Kritische Theorie (953-980). Springer Fachmedien Wiesbaden. doi.org/10.1007/978-3-658-12695-7_52

Dohmke, T. (2023, 25. Januar). 100 million developers and counting – the GitHub blog. The GitHub Blog. github.blog/2023-01-25-100-million-developers-and-counting

Eder, B. (2023). Das Denken der Maschine: Marx, Mumford, Simondon. mandelbaum verlag.

Feller, J., Fitzgerald, B., Hissam, S. & Lakhani, K. R. (2005). Introduction. In J. Feller, B., Fitzgerald & K. R Lakhani (Hrsg.), Perspectives on Free and Open Source Software (1. Aulf., i- xxiii). MIT Press. doi.org/10.7551/mitpress/5326.001.0001

Frings, C. (2019). Sklaverei und Lohnarbeit bei Marx: Zur Diskussion um Gewalt und „unfreie Arbeit“ im Kapitalismus. PROKLA. Zeitschrift für kritische Sozialwissenschaft,49(196), 427-448. doi.org/110.32387/prokla.49.196.1836

Fuchs, C. (2014). Digital Labour and Karl Marx. Routledge.

Fuchs, C. (2021). Social media: A Critical Introduction (1. Aufl.). Sage Publications Limited.

Get the complete developer platform. (o. D.). GitHub. Abgerufen am 05. Januar 2024, von github.com/pricing

Gnisa, F. (2019). Das Maschinensystem des 21. Jahrhunderts? Zur Subsumption der Kommunikation durch digitale Plattformtechnologien. In F. Butollo & S. Nuss (Hrsg.), Marx und die Roboter: Vernetzte Produktion, Künstliche Intelligenz und lebendige Arbeit (1. Aufl., 276-292). Karl Dietz Verlag Berlin.

Hardt, M. & Negri, A. (2018). Assembly: Die neue demokratische Ordnung (T. Atzert & A. Wirthensohn, Übers.). Campus Verlag. (Originalwerk veröffentlicht 2017)

Imai, S. (2022, 21-29. Mai). Is GitHub copilot a substitute for human pair-programming? [Konferenzbeitrag] 44th International Conference on Software Engineering Companion (ICSE ’22 Copanion), Pittsburgh, Vereinigte Staaten von Amerika. doi.org/10.1145/3510454.3522684

Kalliamvakou, E., Damian, D., Blincoe, K., Singer, L. & German D. M. (2015, 16-24. Mai). Open Source-Style Collaborative Development Practices in Commercial Projects Using GitHub [Konferenzbeitrag]. 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, Florenz, Italien. doi.org/10.1109/ICSE.2015.74

Kaplan, J. (2017). Künstliche Intelligenz (1 Aufl., G. Lenz, Übers.). mtip. (Originalwerk veröffentlicht 2016)

Kjøsen, A. M. (2018). Träumen Androiden vom Mehrwert?. Maske und Kothurn: Internationale Beiträge zur Theater-, Film und Medienwissenschaft, 64 (1-2), 144-181.

Kochhar, P. S., Kalliamvakou, E., Nagappan, N., Zimmermann, T. & Bird, C. (2021). Moving from closed to open Source: Observations from six transitioned projects to GitHub. IEEE Transactions on Software Engineering, 47(9), 1838-1856. doi.org/10.1109/tse.2019.2937025

Kula, G. R., Hata, H. & Matsumoto, K. (2021) FLOSS != GitHub: A case study of Linux/BSD perceptions from Microsoft’s acquisition of GitHub. arXiv (Cornell University). doi.org/10.48550/arxiv.2102.01325

Lange, E. L. (2019). „Heißhunger nach Mehrarbeit“: Mit Marx die digitale Revolution verstehen. In F. Butollo & S. Nuss (Hrsg.), Marx und die Roboter: Vernetzte Produktion, Künstliche Intelligenz und lebendige Arbeit (1. Aufl., 38-54). Karl Dietz Verlag Berlin.

Lederer, A. (2021). GitHub – eine praktische Einführung. O’Reilly.

Lotz, C. (2014). Kommunismus des Kapitals?. In C. Amlinger & C. Baron (Hrsg.), Christian Lotz zu Karl Marx: Das Maschinenfragment. (7-48). LAIKA-Verlag Hamburg.

Lukács, G. (1971). History and Class Consciousness: Studies in Marxist Dialectics (R. Livingstone, Übers.). MIT Press. (Originalwerk veröffentlicht 1968)

Luxemburg, R. (1975). Die Akkumulation des Kapitals: Ein Beitrag zur ökonomischen Erklärung des Imperialismus. In R. Luxemburg (Hrsg.), Gesammelte Werke 5 (5-412). Dietz Verlag Berlin

Mackenzie, A. (2018). 48 million configurations and counting: platform numbers and their capitalization. Journal of Cultural Economy, 11(1), 36–53. doi.org/10.1080/17530350.2017.1393443

Marx, K. (1962). Lohn, Preis und Profit. In K. Marx & F. Engels, Marx Engels Werke 16 (1. Aufl., 103–152). Dietz Verlag Berlin.

Marx, K. (1983). Grundrisse der Kritik der politischen Ökonomie. In K. Marx & F. Engels, Marx Engels Werke 42 (1. Aufl., 47-768). Dietz Verlag Berlin.

Marx, K. (1993). Das Kapital: Kritik der politischen Ökonomie: Erster Band. Der Produktinosprozeß des Kapitals. In K. Marx & F. Engels, Marx Engels Werke 23 (18. Aufl., 5-802). Dietz Verlag Berlin.

Microsoft Corporate Blogs (2018, 6. Dezember). Microsoft completes GitHub acquisition – the official Microsoft blog. The Official Microsoft Blog. blogs.microsoft.com/blog/2018/10/26/microsoft-completes-github-acquisition/

Microsoft Corporate Blogs (2023, 7. Februar). Microsoft and OpenAI extend partnership – the official Microsoft blog. The Official Microsoft Blog. blogs.microsoft.com/blog/2023/01/23/microsoftandopenaiextendpartnership/

Nachtwey, O. & Staab, P. (2015). Die Avantgarde des digitalen Kapitalismus. Mittelweg 36, 6, 59-84.

O’Neil, M., Cai, X., Muselli, L., Pailler, F. & Zacchiroli, S. (2021). The Coproduction of Open Source Software by Volunteers and Big Tech Firms. Digital Commons Policy Council.

O’Neil, M., Muselli, L., Cai, X. & Zacchiroli, S. (2022). Co-producing industrial public goods on GitHub: selective firm cooperation, volunteer-employee labour and participation inequality. New Media & Society, 0(0) 1-37. doi.org/10.1177/14614448221090474

Pasquinelli, M. (2019). On the origins of Marx’s general intellect. Radical Philosophy, 2(6), 43-56.

Peng, S., Kalliamvakou, E., Cihon, P. & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv (Cornell University). doi.org/10.48550/arXiv.2302.06590

Perez-Riverol, Y., Gatto, L., Wang, R., Sachsenberg, T., Uszkoreit, J., Leprevost, F. d. V., Fufezan, C., Ternent, T., Eglen, S. J., Katz, D. S., Pollard, T. J., Konovalov, A., Flight, R. M., Blin, K. & Vizacíno, J. A. (2016). Ten Simple Rules for Taking Advantage of Git and GitHub. PLoS Computational Biology, 12(7), 1-11. doi.org/10.1371/journal.pcbi.1004947

Radford, A., & Narasimhan, K., Salimans, T. & Sutskever, I. (2018). Improving Language Understanding by Generative Pre-Training, OpenAI, 1-12. openai.com/research/language-unsupervised

Riehle, D., Riemer, P., Kolassa, C. & Schmidt, M. (2014, 6-9. Januar). Paid vs. Volunteer Work in Open Source [Konferenzbeitrag]. 47th Hawaii International Conference on System Sciences, Waikoloa, Vereinigte Staaten von Amerika. doi.org/10.1109/HICSS.2014.407

Rodríguez Miglio, M. (2018). Understanding Outsourcing and Subcontracting: An Approach from the Theory of Surplus Value. Latin American Perspectives, 45(6), 114-126. doi.org/10.1177/0094582X18791966

Sevignani, S. (2019). Digitale Arbeit und Prosumption im Kapitalismus. In F. Butollo & S. Nuss (Hrsg.), Marx und die Roboter: Vernetzte Produktion, Künstliche Intelligenz und lebendige Arbeit (1. Aufl., 293-310). Karl Dietz Verlag Berlin.

Srnicek, N. (2018). Plattform-Kapitalismus (2. Aufl., U. Schäfer, Übers.). Hamburger Edition HIS. (Originalwerk veröffentlicht 2017)

Staab, P. (2019). Digitaler Kapitalismus: Markt und Herrschaft in der Ökonomie der Unknappheit. Suhrkamp Verlag Berlin.

Vaithilingam, P., Zhangm, T. & Glassman, E. L. (2022, 29-5. April-Mai). Expectations vs. Experience: Evaluating the Usability of Code Generation Tools Powered by Large Language Models [Konferenzbeitrag]. CHI-Conference on Human Factors in Computing Systems Extended Abstracts (CHI’22 Extended Abstracts), New Orleans, Vereinigte Staaten von Amerika. doi.org/10.1145/3491101.3519665

Vogl, J. (2021). Kapital und Ressentiment: Eine kurze Theorie der Gegenwart. Verlag C.H. Beck.

Wolfram, S. (2023). What is ChatGPT doing . . . and why does it work?. Wolfram Media.

Yetistiren, B., Ozsoy, I. & Tuzun, E. (2022, 17. November). Assessing the Quality of GitHub Copilot’s Code Generation [Konferenzbeitrag]. Proceedings of the 18th International Conference on Predictive Models and Data Analytics in Software Engineering (PROMISE ’22), Singapur, Singapur. doi.org/10.1145/3558489.3559072

Zhang, X., Wang, T., Yu, Y., Zeng, Q., Li, Z. & Wang, H. (2022, 29-5. April-Mai). Who, What, Why and How? Towards the Monetary Incentive in Crowd Collaboration: A Case Study of Github’s Sponsor Mechanism [Konferenzbeitrag]. CHI-Conference on Human Factors in Computing Systems Extended Abstracts (CHI’22 Extended Abstracts), New Orleans, Vereinigte Staaten von Amerika. doi.org/10.1145/3491101.3519665

Zhang, B., Peng, L., Zhou, X., Ahmad, A. & Waseem, M. (2023). Demystifying practices, challenges and expected features of using GitHub Copilot. International Journal of Software Engineering and Knowledge Engineering. doi.org/10.48550/arxiv.2309.05687

Ziegler A., Kalliamvakou, E., Simister, S., Sittampalam, G., Li, A., Rice, A., Rifkin D. & Aftandilian E. (2022, 13. Jun). Productivity Assesment of Neural Code Completion [Konferenzbeitrag]. Proceedings of the 6th ACM SIGPLAN International Symposium on Machine Programming (MAPS ’22), San Diego, Vereinigte Staaten von Amerika. doi.org/10.1145/3520312.3534864

Tags: Git, Marx, Open Source, Produktivkraftentwicklung