/*** UPDATE: Was natürlich wieder klar war: Die Idee hatte nicht nur ich, sondern auch jemand, der nicht so lange zögert, sondern sich gleich in den Code vertieft. Ich bin gespannt was dabei raus kommt. Danke jedenfalls, Tim Weber für die Gitpedia und viel Glück für das Projekt!
****/
Ich bin gerade in Köln. Der Weg von Berlin ist relativ weit und aufwändig, auch dann, wenn man fliegt. Ich fahre normalerweise Bahn. Ich mag es mit der Bahn zu fahren, denn die Bahnfahrten sind bei mir nie verlorene Zeit, denn selten gelingt es mir so gut Bücher lesen, wie auf Bahnfahrten. Diesmal bin ich aber geflogen. Das ist billiger, sogar mit Bahncard 50. Und es geht schneller. Aber mit lesen ist es eben schlecht. Diese vielen Stationen, die man da durchläuft. Zwei mal Umsteigen bis man überhaupt am Flughafen ist. Dann Checkin, Warten, Boading, Warten, Fliegen, Gepäckband, etc. Da kommt man schlecht zum lesen, bei dieser ganzen Hektik.
Deswegen hab ich ganz viele Podcasts gehört. Das klappt nämlich super. Zwei der Podcasts, der letzte Chaosradio Podcast sowie ein relativ (relativ ist hier auch ziemlich relativ, nicht Tim Pritlove? ;)) neuer Chaosradio Express-Podcast waren ziemlich inspirierend. Und zwar in Sachen Wikipediadiskussion. Klar, der Chaosradiopodcast ging genau darum. Aber der andere, der Express handelte eigentlich von was ganz anderem und war dennoch wegweisend für diese Debatte. Und zwar ging es um verteilte Versionskontrollsysteme. Dort wurde ein neuer Ansatz diskutiert, um dezentral und kollaborativ an Dokumenten (ok, meist Programmquellcode) zu arbeiten. Ich kann diesen Podcast nur jedem empfehlen, auch Nichtprogrammierern. Die Materie ist einigermaßen Komplex und es ist nicht einfach sich in die abstrakten Probleme der Versionskontrolle rein zu arbeiten. Aber wenn man sich darauf einlässt, dann wird man mit den Sprechern zusammen zur Hälfte hin merken, dass der Ansatz den „Git„, eine relativ neue Software in diesem Bereich, verflogt, tatsächlich revolutionär und zukunftsweisend ist. Und zwar über das Versionieren von Programmcode hinaus.
Die Idee ist recht einfach. Anstatt, dass man alle Dateien des Codes zentral verwaltet und die Programmierer sich nur zum editieren die einzelnen Dateien für die Zeit der Bearbeitung „auschecken“, zieht man sich von Anfang an eine ganze Kopie des Kontens, sowie der Bearbeitungshistorie und sonstigen Metadaten direkt lokal auf die Platte. Man macht so zu sagen sofort einen eigenen Fork auf, sobald man anfängt zu programmieren. Wenn man seine Änderung also lokal getan hat, kann man sie direkt auch lokal testen. Und wenn die Instanz, von der man den Code bezogen hat, selber auch von der Änderung überzeugt ist, kann sie sie einfach wieder bei sich einpflegen.
Der Witz ist nun, dass der Alptraum eines jeden offenen Projekts – der Fork – nicht mehr einerseits schwierig zu bewerkstelligen, andererseits schwierig rückgängig zu machen ist, sondern dass das System genau forken und wieder eingliedern erleichtert, ja sogar fördert. Das vereinfacht nicht nur die üblichen Kompatibilitätsprobleme, sondern lindert effektiv die sozialen Spannungen, die in solchen Projekten immer schnell entstehen.
Und hier kommen wir zur Wikipedia, bei der gerade die sozialen Spannungen so schlimme Ausmaße angenommen haben, dass ein weiterer Fork derzeit heiß diskutiert wird.
Aber vorher etwas Küchensoziologie:
Was die Wikipediadiskussion zeigt, ist, dass die Krise in der die Wikipedia steckt, eigentlich keine ideologische ist. Sie ist eine soziale.
Es ist jenes alt bekannte soziale Phänomen, wenn ein Biotop sich zunehmend gegen außen abschießt, ein inneres Eigenleben entwickelt und dann – einem Tümpel gleich – biologisch umkippt. Das riecht dann streng. So wie die Wikipedia derzeit von innen.
Wann immer sich Gruppen definieren, die zum Beispiel ein gemeinsames Hobby oder Ziel haben, gibt es solche und solche Menschen, die sich am Projekt beteiligen. Es gibt die Engagierten und die weniger Engagierten. Die Beweggründe für das Engagement sind so unterschiedlich wie die Intensitäten. Und so kristallisieren sich zunehmend Funktionäre heraus. Das sind Menschen, die sich „verdient“ gemacht haben. Sie proklamieren – mit einem gewissen Recht – eine Meinungsführerschaft. Und mit der Zeit fühlen sie sich nicht nur völlig berechtigt, sondern gar verpflichtet – ja ganz unabdingbar und unersetzlich, diese Führerschaft inne zu haben. Wo soll das denn sonst hinführen. Nur sie kümmern sich ja schließlich. Denn – so die nachvollziehbare Argumentation – es macht ja sonst keiner. Das stimmt. Die anderen Mitglieder werden zunächst beruhigt feststellen, dass die Engagierten die Sache gut im Griff haben. Warum denen also ins Handwerk pfuschen? Neulinge werden entweder gleich abgeschreckt ob der Bissigkeit mit der die Engagierten ihre Regeln (die sich natürlich über die Jahre entwickeln und kumulieren zu einem dicken Wälzer an Do’s und Don’ts, die kein Nutzer sich von Anfang an draufschaffen kann…) verteidigen. Das ganze geriert zu einem nur noch sich selbst bestätigenden Sumpf an Eitelkeiten und Animositäten und wird zunehmend unattraktiv für jeden Außen stehenden. Was dann die Abwärtsspirale nur noch beschleunigt. Es entsteht ein Nachwuchsproblem und selbst Hartgesottene verlieren die Lust an dem Projekt.
Das ist jetzt, wie gesagt, nicht neu. Das erlebt man in jedem Forum, jedem Verein, jeder Partei, sogar Staaten, schlicht: jedem Zusammenschluss von Menschen zu einer festgefügten Gruppe. Mehr oder weniger. Dann gibt es Kämpfe und Revolutionen, Neuanfänge und neue Einigungen. Und dann geht das Spiel von neuem los.
Deswegen kann die Lösung kein Fork sein, wo sich eben diese Probleme, vielleicht abgewandelt, aber doch genau so ähnlich wieder einstellen werden, früher oder später. Mit anderen Worten, es kann nur eine technische Lösung sein.
Mein Vorschlag: Man schafft eine Wikipediasortware, die weit über das Mediawiki hinausgeht aber darauf aufsetzt. Eine extra Software zur Verwaltung der Wikipedia und ihrer noch zu gebärenden Töchtern. Und zwar zur freien Installation für jederman, selbstredend open source. Natürlich hat keine Privatperson die Mittel die Wikipedia ordentlich zu hosten oder gar zu pflegen. Aber das ist auch nicht nötig, denn die Software ist eine dezentrale, verteilte Multipedia.
Bei Neuinstallation auf eigenem Server generiert sie aus einer bestehenden Wikipediasinstallation (die frei angebbar ist, aber zunächst natürlich die klassische Wikipedia sein wird) einen Index, der lokal gespeichert wird und verweist darin nur auf die Inhalte der Mutterpedia, ohne sie aber lokal zu importieren. Sodann kann man hingehen und diesen Stamm an Daten ändern und erweitern. Das ganze funktioniert dann wie ein Versionskontrolsystem. Man checkt einen einzelnen Artikel aus, dieser wird dann auf den eigenen Server kopiert. Sodann kann man ihn umarbeiten. Neue Artikel werden auch auf dem eigenen Server gespeichert. Nur alle anderen Inhalte verweisen erstmal auf die Mutterinstallation (Wenn diese wiederum nur verweist, dann linkt die eigene natürlich bis zum originären Inhalt durch). So kann sich dann ohne große Kosten jeder seinen eigenen Fork machen. Ist das nicht Prima?
Es ist natürlich so, dass dann viele, unendlich viele Forks im Internet entstünden und sich völlig unabhängig entwickeln würden. Naja, nicht ganz. Denn der besprochene Index ist nicht nur offen für eigene Änderungen und eigene Artikel. Man kann jeden Link des Indexes zu einem Artikel auch auf den Artikel einer völlig anderen Installation umbiegen. Da ist man völlig frei.
Nach und nach entstünde so ein riesiges, dezentrales Netzwerk von Wikipedien, die teils eigene Inhalte hosten, und aus einem bunten Strauss an Links zu allen möglichen anderen Wikipedien bestünden. Wahrscheinlich zunächst immer mit einem Hauptstamm auf die alte Wikipedia, aber von Anfang an dezentral und vom Stamm prinzipiell unabhängig.
Da jede Installation die Erweiterungen und Änderungen jeder anderen Installation wiederum importieren kann, entsteht so eine ständige Kollaboration, mit gleichzeitigem, ständigen Wettbewerb der einzelnen Artikel untereinander. Auch die Stammwikipedia soll sich die ihrer Meinung nach besten Änderungen auch jeder zeit Zurückeinverleiben können. Auch die Stammwikipedia würde davon enorm profitieren.
Man könnte einwenden, dass das ja eine für den Benutzer unzumutbare Vielfalt an unautorisierten und völlig beliebigen Wikipedien sei, die jeden überfordere. Da aber doch eigentlich jede Wikipedia für sich eine relative Vollständigkeit geniest (sie bleibt ja hauptsächlich ein Import), und weil die Stammwikipedia gerade für Neulinge zunächst die Anlaufstelle bleiben wird, glaube ich, dass man sich erst durch zunehmenden Gebrauch nach und nach die Wikipediainstallation suchen wird, die am besten den eigen Ansprüchen gerecht wird, bzw. eine eigene startet.
Mit anderen Worten: Macht nicht einen Fork. Macht viele! Unendlich viele! Macht es jedem DAU möglich seinen eigenen Fork zu starten. Dann hat niemand mehr die Macht über das Wissen, bzw. jeder hat es. Und nur der Nutzer entscheidet, wo er was lesen möchte.