Das Dokument thematisiert das Konzept des 'erfolgreichen Scheiterns' innerhalb von Wikimedias Projekten, insbesondere der Wikipedia, und hebt hervor, wie Fehlversuche zu strategischen Veränderungen führten. Es werden verschiedene Aspekte der Fehlerkultur beleuchtet, die von unzureichenden Ressourcen bis hin zu innovativen Ansätzen wie Crowdsourcing reichen. Der Autor plädiert für die Akzeptanz von Scheitern und die Wichtigkeit, Anforderungen flexibel zu gestalten, um letztlich erfolgreichere Projekte zu realisieren.

1. Erfolgreiches Scheitern –
Scheitern als Erfolg
Ein Lob der #fail-Kultur
Mathias Schindler
Wikimedia Deutschland e.V.
18. November 2011

2. Auf den Schultern von Fail-Riesen
• Jimmy Wales
– Bomis.com (kein Fail)
• Nupedia
– Nachbau einer Enzyklopädieredaktion im Netz
– Bürokratie byzantinischer Größenordnung
– Start im Januar 2000
– Zahl der Artikel Ende 2000: Zwei (2)

3. #fail-induzierter Strategiewechsel
• Start eines Wikis im Januar 2001
– Ziel: Durchlauferhitzer für Nupedia
• Innerhalb von Wochen überholt die Zahl der
Artikel in „Wikipedia“ die der Nupedia
• Larry Sanger als Editor-in-Chief schlägt den
Wikipedianern vor, nun die Inhalte nach
Nupedia zu portieren
• Und alle so: Hä?

4. Wikipedia ist qualitativ hochwertiger #Fail
• Dank des Platzens der dotcom-Blase lief die
finanzielle Unterstützung für einen bezahlten
Editor-in-Chief aus.
– Nach dem Weggang von Larry Sanger legte
Wikipedia dann so richtig los.
• Bis zwei von drei Servern den Geist aufgaben
– Und man überlegte, wo Geld herkommen könnte

5. “downtime is our most
lucrative product”
Jimmy Wales

7. „Business model“
• 2001-2003: Bomis.com
• Um 2003: Spendenaufruf für ein Laptop
• Ende 2003: Servercrash, 30.000 USD Spenden
• Sept 2004: Fundraiser 60.000 USD Spenden
…

8. http://wikimediafoundation.org/wiki/Special:FundraiserStatistics

9. #fail für alle
• Wikinews – da geht noch was
• Wikiversity - dito
• Wikispecies – im Zweifel auch bei
Wikipedianern unbekannt
• Je nach Maßstab gerne auch Wikibooks,
Wikiquote und Wiktionary
• Noch mehr fail:
http://meta.wikimedia.org/wiki/Proposals_for
_new_projects

10. Klassischen Fail verhindern
• Mehr Zeit
• Mehr Geld
• Mehr Personen
• Weniger Anforderungen

11. Mehr Zeit
• Moore‘s Law ist auf Ihrer Seite
• Diverse Probleme lösen sich von alleine
– Im besten Fall eine neue Technologie
– Im schlimmsten Fall Anna-Amalia-Bibliothek
• Und vielleicht macht ja auch jemand anderes
die Arbeit

12. Mehr Geld
• Jeder von uns dürfte einen Plan in der
Schublade haben für den Fall unverhofft
obszön großer Projektförderung

13. Mehr Personal/Personen
• [genauso wie mehr Geld]
• Je nach Szenario: Helfer aus anderen
Projekten, Freiwillige, Zwangsrekrutierte
• Umschichtungen und Streamlining,
Outsourcing, Insourcing, Crowdsourcing
• In Kombination mit mehr Geld:
MechanicalTurk

14. Über die heutigen Zeiten
• Von Wundern, politischen Besonderheiten
und anderen nicht replizierbaren Ereignissen
abgesehen:
– Keine zusätzliche Zeit
– Kein zusätzliches Geld
– Kein zusätzliches Personal
• Und das ist auch verständlich, im Gegensatz zu
HRE ist der Kulturbetrieb generell nicht
staatstragend oder TBTF

15. Was bleibt: Weniger Anforderungen
• Spart Enttäuschungen
• Beliebig skalierbar
• Funktioniert auch und vor allem bei
– Weniger Geld
– Weniger Personen
– Weniger Zeit

16. Weniger Anforderungen
• Versprechen Sie nichts.
• Sagen sie z.B. nicht, wann sie starten, sondern
sagen sie, wann sie einen semi-öffentlichen
Testlauf beginnen werden
• Sagen Sie lieber, was alles in zukünftigen
Ausbaustufen passieren wird
• Noch besser: Sagen sie, was in zukünftigen
Ausbaustufen denkbar sein wird

17. Weniger Anforderungen (II)
• Wenn Sie eigene Pflichten nicht vermeiden
können, vermeiden sie eigene Pflichten durch
eine Beta-Test-Klausel
• Eigene Pflichten werden erträglich, wenn man
sich nicht zu einem Tun, sondern einem Bemühen
verpflichtet
• Eigene Pflichten kann man von der Erfüllung von
Bedingungen Dritter machen und somit
verausstiegsklauseln
• Keine Metriken, denn die sind nachprüfbar!

18. Scheitern verbieten
• Anforderungsmanagement
• Erwartungsmanagement
• Scheitern wird unmöglich gemacht
• Projekte sind dann ab Tag 0 erfolgreich

19. Steile These meines Vortrages
Wenn ein Projekt definitionsgemäß nicht mehr
scheitern kann, dann kann es auch nicht mehr
erfolgreich sein.

20. Mehr Scheitern!
• Einbau von Sollbruchstellen
• Release often, release early -> Fail often, fail early
• Seien Sie kritischer gegenüber Metriken und ihr
Verhältnis zu Fernzielen (Erfolg ist im Zweifel eh
eine kubische Funktion)
• Bauen Sie Metriken für externe Wahrnehmung
• Shakespeare, King Henry VI, Part II, Act IV Scene
II, Line 73