 nützlich, unbedenklich Spektrum. Ich muss Ihnen wie gesagt nicht vorstellen, Pfefe. Ja, guten Morgen. Freut mich, dass alles hier so voll ist. Einglückt, dass es in sich so alle eins ist. Das wäre ja schlimm, so viele Leute. Ja, dieser Vortrag, ich muss gleich ein bisschen Erwartungsmanagement machen. Ich habe nämlich letztes Jahr einen anderen Vortrag eingereicht über TCB Minimierung und das wäre so ein bisschen technisch gewesen, was man machen kann als Programmierer. Der ist abgelehnt worden, weiß ich warum. War voll. Den habe ich dieses Jahr wieder eingereicht, aber es sollte nicht so aussehen, als wenn ich die ärgern will. Also habe ich noch einen Talk eingereicht. Den habe ich natürlich genommen. So, das heißt, den musste ich jetzt schnell vorbereiten. Ja, das Problem ist, das ist eher so ein Gedankengang als eine strukturierte Darstellung. Ich hoffe, es wird trotzdem hilfreich, aber es ist nicht so strukturiert wie meine sonstigen Vorträge. Ich fange einfach mal ein. Also es gibt mehrere Herleitungen, die im Grunde zum selben Ergebnis führen und ich lasse euch einfach mal teilhaben. Also es fing relativ früh in meiner Karriere an, da habe ich mich entschieden, ich werde nie Software schreiben, von der vielleicht Leben abhängen könnten. Ja, also so medizinische Geräte, Atomkraftwerke war so meine Vorstellung Militär natürlich sowieso nicht. Und dann habe ich aber jemanden getroffen, der Code für Atomkraftwerke schreibt und das war so ein Typ, ey, das ist doch ganz einfach. Das heißt, wenn die Leute, die ihre Grenzen einschätzen können, das nicht machen, dann machen sie halt die anderen. Das soll jetzt nicht verergemeinert sein. Ich habe tatsächlich noch einen anderen getroffen, der war nicht so, aber ich meine, dieser Art von Personen gibt es halt. Die Problematik an der Stelle ist, glaube ich, dass man programmieren explorativ lernt. Das ist häufig nicht so ein Kurs, den man durchgeht, sondern man läuft halt rum und sucht Grenzen. Das heißt aber auch, dass man per Definition die Grenzen noch nicht kennt, denn die will man ja gerade finden. Das heißt aber auch, dass alle Leute im Grunde immer gerade an ihrer Grenze arbeiten. Wenn Leute Software schreiben, dann gehen sie so weit, wie sie glauben, dass sie gerade noch können. Und das heißt aber im Umkehrschluss, dass die Technologie, die da draußen ausgerollt wird, das sind hauptsächlich eben nicht abgehangene, wohlverstandene Sachen, sondern das sind genau die Technologien, die der Typ gerade noch verstanden hat. Das ist so ein bisschen ein Problem und das wird noch mal verstärkt dadurch, dass wir eben heute so eine Modularisierung und Abhängigkeitswelle haben, dass Leute einfach noch Module von andersrum mit reinziehen und sich einfach im Grunde ohne Grundlage in der Realität vorstellen, dass derjenige schon wissen wird, was er tut. Und so ist es eben häufig nicht, sondern das sind genauso Leute wie du und ich, die eben auch explorativ gearbeitet haben. Das kann man sich auch ganz gut selbst überlegen, wenn man so ein kurzes Gedankenexperiment macht. Das konnte man auch schon live beobachten. Also nehmen wir mal an, jemand findet einen Weg, um besser mit Komplexität umzugehen, zum Beispiel Modularisierung oder objektorientierte Programmierung, als das gerade frisch war. Und dann würde man ja hoffen, dass wir die Software, die wir da vorgeschrieben haben, jetzt besser machen, weil wir das besser im Griff haben. Aber das passiert halt nicht, sondern was passiert ist, dass wir dann eben größere Software schreiben und wieder am Limit arbeiten. Ich glaube, dass es kein Problem der Softwareentwicklung oder des Programmierens ist, sondern generell ein Problem mit Menschen. So hat uns halt die Evolution gemacht, und da müssen wir lernen, mit umzugehen. Und ich will das mal illustrieren. Ich habe so eine Theorie, die nicht die gradienten Theorie. Und die Theose ist, dass Menschen ihre Umgebung wie ein Optimierungsverfahren betrachten in der Mathematik. Das heißt, man hat sozusagen einen Gelände und sucht den höchsten oder tiefsten Punkt. Das ist so ein Optimierungsproblem. Und dabei geht man eben nicht gezielt vor, wenn man das Gelände nicht kennt. Das heißt, man muss Annahmen treffen. Und das kann man an sich selbst beobachten. Wenn es zu kalt ist, dann geht man ja zur Heizung und stellt nicht so ein, wie man es haben will, sondern man stellt heiß. Und dann wartet man, bis es zu warm wird, und dann geht man wieder hin und stellt wieder runter. Das heißt, wir haben so ein Annäherungsverfahren, wie wir mit der Welt umgehen. Und das ist nicht nur bei Heizung, das ist auch bei Autofahren. Wenn wir so eine Landkarte haben, dann gucken wir uns an. Was ist denn das Limit? Wo müssen wir abbiegen? Und den Weg dahin ignorieren wir, obwohl der vielleicht ganz schön ist. Also viele Sachen, die wir machen, auch die Geschwindigkeitsauswahl ist so ein gradienten Ding. Wir beschleunigen, bis wir uns unwohl fühlen. Dann gehen wir wieder ein bisschen zurück. Oder wenn man im Wörterbuch oder Telefonbuch nachschlägt, dann macht man eine Annahme, wo das ungefähr sein wird. Und wenn das zu weit ist, geht man wieder zurück. Also der elementare Teil ist jedenfalls, wir haben die Annahme, dass das Gelände ungefähr so aussieht. Wir haben hier eine glatte Übergänge. Und dann funktioniert das Verfahren gut. Das heißt gradient descent übrigens, dass man versucht, der Schwerkraft hinterher zu laufen und den tiefsten Punkt zu suchen. Aber es funktioniert in zwei Fällen eben nicht gut. Der eine ist, wenn es einen Abhang gibt, über den ich rüber laufe, und dann kann ich nicht zurück korrigieren. Und das läuft auch nicht gut, wenn man nicht merkt, wenn man zu weit gegangen ist. Also es ist so ähnlich wie der Abhang. Und das zweite Problem ist, wenn man nicht zurückrollen kann aus anderen Gründen. Die gibt es in der Softwareentwicklung eben häufiger. Und es stellt sich raus, das sind genau die Art von Probleme, die Menschen eben haben. Zum Beispiel, wenn wir sowas haben wie zwei Wochen Probe-Abo, dann vergessen die Leute halt, da wieder auszutreten. Oder Drogenabhängigkeit, das ist ein klassiker Spielesucht. Und in der Softwareentwicklung oder überhaupt in Projektmanagement ist es häufig, jetzt haben wir schon so viel investiert, jetzt können wir nicht zurück. Security ist kein Gradient. Es sieht vielleicht aus wie ein Gradient, aber es ist keiner. Das ist gerade, glaube ich, das Grundproblem von der IT-Security. Man merkt nicht, wenn man zu weit gegangen ist, das merkt man erst, wenn man gehackt wird. Und dann kann man nicht mehr zurückrollen, dann sind die Daten schon weg. Komplexität ist ähnlich wie Security auch kein Gradient, aber es fühlt sich an wie einer. Und das ist, glaube ich, der Grund, warum wir damit so schlecht umgehen können. Das fühlt sich an, als wären wir alles unter Kontrolle haben. Und zu dem Zeitpunkt, wo wir merken, dass es nicht mehr so ist, können wir nicht mehr zurück. Übrigens ist auch Daten rausgeben, so an Facebook oder so, ist genau so ein Pseudo-Gradient, nenne ich das mal. Zu dem Zeitpunkt, wo man merkt, dass man zu viel rausgegeben hat, ist zu spät. Die Schlussfolgerung ist eigentlich, Komplexität ist böse. Wir bemerken sie zu spät und wir fangen sie uns auch zu leicht fertig ein. Und da muss man halt irgendwie gegensteuern. Die Kosten dafür werden im Moment an unsere Kunden, wenn wir das beruflich machen, externalisiert, an unsere Benutzer und an unser zukünftiges Selbst. Daher findet man relativ selten glückliche ältere Software-Entwickler. So, das war der erste Gedankengang, der mich in die Richtung geführt hat. Der zweite Gedankengang. Ich will jetzt mal das Genubanifesto rausgreifen, stellvertretend. Das ist kein Genubashing hier, aber am Genubanifesto kann man das ganz gut zeigen. Das war die ursprüngliche Ankündigung des Genubprojekts von Richard Stormen. Da hat er geschrieben, wir machen Unix-Programme und wir werden aber nicht genau dasselbe sein, wie Unix-Übel make all improvements that are convenient. Das ist ein ganz furchtbarer Satz. Was heißt ja ein Convenient, für wen denn? Aber das ist genau die Herangehensweise, die viele Leute haben, die Software schreiben. Oh, das kann man noch schnell dazutun. Was fehlt, ist so ein Korrektiv, dass man vorher drüber lehrt, wo er nachdenkt, was hänge ich mir eigentlich gerade für eine Legislationsbein? Ich glaube, dieser Convenience-Gedanke beim Erweitern von Software ist unsere Erbsünde, um hier mal ein bisschen katholisch zu werden in der Softwareentwicklung. Die haben alle schon mal begangen und das kriegt man eben nicht nachkorrigiert. Daher ist der einzige Weg, das los zu werden, ist, wenn man die ganze Software oder das ganze Modul wegschmeißt und neu macht. Aber Software stirbt halt nicht. Ich habe im Umgang mit Software erst verstanden, dass es gut ist, dass Menschen sterben, weil das ist ein Korrektiv, was gebraucht wird. Wenn ein System besser werden soll, dann muss der alte Scheiß auch irgendwann sterben können und das passiert bei Software halt nicht. Ja, also es ist ein Feature, dass Dinge nicht ewig halten. Man kann das allgemein beobachten, wenn jemand seine Software erweitern will und er hat die Wahl zwischen, wir machen jetzt hier mal was, um das konkrete Problem zu lösen oder wir machen hier was, um ein allgemeineres Problem zu lösen, dann werden die Leute immer das allgemeinere Problem zu lösen versuchen. Viel Feind, viel Ehr. Und das kann man fast flächendeckend beobachten. Es gibt sehr wenige Ausnahmen davon. Und ich hatte meinen ARH-Moment, als ich eines Tages mal GDB aufgerufen habe auf ein Projekt, also ich habe jetzt hier slash TMP genommen, aber das Projekt war irgendein Checkout. Ich habe in meinem eigenen Web-Server, habe ich einen Punkt GDB init. Das ist eine Konfliktarteil für den Genudibagger, wo man dann zum Beispiel sagen kann, da ruft das Programm, wenn ich es debaggen will, mit diesen Kommando-Zahlen-Argumenten auf und da schreibe ich dann rein, nimm nicht Port 80, weil das klappt nicht, sondern nimm Port irgendwie 8000, 5 oder so, was ich halt lokal host zum debaggen. So, und GDB hat eines Tages angefangen zu sagen, nee, die GDB init-Datei, die nehme ich aber nicht, denn die liegt hier in einem Verzeichnis, was du nicht freigeschaltet hast. Ja, und das war genauso ein Versuch, diesen Fehler nach der Tat zu korrigieren. GDB hat festgestellt, unsere Konfliktartei ist so mächtig geworden, dass es ein Sicherheitsproblem darstellt und hat dann halt die ganze Konflik-Sache zugenagelt für rückblickend. Und das hat halt mehr kaputt gemacht, als nötig gewesen wäre vielleicht. Weiß ich nicht, aber es war halt, ist für mich der Ärger nicht, also man kann das jetzt, man kann die so ein Autofahrt eintragen, aber da ist mir das halt zum ersten Mal so richtig aufgefallen. Das war jetzt vor ein paar Jahren, ich weiß gar nicht, wann es genau war. Es gab so einen ähnlichen Fall noch mal mit Wim, den Editor, den ich immer benutze. Da kann man nämlich so Sachen machen, wie in einen Kommentar, in der zu editierenden Datei in den ersten drei Zeilen oder in den letzten drei Zeilen kann man so ein paar Konflik-Settings ändern. Das ist gedacht, um zu sagen, ich benutze hier ein Tappstopp von vier oder so. Aber der Pasa dafür hat halt ein Sicherheitsproblem gehabt und damit war es dann möglich, sozusagen eine Datei zu erzeugen, die ein Programm ausgeführt hat, wenn sie in Wim geöffnet wurde. Was natürlich nicht gewollt war, aber es ist dasselbe Problem in Grün. Und ich glaube, das Problem kann man ein bisschen verallgemeinern, nachdem ich gerade gegen verallgemeinern gewettert habe, aber in der Betrachtung ist verallgemeinernd ja gut, in der Software ist schlecht. Und ich will das mal in einem Beispiel illustrieren. Nehmen wir an, wir haben jetzt CSV-Datei mit irgendwie Troubletickets. Feld 4 ist das, an dem wir jetzt Interesse haben. So, nehmen wir an, die sieht so aus. CSV-Halt. So, und jetzt möchte ich da gern die Summe der vierten Felder haben. So, dann mache ich als erstes mal Cut. Wir sind halt unter Unix. Ja, der Filter hat es hier raus. So, dann die erste Zeile muss noch weg. Also mache ich hier noch ein Tail. So, dann ist die erste Zeile weg. Jetzt müssen wir noch eine Summe bilden. Da gibt es auch ein Programm für Paste, wie man das halt macht unter Unix. Und dann muss ich das ausrechnen. So, aber was ist denn, wenn da jetzt nicht einstand, sondern sagen wir mal Fréd. Ja, dann können wir feststellen, Cut hat damit kein Problem. Tail hat damit kein Problem. Paste hat damit kein Problem. Aber BC fällt auf die Fresse. Ja, so, das heißt, schlimmer noch, BC ist programmierbar. Da könnte jetzt zum Beispiel die Ackermannfunktion stehen und dann steht der Rechner für ne Stunde, wenn er versucht, irgendeine Rekursoren aufzulösen. Ja. So, und ich glaube, das ist sinnvoll hier ein Konzept einzuführen und zu sagen, Cut, Tail und Paste sind harmlos, BC nicht. Das war so einer der Gedanken, wo ich dachte, okay, da kann man eigentlich mal einen Vortrag darüber machen. Allerdings ist es nicht hinreichend. Ja, es gibt verschiedene Arten von harmlosigkeit. Aber ich glaube, die Unterscheidung ist schon mal hilfreich. Ja, sagen wir mal, versuchen wir das mal zu formulieren. Software ist harmlos, wenn unerwartete Eingaben kein unerwartetes Verhalten oder unerwartete Arten von Ausgabe erzeugen. Ja, zum Beispiel so ne Schaar, Check-Summe ist immer harmlos. Egal, was ich dafür daten rein tue, dass die Ausgabe ist, hat ein bekanntes Format. Oder World Count ist auch so ein Ding. So, jetzt könnte man sagen, okay, nimm noch AWK. Und in AWK habe ich zum Beispiel kein Problem, wenn er jetzt Fred steht, statt 4 und der interpretiert auch nicht Funktionen. Das sieht besser aus, aber es ist auch harmlos. Und es stellt sich raus, AWK ist eine andere Art von nicht harmlos, denn man kann im Code im Dateisystem rumschreiben. Ja, da muss ich jetzt nicht auf die Eingabe achten, aber ich muss auf die andere Eingabe achten, nämlich den Code, den ich auf der Kommandozeile übergebe. Und da kann man eigentlich auch sagen, dass man die Unterscheidung haben möchte. Das ist in der Industrie übrigens ein großes Problem. Die Spieleindustrie ist dazu übergegangen, in großem Stil irgendwelche Interpreter in ihre Spiele einzubauen, um die Business-Logik, also die, die nicht die AI, sondern so kleine Skripte eben in einer Skripsprache machen zu können. Und einer der beliebtesten Skripteinterpreter dafür ist Lua. Und Lua wird vor allem deswegen genommen, weil der halt nichts kann, was man nicht freischaltet. Also der kann nicht Datei öffnen, der kann keine Sockles aufmachen. Das kann man alles nachreichen und dann hat man natürlich wieder ein Problem, aber das ist ein reales Problem. Die viele Open Source Leute denken, da sich nicht drüber nach, weil sie sich denken, ach ich lief das aus und der Rest ist ja nicht mehr mein Problem. Aber ich finde, da müssen wir mal generell drüber nachdenken und zwar am besten vor dem ausliefern, am besten schon beim Programmieren. Also das ist eine andere Art von harmlosigkeit. Vorher war die harmlosigkeit keine böse Eingabe, böse Ergebnisse erzielen und jetzt kann das Programm selbst Bösedinge machen und das ist eigentlich eine sehr moderne Überlegung, weil wir heutzutage viel mit Sandboxing arbeiten. Da geht es genau darum, zu verhindern, dass ein Programm versehentlich oder absichtlich Bösedinge tut. Und da gibt es wieder auch verschiedene Sachen, die ein Programm anstellen kann. Also bc konnte Rechenzeit verbraten, avk kann im Dateisystem lesen und schreiben und das geht natürlich weiter. Ja, kommen wir zurück zum GNU Manifesto. GNU AWK ist eine spezielle Version von avk und die kann sockets aufmachen völlig ohne Not. Ja, das heißt, wenn wir einfach avk benutzen und denken, ah avk kann im Dateisystem schreiben, aber das habe ich ja read only gemount, da passiert schon nichts. Und dann ist aber GNU AWK im Einsatz, ist es halt doch wieder nicht harmlos. Ja, BESCH kann übrigens auch sockets aufmachen, ich weiß nicht, wie viele von euch das wussten. Ja, gut, die Sache geht natürlich noch weiter, nach avk kam Perl, das ist noch viel schlimmer und dann Perl kann eWall, eWall ist so, dass das schlimmste Übel, was man haben kann in der Programmiersprache aus meiner Sicht ein bisschen näher am Endkunden kann man das auch an Browsern betrachten. Ja, also gucken wir uns zum Beispiel mal Netscape an. Netscape hat auch mehrfach die Wahl gehabt zwischen nützlich und harmlos und hat immer nützlich gewählt. Ja, es ging dann los mit den Plugins, weiß nicht, wer sich hier noch an das Flash Plugin erinnert oder vorher hat alle den Real Player und das Acrobat Plugin gab es auch mal und das war alles scheiße, ja, weil diese Plugins eben Native Code waren, die konnten alles tun, was das Betriebssystem ihnen erlaubt. Das heißt, das war zwar sehr nützlich, aber es war eben auch sehr gefährlich und das war eine bewusste Entscheidung von den Browsern das zuzulassen. Ja, also das eigentlich Ziel von diesem Vortrag ist den Programmierern unter euch so ein bisschen das Bewusstsein dafür zu geben, dass man nicht einfach eine Pluginschnittstelle einbaut, die alles kann. Die nächste Iteration, weil wir machen einfach alles in JavaScript, ja, das war, er sah erst mal besser aus, aber dieser JavaScript lief dann eben auch mit genügendem Zurechten um im System Mist anzustellen und zumindest im Browser Mist anzustellen und das stellt sich raus, die Leute haben ihre wichtigen Daten heutzutage im Browser, weil sie Online Banking machen und das reicht, um richtig Doltschaden anzustellen. Ja, da musste auch nachkorrigiert werden, Kroben limitiert jetzt noch weiter aus Sicherheitsgründen, um den Ad Blocker kaputt machen zu können, also das ist eigentlich immer die selbe Falle, in die wir hier reinlaufen. Ich weiß nicht, wer hier Windows benutzt, unter Windows gibt es ein Tool, das von Markus Hinovic, der hat sich inzwischen kaufen lassen von Microsoft, also ein offizielles Microsoft Tool und die einzige Funktion von dem Tool ist, die verschiedenen Plugins zu listen, die im System eingetragen sind und ich habe hier mal ein relativ sauberes System genommen, das geht jetzt nicht um das hier unten oder die Größe von dem Scrollbalken, sondern einfach wieviel Tabs es oben gibt, ja, das sind alles Möglichkeiten, wie sich Plugins im System einlisten können und das hat einfach niemand mehr im Blick, weil einfach immer in die falsche Richtung entschieden wurde. Also das ist, glaube ich, ein Kernproblem. So, das gab noch eine dritte Herleitung. Mein Security-Alltag besteht darin, dass ich zur Firmen gehe und die zeigen mir ihren Quellcode und dann suche ich danach Bugs und dann sage ich denen, welche Bugs ich gefunden habe. Ja, und da gibt es dann halt gelegentlich so Fälle, wo man mitkriegt, da gibt es ganz viele Bugs. Ja, gar nicht mal nur die, die ich finde, sondern die haben schon eine Datenbank, ein Bugtracker und da sind schon siebenstellig Bugs drin, ja, so was kommt vor. Und weil das so ein Problem ist, dass wir so viele Bugs haben, gibt es jetzt gegen Strategien von den Entwicklern, die dann anfangen zu sagen, na ok, wenn der Bug nicht wichtig ist, dann kann ich ihn ja später fixen. Und das heißt, in der Realität, nie. Ja, der liegt dann halt rum. Ich versuche seit einer Weile den Begriff Bug Welle dafür zu etablieren, die man vor sich her schiebt, als großer Dampfer. Aber Bugtracker sind in der Realität da draußen häufig riesige Daten entlager. Ja, ich habe zum Beispiel neulich einen Bug bei Firefox gemeldet und habe die ID 1,59 Millionen gekriegt. Das ist ja schon ein schlechtes Zeichen eigentlich. Aber es ist ein gutes Zeichen, weil der Bugtracker offen ist. Ja, bei Microsoft kann man das gar nicht sehen, wie viele Bugs die haben. Also das ist jetzt hier nur als Illustration gemeint. Mozilla ist nicht besonders scheiße. Mozilla hat nur einen offenen Tracker, an dem ich das schön etablieren kann. So, und was ich jetzt noch zeigen wollte, ich habe noch mal geguckt, was ist ja der erste Bug, den ich da gefeilt habe und er hatte noch ne sechstellige ID. Das war 2003. Ja, so, wenn man sich das, den Verlauf anguckt, der Bugnummer, stellt man fest, das wächst exponentiell. Und es ist nicht so, dass die Bugs dann irgendwann weggehen von irgendwann. Also ich habe so zwei große Ereignisse beobachtet, bei denen Bugs geschlossen werden. Das ist wenn es ein neues Release gibt und da schmeißt man die alte JavaScript Engine raus und macht eine neue rein, dann schließt man alle Bugs von der alten Engine. Und das sieht dann so aus, als wenn man was geschafft hat. Und der andere Weg ist dieser hier. Ich weiß nicht, ob man das hinten lesen kann. Mozilla hat einfach ein Bug von mir geschlossen. Da steht drin, this bug has been automatically resolved after a period of inactivity. So die war jetzt nicht von mir die Inactivity. Ich habe den Bug gefeilt und bei Mozilla hat sich keiner darum gekümmert. Und dann haben die den halt automatisch geschlossen, weil die Statistik so schlecht aussah. Das ist ein Riesen Problem, nicht nur bei Mozilla. Wie gesagt, das ist hier nur der Blitzerbleiter, den ich zeigen kann, weil das alles öffentlich ist bei den. Aber das führt zu so einer Kaskade aus Verhalten und Gegenverhalten. Zum Beispiel sieht man dann unwichtige Bugs werden halt gar nicht gefixt. Und dann schreiben die Leute halt wichtig an ihre Bugs, wenn sie wollen, dass die gefixt werden. So und dann haben die Leute gesagt, okay, dann machen wir die wichtigen Bugs, bleiben dann auch liegen, weil da gibt es zu viele von. Und dann schreiben die Leute Security an ihre Bugs ran. Und dann haben wir jetzt eine Welle von Security Bugs und da wird dann verhandelt. Ist das dann wirklich ein Problem? Und da kommt dann so ausreden, wie ist ja nur ein Crash. Und der Punkt daran ist, dass es hier eine unheilige Allianz gibt mit einem anderen Trend, nämlich das Firmen einfach sehen, sie haben so viele Bugs offen, dass es gar nicht das Ziel ist, die alle loszuwerden. Es gibt einfach zu viele, das unrealistisch. Stattdessen macht man so, führt man Metriken ein, wie das man Fashing macht. Fashing ist eigentlich keine doofe Idee, aber es ist eben nicht alle Bugs finden, sondern es ist nur der erste Schritt auf einer langen Straße. Aber es ist halt eine schöne Metrik, die daraus wählt. Wir haben so und so viele Fast-Test-Cases gemacht und jetzt, ja, jetzt sind wir jetzt besser oder schlechter als vorher ist. Alles schwer zu sagen. Und dann gibt es Bugbounties, was ich persönlich für Bullshit halte. Das macht man damit die PR-Abteilung zeigen kann. Guck mal, so viel Wert sind Bugs bei uns, weil wir so wenig Bugs haben. Das ist die Idee. Und der Rest der Industrie hat einfach Mitigations gemacht. Da haben Sie dann gesagt, okay, wir schließen die Bugs nicht mehr, wir machen das Exploiten schwieriger. Und das funktioniert. Ich bin da immer dagegen gewesen. Ich musste also jetzt meinen Hut fressen sozusagen. Das funktioniert. Aber es hat halt Nebeneffekte. Weiß nicht, ob ich Zeit habe für den Entdoten. Ich bin nämlich zeitlich sehr knapp dran. Aber ich hab mal den Typ getroffen, der die Internet Explorer Bugs verwaltet, die reinkommen. Und ich hab den getroffen, weil ich 50 Bugs gefeilt habe. Und der hat gesagt, 35 kenne ich schon. Und da habe ich gesagt, wie jetzt. Also der Typ sah aus wie Gollum in so einer Cave. Der war irgendwie 30 und sah aus wie Ende 60. Und der meinte da, das kommen halt so viele Bugs hier rein. Wir kommen gar nicht dazu, irgendwelche zu schließen. Wir verwalten die nur noch so. Das war der Stand damals. Das ist inzwischen besser geworden. Also Microsoft ist nicht. Und also das, wie gesagt, das sind hier Beispiele. Ja, das ist in anderen Firmen ähnlich. Man verwaltet die Bugs und man schließt sie nicht mehr. Und Memgc ist eine Sache, da habe ich lange Jahre gar nicht überreden dürfen. Aber inzwischen haben sie das selbst veröffentlicht. Deswegen darf ich das jetzt doch erzählen. Da haben sie halt festgestellt, wir haben lauter Memory Corruption Bugs, weil wir immer die Sachen Free vom Heap Free und dann aber noch benutzen. Und da haben sie jetzt einen Hack gebaut, der die Sachen dann halt nicht Free, sondern in eine Liste tut. Und dann läuft er über den Stack und guckt nach Pointern die in die Liste zeigen und gibt die dann nicht frei. Ja, das ist ein furchtbarer Hack. Wir haben mir ja zu peinlich gewesen, das irgendwo zu erwähnen. Aber Microsoft macht jetzt PR damit. Wie geil Memgc ist. Und die Kromleute haben sich das angesehen und haben gesagt, boah, das ist ja geil. Also das ist der Stand, wie die Industrie funktioniert. So, das Problem ist jetzt aber, dass Bugs nur noch mit Exploit als Security Problem anerkannt werden. Also das ist nicht braunschöngübergreifend, aber es ist bei vielen inzwischen so. Ja, wenn man da kein Exploit liefert, wird es nicht anerkannt. Aber wir haben ja vorhin gesehen, dass überhaupt nur noch das anerkannte Security Bugs gefixt werden. Das heißt, Bugs liegen einfach rum, weil der Nachweis nicht erbracht werden konnte. Und wenn das Außennutzen von einem Bugs durch die Mitigation schwieriger wird, heißt es eben, dass immer mehr tatsächliche Sicherheitsprobleme rumliegen, weil niemand Bock hat, den Nachweis zu erbringen, dass es ein Problem war. Das heißt jetzt nicht, dass keiner von den Bugs jemals geschlossen wird. Denn es stellt sich raus, die Entwickler haben so was wie ein Anspruch an ihren Code. Keiner möchte der Typ sein, der die Brücke in Genoa gebaut hat. Das heißt, die Leute laufen schon rum und schließen Bugs, aber sie möchten halt nicht gezwungen werden dazu. Und sie möchten auch nicht anerkennen, dass es ein Problem war. Und das halt so eine Kaskade an Problemen in der Realität. Aber ich schließe daraus erst mal reaktiv auf das Problem mit den Bugs und der Softwarequalität zuzugehen, hilft eigentlich nicht. Ja, ich sage das schon länger über Viren und Würmer und die Antiviren, die ich immer als Schlangenöl bezeichne. Ich glaube, dass das bei Bugs auch so ist. Viel zu viel Software wird einfach entwickelt und man denkt sich, na ja, dann können wir das mal ausliefern und der Kunde testet das dann und dann melden die schon die Bugs und die fixen wir dann halt. Also es gibt so inzwischen das geflügelte Wort, man liefert aus, wenn der Update funktioniert. Und na ja, da müssen wir ja irgendwie mit umgehen als Industrie. Also ich versuche hier als Zielgruppe jetzt die Entwickler. Was machen wir denn jetzt? Das ist jetzt so die Frage. Und da gibt es natürlich verschiedene Ideen. So der FDP-Ansatz ist meines Erachtens gescheitert. Der Markt hat da gar nichts geregelt. Die Leute kaufen immer noch alle Windows und MacOS. Also das funktioniert, glaube ich, nicht. Dann kann man versuchen, an die Moral zu appellieren. Freiwillige Selbstkontrolle, das funktioniert auch nicht aus meiner Sicht. Dann gibt es den BSI-Ansatz. Wir tun einfach ein paar Lagen Schlangenöl drüber. Das funktioniert leider auch nicht. Und es gibt den Twitter-Ansatz, so Ausgrenzung und mit Dingen drohen. Holgabel Mobs. Das hat in meiner Beobachtung eher zu Bendenwehr geführt, weil die Leute halt weggerannt sind. Dann gesagt, da machst du mir doch egal. Das ist nicht mehr meine Software. Es gibt auch so ein Hybrid-Ansatz, den die katholische Kirche seit vielen Jahren erfolgreich fährt. Vielleicht ist das die Lösung. Dass man sagt irgendwie, nicht der Markt, aber sagt Peter, regelt das? Und an Moral-Appellieren funktioniert es ein bisschen. Das müssen wir vielleicht ausbauen. Und dann dachte ich mir so, OK, was machen wir jetzt konkret? Ich habe als erstes gedacht, OK, wir müssen vielleicht gucken, ob wir die explorative Softwareentwicklung von der zielorientierten Softwareentwicklung trennen, dass wir sagen, es ist gut und richtig, dass die Leute explorativ lernen. Aber das ist dann nicht das Produkt, was du schippst. Da müssen wir irgendwie hinkommen. Und ich appelliere seit Jahren an die Firmen und sage, gib hier in der Zeit, dass sie ein bisschen rumspielen und Sachen lernen können. Denn sonst lernen sie das während der Produktentwicklung und dann nur das Produkt. Scheiße. Aber da kann ich lange reden, bis ich blau anlaufe. Der Effekt ist bisher nicht vorzeigbar. So, also ich finde, man kann das gut auf den Punkt bringen, wenn man sagt, sei innovativ damit, was du tust und nicht, wie du es tust. Also eine Firma soll ja innovativ sein, soll Dinge probieren, neue Produkte machen, aber dann nicht irgendeine experimentale Datenbank Tech anwenden, die dann irgendwie mit den Daten verloren geht, weil war noch nicht fertig. Ich glaube, es gibt da nicht nur eine Ursache, sondern es gibt mehrere Komponenten und die muss man, glaube ich, auch getrennt betrachten. Also die erste ist Unwissenheit. Ich weiß einfach nicht, dass der Code scheiße war, den ich da importiert habe. Oder ich wusste nicht, wie man das besser macht. Deswegen habe ich das halt nicht gut gemacht. Und dann gibt es, was ich mal absichtliche Unwissenheit nenne. So, wir haben keine guten Leute gefunden. Das halte ich für eine Ausrede. Wer möchte und wer gut zahlt, findet auch gute Leute. Solange das Projekt irgendwie so ein bisschen was an sich hat, was man vielleicht mal ausprobieren möchte. Also das halte ich für eine Ausrede. Ich glaube, das sagen Leute, die sagen, ach, es ging halt nicht anders. Wir haben halt eine schlechte Leute. Dann wird das Produkt halt nicht so gut. Das macht ja nichts. Ja, so war nicht meine Schuld. Halt ich für eine Schutzbehaltung. Und dann gibt es natürlich Inkompetenz. Also so richtig. Ach, das ging gar nicht anders. Ich habe noch nicht so einen Kunden gehabt. Das sieht häufig nicht aus wie Ausreden, sondern wie Best Practices. Aber ich halte es für Ausreden. Ich habe neulich so einen Kunden gehabt, die machen jetzt, ja, wir machen jetzt eine Plattform für Energiehandel. Also kritische Infrastruktur, würde man eigentlich sagen. Und ja, wir machen das in der Cloud, weil selber Hosten können wir ja gar nicht. Manchmal nicht so. Ja, warum denn nicht? Na, das ist ja so teuer. Verstehe ich nicht. Also ich glaube, wir haben da so eine Kaskade ausreden, die vor uns hergeschoben werden. So und der Ansatz, den ich jetzt gehen möchte, ist das sage, wir versuchen vielleicht so eine Art Legacy Faktor zu definieren, indem man die Software dran schreibt. Und da geht es jetzt nicht darum, wie schlecht ist die Software, sondern wie negativ beeinträchtigt wird meine Software, wenn ich das als Dependent sie reinnehme. Ja, also wenn ich jetzt irgendeine Library reinziehe, wie viel negative Auswirkungen hat das? So das Problem ist jetzt aber, wenn wir das als Metrik machen und die wird irgendeine Art von Erfolg im Markt haben, dass die Leute dann natürlich bescheißen werden und werden nach der Metrik optimieren und nicht nach dem tatsächlichen Ziel der Metrik. Daher ist das so ein bisschen schwierig, aber es gibt ein Vorbild, was so ein bisschen funktioniert, nämlich CVSS, das ist das Common Vulnerability Scoring System. Das wird angewendet, um die Problematik von Bucks zu messen. Da haben sich also Leute zusammengetan und versucht, eine Metrik zu definieren. Und die funktioniert in der Industrie gut, die wird angenommen. Ja, die Leute lieben das. Das funktioniert grob so, wie eine historische Risiko-Bewertung. Man guckt halt so, wie wahrscheinlich ist das, dass das passiert, dass das jemand ausnutzt. Da gibt es dann Kriterien wie, ist das technisch aufwendig? Kommt man daran, wenn man lokal eine Count hat oder auch über Netzwerk? So und was macht man denn kaputt? Wenn man das ausnutzt, kann man dann Daten löschen oder kann man die verändern? So, also diese Art von Sachen klickt man an und dann kommt ein Score raus. So, das finde ich eigentlich eine gute Sache. Ich glaube, wir brauchen so ein Risikoscore. Jetzt nicht für Bucks. Bei Bucks ist das, glaube ich, einfacher zu machen, obwohl das auch schon viele Details Schwierigkeiten hat. Aber eigentlich brauchen wir so eine Art Risikoscore, entweder für das Management oder für die Entwickler. Und das sind getrennte Probleme. Ich glaube, es ist zielführend, sich an die Entwickler zu halten. Denn ich habe bisher noch fast nie erlebt, dass Management gesagt hat, das muss jetzt besser werden und das war nicht nur als PR gemeint. Aber Entwickler haben so eine Art Anspruch an ihren Code. Und ich glaube, wenn man den hilft, zu erkennen, ob sie gerade einen Fehler machen, können wir was stemmen. So habe ich mir gedacht, okay, welche Dimensionen gibt es denn da? Das ist leider ein mehrdimensionales Problem. So, hier ist eine der Dimensionen, die ich mir überlegt habe. Sicherheitslöcher, gut klar. Wenn der Code Sicherheitslöcher hat, ist das ein Problem. Aber das ist leider ein offenes Forschungsfeld, wie man die Sicherheitslöcher finden soll und vor allem da eine Metrik führt zu haben. Na, jetzt kann man sagen, okay, wir haben jetzt 10 Bucks gefunden, also war der Code wahrscheinlich unsicher. Und da ist was dran, aber wir wissen ja nicht, ob das alle 10 Bucks in dem Code waren. Ist der Rest von dem Code vielleicht super? Und das waren halt 10 Ausrutscher? Oder also das ist leider sehr schwer zu messen. Daher eignet sich das, glaube ich, nicht als Metrik. In der Industrie gibt es Versuche, mit Codesmails und statische Analyse zu arbeiten. Das ist eine Sache, die im Moment sehr viele Firmen ausprobieren. Der Erfolg ist bisher ermäßig. Also meine Beobachtung ist, dass man dann eben so ein Tool ausrollt und der wirft dann 10 Milliarden Warnungen. Und dann schaltet man solange die Sensibilität von dem Tool runter, bis die Menge verarbeitbar ist. Und dann verteilt man das an die Entwickler und die sagen ja, das sind aber alles false positives. Und dann ist das Projekt gescheitert. Ja, dann lässt man das weiterlaufen, damit es nicht so aussieht, als wenn es gescheitert ist. Aber das tatsächlich, was passiert, ist halt selten. Daher, das ist zwar eine wichtige Dimension, aber ich glaube, die können wir nicht ordentlich in der Metrik abbilden. Ich wüsste jedenfalls nicht, wie. Es gibt, also ich versuche es hier auch an Beispielen zu illustrieren vielleicht ein bisschen. Ja, also es gibt so extremer, es gibt einmal Q-Mail und Sandmail. Das ist so eigentlich ganz gute Illustrationsbeispiele. Das sind beides MTAs, also Programme, die auf dem Server laufen und Mails weiter verschicken oder annehmen. Und Q-Mail ist halt gebaut worden, mit dem Ziel, eine sichere Software zu haben. Da hat sich jemand erstes Design überlegt und dann die Software so gebaut. Und Sandmail ist halt erst geschrieben worden, dann kam jemand und meinte ja, vielleicht brauchen wir auch ein Design. Ja, und das sieht man halt bis heute. Q-Mail hat, es ist irgendwie in unserer 93, sicher noch so veröffentlicht worden, ging dann bis Version 1.03 und danach gab es nie wieder ein Patch. Und ich setze das aber bis heute ein, weil es da nie wirklich Probleme gab. Also das ist sozusagen fertige Software. Das ist so das eine Ende. Und das ist auf der anderen Seite heißt es aber auch, dass neuere Features einfach nicht drin sind. Ja, so ist ja mein zweischnelliges Schwert. So, das ist so das Spektrum, auf dem wir uns bewegen. Auf der einen Seite so ein alter Legacy-Codehaufen, den keiner mehr wirklich verwalten will, außer er wird bezahlt dafür. Und selbst unter den Leuten, die bezahlt wurden, sind dann die meisten weggelaufen übrigens. Also das will einfach niemand haben. So, die zweite Dimension, über die man nachdenken kann, es gibt es ja noch Wartung dafür. Ja, das kann man bei Open Source Produkten glücklicherweise ganz gut erkennen. Bei kommerzieller Software ist das ein bisschen schwieriger, weil da gibt es dann vielleicht Patches und neue Versionen, aber ob die auch tatsächlich was ändern, ist halt nicht so klar. Oder wie viel sie ändern. Und das ist auch nicht so klar, wie man das jetzt bewerten soll. Denn wenn das Software keine Updates kriegt, muss das ja nicht heißen, dass die Scheiße ist. Das kann ja auch sein, dass die einfach fertig ist. Das ist zwar sehr, sehr selten, aber es gibt Beispiele dafür. Tec ist zum Beispiel so ein Beispiel, das ist ein Satzsystem von Donald Knuth. Das hat er halt geschrieben und das ist jetzt fertig. Also da gibt es zwar immer noch Patches gelegentlich, aber ganz selten. Und die ändern zwei Bits irgendwo. Also im Wesentlichen fertig. Oder LibJPEG habe ich hier als Beispiel genommen, das ist irgendwann geschrieben worden von der Independent JPEG Group um Tom Lane. Und das hat eigentlich nie irgendwelche Updates gebraucht. Das war einfach, hat doch keine Sicherheitslücken gehabt. Das ist deswegen jetzt nicht schlecht. Das heißt, es ist nicht so einfach zu sagen, okay, gibt keine Patches mehr, also ist die Software scheiße. Die Metrik ist also auch sehr schwierig. Ja, so wie machen wir das? Ja, gute Frage. Gut, das habe ich jetzt schon erzählt. Auf der anderen Seite ist es so, wenn eine Software sehr häufig geupdatet wird, ist das auch nicht unbedingt ein gutes Zeichen. Also wenn es gibt, ich habe einen Kunden, der hat eine Software von einem Drittanbieter und der released per Github sozusagen. Und da kommen dann pro Tag fünf Updates. Und da steht aber jedes Mal Release dran. Und gelegentlich brechen die was, gelegentlich nicht. Da hast du nie irgendeinen Ansatzpunkt, um auch nur zu beurteilen, ob die Software jetzt gut ist oder nicht. Weil in dem Moment, wo deine Untersuchung fertig ist, gibt es schon wieder 20 neue Versionen. Ja, das ist also eigentlich auch nicht gut. Eine weitere Dimension ist die Dependency Hölle. Die kennt ja fast jeder, der schon mal Software entwickelt hat, besonders krass ausgebildet bei JavaScript, die da ein paar Mal sehr öffentlich auf die Fresse geflogen sind, als zum Beispiel jemand ein Modul zurückgerufen hat, von dem es sich dann rausstellte, dass das irgendwie über transitive Abhängigkeiten in fast allen Projekten irgendwie drin war. Das müsste man dann transitiv anwenden, wie gesagt. Also wenn ich eine Software rein lade und die halt 50 andere Dependencies, dann muss ich die Summe davon nehmen. Die extremer dabei werden, auf der einen Seite so eine Cloud-Lock-Inhölle, wo man die Abhängigkeiten gar nicht sieht, sondern man hat halt irgendwie irgendeine Pipeline aus der Feld irgendwas raus und der resolft am besten die Abhängigkeiten noch automatisiert während des Bounds und zieht sich irgendwas aus dem Internet, das ist so das eine Extrem. Und die andere Abhängigkeit, die als andere Extrem ist wieder QML, der hat halt überhaupt keine Abhängigkeiten. Der benutzt die C-Library, das C-Runtime, das halt drauf ist und braucht ein C-Compiler zu bauen und das war's. Also da gibt's auch ein Spektrum, was sich ja eigentlich für eine Metrik geeignen würde. Aber wie gesagt, es gibt halt mehrere Dimensionen. Wir kommen weiter. Nächste Dimension ist Codequalität. Das ist so ein bisschen wie Security, aber ich möchte das für allgemein an. Und zwar unter anderem deswegen, weil es eine relativ starke Korrelation zwischen vielen Bugs und schlechter Security gibt. Alle Security-Probleme sind auch ein Bug. Wenn also jemand viele normale Bugs hat oder Bugs, von denen wir nicht wissen oder nicht nachgewiesen haben, das ist ein Sicherheitsproblem. Dann ist das im allgemeinen Zeichen dafür, dass da auch viel Sicherheitslücken drin sein werden. Daher ist es wichtig als Metrik, selbst wenn es nicht um Sicherheit geht. Ja, also wie gesagt, die Trends dazu sind Statische Codeanalyse und Codesmails. Ich wäre noch dafür 100% Coverage beim Unitesting zu erwarten. Aber das ist halt auch schwierig, weil da gibt es verschiedene Messverfahren. Zum Beispiel, was macht man, wenn mehr als ein Statement auf einer Zeile steht? Geht man da an, was ist die Granularität des Testens? Ja, also ist alles nicht so einfach. Aber wir sollten zumindest mal anfangen, über nachzudenken. Und mein Vorschlag wäre aus den eben erklärten Gründen, dass wir einfach gucken, welche bekannten Bugs gibt es denn? Wie ist denn so, wie viele Bugs kommen immer, werden bekannt? Pro, sagen wir mal, ja. Und daraus kann man extra polieren. Die nächste Näherung wäre, dass man alle Compiler-Warnungen anschaltet, was erschütternd wenige Softwarehersteller machen in ihren internen Bills. Ja, das ist wirklich erschreckend. Und was auch viele Leute, die irgendwelche Pipelines in der Cloud benutzen, gar nicht mitkriegen, wie viele Warnungen da eigentlich rausfliegen. Das ist eine der wichtigsten Metriken, die ihr als Entwickler habt, um ordentlichen Code zu produzieren. Also schmeißt Compiler-Warnungen nicht weg. Lest sie und versucht sie wegzumachen. Und zwar nicht mit dem Pragmar. So, die nächste Dimension ist, welchen Anspruch hat der Typ überhaupt? Und das ist mir aufgefallen. Es gab, ich glaube, LibExif2 hieß, dass es so eine Software um Metadaten in digitalen Kamerabildern zu lesen. Da steht so drin, wie GPS-Koordinaten und was das für eine Linse war und so. Und das ist halt mehr oder weniger wohl definiert, wie dieser Standard aussieht. Und es gibt nur Open Source-Library dafür. Und da gab es halt einen Haufen Bugs drin. Und dann hat der Autor von dieser Software irgendwann einfach geschrieben, ja, das dürfte er halt nicht anwenden auf unvertrauenswürdige Dateien. Ja, das heißt, er hat nie den Anspruch gehabt, dass das sicher ist. Aber das stand halt nicht dran. Ja, und die Leute haben seine Software benutzt und angenommen. Ja, der wird schon darauf geachtet haben. Daher glaube ich, das Erste und Beste, was wir machen können, was tatsächlich eine Auswirkung hat ist, wenn wir anfangen, an die Software ranzuschreiben, was eigentlich der Anspruch war. So was glauben wir, was wir erreicht haben, was haben wir überhaupt versucht. Ja, so, das ist, glaube ich, wichtig. Eine andere Sache, die es hier gab, war, dass Leute Features machen, die nach Sicherheit klingen. So, das war eine Sache, die ich bei Microsoft mal erlebt habe. Da gab es ein Feature namens Network Access Protection. Und dann bin ich dahin gegangen für Thread Modeling und wollte wissen, was sind denn eure Security Guarantees. Was sagt ihr denn zu? Und dann meinten die so, ja, gar nichts. Wir sind kein Security Feature. Man ist so, ja, dann ist der Name vielleicht ein bisschen verwirrend. Aber so was passiert halt, ja, weil es einen Disconnect gibt zwischen den Leuten, die das Projekt machen und denen, die den Namen wählen und das Marketing machen. Ja, gut, da gibt es auch nochmal Abstufungen. Also, es gibt halt so explorative Software. Übrigens, fast alle Open Source Software, die ich so veröffentlicht habe, ist auch explorativ. Das ist nicht negativ gemeint. Im Gegenteil, das ist der beste Weg, wie man programmieren lernen kann. Also, ich habe etwas verstanden, wenn ich es einmal implementiert habe. Und das heißt nicht, dass die Implementation dann gut war. Ja, das versuche ich natürlich. Aber es ist wichtig, das zu kommunizieren. Dieser Code war explorativ. Der ist jetzt vielleicht gut genug abgehangen und hat genug irgendwie Real-Life-Tests gemacht und Interprobabilität, dass man dem trauen kann. Aber der Anspruch war explorativ. Oder es gibt halt so dieses Szenario The Guy Left. Das erlebt man gelegentlich bei großen Firmen. Ja, wir haben hier noch ein Stück Code, aber wir wissen gar nicht, wie er es geschrieben hat. Oder wir wissen schon, wer das geschrieben hat. Aber das war einer der Gründer und der hat jetzt keine Zeit mehr für sowas. Oder der Typ, der ist in Ruhestand gegangen oder so, das kommt alles vor. Und das finde ich aber wichtig, dass man das kommuniziert. Weil die Leute, die das benutzen, die wissen das halt nicht. Oder was so üblicherweise das beste Szenario ist. Vom Anspruch her ist, dass der Typ, der das entwickelt, auch der aktuelle Maintainer ist und am besten versucht, das kommerziell zu vermarkten. Weil der hat dann wirklich den Interesse daran, dass es ordentlich wird in den meisten Fällen. Gut, es gibt immer noch mehr Dimensionen. Tut mir leid, dass es so ein komplexes Problem ist. Es gibt auch das Problem, dass der Typ, der das umsetzt, die besten Intentionen hatte und die besten Techniken benutzt. Dies gibt aber, dass die Spektiaumsetz scheiße ist. Zum Beispiel das XML-Spect, die richtig scheiße ist. Da stehen so Sachen drin, wie, dass man eine Entity Expansion machen muss. Und damit kann man einen ganz trivialen Dossangriff machen. Auf im Grunde jeden standardkonformen XML-Paser. Und dann haben die alle angefangen, Konfigurationen nachzurüsten, wo man das ausschalten kann. Aber damit ist man dann eigentlich nicht mehr standardkonformen. Das kommt häufiger vor, dass Spekt's schlecht sind. Also das ist kein Einzelfall, ich will jetzt nicht auf XML zeigen. Andere sind auch nicht gut. Oder JSON-Paser, da gab es jetzt ein paar Versuche, da sind die Leute einfach umgegangen und haben ganz viele Rekusions-Tiefen aufgemacht und plötzlich platzten die Paser alle. Also, oder Window-Messages bei Windows ist ein ganz altes Problem. Das ist halt erfunden worden, bevor es mehr als einen User gab. Oder so Message-Bus allgemein ist so eine Sache, die häufig in so Cloud-Installationen und in großen Firmen gesehen werden kann, dass die Leute sagen, okay, wenn wir das über die Datenbank machen, ist es zu langsam, also bauen wir hier noch ein Message-Bus drumrum. Und dann kann aber jeder, der Zugriff auf den Message-Bus hat, kann halt auch spufen oder kann alle anderen Daten sehen. Da ist die Idee schon schlecht und es ist egal, wie gut ich das umsetze, das wird dadurch nicht besser. Dann gibt es noch so Lock-in-Probleme, die ich weiß nicht, ob die hier wirklich reingehören, aber ich finde das wichtig genug, dass wenn wir schon dabei sind, hier Labels zu vergeben, dass wir das auch erwähnen sollten. Zum Beispiel irgendeine Library, die eigentlich genau das tut, was ich haben will, aber sie läuft nur in der Amazon Cloud. Dann habe ich meine Freiheit, welche Plattform ich verwende, eingeschränkt, wenn ich diese Library reinziehe. Das ist eigentlich auch eine Sache, die man vorher kommunizieren müsste, und zwar klar. Oder bei Cryptocode war lange Zeit ein Problem, dass der Samplerhand optimiert war für die Intel-Architektur. Aber wenn man dann so einen Randgruppen, irgendwie Plattformen wie PowerPC, MIPS oder sogar ARM hatte, dann lief das halt nicht gut. Und das ist jetzt keine harte Abhängigkeit, aber es schränkt den Benutzer ein. Ja, wenn wir schon dabei sind, dann können wir auch gleich den Ressourcen-Footprint reinziehen. Also es gibt ja häufig so Sachen, ja, wir müssen hier sortieren, aber wir rechnen nur mit zehn Elementen, also machen wir halt Bubblesort. Und dann kommt halt jemand und tut mehr Elemente rein und plötzlich platzt das. Das ist eigentlich auch eine Sache, die man kommunizieren sollte. So mit welchen Größenordnungen gehen wir hier eigentlich um. Worauf ist das ausgelegt? Und Achtung, es geht nicht nur um CPU, es geht auch um den Rahmenbedarf. Und es geht auch darum, dass zum Beispiel eine Library ständig auf der Platte rumschreibt und der O-Bandbreite frisst oder versucht aus dem Netz irgendwas nachzuladen. Ja, also das Problem, gut, nehmen wir an, das sind die Dimensionen. Es ist ein bisschen schwierig, da eine Metrik daraus zu bauen, denn eine gute Metrik ist ja immer zwischen 0 und 1 oder sagen wir 0 und 10. Das heißt, man hat eine Vergleichbarkeit. Aber wenn ich sage, wir müssen transitiv die Probleme der Dependencies mit reinziehen, dann haben wir die Scala nicht, weil die kann dann beliebig groß werden, wenn ich mehr Dependencies reinziehe. Ich glaube, von diesem Metrik bzw. Score-Problem müssen wir weg. Und es gibt das Problem, wenn ich eine Metrik habe, dass die Leute dann Gaming betreiben, um die Metrik zu schönern und nicht das Problem zu lösen. Da dachte ich mir, okay, also nennen wir es mal legacy Score, aber Score geht eigentlich nicht. Was kann man denn noch machen? Ja, und vor allem, wofür gilt denn die Metrik dann? Da gibt es eigentlich auch verschiedene Ansätze, was man sagen kann. Man könnte sagen, für die gesamte Software, das ist so eine Art Score aus Rechner. Und das ist, wie sage ich mal, bei einer Versicherung, dass sie halt guckt, wie wahrscheinlich ist es, dass ich hier zahlen muss, so in dem Richtung, also Risikobewertung. Oder ich kann das für Modul machen. Oder ich kann also für Manager, dass der Manager sagt, das Modul ziehen wir nicht rein. Das ist zu riskant. Oder für Entwickler. Oder vielleicht sogar pro Funktion. Und da habe ich mir gedacht, okay, gucken wir doch mal, was es da für Prior Art gibt. Das ist das Modul von 1993. Kompakte Darstellung mehr dimensioneller Daten. Nämlich den Geekode. Wer hier kennt den Geekode? Das ist jetzt für die älteren unter euch. Das sah so aus. Die Formatierung war so ein bisschen als Scherz auf PgP. Die Idee war, dass man sich selbst beschreibt. Also GED heißt zum Beispiel Geek Education Sektor. Und danach, das sind alles irgendwelche Dimensionen. Und dann halt eine Bewertung. Zum Beispiel S heißt, wie groß bin ich? Ja, und das haben die Leute in ihre Signature getan. Und im Usenet verbreitet. Und dann konnte man so grob sich eine Vorstellung machen, was der andere Typ ist, welche Interessen er hat. So, ich finde das nicht gut für Typen. Das war sozusagen der Vorgänger von Facebook, könnte man aus heutiger Sicht machen. Die Leute haben freiwillig alles Mögliche über sich verraten. Aber die Idee ist ja vielleicht nicht schlecht. Und da habe ich mir gedacht, okay, jetzt versuchen wir nochmal die Dimensionen, die ich hier formuliert habe, auf so eine Art Score abzubilden. Und das ist gar nicht so einfach. Da habe ich auch den Vortrag hier erstmal auf Deutsch gemacht, bevor ich das international vortrage, weil ich glaube, da muss noch gefeilt werden. Und ich würde mich über euer Feedback da auch wirklich freuen, also wenn ihr noch Vorschläge habt. Ich zeig jetzt mal den Entwurf, den ich gemacht habe bisher. Und die Idee wäre, dass man es als Autor von der Library in einen Kommentar reinschreibt oben. Und dann hat man so eine Art, ich sage mal, Hundepfeife, der andere Entwickler kann es lesen und versteht, was gemeint ist. Ja, so, und da also gut, das hier ist noch relativ klar, der besitzt eigentlich den Code. Und der schlimmste Fall ist natürlich, man sieht den gar nicht, man hat nicht mal eine Kopie davon, sondern es läuft irgendwo in der Cloud, so, das wäre hier klar, die Dimension, dann, das ist so ein bisschen verwandt, aber es ist nicht genau dasselbe. Ich habe den Code und ich kann ihn ändern oder ich kann ihn nur lesen, so was, ja, oder der ist verloren gegangen. Oder so, das Huawei Modell, wir lassen die Regierung reingucken. Ja, also das ist jetzt so ein bisschen mit einem scharzen Auge natürlich, aber ich finde die Idee eigentlich muss ich sagen, ganz attraktiv. Ich werde das bei meinem eigenen Code mal einbauen. So, hier, das Problem bei so was ist natürlich, dass man gucken muss, dass das obere Ende auch tatsächlich das obere Ende ist und nur von wenigen erreicht werden wird, dass jemand tatsächlich sicher als Zusagen macht, ist sehr selten. Eigentlich fast nie. Dann gibt es so Leute, die machen seit 20 Jahren immer nur dasselbe, zum Beispiel der Typ, der Z-Standard macht, das ist so eine Kompassionslibrerie, die jetzt über Facebook released wurde, der hat vorher LZ4 gemacht und der macht seit Ewigkeiten Kompassionsargorithmen. So, da kann man annehmen, der weiß grob, was er tut. So, und es geht aber runter bis zu, ja, ich bin gar nicht der Typ, der das geschrieben hat, sondern ich muss das hier nur verwalten, ich habe das geerbt, ich bin hier der Azubi. So, das müsste eigentlich dran stehen, finde ich. So, wie sieht es ja mit der Korrektheit aus? Das ist ja auch ein Problem. Und das geht halt von, ich habe ein Beweis und den kannst du nachvollziehen, ich habe ein Beweis und den kannst du nicht nachvollziehen. Oder, na ja, wir versuchen immer alle Bugs zu schließen, wobei schließen und fixen Unterschied ist. Also aufgepasst, immer schön in den Backtracker gucken. Und dann gibt es halt die Leute, die argumentieren, ja, das ist doch gar kein Security-Problem, der krescht doch bloß. Also Leute, die entweder keine Ahnung haben oder böswillig sind. Und das finde ich wichtig, das zu kommunizieren. So, die meisten Leute sind hier bei Stand C-, da draußen. Oder sie haben überhaupt kein Backtracker, das gibt es auch noch vereinzelt. So, dann habe ich hier mir gedacht, okay, vielleicht müssen wir noch sagen, welche Art von Design ist denn in die Entwicklung eingeflossen. Ja, so, das geht halt los, mit ja alle Buzzwords angeklickt, wir haben hier Least Privilege und so weiter. So, dann gibt es einen relativ großen Sprung zu, na ja, wir validieren unsere Inputs, das ist schon mal gut. Ja, aber es geht halt bis runter zu irgendwie so Bullshit, bla, bla, von wegen, ja, wir haben doch ein Antivirus. Und ich finde, das wäre eigentlich schön, wenn man das an der Software hätte. Ja, so eine Art, so eine Art Label. Die Idee, die Idee kam ja eigentlich, als ich mal in Amerika so eine Multivitamin-Tablettenpackung gekauft habe, denn da ist hinten so eine riesige Tabelle drauf mit den Supplement Facts, die Vitamin, so und so viel Prozent, der Recommended Daily Allowance, ja, und da kann man dann sehen, okay, die wollen mich verarschen, weil da steht dann sowas wie Vitamin C, 5000 Prozent, so viel hilft 4. Also, ich meine, da muss man natürlich trotzdem als der, der dieses Label liest, grobes Verständnis haben, was das bedeutet, aber immerhin, ja, ich glaube, das ist ein Weg, den wir mal ausprobieren können. Übrigens, dass hier unten die Author Left und Project Abandon ist häufiger, als man glaubt. Volatility, das versucht so ein bisschen, dieses Agilitätsproblem anzugehen, dass Leute einfach häufiger releasen, als man prüfen kann, ob das jetzt ordentlich ist oder nicht. Aber so richtig eine gute Lösung gibt's eigentlich nicht. Also, was ich so persönlich als am entspanntesten empfinde, ist WIM, ja, WIM bringt so im Grunde täglich Updates raus, aber man merkt nie, dass sich irgendwas verändert hat, weil die Software kommt halt vorher und nachher, alle Sachen, die ich benutzt habe, gehen noch, ja, so, das ist, glaube ich, das optimal eine Ziel, was man da erreichen kann bei Software, dass der Kunde gar nicht merkt, ob gepatched wurde oder nicht, weil das einfach alles weiter funktioniert. Ja, die Speck hat ich ja schon erwähnt, die müssen wir auch irgendwie abbilden, ob die Speck was taugt. Und da gibt's auch ein großes Speck drum, dass die Speck offen, kurz und verständlich ist, ist leider auch selten. Häufig kommt's vor, dass die Speck hinter einer Paywall ist und das ist natürlich dann so gut, als wenn's gar keine Speck gäbe, weil ich als Open Source-Typ etwa 8000 Euro die Impact-Speck runterladen, um zu gucken, ob der Impact-Player ordentlich ist, den ich da gerade runtergeladen habe. So, dann haben wir noch Dependencies. Das müsste man eigentlich transitiv machen, da ist mir jetzt auch nicht klar, wie man das auf den Score abbildet, wenn einer von euch eine Idee hat, wenn ich da gerne für zu haben. Ja, gut, also wie sieht das in der Praxis aus? Ich hab ja immer versucht, ein paar Beispiele zu machen, ungefähr so. Das Problem ist halt, dass die Speckdauer subjektiv sind. Das heißt, für den einen oder anderen ist es vielleicht okay, wenn er den Quellcode nicht hat, solange es noch Wartung gibt. Also Leute, die Windows einsetzen zum Beispiel, die haben halt die, für diese ist es halt okay, wenn es den Quellcode nicht gibt. Aber das heißt eben, dass der Score auch nicht einfach eine Zahl sein kann, sondern muss halt pro Dimensionen so einen Wert haben. Gut, das sieht jetzt aus, wie schwer zu lesen und so hat sich herausgestellt, wenn man das so ein paar Tage macht, dann gewöhnt man sich dran. Und ich glaube, das ist eine ganz gute Idee. Ich hab mir dann noch überlegt, eigentlich brauchst du jetzt noch eine schöne Domäne, hab mir überlegt legacyco.de, wäre super, aber die hat schon Xinc gekauft. Ja, gut. Das war so mein Vorschlag, ich hoffe, ich kriege jetzt eine Menge gute Ideen, was man noch verbessern kann oder vielleicht auch andere Vorschläge, die vorbeinhalten, vielleicht ist ja auch der ganze Ansatz schon falsch, aber ich bin mir sicher, dass wir als Industrie jetzt mal loslegen müssen. Und ich glaube, reaktiv funktioniert das nicht, sondern wir müssen gucken, wie wir im Entwicklungsprozess erstens dafür sorgen, dass die Leute die Entscheidung, welche Produkte sie reinziehen, welche Dependencies sie reinziehen, auf informierter Grundlage treffen können. Und ich hätte gerne, dass das so ein Score gibt, dass es besser werden kann. Ja, weil man sehen kann, an der Stelle bin ich eigentlich noch nicht der Standard, der ich sein möchte. So, ansonsten, wir haben jetzt diese Mikrofone, ich hoffe, die Signalengel sind schon soweit. Ansonsten fragen nämlich auch gern per Mail in den Ging. Vielen Dank für die Aufmerksamkeit. Dann können jetzt alle an die Mikrofone gehen, die noch Fragen haben. Wir haben direkt eine Frage aus dem Internet, bitte. Ja, gibt es Projekte im echten Leben, wo das Problem mit der Komplexität einer Meinung nach richtig gemacht wurde? Und wenn ja, wo findet man die? Sehr selten. Also es gibt, es gab einmal vor ein paar Jahren, gab es so einen Push, wo viele Leute angefangen haben, Software zu veröffentlichen und damit zu bewerben, dass sie besonders klein oder minimal sein soll. Da bin ich auch einer von. Aber es stellt sich halt raus, dass es dann auch andere Projekte gibt, die halt minimal dran schreiben, zum Beispiel gab es neulich einen Announcement von einem SystemD-Clone in Rust. Und ich bin eigentlich ein Fan von Rust und kein Fan von SystemD, deswegen wäre mir dann Ersatz finde ich schon gut. Aber Rust erzeugt halt keine kleinen Bineries, sondern da fallen so große Monster raus. Das heißt, das ist dann zwar minimal im Sinne von wie viel Feature es implementiert, aber das Endprodukt ist halt riesig groß. Da kann jetzt der Typ nichts für der Disk geschrieben hat, noch ein Rust-Problem und da arbeiten die auch dran. Aber minimal ist kein oder Komplexität, gering ist ein subjektive Sache. Ich persönlich habe immer die Software von Dan Bernstein sehr gut gefunden, also Q-Mail und DJB-DNS sind gute Beispiele dafür, wie ein Code aussieht, der Komplexität gut managed und klein hält. Aber es ist ein kleines Feld, also man findet da nicht so viele Beispiele von Software, die gut gemacht und unterkomplex ist. Dann am Mikrofon 10 hatte ich gesehen, kann das sein? Ich habe gerade ein Signal bekommen. Nein, alles klar. Dann machen wir weiter mit Mikrofon 2, bitte. Vielen Dank für die spannenden Ideen. Meine Frage geht so ein bisschen auf, ist das nicht zu freiwillig und zu selbst auferlegt? Ist das nicht zu CDU-mäßig als Lösung? Was hält mich denn davon ab, einfach zu sagen, ich bin M+++, dass ich das vielleicht gar nicht bin? Das ist in der Tat ein Problem und ich bin mir auch nicht sicher wie und ob man das lösen kann. Ich glaube aber, wenn man anfängt und das so ein bisschen losgeht, dass es dann auch einen Druck gibt aus der Community, der die Leute davon abhält, zu lügen. Also meine Erfahrung mit Entwicklern ist, dass die meisten Leute eigentlich gute Menschen sind, die möchten kein Scheiß machen, niemand möchte lügen. Das heißt, wenn du denen eine Gelegenheit gibst, darzustellen, dass das noch nicht fertig ist, dann werden die das auch tun im Allgemeinen außer du hast jemanden, der es wirklich nicht beurteilen kann. Das Risiko kriegst du mit dem Label nicht weg. Aber ich glaube, es ist schon mal ein guter Schritt, wenn wir den Entwicklern, die gerade dabei sind, sich eine Dependency ins Projekt zu ziehen, irgendwas in die Hand geben, woran sie erkennen können, ist das denn jetzt ernst gemeint oder war das hier nur so ein Spielprojekt? Und ich glaube, das ist ein guter Anfang, um es vor ausrollen, um es vor zu gucken. Dann am Mikrofon 6 war zuerst Das geht vielleicht auch jetzt in die selbe Richtung wie der fragende vor mir. Vielleicht könnte man wie so eine Art Rechtsprechungs Instanz installieren. Also ich meine, kein Entwicklerteam aus Indien wird das als Malusse akzeptieren. Wenn da dran steht Entwicklerteam in Indien, hat jetzt das gemacht. Ist das für eine sinnvolle Idee? Wie könnte man das umsetzen? Also es ging jetzt auch nicht um Indien. Das hätte auch Massachusetts sein können, sondern es geht darum, dass das Team halt nicht der ist, der das geschrieben hat, sondern irgendjemand hat es jetzt halt am Bein, weil wir brauchten einen Maintainer. Das ist immer ein Problem und natürlich wird es auch irgendwie Betrüger geben. Aber ich hoffe, dass man die dann erkennt, weil die halt in allen Feldern die Liste jeweils ranklicken. Aber ich weiß es halt auch nicht. Das muss man ausprobieren. Also meine Erfahrung ist, dass an anderer Stelle Communities schon helfen, den Standard hochzuziehen. Wenn man zumindest einfach mal anfängt und sagt, okay, das hier ist wichtig, dann müssen wir drüber reden. Und das ist glaube ich ein Zeichen, wenn es so einen Code gibt, wo es einen Feld gibt, für wie volatil ist denn das. Super volatil ist nicht der höchste Score. Man kann auch Ideen transportieren, transportiert, kriegt. Dass man sagt, okay, vielleicht musst du nochmal drüber nachdenken, wie du dein Projekt aufziehst. Dann bitte am Mikrofon 1. Ja. Ich habe gerade so drüber nachgedacht, ob das nicht so was ähnliches ist, wozu die Lebensmittelindustrie so ein bisschen genötigt werden musste. Also alle Inhaltsstoffe reinzuschreiben, aller Gene reinzuschreiben und so. Deshalb die Frage, sollten wir nicht möglichst bald einzuführen, was ein Rot, Gelb und Grün daraus zu machen. Ja, genau. Das war ja eigentlich die Idee. Aber ich glaube, du kannst das nicht unterbrechen auf den Score, weil einige Teile davon subjektiv sind. Das ist ja bei Lebensmitteln eher nicht so. Sondern vertraust du der Behörde, die Behörde sagt irgendwie so und so viel, was weiß ich, Quecksilber ist Maximum. Und wenn mehr ist, ist es nicht gut. Und dann fängst du nicht an zu verhandeln. Aber wenn jetzt die Software kommt und sagt, okay, wir ziehen ja noch ein Maissequel rein und du weißt es halt nicht besser, sondern auch dem Endbenutzer überlassen. Weil du willst ja auch nicht, du willst ja auch nicht zum Beispiel, sage ich jetzt mal, Okamel benachteiligen, weil dann auch keiner davon gehört hat. Und dass die Leute sagen, ja, da gibt es jetzt keinen Score für, was das halt nicht c, ist es jetzt besser oder nicht. Ja, also du, das muss ja offen genug bleiben. Deswegen glaube ich auch nicht an Schiedsgerichte und irgendwie Organisationen, die Labels vergeben. Weil das ist noch nie gut ausgegangen in meiner Erfahrung. Ich glaube, das muss aus der Community kommen. Und es muss so laufen, dass man das Gefühl hat, ich tue jetzt hier was besseres und ich kann den Erfolg sehen, weil mein Score jetzt hier besser wird. Ich kann jetzt hier plus, plus schreiben. Es ist jetzt die Hoffnung, also ich weiß auch nicht, ob es geht. Dann bitte noch mal Mikrofon 2. Mir hat eine Dimension gefehlt, die ein bisschen in Wartung passt, aber nicht perfekt, weil wir sind ja hier an den Raumvollen Leute, die Sachen selbst in die Hand nehmen. Wie leicht ist es denn mitzumachen? Wie leicht ist es, Backe selbst in abstienen zu fixen? Muss man erst mal einen Vertrag unterschreiben, ob das ein Schritt oder das finde ich, das ist, glaube ich, auch eine wichtige Dimension. Ja, das stimmt. Ich habe das versucht abzubilden über den, ich habe den Code und darf ihn ändern. Aber das Problem ist, dass derjenige, der das Projekt verwaltet, üblicherweise nicht gut beurteilen kann. Sondern er wird immer sagen, ja, ist alles total offen hier. Ja, also das geht, glaube ich, nicht über so ein Score. Aber man kann es natürlich versuchen. Dann bitte Mikrofon 8. Ist fehlen des IPv6 für dich ein Backe oder ein nicht implementiertes Feature? Das ist eine der subjektiven Fragen. Ich finde, für mich persönlich, es ist ein Feat, es ist ein Fehler, wenn kein IPv6 drin ist. Aber es gibt genug Firmen da draußen, die sagen, ja, das haben wir eh nicht. Danke. Dann bitte Mikrofon 7. Die Intention, dass die Community das schon richten wird. Du hattest CVSS als relativ positiv Beispiel dargestellt. Vor fünf Jahren war Heartbleed in OpenSSL, das hat ein CVSS-Backe von 5,0 gehabt und Bruce Schneier kommentiert auf einer Scala von 1 bis 10, ist das Wert 11, CVSS ging gerade bis 10. Also ich sehe nicht, dass das so klappen kann. Und ich finde es gut, dass du aufgezeigt hast, wie komplex das ist. Denn wir haben halt kein Standard, was bedeutet denn zum Beispiel minimal. Oder wenn eine 2-Faktor Authentifizierungsumgehung jede Anwendung mit einer 1-Faktor Authentifizierung automatisch und sicherheitsback? Ja, ist du das völlig recht? Das sind offene Forschungsfragen, wie man das lösen soll. Ich habe da auch keine guten Antworten. Die Heartbleed-Sache hätte man vielleicht klären können, indem man sagt, welche Zusagen machen wir denn. Und wenn die Zusagen gebrochen sind, ist automatisch total schaden. Aber wir haben halt häufig, ich habe das ja auf einer Folie gehabt, wir haben häufig Projekte, die klingen so, und wenn du sie dann fragst, welche Zusagen sie machen, kommt dann halt gar keine. Es ist alles, wer mich einsetzt, ist selber schuld zu. Und da müssen wir irgendwie von weg kommen. Ich glaube, das geht nur, wenn man bei den Leuten so ein bisschen das Empfinden schärft dafür, dass sie gerade die Legacy von morgen schreiben. Die Leute tun immer so, als wenn Legacy vom Himmel fällt, das haben wir geerbt. Nein, du schreibst gerade Legacy, nicht von heute, die Legacy, sondern die von morgen. Dann gab es noch eine Frage aus dem Internet, bitte. Das ist ein Bewertungsschema. Wie soll das bei Projekten funktionieren, bei denen es gar keinen Ohner mehr gibt, der das daranschreiben könnte? Naja, irgendwann, wenn sich das gut genug durchsetzt, ist die Abwesenheit eines Labels an sich schon ein schlechtes Zeichen. Aber das wird natürlich ewig dauernd, bis wir so was sehen. Ja, also es ist nur ein Ansatz. Das kann ich auch nicht lösen, wenn es niemanden gibt, der das Label dran klebt. Kann man vielleicht irgendwie eine Community-Entscheidung auf GitHub machen. Dann bitte am Mikrofon 4. Das sind ja jetzt doch relativ grobe Kategorien. Und gerade bei Enterprise Software, als Entwickler wirst du es jetzt schwer schaffen, irgendwie bei Lizenzen eine Kategorie hochzukommen, ist es dann ein Hoffnung, dass tatsächlich Entwickler dazu angeregt werden, existierende Software zu verbessern? Oder mehr ist in die Richtung, wenn ich jetzt ein neues Software mache, dass ich mir mal Gedanken mache, was will ich überhaupt erreichen, und was wird garantiengebig? Das richtet sich vor allem an Hobbyisten im Moment, für Einschränkungen der Umgebung andere. Da wirst du halt bezahlt von der Firma und der Typ, der dich bezahlt, entscheidet, wofür du deine Zeit ausgibst. Und da hast du gar nicht die Option, jetzt umzulaufen und den alten Code besser zu machen, weil es einen riesigen Backlock gibt, die du noch machen musst. Besonders in Agile-Umfelden wird jede freie Minute noch ausoptimiert. Da stellt sich die Frage gar nicht, ob ich jetzt umlaufe und alten Code besser mache. Daher glaube ich, wir müssen über Open Source kommen. Und da hätte ich früher nicht viel Hoffnung gehabt, aber Open Source hat gewaltigen Einfluss ausgeübt auf Enterprise-Unggebung. Das merkt man vielleicht aus der Open Source Seite noch nicht so. Aber wenn du in Enterprise-Unggebung unterwegs bist, fast alle größeren Projekte sind alle irgendwie Internetbasiert inzwischen. Selbst Appliances hat alle Internet und da ist dann irgendwelche, bestimmt 60, 80 Prozent Open Source, je nachdem, in welcher Branche man da unterwegs ist. Also Open Source hat einen großen Einblick und als Open Source anfängt zu sagen, okay, wir müssen Agile werden, hat Enterprise nachgezogen. Daher glaube ich, wenn wir es schaffen, als Open Source die Standards zu setzen, dass das auch in Enterprise rüber schwappt. Das ist die Hoffnung.