Vorhin stand ich auf der Terrasse und habe den heftigen Regen beobachtet, der den Pegel der Limmat immer weiter ansteigen lässt und die Uferwege bereits überschwemmt. "Wenn es noch weiter regnet, steht das Wasser bald bei uns im Garten". Worauf meine Frau sagte: "Alles was hier fällt, interessiert Downstream. Uns betrifft der Regen, der Upstream fällt." Und schon war die Idee für einen neuen Artikel geboren.
Die Begriffe 'Upstream und Downstream' hört man immer wieder in der Community und im Umfeld von Freier Software. Aber was bedeuten diese Begriffe und was haben sie mit einem Fluss und Software zu tun?
Beginnen möchte ich mit einem einfachen Produktionsfluss, völlig unabhängig von einer Softwareentwicklung. Angenommen, wir möchten ein Auto bauen, erstellen wir zuerst die Teile, bauen sie zusammen und zum Schluss lackieren wir das Auto. Der Fluss lautet: 1. Teile --> 2. Zusammenbauen --> 3. Lackieren. Dabei treten zwei Regeln hervor:
- Abhängigkeitsregel: Jedes Element hängt von allen Elementen ab, die aus seiner Sicht vorgelagert sind (upstream)
- Wert-Regel: Jeder Schritt in der Vorwärtsbewegung (downstream) steigert den Wert des Produkts.
Bekannt ist das Upstream/Downstream-Konzept nicht nur in der Softwareentwicklung, sondern auch bei Netzwerken, in der Industrie, Biologie und Mathematik.
Vorgelagerte und nachgelagerte Software-Abhängigkeiten
Die meisten Softwarekomponenten haben Abhängigkeiten zu anderen Komponenten. Was also ist eine Upstream-Abhängigkeit und eine Downstream-Abhängigkeit?
Komponente C hängt von Komponente B ab, die ihrerseits von Komponente A abhängt. Die Anwendung der Wert-Regel ist hier etwas abstrakter, aber wir können sagen, dass die Komponente C den grössten Wert besitzt, da sie alle Eigenschaften der Komponenten B und A "importiert" und diesen Eigenschaften ihren eigenen Wert hinzufügt, was sie zur nachgelagerten Komponente macht.
Upstream und Downstream Software Projekte
Dies ist ein ziemlich üblicher Entwicklungsstil in Open-Source-Projekten: Wir erstellen einen Fork (Downstream) von einem Projekt, beheben einen Fehler oder fügen eine Funktion in diesem Fork hinzu und reichen dann einen Patch an das ursprüngliche Projekt ein (Upstream). In diesem Zusammenhang macht die Abhängigkeits-Regel das Projekt A zum vorgelagerten Projekt, da es sehr gut ohne Projekt B leben kann, aber Projekt B (der Fork) würde ohne Projekt A (das ursprüngliche Projekt) gar nicht existieren. Die Wert-Regel gilt ebenfalls: Da Projekt B eine neue Funktion oder Fehlerbehebung hinzufügt, hat es einen Mehrwert für das ursprüngliche Projekt A geschaffen. Jedes Mal, wenn wir einen Patch zu einem Open-Source-Projekt beitragen, können wir sagen, dass wir einen Patch stromaufwärts geschickt haben.
Beispiele
Ein typisches Beispiel sind Distributionen, die aufeinander aufbauen, bzw. voneinander abhängen: Debian --> Ubuntu --> Linux Mint. Auch in der Programmierung findet man das Konzept: Hauptklasse --> vererbte Klasse --> Methode im Objekt. Obwohl hier nur eine einfache Abhängigkeitsketten beschrieben wurden, bestehen in Wirklichkeit fast immer Abhängigkeitsnetze, bei denen eine Komponente von vielen anderen abhängig ist.
