Interview mit Kristian Köhntopp

Qualitätssicherung bei Software ist alles andere als ein gelöstes Problem
Kommentare

Was sagt die Heartbleed-Situation über den Stand von Open Source aus? Gäbe es nicht eine moralische Verpflichtung, dass große Unternehmen, die Open-Source-Software verwenden, sich an der Entwicklung beteiligen? Und wie kann Open Source in Qualitätszielen eigener Projekte berücksichtigt werden? Über all das – und einiges mehr – haben wir mit einem angesehenen Mitglied der Community gesprochen: Kristian Köhntopp.

PHP Magazin: Kris, in einem viel beachteten Beitrag auf Google+ hast du geschrieben, dass Open Source die Voraussetzung für guten Code ist. Was macht deiner Meinung nach den Vorteil von Open-Source-Software aus?

Kris KöhntoppKris Köhntopp: Open Source hat für alle an der Entwicklung von Software teilnehmenden Firmen und Personen eine Reihe von Vorteilen, die sich jedoch am Besten unter der Überschrift „Teilhabe“ zusammenfassen lassen. Das beginnt beim Einsammeln von Spezifikationen und Feature Requests, und geht dann über die Implementierung und Testen bis zum Review und zum Einsatz des resultierenden Codes.

Damit erfüllt Open Source auch eine Reihe von notwendigen Voraussetzungen für sicheren Code, da durch die Transparenz des gesamten Entwicklungsprozesses und die Offenlegung des Codes und der Diskussionen, die um seine Gestaltung geführt worden sind, klar ist, was genau warum so aussieht wie es aussieht.

PHP Magazin: Wie konnte es deiner Meinung nach zu so einem Debakel wie Heartbleed kommen?

Kris: „Teilhabe“ setzt natürlich auch ein Interesse der Nutzer an der Entwicklung und den Entwicklungsprozessen voraus. Ich verstehe, dass der Kern von Kryptographie ein sehr geekiges Thema ist und daher nicht so viele Leute in der Lage sind, dort sinnvoll an einer Diskussion oder dem Review von Code und der Mathematik teilzuhaben, die durch den Code implementiert wird. Andererseits ist es schon so, dass gerade OpenSSL (und GNU TLS und MozNSS in geringerem Ausmaß) wichtige Teile unserer Infrastruktur geworden sind – so ziemlich jedes Projekt und viele Unternehmen setzen diese Bibliotheken ein, wenn es darum geht, Dinge zu verschlüsseln, TLS zu implementieren oder mit Zertifikaten zu hantieren.

PHP Magazin: Bei dem gerade angesprochenen Problem ist es ja so, dass auch riesige Unternehmen auf OpenSSL setzen –hätte von denen etwas ins Projekt zurückfließen müssen? Wäre das nicht eine moralische Verpflichtung?

Kris: Die meisten Unternehmen kümmern sich nur in zweiter Ordnung um Moral, insofern ist es schwierig, hier realistisch mit moralischen Verpflichtungen zu argumentieren. Das ist aber auch gar nicht notwendig.

Alle Unternehmen, die mit Open Source arbeiten – und das beschränkt sich nicht auf OpenSSL – müssen schon aus rechtlichem und finanziellem Eigeninteresse sicherstellen, dass sie importiertes Intellectual Property korrekt managen. Das heißt bei Closed-Source-Importen die Lizenzen in Ordnung zu bekommen und die Haftungsfrage bei Fehlern zu klären. Und bei Open-Source-Importen, die Lizenzen in Ordnung zu bekommen, und bei Veränderungen am Source schnell und unbürokratisch zu entscheiden, ob etwas ein Asset oder eine Liability ist.

Assets, also Dinge, die Wert für das Kerngeschäft einer Firma haben, sind bei Open-Source-Entwicklung eher selten. Firmen setzen Open Source in Projekten ja ein, weil etwas Infrastruktur ist, dass jeder machen muss, und für das man die Kosten teilen will. Ein (Software-) Asset ist aber etwas, das uns von allen anderen Firmen, insbesondere aber von den unmittelbaren Mitbewerbern, unterscheidet, also ein Differenzierungsmerkmal, und so etwas findet man bei Software eher in der Business Logic als in Infrastruktur.

Bei Liabilities, also Software im Haus, die eigene Entwicklerkapazität bindet und Agilität kostet, ist es sinnvoll, Entwicklung außer Haus (also im Upstream, dem eigentlichen Open-Source-Projekt) zu finanzieren, und eigene Entwicklungen diesem Projekt wieder zuzuführen, damit man im Haus nicht einen Fork oder einen Satz Patches pflegen muss.

Das ist sehr elementar, aber es wird von vielen Firmen übersehen und nicht oder auf die falsche Weise gemacht – statt Dinge aus dem Haus in den Upstream zu schieben, wird ein lokaler Patch gehortet und manuell auf die nächste Version angepasst, die von außen kommt. Oder halt nicht, dann bleibt man auf einer alten, inkompatibel gepatchten Version von etwas sitzen, baut Technical Debt auf und verliert Agilität, um dann am Ende den Markt wegen Stagnation zu verlassen.

Alle Codeimporte, Closed Source wie Open Source, müssen dabei auch in das Qualitätsmanagement integriert werden, das die interne Entwicklung steuert. Das passiert aber schon bei Closed-Source-Importen oft nicht ordentlich, sondern es wird angenommen, dass importierter Code – gleich welcher Herkunft – magisch fehlerfrei und korrekt ist.

PHP Magazin: Wie hilfreich oder sinnvoll ist es, wenn hinter einem Open-Source-Projekt ein Unternehmen steht (wie beispielsweise bei MySQL) oder eine Foundation, wie es zum Beispiel bei Eclipse der Fall ist? Ist durch eine solche „Verpflichtung“ nicht ein höherer Qualitätsstandard zu erwarten?

Kris: Die Form, in der sich ein Open-Source-Projekt organisiert, ist fast egal, solange es Personen gibt, die sich um die Strukturen kümmern können und es in eine Richtung vorantreiben, die den Interessen der Nutzer genügt. Sehr erfolgreiche Beispiele für unterschiedliche Organisationsformen gibt es zuhauf: Oracle MySQL und SkySQL MariaDB als Firmen, KDE und Apache als Stiftungen oder stiftungsähnliche Strukturen, Perl und PHP als komplett amorphe, selbstorganisierende Haufen ohne einen starken formalen Träger.

Am Ende sind es nicht Dokumente, die Code weiter bringen, sondern Patches und die Diskussionen und Flamewars, die sich um solche Patches entwickeln.

PHP Magazin: In dem Beitrag schreibst du auch, dass das Problem oft auf der Managementseite zu suchen ist, da Qualitätsziele nur für die selbst entwickelten Anteile gesetzt werden – nicht aber für externe Komponenten. Wie könnte eine valide Lösung aussehen?

Kris: Qualitätssicherung bei Software ist alles andere als ein gelöstes Problem, aber es kann keine Entschuldigung sein, gar nichts zu tun.

Die Methoden, die wir haben – Review, Black Box und White Box Testing, Fuzzing und so weiter – müssen auch auf importierte Software angewendet werden. Bei Open Source hat man wieder den Vorteil, dass man das nicht im Haus und mit einer Black Box machen muss, also ohne Kenntnis des Codes. Sondern man kann sich mit anderen Nutzern des Codes zusammentun, die Kosten und den Aufwand teilen und das öffentlich als Teil des Upstreams für alle machen, und man kann einen informierten Ansatz, also White Box Testing, machen und auch prüfen, ob man eine gute Abdeckung hat.

Aber wieder setzt dies informiertes Engagement der Nutzer, also bewusstes Management von Open Source (und ein Budget!), bei institutionellen Nutzern wie Firmen voraus.

PHP Magazin: Eine letzte Frage sei mir noch erlaubt: Durch einen SuperGAU wie Heartbleed ist Open Source nicht mehr nur in auf IT spezialisierte Medien ein Thema – oft leider unter falschen Vorzeichen. Kannst du dieser unverhofften Popularität dennoch etwas Positives abgewinnen?

Kris: Ach, in Deutschland haben wir in den letzten hundert Jahren eine Umkehrung der Kultur erlebt. Zu Beginn des 20. Jahrhunderts war Deutschland eine Nation der Ingenieure und Erfinder, und Autoren wie Hans Dominik oder Bücher wie Das Neue Universum haben versucht, schon Kindern und Jugendlichen eine Begeisterung für Technik, und die MINT-Fächer im Unterricht zu entfachen

Jetzt, 100 Jahre später, haben wir eine öffentliche Kultur und Politik, in der alte Männer mit Kugelschreibern mit ihrem Computer-Unwissen kokettieren, in der Ausbau von Netz-Infrastruktur als unwichtig für das Land angesehen wird.

Die Politik und Teile der Wirtschaft konzentrieren sich auf den vergangenen Ruhm von Deutschland als Fertigungsnation, während Ben Horowitz Schlagwort von „Software Eats The World“ mit zunehmender Geschwindigkeit Realität wird.

Unsere aktuelle Generation von wirtschaftlichen und politischen Führungskräften verspielt gerade die Zukunft von Deutschland als Industrienation, und jede Nachricht, die diesem Land hilft zu begreifen, was da gerade passiert, ist wichtig und hilfreich. Selbst dann, wenn es eigentlich eine schlechte Nachricht ist.

Aufmacherbild: Question and information speech bubble icons, three-dimensional rendering von Shutterstock / Urheberrecht: Oakozhan

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -