Zurück zu den Wurzeln: Warum ohne Softwareinfrastruktur alles nichts ist

Im 5. und letzten Teil unserer Blogreihe zur digitalen Zivilgesellschaft beleuchten wir einen Bereich, über den wenig gesprochen wird, der im Grunde genommen aber der Anfang von allem (Digitalen) ist: Softwareinfrastruktur, die vierte Säule des Prototype Funds. Unter diesem Förderschwerpunkt werden deshalb nicht jene Projekte gefördert, die ihr als Endanwender*innen nutzt, sondern explizit solche, die Entwickler*innen für ihre tägliche Arbeit benötigen.

Softwareinfrastruktur: Was ist das eigentlich?

Wenn es um Software geht, denken viele Menschen erst einmal an konkrete Anwendungen:  Apps und Programme, die wir gut von unserem Startbildschirm und unserem Smartphone kennen und die uns den Alltag erleichtern. Das ist verständlich, denn genau diese Art Software ist es, die für uns als Endnutzer*innen gedacht ist. Wir haben täglich mit ihr zu tun und können sie via Touchdisplay an- und erfassen. Anwendungen sind die sichtbare Spitze des Software-Eisbergs. 

Genauso wichtig, wenn nicht noch wichtiger, ist aber das, was darunter bzw. in ihnen steckt: Infrastruktur. Diese umschließt im Hardwarebereich zum Beispiel Serverfarmen oder auch Unterseekabel – das sind massive Strukturen, die unsere Geräte miteinander vernetzen und somit den Grundstein dafür legen, dass wir sie wie gewohnt nutzen können. Damit diese aber auch wirklich reibungslos miteinander kommunizieren können, braucht es noch mehr: Softwareinfrastruktur. Beispielsweise sind das Software-Pakete oder standardisierte Implementierungen von Protokollen, die von Entwickler*innen benutzt werden, um Anwendungssoftware zu schreiben und diese zum Laufen zu bringen. Die “Plattenbauelemente der Informationstechnik” werden von Entwickler*innen eingesetzt, um Arbeitsschritte einzusparen. Sie werden über Repositorien und Paketverwaltungen ausgetauscht, ausgebaut und wiederverwendet, denn Open-Source-Software ist im Kern modular und oft vielseitig einsetzbar. 

Um sich das ganze noch besser vorstellen zu können, denkt man sich Soft- und Hardware als “infrastrukturellen Stack” aus erprobten Komponenten-Kombinationen, die wie oben beschrieben dafür sorgen, dass Bits und Informationen ungehindert durch die einzelnen Internetprotokoll-Schichten von uns zur Maschine und wieder zurück übersetzt werden können. Softwareinfrastruktur ist mit aufeinander abgestimmten Schrauben- und Werkzeugsätzen vergleichbar, die einem aufzubauenden Möbelstück beigelegt sind – nur mit ihrer Hilfe kann das Regal am Ende auch stehen.

Und wie sieht das konkret aus?

Nehmen wir als weithin bekanntes Anschauungsbeispiel Git, die freie Software zur Versionsverwaltung: Git ist ein wichtiges Hilfsmittel für die Arbeit von Coder*innen und verwendet darüber hinaus selbst infrastrukturelle Software-Projekte: Wie praktisch jede Software wurde das Projekt auf einer Vielzahl bestehender Technologien aufgebaut. So implementiert es die SHA-1-Hash-Funktion, es bietet eine Secure Shell (SSH)-Schnittstelle für verschlüsselte Netzwerkverbindungen und es wurde in C geschrieben, einer Anfang der 1970er Jahre entwickelten Mehrzweck-Programmiersprache. Zusätzlich nutzt Git verschiedene “Code-Bibliotheken”, die in einer Vielzahl von Open-Source-Software verwendet werden, um zu vermeiden, dass immer wieder dieselben Grundfunktionen definiert werden.

Mit diesen und ähnlichen Bausteinen bildet Softwareinfrastruktur die Grundlage für viele E-Mail-Clients, Zahlungsanwendungen oder Kartendienste – und damit für einen Großteil unseres digitalen Lebens. Wer sich zum Thema Software-Stacks noch weiter einlesen möchte, dem empfehlen wir diesen Text  – und für den geneigten Internetprotokoll-Nerd gleich eine dreiteilige Serie (hier geht es zu Teil 1, 2 und 3). 

Die Abhängigkeiten von Bausteinen, sogenannte “dependencies”, haben aber auch das Potenzial, Entwickler*innen in Teufels Küche zu bringen. Wenn z. B. einzelne Libraries nicht gut instand gehalten werden, sind sie nicht ohne weiteres für das eigene Open-Source-Projekt wiederverwendbar. Willkommen in der Dependency Hell! 

Weil diese Arbeitsschritte hinter den oberflächlichen Funktionen von Anwendungen liegen, sind hinter den Kulissen meist Expert*innen am Werk: Coder*innen, die in ihrer Freizeit oder beruflich selbst Software schreiben und sich dabei die vorhandenen Stacks zu Nutze machen oder diese erweitern.

Mit dem Prototype Fund konnten wir in den vergangenen Jahren einige spannende Infrastrukturprojekte fördern: Reproducible Builds lässt Quellcode von unterschiedlichen Entitäten mehrmals bauen, um sicherzustellen, dass der – beispielsweise von System-Administrator*innen untersuchte – Code wirklich das ist, wonach er aussieht. Auf diese Weise macht das Projekt die Benutzung für Entwickler*innen und Endnutzer*innen sicherer. microG stellt eine Infrastruktur bereit, welche die Nutzung von Android-Apps ohne die Einbindung von Google-Play-Diensten ermöglicht. Und Robur.io hat sich gleich zum Ziel gesetzt, auch Menschen ohne profunde technische Kenntnisse zu befähigen, eigene und somit dezentrale Dienste (wie Kalender) zu betreiben. Diese und weitere Softwareinfrastrukturprojekte findet ihr hier.

Warum wir uns so wenig mit Softwareinfrastruktur befassen

Immer wenn man über Softwareinfrastruktur nachdenkt, liegt der Vergleich zu einer anderen Infrastruktur nahe: Verkehrsinfrastruktur. Wir interessieren uns in der Regel nicht für Straßen oder Gleise, sondern für die Verkehrsmittel, die darauf unterwegs sind – diese bringen uns sicht- und spürbar ans Ziel, während die Straße einfach da ist.

Ein Charakteristikum – und gleichzeitig eine Herausforderung – von Infrastruktur ist also, dass sie wenig sichtbar ist und deswegen nur in Ausnahmefällen Beachtung findet. Richtig über Infrastruktur nachdenken müssen die meisten deshalb eigentlich nur, wenn sie nicht (gut) funktioniert. In der Analogie der Verkehrsinfrastruktur ist ein Schlagloch ein gutes Beispiel. Und wie dieses kündigen sich auch Probleme mit Softwareinfrastruktur oft schwelend an, wie die Geschichte des Heartbleed Bugs zeigt: In der freien Software OpenSSL wurde Ende 2011 ein fehlerhafter Commit von einem (der sehr wenigen) Projekt-Maintainer in den Stammcode übernommen, der in der Folge über eine Fehlfunktion eine Angriffsfläche bot. Diese Sicherheitslücke wurde erst im Frühling 2014 entdeckt und behoben – nach  27 Monaten.

Maintenance als Freizeitbeschäftigung

Der Fall ist deswegen so interessant, weil nur wenige Personen OpenSSL gewartet haben und dies größtenteils in ihrer Freizeit. Gleichzeitig war OpenSSL in viele weitere Softwareprodukte eingebaut, auch die großer Firmen. So war zeitweise auch das Android System von Google von der Sicherheitslücke betroffen. Warum Wartung gerade im Bereich der Softwareinfrastruktur so wichtig ist, könnt ihr z. B. im Roads-and-Bridges-Report nachlesen. Mittlerweile hat sich die Core Infrastructure Initiative formiert, um kritische Softwareinfrastruktur besser zu überwachen und verstehen – und sich zu diesem Zweck zum Beispiel ein Zertifikatssystem und Resilienzmetriken ausgedacht. Doch über diese Initiative hinaus sind es nach wie vor oft ehrenamtliche Entwickler*innen, die Softwareinfrastruktur warten – die digitale Zivilgesellschaft.

Wenn ihr die ersten vier Teile dieser Blogreihe gelesen habt, kommt euch das wahrscheinlich mittlerweile bekannt vor: Wie so oft bei Open-Source- und Public-Interest-Technologien entwickeln und betreuen auch im Bereich Infrastruktur Nutzer*innen mit technischer Expertise (unentgeltlich) für andere Nutzer*innen digitale Angebote und erleichtern so unser digitales Leben. Die Arbeit dieser Entwickler*innen sollte von öffentlichem Interesse sein, denn sie orientieren sich dabei an den Interessen und Bedürfnissen der Nutzer*innen und legen deutlich häufiger als proprietäre System Wert auf Datenschutz. Auch die dezentrale Struktur ist ein großer Vorteil, fördert sie doch die Souveränität und Entscheidungsfreiheit der Nutzer*innen.

Deswegen wollen wir diese Blogreihe beschließen, wie wir sie begonnen haben: indem wir uns dezidiert für eine Anerkennung und nachhaltige, finanzielle Förderung der digitalen Zivilgesellschaft und ihrer Arbeit, sowie ihre Einbeziehung in Fragen der Digitalpolitik aussprechen. Die digitale Zivilgesellschaft macht mit ihrem Engagement und ihrer Expertise vielen Bürger*innen das Leben leichter – Zeit, das (auch finanziell) anzuerkennen. Den passenden Aufruf des Superrr Lab könnt ihr hier mitzeichnen.