Ich musste im vergangenen fünften Semester insgesamt drei Hausarbeiten schreiben, weswegen ich eine schon während des laufenden Semesters beginnen wollte, um auch ja rechtzeitig fertig zu werden – Oma Gröner läuft halt nicht mehr so schnell – und das war diese hier. Das heißt, ich hatte bei ihr nicht den konzentrierten Luxus, den ich bei den beiden Geschichtshausarbeiten hatte, die ich nach Vorlesungszeitende schrieb: Ich hatte noch Seminare, musste Hausaufgaben machen und für die Klausuren lernen, und dann schrieb ich zwischendurch eben noch eine dicke Hausarbeit, las bergeweise Bücher, schrieb wieder, las bergeweise Aufsätze, schrieb und las und schrieb und wusste bei den ganzen Ablenkungen zum Schluss nicht mehr, ob das total toll oder total mies war, was ich produziert hatte.

Diesen Punkt des Zweifels erreiche ich irgendwann bei jeder Arbeit, weil ich schließlich jeden Satz 800 Mal gelesen, korrigiert und nochmal gelesen und nochmal korrigiert habe – ich sehe ab einem gewissen Zeitpunkt den Sinn vor lauter Buchstaben nicht mehr und kann qualitativ nicht mehr einschätzen, was ich da lese. Aber bei der hier war ich besonders verwirrt, vor allem, weil ich noch das Feedback meiner sechs Reviewer*innen habe einfließen lassen und daher nochmal über alles gegangen bin.

Scheint aber ganz okay geworden zu sein, wenn ich mir die Mail des Dozenten anschaue, die gestern abend kam:

„Eine solche Note habe ich, glaube ich, noch nie vergeben, musste mich aber fragen, ob ein Argument dagegen spricht. Vielmehr möchte ich Sie fragen, ob ich diesen Text verwenden darf, um ihn anderen Studierenden als vorbildliches Muster für Aufbau und Bibliographie weiterzugeben.“

Darf der Dozent natürlich. Das kleine Fünftsemester ist sehr geschmeichelt.

Zum Inhalt: Mein Referatsthema lautete schlicht „Software“. Anstatt Computergeschichte nachzuerzählen, habe ich im Referat versucht, die vielen Möglichkeiten aufzuzeigen, in denen Software in der Kunstgeschichte (oder der Kunst) zum Einsatz kommt. Ich begann natürlich mit den (haha) Basics, erzählte von Closed-Source-Software und dem Weg zu Open Source, erwähnte Die Kathedrale und der Basar und wandte einige der dort erwähnten Prinzipien zur Softwareproduktion auf die Kunstgeschichte an. Mein Hauptaugenmerk lag auf dem kollaborativen Arbeiten; ich erwähnte Beispiele wie Madison, ARTigo oder das Brooklyn Museum, das sich über Hinweise von Besuchern freut anstatt großkotzig darüberzustehen, was der Pöbel will. („… and we welcome any additional information you might have.“)

Ich sprach über Clay Shirkys Publish first, filter later, über Open Access, über die vergrößerte Sichtbarkeit und bessere Korrigierbarkeit von Texten in e-Books und Blogs und erwähnte meine eigene Hausarbeit, die in den ersten zehn Tagen nach Veröffentlichung beachtliche 230 Mal heruntergeladen wurde – und ich behaupte, ich habe nicht unbedingt viele Kunsthistoriker*innen unter meinen Leser*innen. Ich sprach über Jeff Koons‘ Instagram-Account (der inzwischen arg leergefegt aussieht), dass Vorzeichnungen von Gemälden quasi Betaversionen seien und dass heute alles im Fluss sei – wie auch bei Software, die nie fertig wird und stets ein Update bekommt.

Aus diesem Sammelsurium wünschte sich der Dozent eine Arbeit über die veränderten Publikationsmöglichkeiten für Kunsthistoriker*innen. Das ist sicherlich kein speziell kunstwissenschaftliches Thema – auch die Naturwissenschaft arbeitet mit Open Access –, aber für mich persönlich war es sehr reizvoll, sich intensiver mit diesem Thema auseinanderzusetzen, gerade weil ich eine Freundin des Teilens bin, des offenen und unbeschränkten Zugangs zu Informationen und des Austauschs von Wissen. Und nebenbei habe ich viel über Computer- und Softwaregeschichte gelernt. (Das zitierte Buch von Walter Isaacson – The Innovators: How a Group of Inventors, Hackers, Geniuses and Geeks Created the Digital Revolution – liest sich übrigens wie geschnitten Brot, auch aus feministischer Perspektive.)

Hatte ich schon auf Twitter erledigt, aber hier noch mal der Dank an meine Reviewer*innen, die mir sehr geholfen haben.

Enjoy. Mach’s gut, fünftes Semester.

(1,0. Sehr glücklich.)

Ein weiteres Problem von Softwaregeschichte ist die Vergänglichkeit des Subjekts. Durch die äußerst dynamische Entwicklung des Computers veränderte sich Software sehr oft und sehr schnell; viele der ersten Betriebssysteme und Programme sind für uns heute verloren, und selbst wenn wir sie besitzen, sind sie für uns unzugänglich, weil die Hardware für sie nicht mehr existiert. Emulatoren können die Programme zwar simulieren, aber sie vermitteln nicht das unmittelbare Erlebnis, das ein Computernutzer oder eine -nutzerin vor einem halben oder dreiviertel Jahrhundert hatte.[1] Die Aura des Originals, die gerade der Kunstgeschichte so wichtig ist, bleibt verloren.[2]

[…]

Aber auch wenn über den Computer bzw. über Software noch keine eindeutige Geschichte mit einer definierten Zielrichtung geschrieben werden kann, ist klar, dass beides die Welt verändert hat.[3] Historiker und Historikerinnen sind meist vorsichtig mit dem Begriff der Revolution; auch Michael S. Mahoney nutzte ihn in seinem Essay bewusst nicht.[4] Stattdessen wies er darauf hin, dass der Begriff der Revolution gerne die Kontinuität von Ereignissen ignoriere, bei der eine Entwicklung einer vorausgegangenen folge.[5]

Der Technikjournalist Walter Isaacson schreckte hingegen vor dieser Vokabel nicht zurück. Er beschrieb in The Innovators (2014) ein scheinbares Paradoxon, das für ihn Teil einer digitalen Revolution ist: Ein Arbeitsgerät, das für einen einzelnen User geschaffen wurde, wurde durch das Internet – einer Infrastruktur aus Hard- und vor allem Software – Teil eines weltumspannenden Netzwerks. Dieses machte aus einzelnen viele User und schuf damit erstmals die Möglichkeit, fast unbegrenzt und in sehr kurzer Zeit weltweit kreative Ideen und Wissen auszutauschen.[6]

[…]

Diese Befehle bezeichnen wir heute als Software.[7]

Software ist, im Unterschied zu Hardware, ein nicht-physischer Funktionsbestandteil eines Computers.[8] Nicht nur das Betriebssystem, auch die Programme werden als Software bezeichnet (System- bzw. Anwendungssoftware).[9] Beide Arten von Software liegen hauptsächlich in zwei Versionen vor: als Quellcode (source code) sowie als Binärcode (binary code). Der Quellcode wird in Programmiersprachen geschrieben und ist für Menschen verständlich und lesbar. Durch einen Compiler[10] wird er für den Rechner in Binärcode übersetzt, der von Menschen kaum mehr lesbar ist, dafür aber vom Computer verstanden wird.[11]

Für eine der ersten Programmiersprachen (FORTRAN, 1957 entwickelt) hatte der Compiler vor allem eine Aufgabe: einem bestimmten Rechner möglichst viele Informationen möglichst effizient zu vermitteln. Im Laufe der folgenden Jahre änderte sich diese Stoßrichtung: Bereits zu Anfang der 1960er Jahre lag der Schwerpunkt von Compilern darauf, maschinenübergreifend Informationen lesbar zu machen. Das heißt, ein Programm konnte auf unterschiedlichen Rechnern laufen und war nicht mehr an einen bestimmten Hardwaretyp gebunden.[12]

In den 1960er und 1970er Jahren entstanden verschiedene Arten von Programmiersprachen und Systemsoftware, die das gleiche Ziel hatten: rechnerübergreifend zu arbeiten. Sie kamen vor allem aus der Universität von Berkeley, Kalifornien, dem Massachusetts Institute of Technology (MIT) sowie den kommerziellen Forschungszentren von AT&T in New Jersey (Bell Laboratories bzw. Bell Labs) und Xerox in Kalifornien (Palo Alto Research Center bzw. Xerox PARC).[13] In den Bell Labs entstanden sowohl die Programmiersprache C als auch das Betriebssystem UNIX, das in C programmiert wurde.[14]

1. Vgl. zu diesem Absatz Mahoney, Michael Sean: „What Makes the History of Software Hard“, in: IEEE Annals of the History of Computing 30, Ausgabe 3 (2008), S. 8–18, hier S. 14.
2. Vgl. Benjamin, Walter: Das Kunstwerk im Zeitalter seiner technischen Reproduzierbarkeit, Berlin 2010, S. 15/16.
3. Selbst die Teile der Welt, in denen Computer noch kein gängiges Arbeits- oder Unterhaltungsmittel sind. So schreibt Thomas J. Misa: „In today‘s global economy, a country or region that might entirely lack access to computing still has a relationship with the computer-mediated global economy through trade and travel, even if it is entirely frozen out of such trade.“ Vgl. Misa, Thomas J.: „Unterstanding ‚How Computing Has Changed the World‘“, in: IEEE Annals of the History of Computing 29, Ausgabe 4 (2007), S. 52–63, hier S. 53.
4. Vgl. Mahoney 2008, S. 10: „The main problem with the revolutionary or impact model is that it attributes agency to the computer as if it had a nature of its own that it could impose on subjects or activities to which it is applied, that is, as if the computer in and of itself had the power to transform those activities.“
5. Vgl. Mahoney 2008, S. 10.
6. Vgl. zu diesem Absatz Isaacson, Walter: The Innovators. How a Group of Hackers, Geniuses, and Geeks Created the Digital Revolution, New York 2014, S. 32 von 894 (e-Book).
7. Laut Leimbach 2010, S. 8, gibt es bis heute keine „eindeutige, internationale Definition, was Software ist und was sie umfasst“. Leimbach zählt auch die Dokumentation sowie die Bedienungsanleitung eines Programms zu Software, vgl. Leimbach, Timo: Die Geschichte der Softwarebranche in Deutschland. Entwicklung und Anwendung von Informations‐ und Kommunikationstechnologie zwischen den 1950ern und heute, München 2010, ebd..
8. Meine Definition von Software beschränkt sich, im Gegensatz zu der Leimbachs, vgl. die vorherige Fußnote, auf den simplen Unterschied zwischen den fassbaren und den unfassbaren Teilen eines Rechners und folgt von Engelhardt, Sebastian: „Die ökonomischen Eigenschaften von Software“, in: Jenaer Schriften zur Wirtschaftswissenschaft 14 (2006), S. 1–21, hier S. 1.
9. Diese Unterscheidung existiert seit der Mitte der 1950er Jahre. Die Trennung in zwei Arten von Software ermöglichte es erstmals, einen Computer für unterschiedliche Aufgaben zu nutzen. Die Systemsoftware übernimmt die Grundfunktionen des Rechners, während Anwendungssoftware für einzelne Aufgaben bestimmt ist. Vgl. Mahoney, Michael Sean: Histories of Computing, Cambridge/Mass. 2011, S. 21., S. 82/83.
10. Neben reinen Binär- und Quellcodes gibt es Mischformen wie z. B. Pseudo-Code, ein Quellcode, der ohne einen Compiler zu Binärcode wird, vgl. das Linux Dictionary im Linux Documentation Project, http://www.tldp.org/LDP/Linux-Dictionary/html/p.html [zuletzt abgerufen am 9.2.2015].
11. Vgl. zu Quellcode und Binärcode von Engelhardt 2006, S. 1.
12. Vgl. zu Compilern und ihren Zielen Mahoney 2011, S. 81/82.
13. Vgl. Lerner, Josh/Tirole, Jean: „Some Simple Economics of Open Source“, in: The Journal of Industrial Economics 50, Ausgabe 2 (2002), S. 197–234, hier S. 200/201.
14. So gut wie alle Programmiersprachen, die noch heute die Basis für System- und Anwendungssoftware bilden, wurden vor 1975 entwickelt, vgl. Mahoney 2011, S. 79.