Mattlog

Begonnen mit Mogis hat sich bei Felix von Leitner Felix von Leitner, Kristian Köhntopp und dem Rest der “Blogosphäre” in den letzten Wochen eine Diskussion um die Relevanzkriterien der Wikipedia und ihre Zukunft entwickelt. Von dort ging es munter weiter zur virtuellen Kleingärtnermentalität und zurück zur Frage wie die zur Verfügung stehenden Werkzeuge einen Nutzer beeinflussen: “Wenn Dein ein einziges Werkzeug ein Hammer ist, sieht jedes Problem wie ein Nagel aus”. Der Hammer der Admins ist der Löschlink. Die Nägel der Wikipedia sind neue, rohe Einträge – zu kurz, zu irrelevant oder zu lang und zu unbelegt.

Seit ein paar Jahren schon habe ich das Gefühl, dass sich die Wikipedia nicht wirklich voranbewegt. Die Zahl der Einträge steigt (aber das Wachstum flacht ab) und die jährlichen Spendenaufrufe bitten um größere Summen. Das ist quantitatives Wachstum. Ein qualitatives Wachstum kann ich nicht erkennen. Fefe verdeutlicht qualitative Probleme aus der Sicht des Contributors, ich sehe die Probleme bereits in der Sicht des Lesers: Während Felix ganz zurecht mit der sehr gewöhnungsbedürftigen Editierung von Einträgen argumentiert (ganz besonders bei Tabellen) und einen WYSIWYM-Editor fordert, frage ich, wo denn die Erleichterung für den User ist?

Die Wikipedia benötigt Semantik

Die Wikipedia nutzt — wie der Name schon sagt — das Konzept des Wikis zur Speicherung von Information. In Wikis sind Links unheimlich schnell erstellt und dadurch entsteht schnell ein dichtes Netz von Hyperlinks, an denen man sich entlanghangeln kann. Eine simple Syntax hilt dabei, Abschnitte, Überschriften und schnell erfassbar zu formatieren. Ich benutzte Wikis sehr gerne, um Projekte zu koordinieren. Denn da ist die gute Verlinkung zwischen Seiten die beste Möglichkeit, Dokumente immer bei der Hand zu haben oder neue hinzufügen zu können, ohne dass diese untergehen.

Ich kenne aber auch die Probleme des Wiki-Prinzips. Eines der größten ist die fehlende Semantik, bzw. die Einbindung semantischer Abschnitte. Ein Beispiel gefällig: Ich editiere vor allem an Artikeln zu Automobilthemen und Ländereinträgen. In beiden Fällen hat man mit Tabellen zu kämpfen, die erstens schrecklich zu formatieren sind und zweitens nie weder über die verschiedenen Wikipedias konsistent noch irgendwie vergleichbar ist. So hat Deutschland (Stand 18. November 2009) mit 81.882.342 Einwohnern Platz 15. der Bevölkerungsreichsten Staaten ein, während es in der englischsprachigen Wikipedia mit 82.060.000 Einwohnern noch Platz 14 hat.

Hin und wieder kommt ein Bot vorbei und vergleicht Daten oder fordert zu Korrekturen auf, aber das kann keine echte Semantik ersetzen. Denn diese erforderte die externe Einbindung tabellarisch vorgehaltener Daten. Das muss kein Widerspruch zum Wikipedia-Prinzip sein: Die Möglichkeit, eine semantische Tabelle an jeder Stelle einzubinden, solte in Fefes WYSIWYM-Vorschlag unterkommen können. Zudem bin ich sicher, dass sich mit etwa 20 vordefinierten Tabellentypen 95% der Anwendungsfälle und 99,9% der Aufrufe von Seiten, die Tabellen enthalten, abdecken können. Für den Longtail oder die Frage, nach allen Automobilen der Klasse unter vier Metern, die jemals mit Peugeots TUD-Motor ausgeliefert wurden, sind dann die objektrelationalen Profis zuständig…

Die Wikipedia benötigt Interaktion

Anja und ich haben vor gut einem Jahr für Johann Graf Lambsdorff die interaktive Weltkarte auf Basis von Google Maps für den CPI 2008 erstellt. In der Wikipedia findet sich eine derartige Fülle an Daten, dass es ein leichtes sein sollte, automatisch ähnliche Karten zu generieren. Das Kartenmaterial sollte bei OSM zu beschaffen sein, die resultierenden Möglichkeiten sind einfach zu schön: Wie wäre es mit Karten, bei denen man per Schieberegler die Entwicklung eines Indexes über die Jahre nachvollziehen kann oder die Korrelation verschiedener Indices (bspw. Korruption und BIP) verdeutlicht bekommt? Die traurige Wirklichkeit sind statische Karten, die von sehr engagierten Usern in Handarbeit als SVG oder PNG erzeugt werden können. Was für eine Verschwendung an menschlicher Rechenleistung!

Wir könnten das Thema viel weiter spinnen. Mit einer Ode an die Freude, deren Thema im Notensatz gleich als Midi abspielbar ist. Vielleicht nicht der beste Weg, mit Klassik umzugehen, aber einer, der Einblicke gewährt und Themen erkennen und zuordnen lässt. Um nichts anderes sollte es bei einer Enzyklopädie gehen.

Die Wikipedia benötigt Zwonull

Heutzutage werden Definitionen aus der Wikipedia gerne von Journalisten in den typischen 1000-Zeichen-Kurzerklärungen geglättet und verwurstet. Rankings aus der Wikipedia in Tabellen übernommen und das ganze mal korrekt mit Quellenangaben versehen als Kasten mit Hintergrundinformationen dargestellt, mal als Abschnitt in den Text verwurstet. Doch selbst beim klar abgetrennten Kasten ist nicht immer klar, wie dieser aus Sicht der Wikipedia-Lizensierung zu bewerten ist: Handelt es sich beim gesamten Artikel um ein abgeleitetes Werk oder ist der Kasten als eigenständiges Werk zu betrachten, da der Artikel auch ohne erklärendem Kasten seinen Charakter behält und der Kasten unverändert bei vielen Artikeln platziert werden kann?

Ausgerechnet die Encyclopaedia Britannica hat hierfür eine elegante Lösung gefunden: Widgets, die in jede beliebige Webseite eingebunden werden können und Inhalte aus der Enzyklopädie bereitstellen (bei der Britannica leider nicht toll umgesetzt). Bei dieser Form der Einbindung bleibt der fremde Inhalt klar als solcher erkennbar und wird nicht Teil des anderen Werkes. Technisch ließe sich ein besserer Nachbau der Britannica-Widgets recht einfach realisieren lassen, die nötige JavaScript-Programmierung ist eher trivial. Jedoch müsste sichergestellt werden, dass die als Widgets ausgelieferten Kurzzusammenfassungen in Sachen Qualität und Lesbarkeit über dem gewöhnlichen Niveau der Wikipedia liegen. Kurzum: Den einleitenden Abschnitt zu verwenden, wird in vielen Fällen funktionieren, aber nicht in allen.

Ein wichtiger Effekt wäre die Wahrnehmung, dass nicht mehr der Leser zur Wikipedia muss, sondern die Wikipedia zum Leser kommt. Durch die Einbindung externer Inhalte schüfe man jedoch auch eine gewisse Verantwortung des Einbindenden für die eingebundenen Inhalte. Und da es für eine Onlineredaktion, die einen Artikel mit Wikipedia-Hintergründen aufpeppen möchte, einfacher ist, die Zusammenfassung im Wikipedia-Widget sprachlich zu glätten, als in eigenen Worten komplett neu zu formulieren, dürften schnell beide Seiten profitieren.

Die Wikipedia benötigt Professionalisierung

Die Wikipedia wird gerne mit Open-Source-Projekten verglichen. Doch in der Struktur der Mitarbeit gibt es signifikante Unterschiede. Am Linux-Kernel kann jeder herumschrauben, der sich die Quellen gezogen hat, doch landen seine Patches nicht automatisch im Produktionskernel. In der Wikipedia war es bis vor kurzem so, dass anonyme Änderungen fast überall möglich waren. Mittlerweile ist das Problem etwas entschärft, doch befriedigend ist diese Lösung nicht. Kristian Köhntopp schlägt als Lösungsansatz ein besseres Mentorenmodell vor, das die Meritokratie-Vorstellungen einbezieht.

Mich wundert auch, dass sich Wikimedia Deutschland e.V. kaum in die inhaltliche Entwicklung der Wikipedia einmischt. Zwar sponsort der Verein löbliche Projekte zur Gewinnung älterer Autoren (sinnvoll, denn ein Ingenieur auf Altersteilzeit hat viel freie Zeit, sein erworbenes Wissen in die Wikipedia einzupflegen) oder zur Förderung der Medienkompetenz von Schülern, doch direkte Unterstützung kann ich kaum erkennen: Domain-/Internetkosten sowie Bücher/Fachzeitschriften, die an Autoren gehen, um Artikel inhaltlich zu überarbeiten, machen nicht einmal 5% der Ausgaben aus^[1].

Was spräche also dagegen, hauptberuflich ein oder zwei Editoren zu beschäftigen, die gemeinsam mit der Community Artikel überarbeiten, für die sich prinzipiell viele Nutzer interessieren, deren Qualität jedoch hinter den gewünschten Standards zurückbleibt? Warum nicht einen “Wikimedia Summer of Editing” analog zum “Google Summer of Code” ausrufen, bei dem Studenten oder Doktoranden während der vorlesungsfreien Zeit bestimmte Artikelbereiche nach inhaltlichen und sprachlichen Kriterien überarbeiten? Ich könnte mir gut Dreierteams aus zwei “Fachidioten” und einem Journalistik- oder Sprachwissenschaftsstudenten vorstellen. Profitieren würden alle:

• Zuallerst stiege die Qualität, die Lesbarkeit und die Übersichtlichkeit vieler Artikel

• Eine Überarbeitung durch (angehende) Wissenschaftler und die dadurch zwangsweise bessere Belegung mit Quellen würde die Zitierfähigkeit der Wikipedia verbessern

• Eine bessere Zitierfähigkeit würde wiederum mehr Wissenschaftler dazu bewegen, die Wikipedia nicht nur als Quelle (vor allem für Begriffsdefinitionen und periphäre Informationen) wahrzunehmen, sondern auch dazu motivieren, Artikel aus dem eigenen Fachgebiet zu verbessern

• Schließlich könnte die Bearbeitung von Wikipedia-Artikeln auch der Reputation der (angehenden) Wissenschaftler dienen: Ein gut strukturierter, recherchierter und belegter Wikipedia-Artikel mit 30.000 bis 50.000 Zeichen stellt einen ähnlichen Aufwand wie eine Seminararbeit dar, entsprechend sollte er anerkannt werden

Mir erschließt sich nicht ganz, ob und in welchem Umfang Wikimedia e.V. ein Sponsoring in diese Richtung betreiben möchte. Ein Schreibwettbewerb ist ein kleiner Anfang. Bounties für Überarbeitungen wären besser und ein groß angelegter “Wikimedia Summer of Editing” absolut wünschenswert. Ich möchte diesen Vorschlag nicht als Vorstoß in Richtung der Kommerzialisierung der Wikipedia verstanden wissen. Aber derzeit ist das Editieren der Wikipedia für fast alle Beitragenden eine Luxusbeschäftigung, die in der Freizeit stattfinden muss. Gerade angehende Akademiker haben zwischen Studium und Nebenjobs wenig Zeit, sich diesen Luxus leisten zu können. Deshalb setzt das Modell des “Summer of Code/Editing” an der richtigen Stelle an: Haltet Studenten von fachfremden Billigjobs fern, steigert ihre Motivation und tragt gleichzeitig dazu bei, die Inhalte der Wikipedia analog zum Funktionsumfang von OSS-Software effizient zu verbessern!

Die Wikipedia benötigt einen Fork

Viele der angesprochenen Punkte wären bereits für sich alleine kaum in der bisherigen Wikipedia durchzusetzen. Ein großes Problem ist, dass der Mensch ein Gewohnheitstier ist, der ungern mit alten “User Experiences” bricht. Von vielen derzeit aktiven Admins und Moderatoren wäre schon ob eines Wikipedien-übergreifenden semantischen Tabellenmodells Protest zu erwarten. Würde ein “Summer of Editing” von den vielen Alten Hasen, die an Myriaden von Artikeln Detailverbesserungen vornehmen, als Invasion der Bezahlschreiber wahrgenommen werden? Wie wären die Reaktionen auf eine stärkere Verquickung von Wikimedia e.V. und Wikipedia-Community beispielsweise bei der Auswahl von Themen und Autoren für einen “Summer of Editing”?

Ich glaube nicht, dass derart massive Änderungen in einem großen, gewachsenen Projekt wie der Wikipedia durchzuführen wären – die Analogie vom Schlachtschiff und dem Schnellboot greift ganz gut. Ein kleines Team, das mit einem Fork durchstartet hätte bessere Karten, etwas zu bewirken. Um verwaiste Inhalte sollte man sich keine allzu großen Sorgen machen. Bei Artikeln, die im Fork nur geringe Änderungen erfahren, reicht es, die “Original-Wikipedia” zu beobachten und Änderungen ggf. nach Kontrolle zu übernehmen. Artikel, die sich von der Original-Wikipedia emanzipiert haben und aktive Betreuung oder massive semantische Überarbeitung erfahren oder erfahren haben, werden aus diesem Abgleich ausgenommen.

Oft wird argumentiert, dass aus dem Forking eines Projektes eine ineffiziente Ausnutzung von Ressourcen folgt. Das ist nicht der Fall:

• Bei den meisten Projekten ist der Aufwand, neue Ideen in einem Fork umzusetzen geringer als diese im “Mutterprojekt” auszuprobieren

• Stellt sich ein Konzept als unbrauchbar heraus, ist es einfacher, den Fork sterben zu lassen, als bei Änderungen im Mutterprojekt einen aufwendigen Rückbau durchuführen

• Konnten neue Konzepte erfolgreich im Fork ausprobiert werden, spricht nichts gegen eine Aufnahme dieser Ideen ins Mutterprojekte — Open Source ist durchlässig

Erinnert sich hier noch jemand an EGCS? Die “Enhanced GNU Compiler Suite” war ein Fork des GNU-C-Compilers durch den Linux-Distributor RedHat, der die Maßgabe hatte, die starke Fokussierung auf C/C++ und die x86-Architektur aufzubrechen. Der ursprünglich von einem kleinen Team entwickelte Fork fand bald bei den Entwicklern so starken Zuspruch, dass die Verantwortlichen des GCC-Projektes zwei Jahre nach dem Fork beschlossen, die damalige 2.7-Serie des GCC einzustellen und EGCS 1.1 als GCC 2.95 weiterzuentwickeln.

Natürlich gelten für ein Projekt wie die Wikipedia, das aus Code und Content besteht, andere Regeln: schon die Zusammensetzung der Mitarbeiter ist deutlich breiter. Dennoch bin ich sicher, dass der Fork genügend frustrierte Interessenten anlocken wird, um mit ihm erfolgreich neue Konzepte auszuprobieren: Vom Programmierer, der die Semantik verbessern möchte, über den Webexperten, der Widgets mit guter Usability entwickelt, hin zum Wissenschaftler, dessen Anliegen es ist, Artikel zu “seinem” Themengebiet besser zu strukturieren, sehe ich viel zu befreiendes Potential. Loslösen sollten wir uns auch von dem Irrtum, dass nur eine reine Community-Wikipedia neutral ist: Lieber ein großes Medienhaus stellt einen Redakteur ab, der die oben angesprochenen “1000-Zeichen-Kurzzusammenfassungen” für Widgets glättet und macht dies transparent, als ein anderes verschwendet die Energie darauf um hinter einem Proxy versteckt “als IP” die Unternehmensgeschichte zu schönen.

^[1] Im Rechenschaftsbericht weist Wikimedia e.V. ca. 60.000 Euro Abschreibungen aus, etwas weniger als 20% der Bilanzsumme. Dabei scheint es sich größtenteils um Server zu handeln, die als Reverse Proxy oder lokaler Mirror die Server der Wikimedia Foundation in Florida entlasten.

Nachtrag, Links

• 20. November 2009: Streitgespräch zwischen Felix von Leiter und Pavel Richter im SZ-Blog “Schaltzentrale”

Dieser Eintrag wurde am Thursday, November 19th, 2009 um 1:48 pm geschrieben und ist unter Gedanken abgelegt. Antworten können Sie mit dem RSS 2.0-Feed verfolgen. F�r diesen Artikel sind weder Trackbacks noch Kommentare erlaubt.