Mattlog

Gedanken und Hintergedanken. Außerdem: Computer, Autos, die dicke Katze von nebenan, Biber in der Innenstadt, meine Freundin und Ich.

Zum Panopticon...

Verantwortlich für den Inhalt dieser Seite ist Mattias Schlenker, Inhaber Mattias Schlenker IT-Consulting Mattias Schlenker work Dietrich-Bonhoeffer-Str. 3, 40667 Meerbusch. Germany work Fon +49 2132 9952906. http://www.mattiasschlenker.de

Diese Seite läuft unter Wordpress 2.x.y. News und Kommentare können als RSS-2.0-Feed abonniert werden.

Warum ein Wikipedia-Fork gut wäre

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

28 Antworten auf “Warum ein Wikipedia-Fork gut wäre”

  1. Twitter Trackbacks for Mattlog » Blog Archive » Warum ein Wikipedia-Fork gut wäre [mattiasschlenker.de] on Topsy.com (November 19th, 2009 um 2:32 pm)

    [...] Mattlog » Blog Archive » Warum ein Wikipedia-Fork gut wäre blog.mattiasschlenker.de/2009/11/19/warum-ein-wikipedia-fork-gut-ware – view page – cached Begonnen mit Mogis hat sich bei [DEL: Felix von Leitner :D EL] Felix von Leitner, Kristian Köhntopp und dem Rest der “Blogosphäre” in den letzten Wochen eine Diskussion um die Relevanzkriterien… Read moreBegonnen mit Mogis hat sich bei [DEL: Felix von Leitner :D EL] 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. Read less [...]

  2. Torsten (November 20th, 2009 um 5:55 pm)

    Fast alles, was Du dort oben forderst, wird in der Wikipedia schon gemacht.

    Wikimedia hat OpenStreetMaps kürzlich sogar einen eigenen Server spendiert, der die Anfragen der Wikipedia auffangen kann. Das Projekt Nachwachsende Rohstoffe wurde durch einen haupamtlichen Editor gefördert. “Forks” gibt es haufenweise – neue Funktionen werden meist in kleineren Sprachausgaben oder Schwesterprojekten ausprobiert. Und einige Professoren haben bereits seit mehreren Jahren Seminare, in denen Wikipedia-Artikeln erstellt werden.

    Hättest Du die Schreibarbeit in ein wenig Recherche gesteckt, dann wäre sie besser investiert gewesen.

  3. ms (November 20th, 2009 um 6:12 pm)

    @Torsten: Wieso mit einem derart aggressiven Tonfall?

    Dass Wikimedia OSM mit einem Server unterstützt, ist ja schön und gut, aber was ist mit einer Integration von OSM-Inhalten als Backend für eine Kartenerzeugung in Wikipedia? Warum nicht die Mediawiki-Software komplett überdenken? Der Git-Fork ist schonmal ein toller Ansatz, aber an der Oberfläche, sprich User-Experience, Wiki-Syntax und andere Formen der Objekteinbindung (Tabellen, Bilder, Videos, Karten…) sind auch viele Verbesserungen nötig. Das reine Ausprobieren in einer lokalen Version ist kein Fork, an dem man sich radikal – also an die Wurzel gehend – austoben kann.

    Ich sehe einen Fork als etwas sehr fruchtbares, das die Möglichkeit gibt, neue Konzepte auszuprobieren, ohne mit dem alten zu brechen. Ein Fork bedeutet nicht, dem “Mutterprojekt” etwas wegzunehmen, sondern Konzepte auszuprobieren, die “im Original” nicht möglich sind. Dabei geht es nicht nur um technische Konzepte, sondern auch die soziale Komponente, die besonders festgefahren ist.

  4. Torsten (November 20th, 2009 um 6:29 pm)

    Sorry, wenn das falsch rüberkam – aggressiv war mein Beitrag nicht gemeint.

    Die Arbeit an der OSM-Integration läuft grade, eine Entwicklung für eine so komplexe Angelegenheit wie Wikipedia dauert eben eine Weile. Objekteinbindungen und simple Logiken wurden schon vor lange eingeführt – wenn Du Dich da engagieren willst, ich glaube, die Wikipedianer können an der Stelle tatkräftige Unterstützung brauchen. Und zum Git-Fork – frag mal Scytale wer ihm mehr tatkräftig geholfen hat: Fefe-Leser oder Wikipedianer :-)

    Natürlich gibt es auch massenweise Forks, die sich fundamental von Wikipedia unterscheiden – zum Beispiel Wikinfo oder Citizendium. Das Problem ist: die anderen Projekte fördern seltenst etwas zu Tage, was sich dann auch im Produktivbetrieb von Wikipedia brauchen lässt.

    Wie gesagt: am grünen Tisch lässt sich immer erzählen, wie etwas besser laufen könnte. Wenn Du an der Umsetzung arbeiten willst, hast Du bei Wikipedia massig Gelegenheiten.