Agilität, Versionierung und Open Source. Softwareentwicklung und Praktiken der Geisteswissenschaften

Views
11113
Downloads
13
Editorial Pre-Review
Version
1.0
Arndt Niebisch Autoreninformationen

DOI: 10.17175/sb003_009

Nachweis im OPAC der Herzog August Bibliothek: 1011381583

Erstveröffentlichung: 27.06.2018

Lizenz: Sofern nicht anders angegeben Creative Commons Lizenzvertrag

Medienlizenzen: Medienrechte liegen bei den Autoren

Letzte Überprüfung aller Verweise: 22.06.2018

GND-Verschlagwortung: Softwareentwicklung | Projektmanagement | Agilität | Digital Humanities |

Empfohlene Zitierweise: Arndt Niebisch: Agilität, Versionierung und Open Source. Softwareentwicklung und Praktiken der Geisteswissenschaften. In: Wie Digitalität die Geisteswissenschaften verändert: Neue Forschungsgegenstände und Methoden. Hg. von Martin Huber / Sybille Krämer. 2018 (= Sonderband der Zeitschrift für digitale Geisteswissenschaften, 3). text/html Format. DOI: 10.17175/sb003_009

Abstract

Die Digital Humanities eröffnen neue Wege sich literarischen oder historischen Quellen zu nähern. Sie ermöglichen eine breit angelegte Datenanalyse von kulturellen Artefakten, und darin kann sicherlich das innovative Potenzial der Digital Humanities gesehen werden. In diesem Beitrag möchte ich aber diskutieren, wie der tatsächlich disruptive Einfluss der Digital Humanities daher kommen könnte, dass sie die kollaborativen Praktiken der Softwareentwicklung in die geisteswissenschaftliche Forschung einführen, um mit den Komplexitäten der digitalen Welt umzugehen.

The Digital Humanities open up the possibility to access literary and historical sources in new ways. They enable the large-scale data analysis of cultural artifacts, which can be understood as the highly innovative potential of the Digital Humanities. However, in this article I argue that the truly disruptive power of the Digital Humanities could come from the necessity of introducing collaborative practices from software development into humanities research in order to deal with the complexities of the digital realm.


1. Die Austreibung des Geistes aus den Geisteswissenschaften

Wenn Historiker in einiger Zeit auf die ersten zwei Dekaden des zweiten Jahrtausends zurückblicken, werden sie aller Wahrscheinlichkeit eine Welt im Wandel erkennen, die nicht nur von großen geopolitischen und kulturellen Konflikten gekennzeichnet war, sondern die starken technologischen Veränderungen unterlag. Aus heutiger Perspektive ist es noch höchst unklar, wie sich dieser technologische Wandel konkret weiter fortsetzen wird, aber es ist klar, dass die Digitalisierung dabei eine entscheidende Rolle spielen wird.

Verschiedenste Szenarien dieses digitalen Wandels werden momentan angeboten und erzählen die Geschichte einer neuen Arbeitswelt, in der die Digitalisierung die Arbeit von Anwälten, Steuerberatern und Ärzten so übernehmen wird, wie es die Maschinen in den industriellen Revolutionen der letzten Jahrhunderte in der Landwirtschaft, im Handwerk oder in der Textilproduktion getan haben. Neue Technologien wie AI, Big Data oder Block Chain werden oft als »disruptiv« gekennzeichnet, was bedeuten soll, dass sie solche einschneidende Veränderungen lostreten werden, dass bald nichts mehr so sein wird, wie es bisher war.[1] Die Disruption der Digitalisierung besteht dabei u.a. darin, dass im Finanz- und Verwaltungssektor die menschlichen, kognitiven Fähigkeiten durch maschinelle Intelligenzen abgelöst werden: die Austreibung des Geistes aus den Behörden und den Schreibstuben.[2]

Friedrich Kittler hat eine Austreibung des Geistes aus den Geisteswissenschaften bereits vor einiger Zeit beschworen, die »Programme«, die dies leisten sollten, hatten zwar schon etwas mit dem Computer zu tun, aber waren eher vom Computer als Lese-/Schreibmaschine inspiriert, als dass sie den Computer als etwas begriffen, das die Arbeit des Geisteswissenschaftlers übernehmen und so den menschlichen Geist ein Stück aus den Geisteswissenschaften verbannen würden; es ging bei Kittler vielmehr darum, dass die geisteswissenschaftliche Hermeneutik nicht Produkt des inspirierten menschlichen Geistes sondern ein Ergebnis von Informationsströmen und Nachrichtenverarbeitung war.[3] Die Digital Humanities, auch wenn sie sehr wenig mit einer Medienwissenschaft à la Kittler zu tun haben,[4] verändern die Geisteswissenschaften genau dahin, dass nicht nur Literatur sondern auch die literaturwissenschaftliche Analyse als eine Form von Datenverarbeitung betrachtet wird.[5]

Die Digital Humanities liefern durch diese Einbindung digitaler Verfahren neue Werkzeuge und Fragestellungen. Im philologischen Bereich treten sie besonders durch die Enkodierung von Texten in XML (TEI)-Format und quantitative Verfahren wie dem »Distant Reading« hervor.[6] Auch wenn diese Werkzeuge und Methoden neue Möglichkeiten des wissenschaftlichen Arbeitens anbieten, scheinen sie wenig disruptiv zu sein, und gliedern sich als Alternativen in den wissenschaftlichen Betrieb ein.[7] Das Auftauchen der Digital Humanities löst keinen neuen fundamentalen Methodenstreit aus, wie er bspw. in den siebziger und achtziger Jahren tobte und die verschiedensten Angebote von dekonstruktiven, psychoanalytischen, semiotischen und vielen anderen Lektüreweisen machte. Es wird zwar auch betont, dass die Digital Humanities ein großes Veränderungspotential haben;[8] Positionen, die die Digital Humanities mit einer Theorie und möglichen neuen Praxis des Digitalen weiterdenken, sie als im Kern medientheoretisches Projekt verstehen, stehen nach meiner Erfahrung und Einschätzung zur Zeit nicht im Zentrum der Diskussion. Solche Ansätze sind aber notwendig, um zu reflektieren, wie die Digitalisierung nicht nur mehr oder weniger neue Werkzeuge (Computer, Datenbanken, Internet) zentral werden lässt, sondern vielmehr auch die Grundbasis und Identität der Geisteswissenschaften und der Universität verändert.[9]

Zu den Stimmen, die in den Digital Humanities einen solchen fundamentalen theoretischen und kulturellen Wandel erkennen, gehört Jeffrey Schnapp, der in seinem Digital Humanities Manifesto[10] ein sehr idiosynkratrisches Bild der Digital Humanities zeichnet. Bereits seine Wahl der Gattung, das Manifest, macht klar, dass die Digital Humanities hier als eine neue Avantgarde verstanden wird, die in der Tradition des Dadaismus und Futurismus etablierte Regeln und Normen in Frage stellt. Für Schnapp liefern digitale Werkzeuge neue Möglichkeiten der Kooperation und wissenschaftlichen Kreativität, die zunächst einmal experimentell, wenn nicht spielerisch, erschlossen werden sollten. Für ihn ist es entscheidend, dass durch die Digital Humanities Design und Forschung angenähert und dass die Digital Humanities einen zentralen Einfluss auf die Praktiken geisteswissenschaftlichen Arbeitens haben werden.[11]

Ich möchte im Folgenden zeigen, dass dieser experimentelle Umgang nicht einfach eine Öffnung der Geisteswissenschaften hin zu Fragen von Design oder ›creative research‹ ist, sondern vielmehr als Adaptation von Methoden aus digitalen Arbeitsbereichen wie Softwareentwicklung zu beschreiben ist, und dass Formen des Projektmanagements aus der Softwareentwicklung es notwendig machen, die Digital Humanities als einen Bereich zu verstehen, der Kooperationsformen ausbilden wird, die mit den etablierten Formen der Arbeit in den geisteswissenschaftlichen Bereichen nicht einfach zu vereinbaren sein wird. Es geht mir in diesem Aufsatz darum zu diskutieren, dass die Entwicklung von Software, und viele Projekte in den Digital Humanities sind genau dies, nicht die Arbeit eines einzelnen Individuums abbilden, sondern in einem Team geschehen, was signifikante Auswirkungen auf die Praktiken, aber auch auf die Evaluierungsvorgänge und Institutionen der Geisteswissenschaften haben könnte.

2. Digital Humanities und Softwareentwicklung

Die Entwicklung von digitalen Objekten (Programmen, Datenbanken etc.) zeichnet sich dadurch aus, dass sie nicht einfach als statisch zu begreifen sind, sondern ständig gewartet und weiter entwickelt werden sollten. Kurz gesagt besteht Softwareentwicklung nicht nur in der Konstruktion eines statischen Produktes, sondern in der Historisierung und Archivierung seiner Objekte, da an ihnen von anderen Entwicklern weitergearbeitet werden könnte, und so dauerhaft der Status und die Struktur des Programms kommuniziert werden muss. In dieser Hinsicht hat das Programmieren einiges mit der Arbeit des Philologen gemeinsam. Wie in der Philologie so wird auch beim Programmieren ein Text nach bestimmten Standards aufgearbeitet und kommentiert. Die Arbeit des Programmierers geht aber über die des Philologen hinaus, da die Informatik die Dynamik ihrer Produkte in einer viel radikaleren Art und Weise fasst als die Philologie.

Die Differenz kann wie folgt beschrieben werden: Während der Philologe einen historischen Bestand »feststellen« will, konstruiert der Programmierer ein Programm, in dem die Entwicklung und Überarbeitung von Anfang an mitgedacht wird. Am augenfälligsten ist diese Differenz bei der Kommentierung von literarischen Quellen, bzw. von Computercode. Während die philologische Sicherung durchaus einer Fixierung bedarf, muss das Wissen im Digitalen als etwas Organisches begriffen werden, das wachsen kann. Einfacher gesagt, Kommentare in Büchern konnten als integraler und geschlossener Teil einer Edition verstanden werden, bei einem Computerprogramm dient der Kommentar dazu, dass dieses Programm von anderen Entwicklern weitergeschrieben werden kann, sie sind Teil des Programms, aber nicht nur um das Programm zu verstehen, sondern um an ihm weiterzuarbeiten.[12]

Dieser Fokus auf Evolution innerhalb der Softwareentwicklung macht Software zu einem äußerst dynamischen, temporären Konstrukt, und um mit dieser Komplexität umzugehen, hat das Softwareengineering eigene Praktiken entwickelt, die ich im Folgenden diskutiere, und ich möchte fragen, wie sie in der philologischen bzw. geisteswissenschaftlichen Praxis aufgenommen werden können: es sind Agilität, Versionierung und Open Source.

»Agilität« verweist dabei auf ein zentrales Verfahren im Projektmanagement, das besonders stark Rückhalt in der Softwareentwicklung gefunden hat und den offenen Charakter von Produktentwicklung betont. Mit »Versionierung« meine ich sowohl die technischen Möglichkeiten des Archivierens und Dokumentierens von verschiedenen Entwicklungsschritten in der Softwareentwicklung als auch ein grundsätzliches Denken in Versionen, was eine Herausforderung für die Geisteswissenschaften darstellen könnte. »Open Source« verweist auf die offene Distribution aber auch auf die Produktion von Software, die ich als ein sinnvolles Arbeitsmodell für neue Formen geisteswissenschaftlicher Arbeit sehe.

Diese Zusammenstellung von Agilität, Versionierung und Open Source hat keinen Anspruch darauf, einen vollständigen Überblick von Verfahren der Softwareentwicklung zu geben, sondern versteht sich vielmehr als ein Ensemble von Prozessen, die große Veränderungen in geisteswissenschaftlichen Praktiken hervorrufen könnten, und zwar in der Hinsicht, dass die Digital Humanities ein Paradigma geisteswissenschaftlichen Arbeitens repräsentieren, in dem es nicht mehr primär um individuell erbrachte Ergebnisse sondern vielmehr um in einer Gruppe entwickelte Experimente geht – sie sozusagen als eine Wissenschaft begreift, die auf Teamwork und Experimentierwillen fußt.

2.1. Agilität

Die Entwicklung von Informationstechnologien ist komplex, und beruht darauf, dass eine Vielzahl von Problemen bewältigt und abgearbeitet wird. Software ist dabei zwar ein textuelles System (d.h. es besteht aus einem Text, dem Programmcode), es ist aber ein System, das aus einer Vielzahl von Elementen zusammengesetzt ist, die ineinandergreifen und dies auch am besten fehlerfrei tun.[13]

Historisch gesehen geht Informationstechnologie aus groß angelegten Projekten hervor, die auf den frühen Großrechnern beruhten und auch mit dem Internet werden IT-Projekte schnell zu Unterfangen von höchster Komplexität.[14] Dieser große technische Aufwand, hohe Kosten und juristische und politische Fragen wie Datenschutz führten dazu, dass es innerhalb der Informationstechnologie eine große Notwendigkeit gab Projekte zuverlässig zu managen. Man kann dabei zwischen linearen und iterativen bzw. agilen Verfahren des Projektmanagements unterscheiden.[15]

Das prototypische Beispiel eines linearen Projektmanagementmodells ist das »Wasserfall«-Modell. Das Wasserfall-Modell basiert auf einem linear ablaufenden Projektprozess bei dem zunächst Spezifikationen bestimmt, dann diese Spezifikationen umgesetzt und getestet werden, um dann dem Kunden die fertige Software zu übergeben. Das Problem bei diesem Verfahren ist, dass zwischen Planung und Umsetzung sehr viel Zeit vergehen kann, ohne dass es zu einer Überprüfung oder Veränderung durch den Kunden kommt. Das ist problematisch, da gerade was Informationstechnologie angeht, die Entwicklungen immer schneller laufen. Es gibt immer wieder neue Plattformen, Browser etc. die zu Anfang eines Projektes nicht berücksichtigt wurden, aber dennoch über die Laufzeit eines Projektes hinweg relevant für den Kunden werden.[16] Um diese Dynamik abzufangen und eine engere Zusammenarbeit von Kunden und Entwicklungsteam zu garantieren, werden vermehrt gerade in der Softwareentwicklung agile Verfahren eingesetzt.

Agilität zeichnet sich kurzgesagt durch einen iterativen Prozess aus, bei dem Kunden nicht einfach das Endprodukt gezeigt wird, sondern bei dem Kunden nach bestimmten Zeitabschnitten, das Produkt bzw. Produktfeatures vorgestellt werden. Das hat den Vorteil, dass nun der Kunde noch Modifikationen beauftragen kann. Es geht dabei darum im Entwicklungsprozess so früh wie möglich auf Fehler und Abweichungen aufmerksam zu werden und dann die notwendigen Umstellungen noch in den Entwicklungsprozess einzubinden.[17]

Agile Verfahren der Softwareentwicklung sind nichts radikal Neues. Es gibt Diskussionen, die sie bereits in den fünfziger Jahren entstehen sehen. Ein Fokus auf agiles Arbeiten lässt sich aber verstärkt in den neunziger Jahren erkennen, eine Zeit, in der agile Verfahren wie Scrum oder extreme Programming ausformuliert wurden.[18] Die Diskussion um agiles Arbeiten manifestierte sich in einer klaren deklarativen Form in dem Agile Manifesto von 2001. Inhalte des Manifests schließen »continous delivery« (also die sequentielle Lieferung kleinerer Bestandteile der Software), starke Einbindung des Kunden und den klaren Einsatz von iterativen Verfahren ein.[19]

Eine Neuerung, die die Digital Humanities in den geisteswissenschaftlichen Betrieb einführen, ist eine stärkere Abhängigkeit von Projekten.[20] Dies liegt u.a. daran, dass die Digital Humanities ein Teamwork voraussetzen wie es im geisteswissenschaftlichen Betrieb bisher nicht typisch ist. Digital Humanities Projekte bauen darauf, dass Geisteswissenschaftler, Programmierer, Designer, Hardwarearchitekten etc. zusammenarbeiten, und es kommt hier zu einer wahren Arbeitsteilung, da die Arbeit der Philologen nicht von den Programmierern geleistet werden kann und umgekehrt.[21] Die Produkte der Digital Humanities sind gekennzeichnet von einer kollaborativen Struktur, die sich vehement von dem immer noch standardmäßigen Forschungsnachweis in den Geisteswissenschaften, nämlich den Einzelautor-Aufsatz und die Einzelautor-Monographie, unterscheidet. Dafür gibt es ein großes Bewusstsein und auch dafür, dass dies ein Problem in den zurzeit etablierten Evaluationsmethoden ist, die klar auf einer individuellen Eigenleistung fundiert sind.[22]

Geisteswissenschaftliche Projekte erscheinen mir dabei in den meisten Fällen auf einer »Waterfall«-Methode aufzubauen. Es gibt zwar in den Geisteswissenschaften keine wirklich explizite Tradition des Projektmanagements, die Antragspraxis, die bei den meisten nationalen Förderungsvereinigungen vorliegt, ist jedoch ein System, das zunächst einen Projektantrag voraussetzt, der klar die Spezifikation und den Sinn des Endproduktes beschreibt.[23] Die Probleme des Waterfall-Modells treffen dabei, meiner Ansicht nach, die Digital Humanities besonders stark. Die Digital Humanities sind ein immer noch entstehendes Feld, in dem es keine wirklich lang etablierten ›Best Practices‹ gibt; es gibt auch nur wenig etablierte Infrastrukturen (Datenbanken, Serverinfrastrukturen etc. ), bei denen man wirklich auf langjährige Erfahrungen zurückgreifen kann – die Digital Humanities sind am Anfang und in einer Experimentierphase. Auf der einen Seite macht dies genau die Attraktivität der Digital Humanities aus, auf der anderen Seite ist dies nicht unproblematisch. Viele Projekte in den Digital Humanities sind großangelegte Digitalisierungsprojekte, die durchaus risikobehaftet sind, bei denen man nicht viel experimentieren will und für die bspw. die DFG klare Rahmenbedingungen vorgegeben hat.[24] Dennoch fehlt es auf dieser Ebene an ›Lessons Learned‹ und ich denke, dass die Digital Humanities viel stärker mit kleinen agilen Projekten arbeiten sollten, die es ermöglichen einen Erfahrungsschatz aufzubauen.

Neben einer Beurteilung der momentanen Projektpraxis ist auch die Frage, ob sich agile Methoden für die Humanities eignen oder wie sie in den Geisteswissenschaften benutzt werden können, und ob das Projektmanagement, wie es in der Wirtschaft angewandt wird, sich nicht unmittelbar auf die Anforderungen der akademischen Forschung übertragen läßt.[25]

Ein Element, das zentral für agile Methoden ist, und erst in dieser Form für die Geisteswissenschaften nachkonstruiert werden müsste, ist das Verhältnis vom Projektteam zum Kunden. Das agile Verfahren geht von einem Kunden aus, der in das Projekt mit eingebunden ist und dessen Entwicklung begleitet.[26] Wer ist aber der Kunde in einem typischen staatlich geförderten Forschungsprojekt? Zunächst kommen hier die Förderstellen in Betracht. Allerdings sind die meisten Projekte nicht so strukturiert, dass die entsprechende Institution regelmäßig Feedback auf die einzelnen Iterationen bzw. Projektabschnitte geben würde. Eine weitere mögliche Gruppe ist der Adressat, das Publikum, das mit einem Projekt angesprochen wird. Hier müsste aber ein Repräsentant konstruiert werden. Man könnte hier einen Vertreter der Funding Institution als einen Repräsentanten des Kunden einsetzen oder von Anfang den Test mit Fokusgruppen planen.

Diese Strategien könnte man in den Digital Humanities einsetzen, wenn es um Produkte geht, bei denen das Ergebnis mehr oder weniger klar ist – bspw. eine digitale Edition. Wenn es aber um Forschungsaktivitäten geht, die Wissen nicht konservieren, sondern neues Wissen produzieren sollen, ist die Situation schwieriger, aber genau hier liegt die Stärke agiler Verfahren.

Aufgrund der emergenten Natur von Wissen, kann ein Forschungsunternehmen, das zu Beginn seine Ziele klar darstellt, nur trivial sein. Gerade in den Geisteswissenschaften geht es eben nicht darum Hypothesen zur formulieren und abzutesten, sondern die Forschung in eine Richtung gehen zu lassen, die eben nicht einfach aus den anfänglichen Annahmen abzuleiten war. Geisteswissenschaftliche Forschung kann in einer radikalen Weise experimentell sein, da es in den meisten Fällen um ein diskursives Erschließen von Wissensbereichen geht, bei der es das Ziel ist, neue Probleme und Fragestellungen zu entdecken. Geisteswissenschaftler verhalten sich somit in einer bestimmten Art und Weise immer agil – es geht darum ein Wissensgebiet aufzuschließen und zu sehen, in welche Richtung diese Erkenntnisse einen nun bringen können. Dies ist eine explorative Struktur, die gut an ein agiles Denken angepasst werden kann.

In diesem Zusammenhang würde man die Forschung in verschiedene Zeitabschnitte (Sprints oder Iterationen) einteilen. Das Ziel des gesamten Forschungsprojekts sollte relativ offen formuliert werden und nach jeder Iteration sollte in einem Review beurteilt werden, was die entscheidenden Ergebnisse waren und was der Schwerpunkt der nächsten Iteration sein sollte. Es ist klar, dass ein solches Verfahren in den Digital Humanities nicht benutzt werden kann, um infrastrukturelle Projekte durchzuführen. Es ist aber ein Verfahren, das dringend notwendig ist, um Geisteswissenschaftler mit neuen Technologien experimentieren zu lassen und einen neuen Erkenntnishorizont zu entwickeln. Es handelt sich hierbei dann keinesfalls um Spielereien, sondern um eine Arbeitsweise, die das Lernen und die Emergenz von neuem Wissen und Forschungsmöglichkeiten in das Zentrum stellt.

Das klassische, national geförderte Forschungsprojekt ist dabei allerdings ein schlechtes Modell, da es die Evolution der Wissensgeneration von Anfang an in ein zu striktes Korsett packt. Ein Umfeld, was diese Form von Projekten begünstigt, wäre etwas, was momentan öfter unter dem Titel »Lab« zu finden ist, dabei allerdings dezidiert geisteswissenschaftliches Wissen in Verhältnis zu digitalen Technologien stellt. Institutionen dieses Typs sind bspw. das Signallabor an der HU Berlin, das Media Archaeological Lab in Boulder oder das Meta Lab in Harvard.[27] Ich denke, dass ein solcher experimenteller Umgang mit digitalen Technologien essentiell für die Entwicklung der Digital Humanities ist, es stellt jedoch auch eine große Herausforderung für den Wissenschaftsbetrieb, wie ich ihn kennengelernt habe, dar. Man muss bei dieser agilen Arbeitsform ein Teamwork etablieren, das auf flachen Hierarchien aufgebaut ist und nicht hierarchisch kontrolliert wird.

Es kommt hinzu, dass diese offene Dynamik nicht nur ein Managementtool ist, sondern eine Reaktion auf die prinzipiell offene Entwicklungsstruktur von Softwareprojekten. Softwareprojekte sind keine monolithischen Konstrukte, die einmal geplant und dann durchgeführt werden, sondern verändern sich ständig in ihrem Durchführungsprozess. Sie produzieren somit ihre eigene Geschichte.

2.2. Versionierung

Das Problem und Potenzial von agilen Verfahren besteht darin, dass sie es ermöglichen, neue Pfade zu eröffnen, die aber nicht einfach planbar und teleologisch ausgerichtet sind. Ein entscheidender Teil von agilen Verfahren ist, dass es nicht nur ein Prozess der Produktentwicklung sondern auch ein Projekt des Lernens ist, in dem Fehler gemacht und Strategien angepasst werden. Agile Projekte produzieren eine große Menge von Informationen, die nicht unmittelbar in das Endprojekt einlaufen, aber als Wissen innerhalb eines Projektteams akkumuliert werden.[28] Um dieses Wissen nicht zu verlieren, ist es wichtig die Entwicklung dieser Projekte zu dokumentieren und zu archivieren.

In der Softwareentwicklung benutzt man zur Aufzeichnung und Archivierung des Projektes Versionskontrolsysteme, das bekannteste ist zurzeit Git, das von Linus Torvalds entwickelt wurde.[29] Dieses System ist nicht auf die Verwendung von Software beschränkt, sondern kann beispielsweise auch benutzt werden, um die Genese einer Forschungsarbeit oder eines Romans zu verwalten.[30] Ich will im Folgenden nicht zu detailliert auf Git eingehen, aber ich möchte doch darauf hinweisen, dass die Softwareentwicklung über Werkzeuge der Dokumentation und Selbstarchivierung verfügt, die auch für die Philologie interessant sind. Was wichtig zu beachten ist, ist dass die Softwareentwicklung diese Instrumente benutzt, um ihre eigene Entwicklung zu beobachten. Philologie hingegen benutzt solche Instrumente, um ihre Forschungsobjekte zu historisieren. Natürlich gibt es auch wissenschaftshistorische Zugänge, die die philologische Arbeit historisieren, dokumentieren und archivieren, dies geschieht dann aber auch als eine Organisation eines Forschungsobjekts. In der Softwareentwicklung wird dies aber getan, um das Weiterarbeiten an dem dokumentierten Programm zu vereinfachen oder auch gar erst zu ermöglichen. Softwareprojekte sind meist zu komplex, um sie als geschlossene auf einen teleologischen Endpunkt ausgerichtete Projekte zu begreifen. Es gibt zwar Endpunkte, die sollen aber einen bestimmten Zustand beschreiben, und dieser Endpunkt bedeuten nicht, dass das Produkt für immer fertig ist. Es sind Versionen, die prinzipiell immer erweitert werden können. Wenn die Entwicklung an einer Software abgeschlossen ist, bedeutet das nicht, dass sie nicht weiter entwickelt werden könnte, sondern dass man beschlossen hat, damit aufzuhören.[31]

Ich denke, dass dies eine Perspektive ist, die den Geisteswissenschaften relativ fremd ist. Das Schreiben von Monographien und auch von Artikeln setzt darauf, dass man ein Endprodukt produziert, das als in sich abgeschlossen publiziert wird. Es gibt vielleicht die gelegentliche Ausnahme einer überarbeiteten neuen Auflage oder Ergänzungen zu einem Text, aber geisteswissenschaftliche Produkte laden meist nicht zum Weiterschreiben sondern zur Kritik ein. Es geht darum, eine Abgrenzung zu finden und nicht darum ein Produkt weiterzuentwickeln.

Der literaturwissenschaftliche Diskurs ist in der Kritik begründet, was auch eine wichtige und sinnvolle Tradition ist. Ich denke aber, dass die Digital Humanities nur bedingt an diese Tradition anschliessen können. Projekte in den Digital Humanities sind Softwareprojekte oder zumindest stark von Softwareprojekten abhängig, die nicht als solide, fertige Produkte zu verstehen sind, sondern als Werkzeuge, die sich entwickeln, was auch die Forschung mit diesen Instrumenten zu einem dynamischen historisch sich entwickelnden Gebilde macht. Deutlich wird dies, wenn wir von Digital Humanities sprechen, die selber Software sind. Hier geht es nicht darum, ein fertiges Produkt abzuliefern, sondern eine mögliche Version vorzustellen, die die weitere Entwicklung eben dieses Systems ermöglicht. Solche Produkte laden nicht zur Kritik sondern zum Weiterarbeiten, zum Erweitern und zum Anpassen an neue Kontexte ein. Dies ist auch der Grund, warum die Produkte und Ergebnisse, die an der Universität oder Bibliotheken produziert werden, Open Source Produkte sein sollten.

3. Open Source

Open Source ist bekannt in der Softwareentwicklung als eine offene Entwicklungsform bei der kollaborativ eine Software entwickelt wird. Das Betriebssystem Linux ist hier vielleicht das bekannteste und auch erfolgreichste Projekt in der Open Source Community. Bei Open Source wird der Quelltext öffentlich freigestellt und prinzipiell kann jeder an der Software weiterarbeiten.[32]

Friedrich Kittler hat in seiner Rede »Wissenschaft als Open-Source-Prozeß«[33] darauf aufmerksam gemacht, dass diese freie und kollaborative Geste der Open Source Entwicklung durchaus als zentraler Teil der universitären Forschungskommunikation zu begreifen ist. Kittler verweist dabei darauf, dass die Universität oder zumindest universitätsnahe Institutionen das Internet oder auch Linux hervorgebracht haben. Ich denke, dass es notwendig ist, die Digital Humanities prinzipiell als Institution zu verstehen, die Open Source Projekte entwickelt. Dies bedeutet aber mehr als, wie bei Publikationen, zunehmend auf Open Access zu pochen. Es geht nicht nur darum, Wissen zugänglich zu machen. Das ist sicherlich ein Aspekt, aber bei Open Source geht es vielmehr darum, Infrastrukturen und Projekte zu erweitern und an ihnen weiterzuarbeiten.[34]

Eine zentrale Frage ist dabei wie diese Arbeit zu einem Teil des akademischen Betriebs werden kann. Projekte, die Open Source sind, besitzen eine dezentrale Struktur, bei der nicht mehr ein Projektteam an einem Produkt arbeitet, sondern an dem mehrere Projektteams mehr oder weniger unabhängig voneinander ein Produkt entwickeln. Das bedeutet, dass man in den Geisteswissenschaften Projekte von Anfang an als offen gestalten sollte und auch kommuniziert, dass hier Interesse an kollaborativer Arbeit besteht. Es geht hier in einem verstärkten Masse nicht mehr darum, andere Arbeit zu kritisieren und von der eigenen abzugrenzen, sondern vielmehr darum an anderen Projekten mitzuarbeiten.

4. Abschluss: Digital Humanities und das Ende des Gelehrten

Die Digital Humanities bieten neue Publikationsformen wie digitale Editionen, interaktive historische Karten oder dynamische Zeitreihen. Sie profitieren von groß angelegten Digitalisierungsprojekten und haben nun die Möglichkeit die Geisteswissenschaften auf einem quantitativen Materialzugriff aufzubauen, der wenig mit einer doch immer selektiven Lektüre von Quellen zu tun hat, wie er die bisherige Praxis ist. Nun können immense geisteswissenschaftliche Daten in Datenbanken gespeichert, strukturiert und ausgewertet werden. Diese Daten können für Forschungsprodukte verwendet werden, die diese Daten statistisch verarbeiten oder visuell darstellen. Die Digital Humanities könnten eine neue Form der Literaturwissenschaft hervorbringen, die die Erforschung von Literatur nicht mehr als eine Vielzahl von verschiedenen Lektürepraktiken begreift (Hermeneutik, Diskursanalyse, Dekonstruktion, etc.), sondern im Kern zu einer Datenanalyse wird. Franco Morettis Verständnis des »Distant Reading«[35] verweist bereits auf diese neue Lektürepraxis, und der doch recht einfache Zugriff auf Handwerkzeuge der Datenanalyse, bspw. der Datenvisualisierung durch Python Libaries, Javascript Frameworks wie d3[36] oder Web-Applikationen wie Voyant Tools[37] ermöglicht es auch Geisteswissenschaftlern, ohne viel Wissen im Bereich von Statistik, mit diesen Möglichkeiten zu experimentieren.

Es ist sicherlich eine wichtige Frage, ob die Literaturwissenschaft in einer solchen datengetriebenen Disziplin aufgehen sollte, dies ist aber auch nicht der Fokus meiner Überlegungen in diesem Text. [38] Ziel dieses Aufsatzes war es zu betonen, dass das Besondere bzw. das innovative Potenzial der Digital Humanities nicht einfach in der computergestützten Auswertung von Daten besteht, sondern in dem Experimentieren und Konstruieren von Werkzeugen, die diese Auswertung übernehmen, und in einer Diskussion, wie diese Daten zu interpretieren und zu verwenden sind. Was dabei neu ist, ist eben nicht die Verwendung des Computers als Werkzeug, hier gibt es den berühmten Verweis auf den Jesuiten Roberto Busa, der bereits 1949 mit IBM zusammengearbeitet hat,[39] und spätestens seit den frühen Zweitausendern kommt kein Geisteswissenschaftler ohne elektronische Kataloge oder Suchmaschinen wie Google aus. Was aber über diese eher passive Nutzung von digitalen Werkzeugen hinausgeht, ist, dass das Internet nicht nur zum Konsumieren von Daten, sondern zur kollaborativen Konstruktion von Werkzeugen aber auch von Forschungsergebnissen einlädt. Die Digital Humanities basieren auf den Kommunikationsmöglichkeiten des Internets und müssen, um die Komplexität der neuen Formen von Forschung auszuschöpfen, auch die Möglichkeiten der Zusammenarbeit suchen, die bspw. im Bereich der Softwareentwicklung Gang und Gäbe sind. Dies ist nicht nur eine einfache Umstellung der Arbeitspraktiken, sondern könnte dazu führen, dass sich die Rolle und Position der Geisteswissenschaften innerhalb der Institution der Universität verändert.

Foucaults bon mot, dass der Mensch vergehen wird wie der Abdruck eines Gesichtes im Sand am Meer,[40] trifft eben nicht nur auf den Menschen sondern auf alle diskursiven Formationen zu. Das Aufkommen der Digital Humanities wird dabei die Position des Gelehrten, wie er im europäischen Universitätssystem entstand, attackieren. Ein Gelehrter zu sein ist (zumindest in den Geisteswissenschaften) der Prozess einer Individualisierung. Der ultimative Beweis für eine erfolgreiche intellektuelle Tätigkeit ist der Lebenslauf, der die individuellen Leistungen wie Aufsätze, Monographien und Vorträge auflistet. Die Qualität von geisteswissenschaftlichen Texten wird dabei maßgeblich dadurch bestimmt, ob sie innovativ sind, also, ob sie sich von anderen Forschungsergebnissen entscheiden abgrenzen oder hinzufügen – also eine klar erkennbare individuelle Spur tragen. Das gesamte Forschungs- und Bewertungssystem des geisteswissenschaftlichen Betriebs ist auf eine solche Individualisierung ausgerichtet.[41]

Die Digital Humanities, wenn sie sich auf die technischen Herausforderungen einlassen, die das Medium und die Praktiken aus der Softwareentwicklung vorgeben, unterlaufen diese Betonung des Individuums. Es geht hier nicht mehr darum, dass eine einzelne Person ein komplexes Problem löst. Die Komplexität von Computerapplikationen machte es notwendig, dass diese Komplexität so aufgeteilt wird, dass ein Team kollektiv an diesem Problem arbeiten kann. In diesem Zusammenhang ist es auch wichtig zu betonen, dass das Internet nicht nur einen globalen Zugang auf Daten liefert, sondern auch eine Kolaborationsplattform darstellt. Da das Internet nun diese neuen Arbeitsmodalitäten anbietet, scheint es mir sinnvoll, dass wir verstärkt nach Arbeitsweisen in den Geisteswissenschaften suchen, bei denen kollaborativ, ähnlich wie bei Open Source Projekten, an Forschungsfragen gearbeitet wird. Dies bietet sich deutlich für die Entwicklung von Software im Bereich der Digital Humanities an, kann aber auch andere Bereiche wie das gemeinsame Schreiben von Forschungsliteratur oder das kollektive Erstellen von Fachlexika betreffen. Was diese Produkte dann gemeinsam haben, ist dass sie aus Kollektiven entstehen und nicht einem einzelnen Genie entspringen.

Aus diesem Grund könnten die Digital Humanities so den Weg zu einer neuen Arbeitsweise öffnen, die auf Teamwork und Experimentierwille fußt, und die starke hierarchische Struktur, die ja eng an die Individualisierungspraktiken der Universitäten geknüpft ist, aushöhlen.

Die Digital Humanities haben das Potenzial, die Geisteswissenschaft von Grund auf zu verändern. Es ist nicht einfach so, dass der Computer oder digitalen Methoden als Ergänzung benutzt werden. Dies ist etwas was wir schon lange tun, wenn wir unsere Texte mit dem Computer schreiben, online Quellen oder Volltextsuchen etc. benutzen. Die Digital Humanities, wenn sie ihr volles Potenzial ausschöpfen wollen, werden eben nicht nur den Computer hinzufügen, sondern neue Praktiken hervorbringen, die mit der Figur des einsam denkenden Gelehrten nicht mehr zu vereinbaren sind.

Fußnoten

  • [1]
    Joseph L. Bower und Clayton M. Christensen haben mit ihrem Aufsatz »Disruptive Technologies«, die Diskussion um disruptive Technologien, Technologien, die die Dominanz von bestimmten Firmen in technologischen Märkten stark verändern können, maßgeblich bestimmt, vgl. Bower / Christensen 1995, passim.

  • [2]
    Die Diskussion um die Digitalisierung und eine damit verbundene neue industrielle Revolution ist allgegenwärtig. Als ein Beispiel für diesen Themenkomplex siehe den ZEIT-Artikel von Broy / Precht 2017, passim.

  • [3]
    Kittler 1980, passim; vgl. auch Aufschreibesysteme 1800 / 1900 (Kittler 1985, passim), wo Kittler zeigt wie Kultur maßgeblich als Prozess der Datenverarbeitung zu begreifen ist.

  • [4]
    Kittler hat Medien und besonders den Computer zu einem Denkmodell in den Geisteswissenschaften gemacht. Es geht bei Kittler aber mehr um eine Reflexion über Technik als um ein Untersuchen von Literatur mit neuen Technologien. Für eine längere Diskussion von Kittler und seinem Verhältnis zu den Digital Humanities vgl. Niebisch 2016, passim.

  • [5]
    Vgl. hier bspw. Lauer 2013, der darauf hinweist, wie die Literaturwissenschaft durch die Digital Humanities zu einer rechnenden Disziplin wird.

  • [6]
    Für eine kritische Auseinandersetzung zum Verhältnis von Digital Humanities und Literaturtheorie vgl. bspw. Eyers 2013, passim oder Pressman / Swanstrom 2013, passim.

  • [7]
    Diese Position, dass die Digital Humanities geisteswissenschaftliche Arbeiten mit digitalen Instrumenten bereichern, wird von dem bei Metzler erschienen Handbuch Digital Humanities unterstrichen. Die Einleitung beschreibt die Aufgabe von Digital Humanities wie folgt: »Die Forscherinnen und Forscher in diesem Feld beschäftigen sich damit neue Entwicklungen in der Informatik auf ihre Verwertbarkeit in den Geisteswissenschaften zu prüfen oder eigenständig geeignete Verfahren zu entwickeln, und sie erforschen die Algorithmen und Datenstrukturen, die sich als geeignet erwiesen haben.«, Jannidis et al. 2017, XI.

  • [8]
    Vgl. hier bspw. Lauer 2013 , passim.

  • [9]
    Diese Einschätzung, dass die Digital Humanities keine literaturtheoretische Diskussion auslösen, kann man sicherlich schnell die Zähne ziehen. Gerade das Distant Reading entwickelte sich aus einem sehr großen literaturtheoretischen Duktus heraus, der sich evident vom Close Reading abgrenzte und eine neue Form von quasi-marxistischer Literaturwissenschaft möglich machen wollte, vgl. Moretti 2013, passim. Meine Kritik an den Digital Humanities besteht aber darin, dass die Digital Humanities sich nicht als bloße Werkzeuge des wissenschaftlichen Arbeitens verstehen sollten, sondern als Reflexionswege um den digitalen Wandel mitzudenken. Siehe hierzu bspw. auch Hall 2012, der auf Positionen aufmerksam macht, die in den Digital Humanities einen »post-theoretical« Ansatz sehen, der einen potenziellen Methodenstreit, wie es ihn die achtziger Jahre geschehen ist, verhindert, vgl. Burdick et al. 2012, passim. Für andere Ansätze in den Digital Humanities, die sich einer weiteren Theoriediskussion öffnen vgl. bspw. Limpsel 2016, passim.

  • [10]
    Schnapp 2011, passim.

  • [11]
    Zu den neuen Arbeitsweisen in den Digital Humanities siehe besonders Burdick et al. 2012, passim.

  • [12]
    Für eine ausführlichere Diskussion von Techniken des Kommentierens in Computerprogrammen vgl. bspw. Kapitel 8 in The Elements of Programming Style Kernigham / Plauger 1978.

  • [13]
    Der Text eines Computerprogramms unterscheidet sich von Texten zur menschlichen Kommunikation darin, dass er, besonders wenn es um komplexere Programme geht, nicht mehr als linear bezeichnet werden kann. Aufsätze, Essays oder auch Bücher geben ihren menschlichen Lesern meist eine klare lineare Struktur vor. Computerprogramme sind von Verzweigungen und Schleifen und anderen Konstruktionen gekennzeichnet, die je nach konkreten Daten anders ablaufen können. Ein Programm wird eben nicht Zeile für Zeile abgearbeitet, sondern es gibt Sprünge und Wiederholungen, was diesen Texten eine Komplexität gibt, die bei natürlichsprachigen Texten höchstens in experimentellen und ästhetisch hochbearbeiteten Formen zu finden ist.

  • [14]
    Facebook ist ein gutes Beispiel dafür wie zunächst kleine Projekte, wie eine Software zur Kommunikation zwischen Studenten zu einem der wichtigsten Kommunikations- und Marketinginstrumente der Welt wurde.

  • [15]
    Für einen kompakten Überblick von agilen und linearen Verfahren vgl. Hakizabera / Yamada 2010, passim.

  • [16]
    Ich möchte darauf hinweisen, dass das Waterfall-Modell ein Strohmann ist, der meist angeführt wird, um zu zeigen, dass eine »plan-driven« Entwicklung zu statisch ist. Bereits der kanonische Text zum Waterfall-Model (vgl. Royce 1970) war eine Reflexion, die diskutierte, warum ein linearer Projektablauf nicht ohne iterative Phasen auskommen kann.

  • [17]
    Für einen kompakten Überblick zu agilem Projektmanagement vgl. Stare 2013, passim.

  • [18]
    Zu einem historischen Überblick zu agile Verfahren vgl. Larman / Basili 2003, passim.

  • [19]
    Vgl. Highsmith et al. 2001.

  • [20]
    Der Band Digital Humanities betont ebenso die Notwendigkeit der Arbeitsform Projekt, vgl. Burdick et al. 2012, S. 124–125.

  • [21]
    Für eine weitere Diskussion des Projektmanagements in den Digital Humanities vgl. Tabak 2017, passim.

  • [22]
    Zur Diskussion der Evaluierung von DH Projekten siehe das MLA Statement zur Evaluierung von digitalen Forschungsarbeiten Guidelines for Evaluating Work in Digital Humanities and Digital Media.

  • [23]
    Der FWF (Österreichische Forschungsgemeinschaft) formuliert bspw. die Voraussetzungen für ein Projekt wie folgt: »Ein hinsichtlich der Ziele und der Methodik genau beschriebenes, zeitlich begrenztes Projekt (max. 48 Monate) auf dem Gebiet der nicht auf Gewinn gerichteten wissenschaftlichen Forschung« und setzt damit voraus, dass die Ziele am Anfang so gut wie möglich definiert sind, vgl. FWF Antragsrichtlinien für Einzelprojekte.

  • [24]
    Für die DFG Anforderungen an digitale Projekte siehe: DFG-Vordruck 12.151 – 12/16 – Praxisregeln »Digitalisierung«.

  • [25]
    Zu einer kritischen Diskussion des Verhältnisses von Verfahren der Softwareproduktion und den Geisteswissenschaften vgl. Smithies 2011, passim.

  • [26]
    Die Interaktion mit dem Kunden als essentieller Teil des agilen Prozesses ist im Manifesto of Agile Software Development eingeschrieben: »Customer collaboration over contract negotiation«. Tabak erkennt auch in der (in den Geisteswissenschaften fehlenden) Rolle des Kunden und in der emergenten Natur von Wissen, die zentralen Probleme das agile Verfahren anzuwenden: »However, there are several issues, which prevent some aspects of agile project management to be easily translated into DH research projects. The agile methods assume that there is a customer on the other side waiting for a product to be used, while in a DH project, there is a researcher constantly creating research questions rather than a list of features to be implemented«, Tabak 2017, S. 19.

  • [27]
    Lori Emerson beschreibt bspw. das Media Archaeology Lab in Boulder als genau so einen Experimentierraum, der lineare Forschungsnarrative aufbrechen will und dabei auch den Unterschied zwischen analytischer Forschung und kreativer Produktion verflacht: »Ich habe das MAL für meine eigene Forschung genutzt, um nichtlineare und nicht-zielgerichtete Reihen von Medienphänomenen – oder Brüchen – zu beschreiben. Auf diese Weise wollte ich die Vorstellung einer Mediengeschichte des Fortschritts vermeiden, die weitgehend vernachlässigte, gescheiterte oder tote Medien ignoriert. Ich habe jedoch bald festgestellt, dass diese Forschung nur eine der möglichen Anwendungen ist, die das MAL seinen Nutzern gewährt. Heute verstehe ich das MAL als eine Art eigenständigen ›variantologischen‹ Raum – ein Ort, der je nach Herangehensweise unzählige Möglichkeiten für Forschung und Lehre eröffnet oder für andere, weniger klar definierte Tätigkeiten, welche durch eine Sammlung ermöglicht werden, die Objekt und Werkzeug zugleich ist. Das MAL ist ein Archiv für originale Werke der digitalen Kunst/Literatur und die Plattformen, auf denen sie entstanden sind. Es ist aber nicht nur ein Archiv für Medienobjekte, sondern auch ein Ort für künstlerische Experimente und Projekte wie: ›MALpractices‹ (Wohnsitze für Künstler und Schriftsteller, die zum einen zum direkten Arbeiten und Experimentieren mit unseren Text und Materialien genutzt werden können, [...].«, Emerson 2014, S. 18–19.

  • [28]
    Alistair Cockburn hat in seinem Standardwerk Agile Software Development darauf aufmerksam gemacht, dass das Fehlermachen und das Lernen aus diesen Fehlern ein zentraler Bestandteil der agilen Methode ist; vgl. Cockburn / Highsmith 2001, S. 48.

  • [29]
    Der Download für Git und eine ausführliche Dokumentation findet sich auf der folgenden Webseite: git-scm.com. Einen guten Überblick über die Aufgabe und Funktion von Versionskontrollsystemen gibt das Buch Version Control by Example (Sink 2011).

  • [30]
    Beispiele für die Verwendung von Git durch Autoren finden sich auf GitHub.

  • [31]
    Für eine Diskussion von Versionierungspraktiken vgl. Preston-Werner 2013, passim.

  • [32]
    Der Text The Cathedral and the Bazaar von Eric S. Raymond ist zu etwas wie dem Standardwerk über Open Source geworden und versteht Open Source als eine komplexe Interaktion (wie auf einem Basar), bei der nicht mehr von einer Einzelperson oder einem Monopol, sondern einer systemischen Emergenz ausgegangen wird; vgl. Raymond 1999, passim.

  • [33]
    Kittler 2006, passim.

  • [34]
    Für meine Diskussion ist es zentral, dass es beim Open Source nicht primär wie beim Open Access (vgl. hier bspw. Schirmbacher 2007) um Publikation und Kommunikation, sondern zudem stark um Kollaboration geht.

  • [35]
    Moretti 2013, passim.

  • [36]
    D3 (Data Driven Documents) ist eine Javascript Library, die eine Vielzahl von Formen der Datenvisualisierung zur Verfügung stellt: Data Driven Documents.

  • [37]
    Voyant Tools ist eine frei zugängliche Webapplikation mit der man eine Vielzahl von computergestützen Analysen durchführen kann.

  • [38]
    Eine zentrale Frage in einer Methodendebatte um die Digital Humanities wäre sicherlich wie sich die mathematischen Verfahren zu den Erkenntnis- und Bildungsprozessen einer individuellen Lektüre stehen.

  • [39]
    Vgl. hierzu bspw. Burdick et al. 2012, S. 129.

  • [40]
    Foucault 1974, S. 462.

  • [41]
    Dass die Universität ein solches Individualisierungssystem ist, kann man bspw. an den Urheberschafts- und Prüfungspraktiken erkennen, bei denen erklärt werden muss, dass eine wissenschaftliche Arbeit die individuelle Leistung des Autors ist. In der jüngsten Vergangenheit haben die Aufdeckungen von plagiierten Doktorarbeiten gezeigt, wie eng die Verbindung von Individuum und wissenschaftliche Arbeiten ist.

Bibliographische Angaben

  • Joseph L. Bower / Clayton M. Christensen: Disruptive Technologies. Catching the Wave. In: Harvard Business Review 73 (1995), S. 19–45. [Nachweis im GVK]

  • Manfred Broy / Richard David Precht: Daten essen Seele auf. [online] In: Die Zeit 5 (2017) vom 09.02.2017. [online]

  • Anne Burdick / Johanna Drucker / Peter Lunenfeld / Todd Presner / Jeffrey Schnapp: Digital_Humanities. Cambridge, MA. 2012. [Nachweis im GVK]

  • Alistair Cockburn / Jim Highsmith: Agile Software Development. The Business of Innovation. PDF. [online] In: Computer 34 (2001), H. 9, S. 120–122. [Nachweis im GVK]

  • Lori Emerson: Das Media Archaeology Lab. In: Retro. Computer, Spiele, Kultur 31 (2014), S. 18–19. [Nachweis im GVK]

  • Tom Eyers: The Perils of the Digital Humanities. New Positivisms and the Fate of Literary Theory. In: Postmodern Culture. Journal of Interdisciplinary Thoughts on Contemporary Culture 23 (2013), H. 2. [Nachweis im GVK]

  • Michel Foucault: Die Ordnung der Dinge. Eine Archäologie der Humanwissenschaften. Frankfurt/Main 1974. [Nachweis im GVK]

  • Aline Uwera Hakizabera / Koichi Yamada: Linear Models vs. Agile Models. Making the right model decision. The Papers of Technical Meeting on Information Systems. PDF. [online] In: IEE Japan 10 (2010), H. 1, S. 85–88.

  • Gary Hall: Has Critical Theory Run Out of Times for Data-Driven Scholarship. In: Debates in the Digital Humanities 2015. Hg. von Matthew K. Gold. Minneapolis, MN. 2015. Siehe auch: [online]

  • Jim Highsmith et al.: Manifesto for Agile Software Development. 2001. [online]

  • Digital Humanities. Eine Einführung. Hg. von Fotis Jannidis / Hubertus Kohle / Malte Rehbein. Stuttgart 2017. [Nachweis im GVK]

  • Brian Wilson Kernigham / Phillip James Plauger: The Elements of Programming Style. New York 1978. [Nachweis im GVK]

  • Austreibung des Geistes aus den Geisteswissenschaften. Programme des Poststrukturalismus. Hg. von Friedrich Kittler. Paderborn 1980. [Nachweis im GVK]

  • Friedrich Kittler: Aufschreibesysteme 1800–1900. München 1985. [Nachweis im GVK]

  • Friedrich Kittler: Science as Open Source Process. In: New Media, Old Media: A History and Theory Reader. Hg. von Wendy Hui Kyong Chun / Thomas Keenan. (Tagung: The Archaeology of Multi-Media", Providence, RI., 02.–04.11.2000) New York 2006, S. 177–179. [Nachweis im GVK]

  • Gerhard Lauer: Die Vermessung der Kultur. Geisteswissenschaften als Digital Humanities. In: Big Data. Das neue Versprechen der Allwissenheit. Hg. von Heinrich Geiselberger / Tobias Moorstedt. Berlin 2013, S. 99–116. [Nachweis im GVK]

  • Craig Larman / Victor R. Basili: Iterative and Incremental Development. A Brief History. In: Computer 36 (2003), H. 6, S. 47–56. [Nachweis im GVK]

  • Mirco Limpinsel: Was bedeutet die Digitalisierung für den Gegenstand der Literaturwissenschaft? DOI: 17175/2016_009 In: Zeitschrift für digitale Geisteswissenschaften. Wolfenbüttel 2016. DOI: 10.17175/2016

  • Franco Moretti: Distant Reading. London 2013. [Nachweis im GVK]

  • Arndt Niebisch: Close Writing. Friedrich Kittler und die Digital Humanities. PDF. [online] In: Metaphora 1 (2016). [online]

  • Jessica Pressman / Lisa Swanstrom: The Literary And/As the Digital Humanities. [online] In: Digital Humanities Quarterly 7 (2013), H. 1. [online]

  • Tom Preston-Werner: Semantic Versioning 2.0.0. San Francisco, CA. 2013. [online]

  • Eric S. Raymond: The Cathedral & the Bazaar. Musings on Linux and Open Source by an Accidental Revolutionary. Peking 1999. [Nachweis im GVK]

  • Winston Royce: Managing the Development of Large Software Systems. In: 1970 WESCON technical papers. (Western Electronic Show and Convention: 14, Los Angeles, CA., 25.–28.–08.1970) Los Angeles, CA. 1970, S. 1–9. [Nachweis im GVK]

  • Peter Schirmbacher: Open Access – ein historischer Abriss. In: Open Access – Chancen und Herausforderungen. Hg. von der Deutschen UNESCO-Kommission. Bonn 2007, S. 22–25. PDF. [online] [Nachweis im GVK]

  • Jeffrey Schnapp: Digital Humanities Manifesto. Los Angeles, CA. 2011. PDF. [online]

  • Eric Sink: Version Control by Example. Champaign, IL. 2011. PDF. [online]

  • James Smithies: A View from IT. [online] In: Digital Humanities Quarterly 5 (2011), H. 3. [online]

  • Aljaž Stare: Agile Project Management – A Future Approach to the Management of Projects? DOI: 10.17708/DRMJ.2013.v02n01a04 In: Dynamic Relationships Management Journal 2 (2013), H. 1, S. 43–53. [online]

  • Edin Tabak: A Hybrid Model for Managing DH Projects. [online] In: Digital Humanities Quarterly 11 (2017), H. 1. [online]