Wessen Morgen ist der Morgen?

Die Reformation zum Anfassen: GNU/Linux und Open Source - Teil 6

Hobbyisten und Firmen tragen gleichermaßen dazu bei, dass der gemeinsam genutzte Pool an freiem Wissen und freier Software stetig wächst. Doch die Vielzahl unterschiedlicher Lösungen führt immer häufiger zu Verwirrung und Chaos beim Endnutzer. Die oft stark unterschiedliche Qualität freier Lösungen und ihre verteilte Speicherung machen außerdem neue Ansätze bei der Bewertung und Auswahl von Software erforderlich. Aber auch durch neue Geschäftsmodelle, einfache Zahlungsverfahren und bessere Verteilung von nicht-technischen Arbeitsvorgängen könnten Normalnutzer stärker in die Entwicklung einbezogen werden. Die entsprechende Technologie kann langfristig dramatische Auswirkungen auf Politik, Wirtschaft und Gesellschaft haben.

Beinahe jeder Satz, der mit "Linux ist .." anfängt, ist falsch. Selbst der Betriebssystem-Kern existiert in zahlreichen unterschiedlichen Varianten, angepasst an verschiedene Anwendungsfälle und Hardware-Konstellationen. Dank Open Source kann nahezu jeder Teil eines GNU/Linux-Systems individualisiert und verbessert werden. Dazu muss man kein Hacker sein: Um z.B. einige Dialog-Texte und Tastenbelegungen in einem Programm zu ändern, genügt ein grobes Verständnis der Struktur, das Kompilieren ist dank der GNU-Tools im Normalfall mit drei bis vier Befehlen erledigt.

Die Linux-Distributionen wie SuSE und Red Hat unterscheiden sich dann auch in zahlreichen Einzelheiten. Unterschiedliche Installations-Programme, Hardware-Erkennung, Software-Auswahl, Update-Systeme und Paket-Manager, Verzeichnis-Strukturen, Dateinamen, Wartungs-Skripte, Konfigurations-Dateien und Front-Ends usw. dienen den Distributoren als Hervorhebungs-Merkmale oder sind Nebeneffekt der separaten Entwicklung. Manchmal entsteht dabei fast der Eindruck, es handle sich um unterschiedliche Betriebssysteme. Interoperabilität kann dabei nicht immer gewahrt bleiben. Besonders bei der Installation von Programmen trifft man immer häufiger auf Pakete für die unterschiedlichen Distributionen. Ein RPM-Paket für Red Hat, ein RPM für SuSE, ein RPM für Mandrake, ein DEB für Debian, ein TGZ für Slackware ..

Klar, dass ein Paket oft nicht in einer Spezial-Version für die gewünschte Distribution vorhanden ist. Das ist meist kein Problem, doch in Einzelfällen kommt es zu Konflikten: Eine Programmbibliothek liegt im "falschen" Verzeichnis und wird nicht gefunden, oder eine abhängige Bibliothek ist nicht installiert und muss mühsam per Suchmaschine lokalisiert werden (ganz ähnlich wie bei fehlenden DLLs unter Windows, nur häufiger). Oft muss man dann in der Kommandozeile herumhangeln und das Programm von Hand kompilieren.

Diese Probleme wären vermeidbar, wenn sich die Distributoren über den Paket-Standard und die Verzeichnisstruktur einig würden. Vom Standard abweichende Verzeichnisstrukturen und Dateinamen wären mittels einer ebenfalls standardisierten Datenbank, die entsprechende Zuordnungen zwischen dem Standard und den Abweichungen vornimmt, immer noch möglich. Statt dessen gibt es gerade hier einen regelrechten Kleinkrieg zwischen den Distributoren.

Die Linux Standard Base

Für Standardisierung ist eigentlich die Linux Standard Base zuständig. Sie wurde 1998 vor allem als Resultat der Aktivitäten des Open-Source-Evangelisten und Ex-Debian-Hackers Bruce Perens gegründet (Original-Ankündigung). Schon kurz nach ihrer Gründung kam es zum Eklat: Perens wollte zuviel standardisieren, bis hin zum Desktop. Sogar ein Referenzsystem wollte er bauen. Es bildete sich eine ungewöhnliche Allianz zwischen den Hackern des nichtkommerziellen Debian-Projekts und dem extrem kommerziell ausgerichteten Distributor Red Hat. Red Hat begrüßte die Bemühungen um einen Standard zwar grundsätzlich, aber CEO Bob Young wurde zitiert, mit der Zeit standardisiere sich Open Source Software eigentlich von ganz alleine.

Red Hat und Debian einigten sich dann in einem "Akt der Meuterei", wie Freshmeat berichtete, auf einen separaten Standard, der nur wenige wesentliche Systemeigenschaften vereinheitlichen sollte. Perens verließ schließlich die LSB, die daraufhin mehrfach neu besetzt wurde und nun von George Kraft dem Vierten, Linux-Abgesandter von IBM, geleitet wird. Mittlerweile wurde immerhin Version 1.0 der LSB-Spezifikation verabschiedet, die so kritische Komponenten wie Binär-Dateien, Standard-Bibliotheken und Verzeichnishierarchie zumindest zu Teilen standardisiert.

Wenig überraschend finden sich Red Hat und Debian nun erneut auf unterschiedlichen Seiten wieder. Teil der LSB ist nämlich eine Empfehlung, das von Red Hat favorisierte Format RPM für die Software-Paketverwaltung zu verwenden. Von Debian-Nutzern wurde diese Empfehlung bislang weitgehend ignoriert. "Das .deb-Format ist dem .rpm-Format weit überlegen", erklärt Debian-Mitentwickler Ian Jackson, der die ersten Versionen des Debian-Paketmanagers schrieb. "Es gibt, soweit ich weiß, keinerlei Pläne, umzusteigen." Die Installation von Software unter Debian sei wesentlich reibungsloser als unter anderen Linux-Distributionen, weil Abhängigkeiten (Paket A benötigt Pakete X, Y und Z, die wiederum ..) besser aufgelöst werden.

Darin sind sich Debian-Nutzer und RPM-User häufig sogar einig, doch das RPM-Format war zum Zeitpunkt der Standardisierung weiter verbreitet. Die naheliegende Lösung, einen gemeinsamen Nachfolger zu definieren, kommt den Debian-Hackern jedoch nicht in den Sinn: "Soweit es mich betrifft, sehe ich keinen Grund, warum Debian irgendein anderes Format verwenden sollte. Wir werden unser Format natürlich weiter verbessern", so Jackson. Bei der LSB gibt es immerhin eine Task-Gruppe, die genau einen solchen Standard definieren soll. Die letzten zehn Nachrichten auf deren Mailing-Liste wurden in den Monaten Februar bis Juli 2001 gepostet. "Wir haben die richtige Zahl von Leuten auf das Problem angesetzt, sie haben nur im Moment andere Prioritäten", so George Kraft IV.

Anfang 2002 will man damit beginnen, Linux-Hersteller gemäß der LSB zu zertifizieren. Das könnte ein Grund für zögerliche Hersteller wie Red Hat sein, dem Standard zu folgen. Die SuSE AG hat sich dagegen von Anfang an an dem Standardisierungs-Vorhaben beteiligt und setzt die Spezifikationen als einer von wenigen Distributoren vollständig um.

Juckreizmangel

Es fällt auf, dass an dem so bedeutenden LSB-Projekt nur wenige Freiwillige beteiligt sind. Das bestätigt zu einem gewissen Grad das "Scratch an Itch" Erklärungsmodell, das oft für Open-Source-Software angeführt wird: Es geht den Beteiligten in erster Linie darum, eigene Probleme zu lösen, den eigenen Juckreiz zu stillen. Große Vorhaben wie Standardisierung sind zwar elementar, machen aber aus individueller Sicht nur sehr langfristig Sinn. Das ist um so problematischer, als gerade die kommerziellen Distributoren in der Frage der Standardisierung natürlich nicht unparteiisch sind.

Wie in Teil 5 beschrieben, bietet Red Hat mit seinem abonnierbaren "Red Hat Network" einen kostenpflichtigen Update-Service an, was jedoch im Widerspruch zu einem vollautomatischen, kostenlosen und einfachen Paket-Aktualisierungs-System wie bei Debian steht. Auch Desktop-Firma Ximian möchte mit "Red Carpet" einen kommerziellen Software-Abo-Service etablieren.

Weiterhin gehen natürlich mit Standardisierung Unterscheidungsmerkmale verloren, die unter Umständen einer Distribution einen Vorteil vor einer anderen verschaffen. Solche Überlegungen sind alles andere als langfristig: Wenn Desktop-Umsteiger Linux als schwer bedienbar und wartbar erleben, werden sie sich schnell in die ganz bestimmt einheitliche Fensterwelt aus Redmond zurückwünschen.

Es gibt keinen Mechanismus in der Free-Software-Welt, der sicherstellt, dass das, was sich alle wünschen, auch implementiert wird. Als Nichtentwickler kann man häufig lediglich auf die Open-Source-Dynamik hoffen und eventuell ein paar Emails schreiben. Die LSB beabsichtigt auch keinerlei Linux-User-Umfragen: Dies sei wie eine Umfrage über Mayonnaise oder Senf zum Mittagessen und würde nicht funktionieren, meint George Kraft. Wer Einfluss nehmen wolle, müsse sich einfach an den Diskussionen auf den Mailing-Listen beteiligen.

Interessengruppen wie IBM und Red Hat können in solchen isolierten Grüppchen starken Einfluss ausüben. Würde dagegen eine große Zahl von Nutzern über öffentliche Abstimmungssysteme in den Standardisierungs-Prozess eingebunden, wären mehrere typische Medien-Effekte die Folge: Von besonders vielen Nutzern als wichtig empfundene Entwicklungen würden auch von einer größeren Zahl von Entwicklern in Angriff genommen (ähnlich dem Effekt, den ein News-Posting bei Slashdot oft auf ein Open-Source-Projekt hat), und wer diese Ziele sabotieren wollte, würde in den Open-Source-Medien besondere Kritik erfahren.

Veraltete Werkzeuge

George Krafts Verweis auf die Projekt-Mailing-Listen der LSB offenbart ein typisches Problem der Open-Source-Community: Die Bewegung verwendet in vielen Bereichen noch die gleichen Werkzeuge wie zur Linux-Anfangszeit vor zehn Jahren. Zur Projektkoordination sind das vor allem Newsgroups und Mailing-Listen, bei denen alle Probleme durch Diskussion ausgeräumt werden sollen, und die schon wegen des zur Beteiligung notwendigen Zeitaufwands nur einer Minderheit wirklich zugänglich sind.

Mailing-Listen sind Listen von Email-Adressen, die eine gemeinsame Empfängeradresse teilen. Wer sich auf einer solchen Liste einträgt, kann an diese Empfängeradresse, also an alle anderen Listenmitglieder, Mails verschicken. Manchmal sind solche Listen moderiert, meist sind sie es nicht. Newsgroups sind offene Diskussionsforen, vgl. Die Reformation zum Anfassen: GNU/Linux und Open Source. Newsgroup-Inhalte kann man z.B. bei groups.google.com durchsuchen, Mailing-Listen haben eigene Archive, wobei sich viele davon bei Yahoo! befinden (groups.yahoo.com). Solche Archive sind zwar nützlich, aber zu unstrukturiert und unselektiert, um die Wiederholung von Diskussionen zu vermeiden. Da das einzige Instrument zur Konfliktlösung die Diskussion ist, können einzelne diskussionsunfähige Gruppenteilnehmer Projekte bewusst oder unbewusst sabotieren.

Mail und News sind in ihrer Flexibilität begrenzt. Die Protokolle sind Jahre und im Kern Jahrzehnte alt und können wegen der großen Zahl der beteiligten Computer kaum verändert werden. Beide Anwendungen funktionieren nach Peer-to-Peer-Prinzipien: Es gibt keinen zentralen Internet-Mailserver oder Newsserver, vielmehr sorgen die Server untereinander für die Verteilung der Inhalte. Bei Mails sind das meistens die Server des Senders und Empfängers (technische Einführung), das Usenet dagegen ist ein gigantisches Servernetz, das sich ständig selbst synchronisiert. Wird das technische Verhalten eines Mailservers oder Newsservers wesentlich verändert, sind Kompatibilitätsprobleme unvermeidbar.

Dabei sind beide Systeme fehlerbehaftet. Emails sind standardmäßig weder fälschungssicher noch vor Fremdeinblicken geschützt - vielmehr kann man sie mit Postkarten vergleichen, die für jeden einsehbar das Netz durchkreuzen. Es ist trivial möglich, mit gefälschten Emails z.B. in einem Unternehmen Chaos zu stiften. Zwar stehen dann in den Kopfzeilen verräterische Daten über die tatsächliche Herkunft, doch selbst Techniker verwenden bevorzugt Email-Clients, die diese Informationen verstecken und statt dessen nur die Kurzversion zeigen (Absender, Empfänger, Betreff, Datum). Mit entsprechendem Wissen lassen sich digitale Signaturen verwenden, um fälschungssichere Mails zu verschicken, doch dazu sind die wenigsten Nutzer in der Lage.

Ist eine Email plausibel, wird ihre Echtheit von den wenigsten Usern hinterfragt. Insofern muss man Email-Würmern wie Sircam und Nimda fast dankbar sein, denn sie gaben sich als reale Personen aus und sensibilisierten die unglücklichen Empfänger so zumindest ein wenig für die Authentizitäts-Problematik. Die Probleme werden dadurch freilich nicht gelöst.

Im Usenet sieht die Situation ähnlich aus, auch Newsgroup-Postings sind nicht fälschungssicher. Wie die meisten Email-Nutzer werden viele Diskussionsforen von Spammern geplagt, was sicherlich ein wesentlicher Grund für die sinkende Bedeutung des Usenet ist. Mail und News teilen ein weiteres, verwandtes Problem: Wie soll man aus einer Newsgroup oder Mailing-Liste mit Hunderten Postings am Tag die guten herausfiltern? Die Probleme sind seit Jahren die gleichen, doch die Lösungen, die alle in der Theorie schon existieren, sind noch nicht umgesetzt.

Reputation, Trust und Ratings

Einige Newsreader (typischerweise solche aus der Unix-Welt) erlauben es, Punktzahlen (Scores) für bestimmte Themen oder Autoren in Newsgroups festzulegen. So könnte man z.B. alle Posts, in denen es um Linux-Textverarbeitungen geht, in einer entsprechenden Newsgroup hervorheben, oder alle Nachrichten des KDE-Entwicklerteams. Diese Scorefiles funktionieren auf rein individueller Basis: Man beginnt gewissermaßen bei Null und muss ständig darauf achten, sein Scorefile auf dem neuesten Stand zu halten. Die darin festgelegten Daten finden ausschließlich im Usenet Verwendung - begegnet einem der gleiche Autor, den man in der Newsgroup bereits mit einem negativen Score versehen hat, um seine Beiträge zu filtern, in einem Diskussionsforum im Web erneut, ist das bereits digitalisierte Wissen nutzlos.

Einige Usenet-Nutzer posten ihre Scorefiles regelmäßig öffentlich oder geben sie privat weiter, so dass zumindest eine gewisse Kollaboration in der Verwertung der Daten entsteht. Prinzipiell ist "Scoring" jedoch ein recht einsamer und mühseliger Prozess, der nicht dabei hilft, neue Erkenntnisse zu gewinnen, sondern darauf abzielt, gemachte Erfahrungen zu speichern und anzuwenden.

Das nach dem Client-Server-Prinzip arbeitende Web bringt derzeit die meisten technischen und sozialen Innovationen hervor. Die flexible Seiten- und Interface-Beschreibungssprache HTML und ihre Erweiterungen ermöglichen es, eine Vielzahl von Anwendungen zu realisieren, ohne die Clients dazu zu aktualisieren. Da die Server nicht voneinander abhängig sind, besteht auch hier kein Zwang zu Interoperabilität. Auf diese Weise sind in den letzten Jahren viele unterschiedliche Lösungen entstanden, die das Kommunizieren im Internet vereinfachen und verbessern könnten.

Kollaborative Moderations-Mechanismen dienen wie Scorefiles dazu, Beiträge oder Personen mit Bewertungen zu versehen, werden aber von mehreren Personen gleichzeitig verwendet, um bessere Ergebnisse zu erzielen und Wissen zu teilen. Nur einige illustrative Beispiele:

1. Slashdot: Moderation von Kommentaren in Diskussionsforen. Slashdot.org erhält einen Großteil seiner Nachrichten von den Lesern der Site. Eine kleine Zahl von Redakteuren wählt aus den Tausenden eingesandten Nachrichten im Geheimen eine winzige Untermenge aus und setzt die ausgewählten Nachrichten auf die Homepage. An jede Nachricht ist ein Diskussionsforum angehängt. Hier können nun Moderatoren einzelne Kommentare mit einem positiven oder einem negativen Wert sowie einer Beschreibung versehen. Moderator werden kann prinzipiell jeder, der die Site regelmäßig besucht und nicht zu häufig von anderen heruntermoderiert wurde. Moderator ist man nicht auf Lebenszeit, sondern nur für ein paar Tage, mit einer begrenzten Zahl an zu vergebenden Punkten. So soll sichergestellt werden, dass die stark fluktuierende Minderheit die Mehrheit akkurat repräsentiert.
2. Kuro5hin: Moderation von Stories. Bei der News/Diskussions-Site Kuro5hin.org wird ein System verwendet, das allen Nutzern die Abstimmung über eingesandte Stories und über abgegebene Kommentare erlaubt. Hier wurde das System von Slashdot stärker dem Modell einer direkten Demokratie angepasst und auf nahezu alle Bereiche der Website erweitert.
3. Advogato: Bewertung einzelner Nutzer. Advogato.org möchte ein Forum für Technik- Begeisterte schaffen, die im Elfenbeinturm die Auswirkungen ihrer Schöpfungen auf die Gesellschaft diskutieren. Viele Beteiligte an bedeutenden Open-Source-Projekten führen auf der elitären Site Tagebücher. Um anerkannt zu werden (und die Erlaubnis zum Posten von Stories zu bekommen) muss man von anderen Nutzern mit Bewertungen versehen werden: Lehrling, Reisender, Meister usw. Mit Hilfe eines komplexen Modells wird aus allen Bewertungen ein aggregierter Wert erzeugt, wobei verhindert wird, dass sich Nutzer durch gegenseitiges Hochmoderieren im System heraufschlingeln können.

Mit Bewertungen von Inhalten und Personen lassen sich verschiedene Dinge anstellen. Sie können eingesetzt werden, um die Zugriffsrechte eines Nutzers in einem System zu reglementieren. Sie können aber auch der Hervorhebung bestimmter Inhalte dienen: Welche Kommentare haben eine besonders hohe Bewertung? Slashdot und Kuro5hin erlauben eine entsprechende Sortierung. Teilweise wird versucht, auf manuelle Bewertungen möglichst zu verzichten. Amazon.com ist hierfür ein gutes Beispiel. Der Online-Alleshändler verwendet Verkaufsdaten, um seinen Kunden nach einem Kauf automatische Tipps zu geben ("Kunden, die dieses Buch gekauft haben, haben auch noch diese drei Bücher und einen Regenschirm gekauft") und ihre Homepage maßzuschneidern.

Aber sowohl Amazon.com als auch Konkurrent eBay kommen nicht umhin, an vielen Stellen ihre Nutzer um Bewertungsinformationen zu bitten: Bei Amazon geben Leser ihre Meinung über bestimmte Bücher, Kassetten, Videos usw. zum Besten (Meinungen, die wiederum bewertet werden können, was ihre Positionierung in der Anzeige beeinflusst), eBay gestattet nach einer erfolgreich abgewickelten Transaktion Käufer und Verkäufer die gegenseitige Beurteilung, um so durch Selbstregulation Betrug und Fehlverhalten vorzubeugen.

All diese Systeme funktionieren erstaunlich gut. Auch wenn nur eine Minderheit der Benutzer Zeit für die Bewertungs-Ebene einer Website hat, ergibt sich daraus bei gutbesuchten Sites eine durchaus relevante und nützliche Datenbasis, wie wohl jeder weiß, der nur wegen der Leserrezensionen gelegentlich bei Amazon & Co. vorbeischaut. Offene Diskussions-Sites wie Slashdot müssen mit einer absolut stets wachsenden Zahl von Trollen, Flamern, Lamern, Perversen und Skript-Kiddies kämpfen - dennoch wird man schnell fündig, wenn man bei Slashdot Kommentare unterhalb eines bestimmten numerischen Schwellenwerts ignoriert.

Aus den genannten Beispielen kristallisieren sich drei Grundtechniken für die Bewertung von Inhalten und Personen heraus: Ratings sind einfache Bewertungen, teilweise nur numerisch, teilweise zusätzlich mit einem Label wie "interessant" oder "witzig" versehen, für Kommentare und Inhalte aller Art. Vertrauen, in solchen Systemen meist Trust genannt, ist eine numerische Bewertung für eine bestimmte Person. Die Reputation, die diese Person genießt, ist wiederum das angesammelte Vertrauen durch andere, wobei es sich nicht um einen einfachen Durchschnittswert handelt.

Leider existieren noch kaum sinnvolle Kombinationen dieser Modelle. Eine Abfrage der Form "Zeige mir Kommentare, die von Personen, denen ich vertraue, positiv bewertet wurden" ist z.B. bei Advogato nicht möglich, weil es keine Ratings gibt, sondern nur Trust und Reputationen. Slashdot wiederum kennt nur Ratings, wobei erste Ansätze in Richtung Trust bereits existieren. Weiterhin sind wie im Usenet die Rating- und Reputations-Daten in ihrer Verwertbarkeit begrenzt, und zwar nicht von Medium zu Medium, sondern von Website zu Website. Trolle müssen in jedem Forum von Neuem identifiziert und bewertet werden.

Einige Websites haben sich um eine stärkere Kombination von Trust und Ratings bemüht, z.B. der Bewertungs-Service epinions.com. Meist scheitern solche Systeme schlicht daran, dass sie nie die notwendige kritische Masse erreichen. Slashdot und Kuro5hin haben Nutzer ja zunächst nicht dadurch angezogen, dass bereits Nutzer dort waren, vielmehr haben in beiden Fällen engagierte Redakteure regelmäßig interessante Beiträge veröffentlicht. So bildete sich ein Pool von Nutzern, und die Moderationssysteme wurden erst aufgrund ihrer Notwendigkeit erfunden oder spielten erst jetzt wirklich eine Rolle.

Bedeutung von Interfaces

Ein vielfach unterschätztes Problem ist das Design der verwendeten Benutzerschnittstellen. Was im Hirn des Users ablauft, wenn er eine Site besucht, ist wesentlich von ihrem Design abhängig. Ob ein interessanter Text gelesen wird, kann allein davon abhängen, ob dazu eine komplizierte Navigation verwendet werden muss. Natürlich nehmen Nutzer selbst stümperhaft in Flash animierte Website-Maskottchen, bildschirmfüllende vibrierende Werbebanner und absturzintensive JavaScripts auf sich, wenn sie eine bestimmte Information unbedingt haben wollen oder müssen. Im Wettbewerb verlieren solche Sites aber, wie der Erfolg der Suchmaschine Google zeigt. Sie gilt als Musterbeispiel von Usability - keine unnötigen Informationen, dafür hilfreiche Tricks, wie ein kleines JavaScript, das den Cursor in der Suchmaske positioniert.1

Bei Aktivitäten, die nur geringe unmittelbare Belohnung versprechen, wozu die gesamte Bewertungs-Ebene gehört, ist die Einfachheit der UI essentiell. Mehr als ein oder zwei Klicks ist kaum jemand bereit hinzunehmen, um einen Nutzer oder Inhalt mit einer schnellen numerischen Bewertung zu versehen. Um so katastrophaler ist das Design mancher Open-Source-Sites: Bei Freshmeat, einer Software-News-Site, muss man sich durch mehrere Navigationsebenen hangeln, um Bewertungen vornehmen zu können, wozu auch noch eine Anmeldung erforderlich ist (eine kaum zu vermeidende Notwendigkeit, für die sich dem Nutzer aber nicht genügend Gründe offenbaren).

Ähnlich sieht die Situation beim Mozilla-Bugtracking-System Bugzilla aus, wo Nutzer über besonders schwerwiegende Fehler im Open-Source-Browser abstimmen sollen. Hier kommt hinzu, dass das Interface mit Informationen überladen ist, die nur für Mozilla-Coder nützlich sind, und einzig ein winziger Link auf die Abstimmungsmöglichkeit hinweist. Nur in wenigen Ausnahmefällen, wo extern ein Link auf eine bestimmte Bug-Abstimmung gesetzt wurde, kommt das System wirklich zum Einsatz. Etwas besser implementiert ist das Abstimmungssystem bei apps.kde.com, einer Website für News über KDE-Anwendungen. Von Trust fehlt bei all diesen Systemen aber jede Spur.

Die Grenzen des Web werden dabei nicht ausgereizt. Slashdot & Co. kommen dem schon näher. Bei diesen Sites zeigt sich, dass vor allem Latenzprobleme die Nützlichkeit der Ratings einschränken. Bei Kuro5hin befindet sich unterhalb jedes Kommentars eine Auswahlbox mit den zulässigen Bewertungen, daneben ist ein Button "Rate All". Nach Drücken dieses Knopfes werden alle Bewertungen, die geändert wurden, gespeichert. Dazu muss aber in jedem Fall die gesamte Seite neu geladen werden. Bei ausgeklappten Threads ist das ein recht langwieriger Prozess, der auch viel Bandbreite auf dem Server verschlingt. Nur um einen Kommentar zu bewerten, möchten die meisten Nutzer aber nicht mehrere Sekunden warten.

Mancher Webdesigner versucht solche Probleme mit Hacks zu umgehen. Die postmoderne Ideenbörse half-empty.org z.B. verwendet Popup-Windows, um Bewertungspunkte zu speichern, ohne die Seite neu zu laden. Erwartungsgemäß mehr Leute verwenden das System, und erwartungsgemäß mehr Leute beschweren sich über das nicht mit allen Browsern kompatible JavaScript. Andere Sites verwenden Frames, doch die sind aus anderen Gründen unter Usability-Experten verpönt.

Es zeigt sich, dass mit bisherigen Browser-Mitteln solche User Interfaces kaum abbildbar sind, auch wenn neue Scripting-Möglichkeiten und neue Dastellungsstandards hier Abhilfe schaffen sollen. Eine vom Browser unabhängige Anwendung wäre aber schon allein deshalb vorzuziehen, weil sie auch von den angesteuerten Websites unabhängig wäre, man Nutzer und Inhalte also überall mit dem gleichen Werkzeug bewerten könnte. Doch hier zeigt sich das nächste Problem: Wo sollen die Bewertungsdaten gespeichert werden? Schließlich sind sie weit aufschlussreicher als nur eine Liste der vom Nutzer besuchten Websites. Da gehen bei Datenschützern alle Alarmlichter an, und kein Wunder - Unternehmen würden hohe Preise für solche Profile zahlen. Deshalb sind Rating-Unternehmen wie Alexa, die genau solche Bewertungen erlauben wollten, immer wieder in die Kritik geraten.

Dezentrale Authentifizierung

Wer eine zentrale Rating- und Reputations-Datenbank aufbaut, kommt ohnehin nicht umhin, Microsoft Passport praktisch zu kopieren, denn neben den Ratings müssen ja auch noch die Identitäten der Personen gespeichert werden, die sie abgegeben haben. Die Probleme von Passport (vgl. Teil 2) gelten also auch hier. Ließe sich die Kombination von Ratings, Trust und Authentifizierung denzentralisieren? Zumindest für den Authentifizierungs-Aspekt gibt es das bereits in Teil 2 angesprochene Projekt DotGNU Global Login.

Auch Trust-Verfahren sollen der eindeutigen Authentifizierung von Nutzern dienen. In Verbindung mit digitalen Signaturen sollen sogenannte "Webs of Trust" entstehen. Benutzer zertifizieren, dass ein bestimmter kryptographischer Schlüssel tatsächlich zu genau der genannten Person gehört und zu niemand anders. Wer nun diesen Schlüssel verwendet, um z.B. einen Brief zu signieren, muss sich nicht darum kümmern, dessen Echtheit unter Beweis zu stellen, wenn die bereits von einer anerkannten Behörde beglaubigt ist.

Hier zeigt sich ein Problem des WoT-Ansatzes: Zwar soll alles so weit wie möglich dezentralisiert werden, und über indirekte Beziehungen ("Person A vertraut Person B, und Person B vertraut Person C, also vertraut vermutlich Person A Person C ein kleines bisschen") soll der Nutzen des Netzes mit seiner Größe exponentiell wachsen. Doch echte Sicherheit ist das nicht, und Unternehmen wie Privatpersonen werden sich bei sensitiven Transaktionen nicht mit komplexen numerischen Bewertungen herumschlagen wollen, sondern einfach die Information "Autorität X vertraut Person A" anfordern. Das ist im Grunde auch für Datenschützer kein Problem und elementarer Bestandteil des Konzeptes der digitalen Signatur; es soll durch sogenannte "Trust Center" verwirklicht werden, die nicht nur die Echtheit von Schlüsseln bestätigen, sondern auch selbst "digitale Ausweise" ausstellen. Entscheidend ist, wie wettbewerbsoffen solche Systeme sind, und wie viele Daten bei zentralen Autoritäten gespeichert werden.

Ratings, Trust, Reputationen und Authentifizierung bilden Schlüsselkomponenten, um die gemeinsame Entwicklung von Software zu koordinieren, ihre Anwendbarkeit in vielen anderen Bereichen sollte offensichtlich sein. Weitere Versprechen des digitalen Zeitalters lassen immer noch auf sich warten: effiziente gemeinschaftliche Bearbeitung von Dateien, optimierte Abstimmungssoftware und elektronisches Geld.