Fehler sind Silber, darüber reden ist Gold
Lasst uns übers Fehler machen sprechen! Wir finden: Eine konstruktive Fehlerkultur – wir nennen es Failosophy – bildet die Grundlage einer jeden Innovation. Gleichzeitig ist diese noch lange nicht überall verbreitet – und auch wir lernen ständig dazu.
Aber was meinen wir eigentlich, wenn wir von Failosophy reden? Weniger neudeutsch könnten wir auch von einer “offenen Kultur der Fehlertoleranz” sprechen. Gemeint ist damit, dass Fehler a) vollkommen in Ordnung sind, b) uns dabei helfen, besser zu werden und c) viel häufiger Gesprächsthema sein sollten, denn nur so können wir als Gesellschaft aus ihnen lernen.
Dabei sind Fehler noch nicht einmal per se etwas schlechtes. Was im ersten Moment wie ein Fehlgriff aussieht, kann dazu führen, dass ein Projekt eine ungeahnte und letztlich positive Wendung nimmt – man denke an die Entstehungsgeschichte von Penicilin. Und auch wenn das nicht der Fall ist, so können Fehler zu anderen Erkenntnissen führen, die uns auf dem Weg begleiten. Beispiele für Fehler von Programmierer*innen – und was sie daraus gelernt haben – finden sich online übrigens zuhauf.
Warum Fehler helfen können
Im Prototype Fund ist uns das besonders wichtig. Denn der Fund ist kein Inkubatorprogramm, bei dem es darum geht, Produkte so schnell wie möglich zur Marktreife zu bringen und zu monetarisieren. Es geht stattdessen darum, technische Machbarkeitsstudien durchzuführen und Entwickler*innen Freiräume zu geben, damit diese ihr volles Potenzial entdecken und ausschöpfen können. Experimente, Fehler, Neuanfänge und Lernkurven gehören hier dazu.
Natürlich haben alle Geförderten ein erklärtes Ziel: Nach sechs Monaten wollen sie einen Softwareprototypen entwickelt haben. Das heißt aber nicht, dass dieser perfekt funktionieren muss, skaliert und alles beinhaltet, das die Entwickler*innen in ihrer Projektskizze eingeplant haben. Mut zur Lücke sehen wir beispielsweise gern, wenn er dazu beiträgt, den Fokus zu behalten.
Weil der Weg zum Prototypen steinig sein kann und oft viele – aber eben nicht alle – Wege zum Ziel führen können, ist uns ein guter Umgang mit Fehlern, Veränderungen und (ungeplanten) Neuanfängen ein Anliegen. Dazu gehört, Fehler anzunehmen, transparent und ehrlich mit ihnen umzugehen – und der Mut, Andere nach Hilfe zu fragen.
Der Prototype Fund – und Open Source als Ökosystem – lebt von der Gemeinschaft. Open-Source-Entwicklung ist historisch eng mit einem bottom-up Organisationsprinzip verbunden, das Partizipation über “Meritokratie” regelt. Der typische Weg in ein Softwareprojekt sieht demnach überspitzt dargestellt vor, sich das notwendige Wissen, insbesondere für kritische Projektteile, selbst anzueignen und Expertise für verschiedene technische Herausforderungen mitzubringen, um die Software selbstverantwortlich erweitern und warten zu können. Zur Sicherheit gibt es dabei natürlich den Code-Review der Öffentlichkeit, denn der Code ist frei zugänglich. Aber – auch wenn voneinander lernen erwünscht ist – wer “zu viele” Fehler macht, hat (oft) einen schweren Stand im Projekt. Dass Meritokratie als Prinzip seine Schwächen hat, weil es übersieht, dass Leistung eng an persönliche, zeitliche und finanzielle Ressourcen gebunden sind, ist mittlerweile ebenfalls bekannt. Zum Glück setzt sich langsam aber sicher die Erkenntnis durch, dass es spezielle Supportstrukturen braucht, damit es nicht nur bessere Technologien für Alle gibt, sondern auch alle die Möglichkeit haben, gute Coder*innen zu werden.
Wie Failosophy im Prototype Fund gelebt wird
Speziell in der Projektförderung legen wir also Wert darauf, den Geförderten nicht nur finanzielle Starthilfe zu geben, sondern sie auch ideell voranzubringen. Deswegen beinhaltet die Förderung neben Coachings auch den Austausch und die Beratung mit den anderen und ehemaligen Geförderten sowie dem Team des Prototype Fund. Hier warten ein großer Erfahrungsschatz und vielfältige Perspektiven, die dabei helfen können, Ideen zu schärfen, neue Ansätze zu finden und konkrete Problemstellungen zu lösen. In dieser Community auf Augenhöhe können auch unausgegorene Ideen und Ansätze unvoreingenommen besprochen werden, denn dass wir alle Fehler machen, ist klar. Auf diese Weise sollen die Geförderten die Hilfestellung erhalten, die sie brauchen und wollen auf dem Weg zum Prototypen – und sich gleichzeitig ausprobieren.
Dieser Ansatz bedeutet in der deutschen Förderlandschaft ein Alleinstellungsmerkmal für den Prototype Fund. Die Förderprojekte dürfen Fehler machen und in der Förderphase umplanen und wenn am Ende nicht exakt der Prototyp herauskommt, der anfänglich geplant war, ist das nichts Negatives. Außerdem ermöglicht das Programm Entwickler*innen, die nicht an Institutionen angebunden sind, niedrigschwellig Zugang zur Anschubfinanzierung. In der Regel ist der Weg zur Förderung mit zahlreichen Anträgen und Nachweisen übersät. Der Prototype Fund macht es den Entwickler*innen einfacher. Es braucht dringend mehr fehlertolerante und leichtgewichtige Förderinstrumente, will man dem Ruf des “Innovationslands” gerecht werden.
Wir wollen mit unserem Loblied auf Failosophy übrigens nicht gesagt haben, dass die “fertige” Software letztlich ein buggy Experiment sein soll (an fehlerhafter Software haben auch wir keine Freude!). Ganz im Gegenteil: Auch hier sind deswegen die Ursachen genau zu betrachten: Beim Heartbleed-Bug beispielsweise führte jahrelange finanzielle und personelle Unterversorgung zu einer umfassenden Sicherheitslücke, die mehr als zwei Jahre lang unentdeckt blieb. Erstrebenswert ist deswegen eine langfristige Förderung, die über Innovationsförderung hinausgeht und Entwickler*innen auch nach dem Launch unterstützt, damit diese die Software weiterentwickeln und instandhalten können. Innovationsförderung – wie die im Rahmen des Prototype Funds – bringt Neues hervor, das sonst nicht (oder in ungleich längerer Zeit) entstanden wäre. Doch es ist die Anschlussförderung, die eine nachhaltige Technologieentwicklung möglich macht.
Was lernen wir daraus? Steht zu euren Fehlern, lernt im besten Fall aus ihnen und holt euch Feedback und Hilfe, wo immer ihr sie braucht und wollt! Denn: Sobald ihr einen Fehler einmal gemacht habt, macht ihr ihn beim nächsten – vielleicht noch größeren – Projekt nicht noch einmal!