Christian Bahls hat sich die Logdateien von der deutschsprachigen Wikipedia genauer angeschaut und kommt zum Schluss, dass die Wikipedia langsam stagniert.

Liest man den Text ungenau, verfestigt sich schnell die Erkenntnis, dass soviele Artikel gelöscht werden, wie hinzukommen (siehe zweites Bild + Erklärung). Das ist jedoch nicht der Fall.

Christian weist selbst auf das methodische Problem hin: Er schaut sich zwar alle Löschungen an. Dazu gehören neben Löschungen von kompletten Artikeln aus unterschiedlichsten Gründen (Ergebnis von Löschdiskussion, Urheberrechtsverletzungen, …) auch Tastaturtests und “Simon stinkt”-Neuanlagen.

Gleichzeitig betrachtet er im Gegenzug die Neuanlagen, die am Ende des Tages noch nicht gelöscht sind (vermutlich also Artikel in halbwegs akzeptabler Qualität).

Sinnvolle Ergebnisse kann man bei gleichzeitiger Betrachtung von Neuanlagen und Löschungen aber nur erhalten, wenn man

• a) alle Neuanlagen mit allen Löschungen in Bezug setzt oder
• b) sinnvolle Artikelneuanlagen mit regulären Artikellöschungen (keine Schnelllöschungen!) in Bezug setzt.

Ansatz b) ist sehr kompliziert, da nicht automatisch auswertbar. Ansatz a) bietet sich für eine nähere Untersuchung an.

Nur um das methodische Problem zu verdeutlichen: Erhöht sich die Anzahl von “Nicht-Artikel-Neuanlagen” durch Vandalismus an einem Tag um 1.000 Stück, so werden auch diese 1.000 Stück schnellgelöscht, fließen in die Statistik ein und zeigen, dass dann wesentlich mehr gelöscht wird, als den Tag übersteht.

Konkret ist es so, dass die Wikipedia beständig linear wächst. Dies kann man beispielsweise der Seite Wikipedia:Meilensteine entnehmen. Ich habe den Ersteller der Grafik auf der Seite gebeten, dass er sie noch einmal auf den aktuellen Stand bringt (momentan Juni 2009).

Ich freue mich über weitere Untersuchungen zum Thema!

Update: Die Meilensteingrafik wurde aktualisiert. Vielen Dank an Chumwa.

In der aktuellen Debatte, die zum meistkommentierten Beitrag auf diesem Blog geführt hat, wurde häufig in verschiedenen Ausprägungen die Behauptung aufgestellt, dass die deutschsprachige Wikipedia tendenziell exklusionistisch eingestellt ist und die englischsprachige Wikipedia tendenziell inklusionistisch.

Kai Biermann behauptete so in einem Artikel in der Zeit gar “In der englischen Wikipedia haben letztere [die Inklusionisten] die Oberhand, in der deutschen erstere [die Exklusionisten].”

Diese Aussagen werden allerdings nicht belegt. Während es richtig ist, dass es in der englischensprachigen Wikipedia beispielsweise zu jeder Simpsons-Folge einen Artikel gibt, dieses aber zu meinem Bedauern in der deutschsprachigen Wikipedia unerwünscht ist, ging in der Debatte auch der Link zum Lemma Bauchnabelfussel durch die Netzgemeinde (den es zugegebenermaßen auch in der englischsprachigen WP gibt).

Ich persönlich glaube allerdings nicht daran, dass Löschungen in der englischsprachigen WP grundsätzlich anders behandelt werden, als im deutschen Schwesterprojekt. Das kann ich aber genauso wenig belegen… damit ist es also mal wieder Zeit für etwas Wikipedistik!

Ich habe mir die Löschkandidaten von August und September diesen Jahres in beiden Sprachversionen angeschaut und untersucht, wie viele davon “erfolgreich” (je nachdem, wie man es nimmt…) waren. Die dazu verwendete Metrik habe ich vergleichsweise einfach gewählt:

Ich extrahiere die Löschkandidaten-Seiten pro Tag und zähle die Löschanträge im Artikelnamensraum, anschließend schaue ich mir an, ob die Lemmata jetzt noch existieren oder nicht.

Die Ergebnisse haben mich erstaunt. Während ich nicht von grundsätzlichen Unterschieden ausgegangen bin, hätte ich mir schon vorstellen können, dass die englischsprachige Wikipedia zumindest leicht zum Inklusionismus tendiert. Tatsächlich ist das Verhältnis von durchgeführten Löschungen zur Anzahl der Löschkandidaten nahezu gleich.

Von den englischen Löschkandidaten im August 2009 wurden 59,17 % der Artikel gelöscht. Im gleichen Zeitraum traf 61,08 % der deutschen Artikel dasselbe Schicksal. Im September drehte sich das Blatt – während 61,04 % der englischen Artikel ins Gras beißen mussten, wurde “nur” 59,5 % der deutschen Artikel gelöscht.

Fasst man beide untersuchten Monate zusammen, so ergibt sich folgendes Bild:

Im untersuchten Zeitraum wurden also in beiden Sprachversionen 60 % der Löschanträge im Sinne des Antragstellers entschieden. Legt man die Annahme zugrunde, dass Löschanträge in der englischsprachigen WP nicht grundsätzlich anders gestellt werden, als in der deutschsprachigen WP, scheint mir viel dafür zu sprechen, dass es keine großen Unterschiede in diesem Bereich zwischen den beiden Sprachversionen gibt.

Ich habe für den 1.-14. September eine Gegenprobe zum Test der Metrik gemacht, indem ich die Löschkandidaten-Ergebnisse per Hand ausgezählt habe. Aufgrund von verschiedenen Faktoren (z.B. Falschschreibungen, doppelten Inhalten) habe ich im Testzeitraum die tatsächlichen Werte mit der gewählten Metrik leicht überschätzt. Für die Wahl spricht aber, dass sie verständlich, nachvollziehbar und leicht reproduzierbar ist (und vor allem: einfach automatisiert werden kann).

Dennoch muss man natürlich festhalten: Eine rein quantitative Untersuchung kann zwar Anhaltspunkte geben und als Ausgangspunkt für weitere Hypothesen dienen – für eine umfassende Erklärung braucht man allerdings eine qualitative Methode.

So ist in der englischsprachigen Wikipedia die Gesamtzahl der Löschanträge (5.135) im untersuchten Zeitraum in Bezug zum gesamten Artikelkorpus (~3.070.000 Artikel) niedriger, als die Zahl der Anträge (3.256) in der deutschsprachigen Version (~970.000 Artikel).

Ob das nun wiederum daran liegt, dass in der deutschsprachigen Wikipedia schneller zum Mittel eines Löschantrags gegriffen wird – oder ob die Artikel in der deutschsprachigen Wikipedia gar im Schnitt schlechter sind, als die in der englischsprachigen Wikipedia, so dass ein Löschantrag eher gestellt wird…

…das bedarf dann einer weiterführenden Untersuchung. Viel Spaß. :-)

Diese Projekt wurde allerdings für unbestimmte Zeit auf Eis gelegt, da das Interesse an diesem Projekt nicht ausreichte.

Etwas weniger ambitioniert, dafür aber sichere Sache, ist das Wikipedia-Lexikon in einem Band. Das einbändige Print-Nachschlagewerk des Bertelsmann Lexikon Institut ist ab September 2008 zum Preis von 19,95 Euro im Buchhandel erhältlich.

Dafür erhält man 1.000 Seiten mit den 50.000 am häufigsten genutzten Lemmata der Wikipedia, die anhand der Seitenzugriffe der deutschsprachigen Wikipedia bestimmt wurden. Die entsprechenden Daten stammen aus einer Auswertung der Statistiken von Domas Mituzas, die uns bereits den lang ersehnten Artikel-Zähler beschert haben. Etwas genauer wird die Auswahl von Mathias in der Mailingliste der deutschsprachigen Wikipedia erklärt.

Die Planungen an diesem Werk gehen übrigens bis in das Jahr 2004 zurück. Wenige Monate nach Gründung des Wikimedia Deutschland e.V. legte Mathias, dem das Projekt als Freund bedruckter toter Bäume sehr am Herzen liegt, eine entsprechende Seite in der Wikipedia an.

Die Umsetzung dieser Idee ist lange fällig und aus verschiedenen Gründen zu begrüßen.

• Ziel der Wikipedia ist die Verbreitung von Wissen – mit Hilfe einer Print-Version wird eine neue Zielgruppe angesprochen.
• Die Inhalte des Einbänders bestehen jeweils aus den Einleitungsabsätzen der ausgewählten Lemmata, die – sofern nötig – entsprechend überarbeitet wurden. Diese Überarbeitungen fließen in die Wikipedia zurück.
• Die Wikimedia Foundation erhält einen Euro pro verkauftem Exemplar.
• …und auch wenn es einige wenige Personen innerhalb der Wikipedia nicht wahrhaben möchten, ist es ein Image-Gewinn für die Wikipedia.

Im Vergleich zu Brockhaus, die sich aus dem Print-Bereich zurückziehen wollten (sich allerdings inzwischen wieder anders geäußert haben), scheinen die Erfahrungen bei Bertelsmann anders gelagert zu sein.

Verlagsleiterin Dr. Beate Varnhorn meint dazu:

Also, im Gegensatz zu Brockhaus bewerten wir den Markt für Print-Lexika weiterhin positiv. Wir verzeichnen konstant gute Verkaufszahlen, vor allem im Bereich der ein- bis dreibändigen Lexika und können auch nur beobachten, dass das Angebot an diesen Lexika in den letzten Jahren tatsächlich gestiegen ist. Das zeigt, denke ich doch deutlich, dass beide Lexikon-Formen ihre Berechtigung haben. Online-Lexika ebenso wie Offline-Lexika, die klassischen Lexika ebenso wie die user-generierten Lexika.

Wenn ich schon gerade über Quantität blogge…

Die Wikipedia feiert ihren 10-millionsten Artikel.

Wie jeder weiß, der sich auch nur kurz mit den Meilensteinen in der deutschsprachigen Wikipedia beschäftigt hat, ist es aufgrund unterschiedlicher Zählweisen und anderer Probleme nicht wirklich möglich, einen genauen Kandidaten zu identifizieren.

Da das allerdings Aussenseitern schwierig zu erklären ist, einigt man sich schließlich doch immer auf einen “möglichst passenden” Meilenstein-Artikel :-).

Im aktuellen Fall ist dies der Eintrag über Nicholas Hilliard, einen Künstler aus dem 16. Jahrhundert, in der ungarischen Wikipedia.

Jimbo wird dazu wie folgt zitiert:

Jimmy Wales, founder of Wikipedia and the Wikimedia Foundation remarked on the occasion of this milestone, “It’s incredible to think that we’ve grown from one Wikipedia in English to over 250 language Wikipedias. Ten million articles is something we could never have imagined happening so fast when we embarked on Wikipedia in 2001. This is a testament to the incredible dedication of our volunteers around the world.”

Interessanterweise erwähnt und verlinkt die Pressemitteilung der WMF auch den Brockhaus-Wikipedia-Vergleichstest des Sterns.

Insgesamt existiert die Wikipedia in mehr als 250 Sprachen. Eine ausführliche Liste mit Größenübersicht der einzelnen Sprachversionen findet sich auf Meta.

Das Spam-Problem hat in den letzten Monaten bei mir etwas überhand genommen. Der Großteil der Mails, die an eine meiner Domains gesendet werden, landen auf einem gemeinsamen Server und wurden bisher ausschließlich SpamAssassin vorgeworfen.

Der Assassine leistet hervorragende Arbeit. Um Spam (= unerwünschte Mail) von Ham (= erwünschte Mail) zu unterscheiden, führt er eine Reihe von Tests durch:

• Prüfung der Mails auf statistische Spam-Merkmale (z.B. “Absender aus Korea”, “Mail nur in GROSSBUCHSTABEN”, …)
• Abfrage von RBLs und DNSBLs
• Abfrage von Prüfsummen-basierten Filter-Diensten
• Bayes-Filterung

Das Problem: Die Durchführung dieser Tests ist ressourcen-intensiv. Neben einer Menge Hauptspeicher belegt die Spam-Filterung zusätzlich CPU-Arbeitszeit und die Abfragen an netzbasierte Dienste summieren sich auch.

Schaut man sich einmal das Aufkommen von meiner Mail der letzten Monate an…

Mailaufkommen (Größter Teil meiner Mailadressen) 2007/2008

…so sieht man, dass die Situation wohl eher nicht besser wird.

Neben dem Problem der Ressourcen-Auslastung (das z.B. dazu führt, dass die Webseiten auf dem Server – unter anderem Wikipedistik – langsamer ausgeliefert werden) kommt noch dazu, dass die Anzahl der false negatives steigt. Unter “false negative” versteht man Mails, die Spam sind, aber nicht als solcher erkannt werden. Diese Nachrichten verstopfen die Inbox und verursachen Aufwand, da sie von Hand gelöscht werden müssen.

SpamAssassin ist gut – aber kein Spamfilter hat eine Erkennungsrate von 100 Prozent. Daraus folgt: Je mehr Mails durch den Filter gehen, desto mehr Problemfälle treten auf. Dank sinnvoller Einstellung gibt es bei mir jedoch so gut wie keine false positives, also Mails, die erwünschte Mails darstellen, aber als Spam erkannt wurden. Der Preis für eine geringere Wahrscheinlichkeit an “false positives” ist jedoch eine höhere Wahrscheinlichkeit für “false negatives”.

Die einfachste Lösung um die Anzahl an Fehleinordnungen wieder zu senken ist einleuchtend: Die Anzahl der von SpamAssassin zu bearbeitenden Mails muss gesenkt werden. Dies führt dann zusätzlich zu einem weniger ausgelasteten, performanteren System.

Greylisting
Aus diesem Grund habe ich am Karfreitag um 7:00 Uhr auf meinem Mailserver Greylisting aktiviert.

Whitelisting bedeutet, dass Mail nach bestimmten Kriterien immer angenommen wird, während beim Blacklisting die Mail immer abgelehnt wird. Greylisting nutzt hingegen eine Besonderheit des SMTP-Protokolls: Kann eine Mail nicht zugestellt werden, so versucht es der entsprechende Server nach einer gewissen Zeitspanne erneut.

Während diese Funktionalität in jedem vernünftigem Mailsystem umgesetzt ist, so gilt dies nicht für eine Vielzahl von Spam-Software, die wesentlich einfacher gestrickt ist und in der Regel nur einen Zustellversuch macht.

Kontaktiert ein einlieferndes System meinen Mailserver, so gibt es folgende Daten an:

• IP-Adresse des absendenden Mailservers
• E-Mail-Adresse des E-Mail-Senders
• E-Mail-Adresse des E-Mail-Empfängers

Wurde noch nie Mail empfangen, auf die dieses Trippel zutrifft, so wird die Maileinlieferung mit einem temporären Fehler quittiert. Ein herkömmliches Mailsystem versucht dann nach einer kurzen Zeitspanne eine erneute Einlieferung, die dann akzeptiert wird. Bei der Vielzahl von einmaligen Zustellversuchen von Spam führt dies dazu, dass die betreffende Mail gar nicht erst in meinem System landet und demnach auch nicht von SpamAssassin untersucht werden muss.

Systeme, die in der Greylist gelandet sind und danach eine erfolgreiche Zustellung durchführen, werden automatisch in die Whiltelist aufgenommen. So tritt der Nachteil der nicht unmittelbar ankommenden Mail nur beim ersten Kontakt mit einem bisher unbekannten Trippel auf. Trotzdem muss natürlich dieser Nachteil mit einem möglichen Vorteil abgewogen werden.

Wie meine Abwägung ausfällt?
Das muss ich glaube ich nicht extra in Worten beschreiben.

Die folgenden Graphen sprechen für sich:

Angenommene (und verarbeitete) Mails – Massiver Rückgang seit Freitag, 7:00 Uhr

(Durch Greylisting) abgelehnte Mails – Aktivierung ab Freitag, 7:00 Uhr

Aus der Reihe “unnützes Wissen” vermelde ich heute:

Es gibt 2.341 Domains unterhalb der Top-Level-Domain .de, die das Wort “wiki” enthalten.

Wobei man fairer Weise dabei erwähnen muss, dass auch alle “Wikinger”-Kombinationen darunter fallen.

Hingegen gibts es nur 711 Domains mit der Zeichenkombination “pedia”.

Am Vortag der Mitgliederversammlung 2007 des Wikimedia Deutschland e.V. fand ein eintägiges Rahmenprogramm mit interessanten Workshops statt, zu dem auch Nichtmitglieder eingeladen waren.

Um das Programm zeitlich an einem Tag unterbringen zu können, war es nötig, mehrere Vorträge zur gleichen Zeit anzubieten. Was natürlich das Problem aufwarf, sich für bevorzugte Themen entscheiden zu müssen.

Die Programmteile waren jeweils in Zwei-Stunden-Blöcke unterteilt und für mich eigentlich ohne Ausnahme sehr interessant. Im Einzelnen wurden die folgenden Workshops angeboten:

• Juristische Grundlagen für den Wikimedia-Support
• Wikimedia, an international movement
• Wikimedia – Technische Architektur
• Visionen und Reality Checks
• Wikimedia-Projekte zielgerecht vermitteln

Juristische Grundlagen für den Wikimedia-Support
Die “Juristischen Grundlagen für den Wikimedia-Support” wurden von Thorsten Feldmann und Julian Höppner vermittelt. Dieser Vortrag unterschied sich insoweit von den anderen, als dass er sowohl aufgrund des umfangreichen Themengebiets mit zwei Zwei-Stunden-Blöcken doppelt so lang war, als auch nicht für alle zugänglich war. Adressaten waren ausschließlich aktive OTRS‘ler (von denen eine ganze Reihe anwesend war), bzw. Wikipedianer, die ein “berechtigtes Interesse” an dem Thema hatten.

Diese Zugangsbeschränkung war aufgrund der teilweise etwas heiklen Inhalte und vor allem aufgrund der Illustration anhand von konkreten Beispielfällen aus der Vergangenheit nötig. (Der anwesende Reporter vom ZDF Morgenmagazin wäre gerne noch geblieben…)

Von einer Reihe von OTRS’lern habe ich im Nachhinein mitbekommen, dass sie es als sehr hilfreich empfunden haben, “unsere Anwälte” einmal live kennenzulernen. Und auch für die Anwälte von JBB war es interessant, einmal hinter die Kulissen der “Wikimedia Kommunikationszentrale” zu blicken. Beide waren von dem hohen Kenntnisstand des Wikimedia Support Teams gerade in Hinsicht auf das Urheberrecht sichtlich angetan.

Um die Quintessenz des ersten Teils des Workshops zusammenzufassen, lohnt es sich Feldmann zu zitieren:

“Das deutsche Recht ist von vielen Abwägungsprozessen gekennzeichnet.”

Wikimedia, an international movement
Nach dem Mittagessen am Samstag hätte ich mich als OTRS-Vertreter zwar durchaus gerne weiter mit dem Thema beschäftigt, aber die gleichzeitige Diskussion mit Vertretern von verschiedenen internationalen Chapters der Wikimedia Foundation, mochte ich auch nicht verpassen. Organisiert wurde das Ganze von Nina Gerlach und Delphine Ménard, anwesend waren Vertreter von Wikimedia Schweiz, Wikimedia Holland, Wikimedia Polen, Wikimedia Frankreich und natürlich Wikimedia Deutschland.

Abgesehen von dem interessanten Einblick in die Arbeit der anderen Chapter, gab es einige weitere Punkte, die diskutiert wurden: So wurden die Unterschiede zwischen den Chapters (als Graswurzel-Organisationen) und der WMF (auf die das nicht zutrifft) sowie mögliche Konkurrenz zwischen diesen angesprochen. Aber auch die Unterschiede innerhalb der verschiedenen Chapters wurden thematisiert.

Während Wikimedia Deutschland finanziell keine Not leidet, haben andere Chapter ein sehr geringes Spendenaufkommen. Das Thema Fundraising war somit zwangsweise ein wichtiges Thema. Neben den naheliegenden Gründen (schlecht aufzufindende Spendenseiten für lokale Chapters, kurze Existenz von Chapters) brachte Delphine auch ein Beispiel für kulturelle Unterschiede:

Während Deutsche jemandem Geld spenden und dann erwarten, dass dieser die Spende sinnvoll verwendet um etwas damit zu erreichen, so sind die Franzosen erst dann freigiebiger, wenn sie sehen, dass der Geldempfänger bereits etwas geleistet hat.

Kulturelle Unterschiede im Umgang mit Spenden

Leider haben wir uns dann am Thema Fundraising etwas festgebissen, was sehr schade war, da so andere Bereiche zu kurz kamen. Eine zukünftige vergleichbare Veranstaltung sollte über einen deutlich größeren Zeitraum laufen, da so leider viele Fragen offen blieben.

Wikimedia – Technische Architektur
Ebenfalls super interessant war der Vortrag von JeLuF mit dem Titel “Wikimedia – Technische Architektur”. Zuerst hatte ich etwas Sorgen, dass ich nicht allzuviel Neues erfahren würde, da ich Journalisten und Externe bereits seit geraumer Zeit mit einigen Informationen zu dem Thema versorge und aufgrund Eigeninteresses und eines Vortrages in der Vergangenheit eigentlich schon recht umfassend über Daten und Statistiken informiert bin.

Jeluf hat es jedoch prima geschafft aus interner Sicht eine geballte Ladung an interessanten Fakten zu präsentieren. Um einmal ein paar (nicht mehr ganz aktuelle) Daten aus dem Vortrag zu nennen, die interessant sind, wenn man über die Wikipedia spricht:

• Die Wikipedia umfasst inzwischen mehr als 8 Millionen Artikel.
• Insgesamt sind über 110 Millionen Artikelversionen im Zugriff.
• Die Texte belegen (komprimiert gespeichert) 2,4 Terabyte.
• Im Peak verarbeitet die Wikipedia 30.000 Anfragen pro Sekunde.
• Das übertragene Datenvolumen beträgt im Peak 3 GBit/s Datenvolumen.
• Etwa 350 Server sorgen dafür, dass der Betrieb mehr oder weniger problemlos läuft.
• Die Hardware reicht von P4-Rechnern, bis zu Quadcore-Systemen.
• Administriert wird das ganze von 4 Hauptadmins (Brion, Tim, Mark und Rob) und ~3-4 freiwilligen Helfern.

Weitere Themen waren unter anderem die Reverse Squid Proxies, der Nutzeranstieg, die geografische Zuteilung der Nutzer via DNS auf die verschiedenen Rechenzentren (Tampa/Florida, Amsterdam/Niederlande. Seoul/Südkorea) genauere Hintergrundinformationen zum Caching und an welchen Stellen man bereits gerenderte Ausgaben erneut nutzen kann und noch vieles mehr.

Interessant waren besonders auch die Informationen zum memcached-Setup, der die Erklärung lieferte, warum manchmal bei einer Reihe von Nutzern die Anmeldedaten nicht gespeichert werden, sondern immer wieder erneut angefordert werden, während der Großteil der Benutzer keine Probleme wahrnimmt.

Etwas beunruhigend war es mitzubekommen, dass sämtliche Bilder der Wikimedia-Projekte nur auf einem Server liegen (mit 4 Terabyte Plattenspeicher), der somit einen SPOF darstellt. Ein gestartetes Backup lief ~14 Tage.

Ausklang
Abends schloss sich an das Programm noch ein geselliges Grillen im Hof, bzw. später ein geselliges Getränkekonsumieren am Main an, bei dem es genug Gelegenheit für Diskussionen rund um die Wikipedia gab.

Der daraufhin entstandenen Diskussion kann man eine Reihe interessanter Fakten entnehmen: Ausgehend von der Größe des vorletzten SQL-Dumps gilt…

• …die deutsche Ausgabe der Wikipedia wird zu etwa 663.869 einseitig bedruckten DIN A4 Seiten (bei 5000 Zeichen pro Seite).
• …legt man diese Blätter längs aneinander, so ergibt sich ein Papierstreifen von 197 km und 169 m Länge.
• …platzsparenderweise legt man die Blätter quer aneinander und erhält so eine Länge von nur 139 km und 412 m.
• …schreibt man stattdessen alle Buchstaben in nur eine Zeile, so wird diese 6638 km und 688m lang.
• …ausgehend von einem Papiergewicht von 80 g/m², hätte die ausgedruckte Vollversion ein Gesamtgewicht von etwa 3.319 kg.
• …und wenn man von einer Lesegeschwindigkeit von 5 Minuten pro Seite ausgeht, so benötigt man für die komplette Lektüre die im Titel angegebene Dauer von 12 Jahren und 8 Monaten.

Problematisch ist allerdings, dass die Wikipedia sich in der Zwischenzeit massiv weiterentwickelt. Wenn man bedenkt, dass die Wikipedia gerade erst einmal 6,5 Jahre alt ist, scheint mir das (zumindest quantitativ) kein schlechtes Ergebnis zu sein.

(via Wikipedia:Kurier)

Während des Seminars gab ich Olaf online die Zahl der angemeldeten Nutzer der deutschsprachigen Wikipedia, die mehr als 100 Edits haben, mit 1.141 an – was jedoch falsch ist. Diese Zahl gibt die Anzahl der angemeldeten Nutzer der deutschsprachigen Wikipedia an, die im März 2007 mehr als 100 Bearbeitungen durchgeführt haben.

Uns interessierten allerdings die absoluten Zahlen. Ich habe mich daraufhin noch einmal auf die Suche begeben…

Anfang Februar 2006 wies Jimmy Wales daraufhin, dass 0,7 Prozent der Nutzer der englischsprachigen Wikipedia (damals ~615 Personen) für mehr als die Hälfte aller Bearbeitungen verantwortlich seien. Mitte 2005 sah das Verhältnis insbesondere bei der deutschsprachigen Wikipedia nach Angaben von Jimbo noch so aus:

What helps is that in fact 50 percent of all edits on the English-language Wikipedia site are done by a mere 0.7 percent of all users — 524 people — and only two percent have written over 70 percent of all articles, Wales said. On the German-language site, he added, nine percent — 320 people — of all users are responsible for more than 90 percent of edits.

Viel aktuellere Zahlen habe ich auf Anhieb auch nicht gefunden. Aus diesem Grund habe ich DaB. (den Meister des Toolservers, der auch ein Wikipedia-Blog führt) um aktuelle Zahlen gebeten.

Anzahl der angemeldeten Benutzer mit mehr als x Beiträgen

Diese Zahlen sind auf dem Stand von gestern (deutschsprachige Wikipedia) und von vor 115 Tagen (englischsprachige Wikipedia).

Als kleine Anmerkung am Rande: Es gibt acht angemeldete Benutzer in der deutschsprachigen Wikipedia, die mehr als 100.000 Bearbeitungen vorgenommen haben. Da muss ich mich wohl noch etwas anstrengen :-)

Zum Schluss darf der Hinweis nicht fehlen, dass es seit geraumer Zeit grundlegende Kritik an dem vorliegenden Ansatz gibt.

Insgesamt haben wir mit etwa 35 potentiellen Mirror-Betreibern Kontakt aufgenommen und an ~15 davon im Vorfeld über einen Distributionsserver die DVD-Dateien per HTTP, FTP, rsync und BitTorrent verteilt. Manuel Schneider hatte über verschiedene Fachlisten (GUUG, Linux-Verband, WilhelmTux, PingoS…) angefragt und ich die ehemaligen Mirror-Betreiber und einige weitere “typische” Mirror-Anbieter angeschrieben.

Der Zähler der FTP- und HTTP-Downloads, die über das Download-Rotations-Skript von Manuel gestartet wurden, liegt momentan bei 35.000. Dazu muss man sagen, dass vermutlich nicht alle Downloads auf Nutzerseite bis zum Ende durchgeführt wurden.

Zum Gebrauch der DVD benötigt man zwingend die Basisdatei wikipedia.zeno. Dieser Download wurde 10.000 mal gestartet. Von den Mirrors haben wir gehört, dass sie ordentlich ausgelastet sind:

Perfekt. Wir schieben z.Z. 50MBit/s raus mit der DVD.

Also läuft wunderbar mit dem download, seitdem es in den heise news war hab ich durchgänig ca 180-250 Mbit outgoing und 250 user. Wollte euch nur mal einen kurzen überblick geben.

Aufgrund der geringen Anzahl an HTTP-Mirrorn (wir stocken gerade noch um einen weiteren auf: “Der Mirror sind zwei redundante SunServer, mit RAID und einer schnellen Anbindung (2x 2,4GB / 100BaseT) direkt im Rechenzentrum.”) waren diese auch schon mal platt – Michael Diederich, der einen davon anbietet, kann davon ein Liedchen singen.

An der P2P-Front sieht es auch ganz gut aus. Wir hatten vorab dafür gesorgt, dass ~10 komplette Seeds zur Verfügung standen – dies hat den Einfall der Sauger-Horden nach der Veröffentlichung bei Heise und Golem etwas abgefangen. Momentan haben wir 150 Peers (=Rechner die downloaden) und 36 Seeds (=Rechner, die 100% der Dateien anbieten). Diese Nacht waren es über 550 Peers und 45 Seeds. Die .torrent-Datei wurde 3.700 mal downgeloaded.

Alleine der Distributionsserver hat mehr als 100 GB Traffic erzeugt. Michael hat per BT über 200 GB geseeded und noch mal deutlich mehr per HTTP verteilt.

Ein paar schöne Bildchen können dank Leon Weber hier bestaunt werden:
DVD-Verteilung (Tag)
DVD-Verteilung (Stunde)

Und Webzugriffs-Statistiken finden sich hier.

Soviel der Zahlenspielerei, in ein paar Tagen noch mal mehr dazu…