Prof. Dr. Detlef Stern

Free/Open-Source Software: Mehr Free als Source

Freie, quelltextoffene Software, auch Free/Open-Source Software genannt, ist ein essentieller Baustein für den Erfolg des Web, wohl auch des Internets. Diesen Post schreibe ich gerade mit Hilfe eines Editors, der in einem Terminal-Emulator läuft, der in einer graphischen Oberfläche angezeigt wird, die von einer Linux-Distribution verwaltet wird. Sobald ich fertig bin, wird der Text mit Hilfe eines Generators in HTML umgewandelt und mit einer einer Synchronisationssoftware auf den Server meines Hosters übertragen. Dieser wird mit einer anderen Linux-Distribution. Ein dort ablaufender Web-Server liefert den Post dann an Ihren Web-Browser, der ebenfalls sehr wahrscheinlich zu erheblichen Teilen aus freier, quelltextoffener Software entwickelt wurde.

Spätestens seit dem Vorfall mit der Software-Bibliothek log4j sollte jeder Person bewusst sein, wie sehr auch betriebliche Software freie, quelltextoffene Software verwendet, ja sogar von dieser abhängig ist. Wie weit diese Abhängigkeit gehen kann, wird gerne auch mal in einem Comic-Panel visualisiert.

Als Lösung wird in der letzten Zeit postuliert, dass man den entsprechenden Entwicklern einer solch freien, quelltextoffenen Software nur genügend Geld zukommen lassen müsse. Das ist viel zu kurz gedacht, und zwar aus einigen Gründen. Diese Pseudo-Lösung ignoriert wesentliche Elemente des Produkt- / Projektmanagements, der Softwaretechnik und persönlicher Motivation.

Zunächst zu gedanklichen Fehlern im Kontext der Softwaretechnik im engeren Sinne.

Einer der Gründe für die relativen Fortschritte in der Entwicklung von Software liegt in der Möglichkeit der Wiederverwendung schon programmierter Software. Die Idee der Wiederverwendung sollte jede:r begreifen, der:die schon mal mit Lego-Bausteinen gespielt hat, alternativ mit fischertechnik oder Metallbaukästen. Wer eine weniger monetär abgesicherte Kindheit hatte, konnte bestimmt schon einmal beobachten, wie ein Haus entsteht: aus lauter Ziegelsteinen, Betonplatten und/oder Porenbetonsteinen. All diese Komponenten wurden nicht speziell für das jeweilige Endprodukt hergestellt, sondern konnten auch für andere Endprodukte verwendet werden. Im Fall der Spielzeuge lässt sich so eine Burg schnell in eine Brücke umwandeln.

So ähnlich, wie diese handgreiflichen Komponenten, möchten viele Softwarearchitekten und -entwickler ebenfalls Komponenten verwenden. Log4j ist so eine Komponente. Die große Hoffnung dabei: je weniger Software man selbst entwickelt, desto schneller ist man fertig und desto weniger Fehler treten auf. Im Großen und Ganze erfüllt sich die Hoffnung mit der schnelleren Fertigstellung. Das gilt auch für eine geringere Anzahl an Fehler, rein numerisch betrachtet. Eine qualitative Betrachtung ist bei Software nicht immer ganz einfach.

Software existiert nicht. Zumindest nicht in dem Sinne, dass man Software sehen oder fühlen könne. Man kann Quelltext, den Programmcode sehen. Dieser ist aber nur eine Vorform der ablaufenden Software. Man kann die Auswirkungen von Software sehen, etwa beim Betrachten dieses Posts. Software selbst ist immateriell und unterliegt keinen physikalischen Gesetzen. Dies bedeutet aber auch, dass selbst ein klitzekleiner Fehler, zum Beispiel ein falsch gesetztes Bit, riesige Auswirkungen haben kann. Im Gegensatz zu Lego-Bausteinen ist Software bezüglich Fehler nicht stetig. Zusätzlich sind Softwarekomponenten Unikate, im Gegensatz zu vielen gleichartigen Lego-Bausteinen. Jede einzelne Softwarekomponente hat eigene Fehlermöglichkeiten und -auswirkungen.

Wenn man ein Softwaresystem erstellt und dabei externe erstellte Komponenten verwendet, darf man sich nicht darauf verlassen, dass Fehler in diesen Komponenten sich nur dort auswirken. Das ist aufwendig zu prüfen, was viele gerne ignorieren. Es wird noch aufwändiger, wenn die extern erstellte Komponente selbst wieder extern erstellte Komponenten verwendet, und so weiter.

Man kann das recht gut messen, nämlich über die Anzahl der direkten und indirekten Abhängigkeiten einer Software. Freie, quelltextoffene Software macht es relativ einfach, diese zu verwenden. Aber man darf nicht vergessen, dass Fehler, und in jeder Software gibt es genügend Fehler, sich auch auf das eigene Softwaresystem auswirken können. Mit Abhängigkeiten entstehen Verpflichtungen, wenn man sein eigenes Softwaresystem ernst nehmen will.

Ein Lösungsansatz könnte sein, dass man freie, quelltextoffene Software nicht nur als frei erhältliche Softwarekomponente begreift. Statt dessen könnte man sich auf den Punkt der Quelltextoffenheit besinnen.

Wenn man ein Log4j als Blackboxkomponente auffasst, dann handelt man sich zum einen zu viele Abhängigkeiten ein. Gerade diese Abhängigkeiten haben zu dem Problem im letzten Dezember geführt. Log4j ist in der Java-Welt eine eierlegende Wollmilchsau zur Protokollierung. Das meiste davon wird in einem konkreten Softwaresystem gar nicht benötigt. Trotzdem hat so gut wie jede:r Log4j als Gesamtpaket in sein Softwaresystem integriert. Mit dem bekannten Ergebnis.

Statt dessen hätte man auch nur den relevanten Quelltext aus Log4j in sein Softwaresystem übernehmen können. Das ist nämlich bei vielen Lizenzen für freie, quelltextoffene Software explizit erlaubt, auch bei Log4j. Das macht das Testen einfacher, da nur der relevante Teil getestet werden muss. Und man baut in seinem eigenen Kontext Wissen über die übernommene Software auf und ist nicht vom dem einen externen Softwareentwickler irgendwo in Nebraska abhängig.

Natürlich ist die Übernahme von Teilen des Quelltextes aufwändiger, als wenn man den gesamten Quelltext übernimmt oder sich gar darauf verlässt, dass jemand diesen Quelltext in eine direkt ausführbare Form gebracht hat. Denn Software ändert sich und man müsste sich dann immer wieder die jeweiligen Änderungen ansehen und entscheiden, ob man diese übernehmen muss. Dabei vergisst man, dass man dieses sowieso besser immer bei extern erstellter Software tun sollte, besonders wenn nicht 100%ig klar ist, wer für die externe Software verantwortlich ist und in welchem Vertragsverhältnis man mit den Verantwortlichen steht. Vielleicht erinnert sich noch die eine oder der andere an den Vorfall, bei dem jemand eine NodeJS-Komponente um Programmcode zum Bitcoin-Mining ergänzt hat und diese Komponente dann ungesehen von vielen verwendet wurde.

Ebenso hat mein Vorschlag eine natürliche Grenze. Irgendwo wird man eine Grenze ziehen müssen, bei der man nicht mehr Teile des Quelltextes übernimmt, sondernsich darauf verlassen muss, dass die gesamte Komponente funktioniert. Offensichtliches Beispiel ist für viele Softwaresysteme das Betriebssystem, der Web-Browser oder Web-Server. Das ist im konkreten Fall eine Frage der Risikoabschätzung, und nicht eine der Faulheit.

Mit jeder zusätzlichen softwaretechnischen Abhängigkeit zu einer extern erstellten Komponente, macht man sein Softwaresystem verwundbarer gegenüber extern induzierten Fehlern. Auch hier muss man eine Risikoabschätzung vornehmen. Freie, quelltextoffene Software ist hier in einem gewissen Sinne verführerisch, wenn man den Fokus auf den Freiheitsaspekt liegt, meist fokussierter auf den Aspekt der freien Nutzung, wie bei Freibier. Bei kommerziell vertriebener Software muss man sich um Budget kümmern. Da scheint die „Beschaffung“ von Open-Source-Software einfacher, weil nur einen Mausklick entfernt. Die Folgen sollte man besser nicht ignorieren.

Zum Schluss dieses Posts ein Beispiel auf meinem eigenen Umfeld.

In meinem letzten Post über die Version 0.2 des Zettelstore gab ich den Ausblick auf das nächste Release 0.3. Es wird dann möglich sein, eine Graphik mit einfachen Zeichen zu „malen“. Konkret verwende ich die Bibliothek ASCIIToSVG, die diese einfachen Zeichen interpretiert und daraus eine SVG-Repräsentation erstellt, die dann als Graphik dargestellt werden kann.

Mit dem ersten Prototyp war klar, dass ASCIIToSVG einiges anders interpretiert, als ich es für den Zettelstore definiert hatte. Zum Beispiel generiert ASCIIToSVG immer einen bestimmten, für den Zettelstore schädlichen SVG-Header. Der SVG-Code enthält Zeilenumbrüche und hätte so nicht in Data-URLs verwendet werden können. Nun hätte ich eine Mail an die Entwickler senden können, in der ich um Anpassung dieser Aspekte bitten würde, und dabei den notwendigen Quelltext mitliefern. Offen wäre, ob und wann diese Änderung vorgenommen worden wäre. Viel wichtiger ist aber, dass die Änderungen dazu geführt hätten, dass die Komponente ASCIIToSVG komplexer geworden wäre. Denn andere Nutzer von ASCIIToSVG hätten meine Änderungen abgelehnt. Um beide Sichtweisen zufrieden zu stellen, müsste die Komponente konfigurierbarer werden. Also wäre ASCIIToSVG fehleranfälliger geworden. Zudem wäre der Zettelstore auch von den Komponenten abhängig, von denen ASCIIToSVG abhängig ist, Mir ist nicht ersichtlich, ob diese Komponenten auf eine ähnliche Langlebigkeit wie der Zettelstore ausgerichtet sind.

Im Ergebnis habe ich den Quelltext kopiert / übernommen und an die Bedürfnisse des Zettelstore angepasst. Dabei habe ich einige für den Zettelstore angemessenen Vereinfachungen vorgenommen, die im Endeffekt die generierten Graphiken etwas netter aussehen lassen. Den Großteil des Quelltextes meine ich verstanden zu haben und konnte diesen so an die Fehlerbehandlungsphilosohie des Zettelstore anpassen. Dadurch wurde das Zusammenspiel viel robuster und Fehlermeldungen aussagekräftiger. Als das wäre mit einer Anpassung von ASCIIToSVG durch dessen Entwickler nicht möglich gewesen.

Damit habe ich die Abhängigkeit zu ASCIIToSVG wesentlich vermindert. Natürlich beobachte ich das Projekt, zum Beispiel in Bezug auf Fehlerkorrekturen oder für den Zettelstore relevante Funktionserweiterungen. Aber es bleibt in meiner Entscheidung, ob ich Änderungen übernehme oder als nicht relevant für den Zettelstore ignoriere.

Und wer sich den Quelltext des Zettelstore genau ansieht, wird feststellen, dass ASCIIToSVG nicht die einzige Komponente ist, die ich dank einer Open-Source-Lizenz übernehmen konnte. Auch so steht der Zettelstore auf den Schultern von Riesen.

In den nächsten Posts werde ich beleuchten, wieso Geld für die Entwickler von freier, quelltextoffener Software aus Gründen des Produkt- / Projektmanagements und aus Gründen persönlicher Motivation viel zu kurz gedacht ist und das eigentliche Problem vielleicht für eine gewisse Zeit ruhigstellt, aber nicht löst.

Aus Sicht der Softwaretechnik lässt sich eine unüberlegte Inklusion extern erstellter Software schon einmal nicht immer mit Geld an die Entwickler kompensieren.