Seite 2: Das Web, wie es hätte sein sollen

Der heute an der Keio Universität in Japan forschende und lehrende Ted Nelson stellte sich das Web vor nun über vierzig Jahren weit anders vor - und nützlicher - als es heute existiert. Sein seit 1960 propagiertes Xanadu-Modell2 für Hypertext-Dokumente hat wenig Ähnlichkeit mit dem vergleichsweise primitiven heutigen System aus nicht mehr funktionierenden Links und oftmals völlig unstrukturierten Dokumenten. Xanadu sollte das Hypertext-System der Zukunft sein. Jedes Dokument in Nelsons Hypertext-Raum sollte eine absolut eindeutige Adresse (unabhängig vom Speicherort) besitzen. Innerhalb des Dokuments sollten selbst einzelne Zeichen direkt von anderswo adressierbar sein, man sollte also z.B. von einem anderen Dokument auf den Beginn dieses Absatzes verweisen können (ohne dass man dazu, wie in HTML notwendig, extra in diesem Dokument einen "Anker" definieren müsste).

Ein in Xanadu veröffentlichtes Dokument sollte unlöschbar sein, man konnte zwar, so die Idee, eine neue Version veröffentlichen, doch die alte Version des gleichen Dokuments blieb verfügbar, und Unterschiede zwischen zwei Versionen ließen sich auf einfache Weise sichtbar machen (wie heute mit verschiedenen diff-Tools möglich). Verweise sollten bidirektional sein; wenn man eine Seite in Xanadu betrachtete, sollte man also auch sehen, welche anderen Seiten auf diese Seite verwiesen. Anstelle des im Web üblichen "Copy & Paste", des einfachen Kopierens von Inhalten, sollten die Adressen von Inhalten an der Stelle, an der man sie benutzt, eingefügt werden. Wenn man also z.B. ein Buch zitiert, würde man einfach die Adresse (also die global eindeutige Nummer des Buches sowie die Zahl der zu zitierenden Zeichen) an der entsprechenden Stelle einfügen, nicht den Zitattext selbst. Der Client (das Xanadu-Äquivalent zum Webbrowser) würde die Daten dann an der richtigen Stelle einfügen.

Die Vorteile: Zitate bleiben automatisch aktuell, wenn dies gewünscht ist, ihre Echtheit kann gewährleistet werden, man kann sofort den Kontext eines Zitates anfordern, und Urheber können ggf. ohne großen Aufwand im Hintergrund vergütet werden.

So ganz nebenbei wollte Nelson mit Xanadu also auch die abzusehenden Urheberrechts-Probleme lösen, die mit der zunehmenden Digitalisierung und Vernetzung einher gehen würden. Anstatt mühsam jede "Verletzung" zu verfolgen, sollten Dokumente in Xanadu so günstig sein, dass man ihre Bezahlung gar nicht beachtete. Bruchteile von Cents sollten für die Verwertung eines Dokumentes innerhalb eines anderen fällig werden, und aufgrund des Systems der direkten Adressierung von Inhalten anstelle ihres Kopierens würden solche Verwertungsvorgänge auch erfassbar bleiben, sofern man das System nicht mit Absicht umging. "Ich würde gerne in einer Welt leben, in der es kein Copyright gibt, aber so liegen die Dinge nun einmal nicht", meint Nelson - und nennt sein alternatives Modell "Transcopyright". Essentiell dafür ist es, Kleinstbeträge zwischen Nutzern wirtschaftlich übertragen zu können.

Dass das Web letztlich nur eine bescheidene Teilmenge der von Xanadu definierten Funktionalität umsetzt, überrascht nicht, schließlich sind einige der technischen Probleme bis heute nicht gelöst, ganz zu schweigen von den sozialen Implikationen "ewiger Speicherung", die Xanadu prinzipiell erfordert. Nelson bleibt der ewige Visionär, genau wie sein Zeitgenosse Douglas Engelbart, der als Erfinder der Maus bekannt ist, aber nebenbei auch die Grundlagen für grafische Benutzeroberflächen und Tools zum gemeinsamen Bearbeiten von Dokumenten entwickelte.

Gemeinsame Dateibearbeitung

Die gemeinsame Bearbeitung von Dateien, sei es Software-Quellcode oder seien es Texte aller Art, kann auf zwei Arten erfolgen: Zwei Nutzer sehen unmittelbar das gleiche Dokument vor sich und einigen sich in Echtzeit über die Änderungen, oder sie bearbeiten unterschiedliche Teile des gleichen Projekts getrennt voneinander und bemühen sich anschließend um eine möglichst optimale Synchronisation.

Die Echtzeit-Kollaboration steckt nach wie vor in den Kinderschuhen. Microsoft Word enthält rudimentäre Funktionen hierzu, und auch mit komplexen Unix-Editoren wie Emacs lässt sie sich realisieren, aber die entsprechenden Werkzeuge sind weder umfassend in ihrer Funktionalität noch verbreitet noch einfach in der Handhabung. Dabei hatte Douglas Engelbart in seiner weltberühmten Stanford-Präsentation von 1968 bereits demonstriert, wie zwei Nutzer gleichzeitig an einem Dokument arbeiten (wobei ein Nutzer die Kontrolle über die Maus erhält) und sogar ihr Videobild im Monitor sehen können. Ein Grund für den mangelnden Erfolg von Online-Kollaboration ist sicherlich, dass die Bandbreite der meisten Nutzer dafür schlicht nicht ausreicht. Die Tatsache, dass viele schnelle Internet-Zugangsarten wie ADSL in Senderichtung verlangsamt sind, macht die Verbreitung von Video- oder Audioconferencing auch nicht gerade leichter. Doch einfache Systeme mit Chat- und Bearbeitungsmodus wären durchaus realisierbar, sind aber kaum verbreitet.

Die Werkzeuge für asynchrone (also zeitlich versetzte) Bearbeitung von Dokumenten existieren, werden aber selbst im Firmenumfeld außerhalb der Software-Entwicklung nur wenig eingesetzt. Beliebt besonders für nichttechnische Texte sind Wiki-Wiki-Webs. Ein Wiki ist eine Website, bei der jede Seite durch jeden Besucher bearbeitet werden kann. Das System wird mittlerweile mit Wikipedia sogar für eine kollaborative Enzyklopädie eingesetzt, die von jedem bearbeitet werden kann. Das Erstellen von Links auf Seiten eines Wikis ist innerhalb des Wikis besonders einfach, z.B., indem man den Namen der entsprechenden Seite in eckigen Klammern schreibt.

Wikis entwickeln eine interessante Eigendynamik. Obwohl sie technisch sehr primitiv sind, verfügen sie doch über die wesentlichen Werkzeuge, um dauerhafte Aktivität zu gewährleisten. Man sollte meinen, dass bei einer Seite, die jeder bearbeiten kann, Vandalismus nicht lange auf sich warten lässt. Das ist tatsächlich der Fall. Doch die meisten Wikis haben sogenannte "Recent Changes"-Listen der zuletzt gemachten Änderungen. Die Benutzer des Wikis kontrollieren diese Listen regelmäßig und korrigieren unerwünschte Änderungen.

Dass dieses Prinzip erstaunlich gut funktioniert, demonstriert das Projekt Wikipedia - in der interaktiven Enzyklopädie kann jeder Nutzer jeden Artikel bearbeiten, mittlerweile sind es rund 22.000. Die Qualität mancher Artikel ist erstaunlich, und der Theorie nach sollte sie stetig zunehmen.

Manche Software-Projekte nutzen Wikis für Spezifikationen, andere greifen auf ein anderes Verfahren zurück: Concurrent Versions System (CVS). CVS ist ein technisches Verfahren vor allem zur gemeinsamen Bearbeitung von Quellcode. Es gibt ein zentrales Archiv, das die aktuellste Version aller Programmdateien und Dokumente enthält. Will man eine Datei bearbeiten, nimmt man einen sogenannten "Checkout" vor, lädt also die aktuellste Version herunter. Noch während man die Datei lokal bearbeitet, kann ein anderer Entwickler die gleiche Datei auf seinem Rechner ebenfalls bearbeiten, sie wird nicht gesperrt. Nach dem Upload der Änderungen ins Archiv werden automatisch Versionsnummern vergeben und Protokolle geführt. Kommt es zu einem Konflikt mit der Bearbeitung durch einen anderen Nutzer, wird die entsprechende Stelle des Dokuments, an der Änderungen sich widersprechen, gezeigt, und einer der Entwickler löst den Konflikt.

CVS unterstützt auch die Sperrung von Dateien vor der Bearbeitung, oder zumindest die Anmeldung von Änderungswünschen, so dass man weiß, ob jemand anders gerade eine bestimmte Datei bearbeitet.

Wikis, CVS und sogenannte Content Management Systeme zur gemeinsamen Bearbeitung von Website-Inhalten sind praktisch, aber außerhalb der Geek-Kultur kaum verbreitet. Den meisten Windows-Nutzern dürften die Begriffe nichts sagen, und gängige Textverarbeitungen unterstützen ohnehin nur bruchstückhaftes Versionsmanagement. Eher nichttechnische Linux-Nutzer, die z.B. bei der Erstellung von Dokumentation helfen wollen, stoßen häufig auf technische Barrieren: Entweder Wikis und CVS werden nicht eingesetzt, oder CVS wird verwendet, wofür nur wenige leicht erlernbare grafische Front-Ends existieren. Wer ein Open-Source-Projekt startet, sollte sich darüber im Klaren sein, bei welchen Teilen des Projekts die breite Öffentlichkeit involviert werden kann, und die entsprechenden Werkzeuge verwenden (langfristig wäre eine Integration von CVS in einfache, grafische Editoren wie den KDE-Editor Kate wünschenswert). Ein negatives Gegenbeispiel sind die Übersetzungen der Linux-Manual-Pages ins Deutsche, die von einer Person per Email koordiniert werden und nicht zuletzt deshalb stagnieren. In solchen Fällen wäre ein moderiertes Wiki ideal.

Immerhin kommen Wikis und CVS dem Xanadu-Ideal von der ewigen Speicherung aller Versionen schon etwas näher: Manche Wikis tun genau das, und auch bei CVS sollte prinzipiell ein Backtracking bis zur ersten Dateiversion möglich sein.

Online-Abstimmungen

Wie aber realisiert man Abstimmungsverfahren z.B. für Linux-Standards? Technische Verfahren für Online-Abstimmungen existieren, sind aber noch recht umständlich. Prinzipiell benötigt man einen oder mehrere vertrauenswürdige Server, die Stimmen zählen. Nutzer müssen sich über einen gegebenen Mechanismus authentifizieren können, und Verschlüsselung aller Vorgänge ist meist erwünscht. Eine Abstimmung kann nach einer bestimmten Zeit oder bei Erreichen einer bestimmten Stimmenzahl oder eines bestimmten Schwellenwerts abgeschlossen werden. Man kann für bestimmte Umfrageoptionen stimmen oder auf einen Vorschlag mit bestimmten Standard-Antworten ("Ja", "Nein", "mehr Informationen notwendig", "interessiert mich nicht" usw.) reagieren. Wünschenswert ist es in beiden Fällen, dass die Abstimmung direkt mit Chaträumen und Diskussions-Threads verknüpft ist, wobei Rating- und Reputations-Systeme hochwertige Beiträge (aus individualisierter Sicht) hervorheben sollten. Noch hat sich kaum ein Software-Standard in Sachen Abstimmung durchgesetzt. Wer seine Projekt-Mailingliste bei Yahoo! einrichtet, kann dort immerhin simple Umfragen durchführen, was von manchen Open-Source-Projekten ausgiebig genutzt wird.

Wenn eine Abstimmung in Arbeit für beteiligte Personen resultiert, besteht die Gefahr einer exploitativen Beziehung zwischen Wählvolk und Beauftragten. Im Falle der LSB könnte ein Unternehmen wie IBM die Entwicklung gewählter Features aus der Portokasse finanzieren, doch bei einzelnen Free-Software-Produkten ist das keine Lösung. Abstimmungssysteme müssten also auf verschiedene Weise mit Electronic Payment verknüpft werden, z.B. über den Kauf oder die Gewichtung von Stimmen oder mit Zahlungsversprechen, die bei Erreichen eines bestimmten finanziellen Schwellenwerts in der Realisierung des gewünschten Features oder Patches kulminieren oder ansonsten nicht eingelöst werden müssen (Street Performer Protocol).

Abstimmungsverfahren könnten auch neue Impulse in Vertragsverhandlungen liefern, z.B. wenn es um ein Software-Projekt geht. Ein Beispiel für ein entsprechendes Interface stammt aus der Spielewelt: Der Civilization-Clone Freeciv verwendet bei den diplomatischen Verhandlungen zwischen zwei Zivilisationsführern einen Verhandlungstisch, bei dem beide Spieler ihr Angebot schnell aufeinander abstimmen und schließlich bestätigen können.