Open Source - offene Protokolle - Open Access

Baukasten für ein zukünftiges Web des Wissens

Impulsvortrag zum Lotus JamCamp 2010 , 23. April 2010, Jörg Kantel

(Photo: Norbert Spitzer)

Jörg Kantel, Jahrgang 1953, studierte Mathematik, Informatik und Philosophie. Nach einigen Jahren in der Industrie ist er seit 1994 EDV-Leiter am Max-Planck-Institut für Wissenschaftsgeschichte (MPIWG) in Berlin und dort unter anderem mit der Frage beschäftigt, wie man Forschungsergebnisse und -Quellen im Web sinnvoll präsentiert.

Von 2006 bis 2009 war er außerdem Lehrbeauftragter für Multimedia im Fachbereich »Angewandte Informatik« an der Fachhochschule für Technik und Wirtschaft (FHTW), jetzt Hochschule für Technik und Wirtschaft (HTW) in Berlin.

Seit dem 24. April 2000 gibt er außerdem das Weblog Der Schockwellenreiter heraus und ist damit vermutlich der »dienstälteste« noch aktive deutschsprachige Blogger.

Autor diverser Bücher und Aufsätze zum Web 2.0.

The Web is a Writing Environment – Dave Winer

Das sah übrigens Tim Berners-Lee auch schon so.

Seit Bestehen des Netzes tobt ein heftiger Kampf zwischen denen, die das Netz als einen Kommunikationskanal betrachten und denen, die darin nur einen weiteren Kanal zur Distribution herkömmlicher Medieninhalte sehen.

»Das Internet ist von einem Distributions- in einen Kommunikationsapparat zu verwandeln.« (Frei nach Bertolt Brecht: Radiotheorie)

»Jeder heutige Mensch kann einen Anspruch vorbringen, gefilmt zu werden.« (Walter Benjamin: Das Kunstwerk im Zeitalter seiner technischen Reproduzierbarkeit)

Am MPIWG existieren etliche Projekte, die versuchen, historisches Wissen online zur Verfügung zu stellen, z.B.:

• Das Archimedes-Projekt mit Quellen zur Wissenschaftsgeschichte
• Das Virtual Laboratory for Physiology (VLP)
• European Cultural Heritage Online (ECHO), ein EU gefördertes Projekt
• Die Cuneiform Digital Library Initiative (CDLI) zusammen mit der University of California Los Angeles (UCLA)

Natürlich existieren auch sonst überall auf der Welt (fächerübergreifende) Digitalisierungsprojekte mit ähnlichen Zielen, nur …

• sie wissen nichts voneinander und …
• wenn sie voneinander wissen, besteht die Schwierigkeit der Kommunikation ihrer Webapplikationen und …

• es macht weder Sinn, die Daten zusammenzulegen (Update-Problematik) noch sie zu spiegeln (Speicherplatz-Verschwendung).
• Außerdem ist jeder Beteiligte stolz auf seine Arbeit, sein Layout, etc.

• Jürgen Renn forderte daher schon vor einigen Jahren: Gebt uns Tools!
• Dabei waren diese Tools schon lange vorhanden

Etwa 2000 gründete Dave Winer mit EditThisPage einen kostenlosen Weblog-Service. Doch nach kurzer Zeit war dieser völlig überlastet und brach ständig zusammen. (Ich nannte das damals das Manila-Syndrom.)

Daher machte er etwa 2002 einen seiner berüchtigen cornerturns und mit Radio UserLand etwas ganz anderes.

• Webserver auf dem Desktop als Redaktionsserver
• Statische Seiten auf dem Produktionsserver
• Community-Server: Kommunikation via Ping und XML/RPC
• Inhalte werden auch via RSS zur Verfügung gestellt

Das sind die Tools, die benötigt werden:

• Webserver auf dem Desktop / Arbeitsgruppenserver (QEDWiki, Django, Rails, DokuWiki – dazu später mehr)
• Ping, Trackbackping und/oder Pingback
• XML-RPC, SOAP (?), XMPP (auch dazu später noch mehr)
• RSS und Atom

Ausgehend von diesen Tools habe ich schon 2003 in einer Keynote auf der BlogTalk in Wien folgendes Szenario vorgeschlagen:

• Jede Institution stellt ihre Sammlungen und Ergebnisse (wie auch immer) online
• Ein oder mehrere Community-Server werden per Ping informiert
• Diese Server rufen die Inhalte per RSS/Atom ab und erstellen automatisch daraus Inhaltsverzeichnisse …

• Auf den Community-Servern läuft die Suche und sie zeigt die Suchergebnisse als Links auf die (verteilten) Originalseiten
• Redundanz ist kein Problem, sondern dient im Gegenteil eher als ein primitives Load-Balancing

• Peer-Review-Verfahren sind langsam und meiner Meinung der Publikationsform WWW nicht angemessen
• Trackback und Pingback in Verbindung mit einer Kommentarfunktion könnten neue Verfahren zur »Wertigkeit« einer Publikation eröffnen

• Der Community-Server als one point of failure störte mich …
• Daher kommen wir später noch einmal darauf zurück

• Da alle Beteiligten mit den Tools ihres Vertrauens arbeiten, müssen diese Werkzeuge untereinander über offene Protokolle kommunizieren
• Und natürlich macht das Ganze nur Sinn, wenn die Inhalte frei zur Verfügung stehen

Und so nimmt es nicht wunder, daß das MPIWG einer der Initiatoren der Berliner Erklärung zum Open Access ist.

Doch erst einmal einen Schritt zurück und wir stellen das »Quick and Easy Done Wiki« (QEDWiki) vor …

• ist ein Mashup-Werkzeug
• ist ein Wiki
• funktioniert im Browser

• In all den Jahren habe ich die Erfahrung gemacht, daß all die großen, kommerziellen Rundum-Sorglos-Pakete genau das nicht machen, was der Wissenschaftler für seine Arbeit benötigt
• Das von der IBM entwickelte Konzept des Situational Computing ist ein Lösungsansatz für dieses Problem: Kleine Tools werden verändert und mithilfe von Glue-Skripten zu einer Applikation vom beteiligten Wissenschaftler selber zusammengestrickt.
• Dazu müssen alle benötigten Tools Open Source gestellt sein

die an sich faszinierende Idee wurde von IBM zugunsten von IBM Lotus-Mashups aufgegeben.

Situational Computing geht auch anders:

Doch dafür erwarten wir nun Google Wave

• Google Wave (Open Source) ist ein neues Kommunikations- und Kollaborationswerkzeug des Suchmaschinengiganten, das die Arbeit im Netz völlig umkrempeln soll.
• Es ist eine zentrale Kommunikationsplattform, die E-Mail, Instant-Messaging, Chat, Photos, Videos, Karten und Dokumente verbindet.
• Wave erlaubt unter anderem die gemeinsame Arbeit an Texten und anderen Dokumenten und die Änderungen können in Echtzeit verfolgt werden.

• Über APIs soll sich Wave in andere Internetseiten einbetten oder mit Anwendungen anderer Entwickler kombinieren lassen.
• Teile von Google Wave stehen seit Herbst 2009 der Öffentlichkeit zur Verfügung. Später soll der komplette Wave zugrundeliegende Code freigegeben werden, so daß jeder einen Wave-Dienst auf seinen Servern anbieten kann.

Es war von Google sicher nicht so geplant, aber Wave ist der Prototyp einer Peer-to-Peer-Anwendung.

• Denn wie sieht das Internet heute aus, wenn Google einmal ausfällt
• oder die Wikipedia? (Von nervenden Relevanzdiskussionen will ich gar nicht erst reden)

»Like Google, Twitter and the other leading commercial Internet sites have made tremendous contributions to the functionality of the Internet and have earned both their popularity and (where it exists) their revenue. But the end-to-end principle and the reliability of distributed processing must have their day again, whenever some use of the Internet becomes too important to leave up to any single entity.« (Andy Oram: Why social networks need to be decentralized)

• Google hat versprochen, Wave als Anwendung unter einer Open Source-Lizenz freizugeben (sollte eigentlich diesen Monat noch passieren).
• Damit ist a) die Kritik des BSI an Google Wave hinfällig.
• Und b) eine dezentrale Wave-Umgebung denkbar.
• denn Wave basiert auf einer Erweiterung des XMPP-Protokolls (Jabber)

Der Community-Server ist weg.

• denn XMPP kann abfragen, ob die Gegenstelle erreichbar ist und erst dann entsprechend reagieren
• soll auch mit PubSubHubbub gehen (noch nicht getestet)
• So entfällt die Notwendigkeit eines Community-Servers selbst dann, wenn der Redaktionsserver nicht ständig online ist

Bleibt nur noch das Problem der Suche, doch …

• Warum sollen wir dies nicht Google überlassen?
• Solange sichergestellt ist, daß wir mit einem »Knopfdruck« auf Yahoo!, Bing oder andere Alternativen umschalten können
• Und Inhaltsverzeichnisse kann sich jeder Anwender aus den Suchergebnissen generieren

Also besteht unsere Umgebung jetzt nur noch aus …

• einem Redaktionsserver
• einem Produktionsserver (der kann durchaus aus statischen Seiten bestehen)
• offenen Protokolle wie XML-RPC, XMPP und RSS/Atom
• dynamische Elemente auf dem Produktionsserver werden als Gadgets/Widgets dazugeladen

Gerade bei kleinen Sammlungen ist die Trennung zwischen Redaktions- und Produktionsserver nicht immer sinnvoll:

• Hier lassen sich (erweiterbare) Wikis wie das DokuWiki nutzen
• Wenn sie (durch einen Plugin-Mechanismus) einfach erweiterbar sind und …
• mindestens XML-RPC, XMPP und RSS/Atom »verstehen«

• Carr vergleicht die Entwicklung der IT mit der Entwicklung der Energieversorgung
• Ähnlich wie die Energieindustrie einen »Switch« vom Verkäufer von Turbinen zum Verkäufer von Energie durchmachte, wird die IT-Industrie einen Switch vom Verkäufer von Rechnern zum Verkäufer von Rechenleistung durchmachen

• Große, zentralisierte Serverfarmen werden nicht nur die PCs ablösen, sondern auch die IT-Abteilungen der Unternehmen überflüssig machen
• Rechenleistung wird eine Dienstleistung, ähnlich wie die Versorgung mit Energie, die von außerhalb in die Unternehmen kommen wird

• Wissen Sie noch, was ein Growian ist?
• Erinnern Sie sich noch an den Cargo-Lifter?

(Photo: Gabriele Kantel)

• Der Wandel vom Turbinenproduzenten zum Energieversorger und die darauf folgende Zentralisierung enstand aus gesellschaftlicher Notwendigkeit: (nationale) Vereinheitlichung des Stromnetzes auf 110 resp. 220 Volt)
• Diese gesellschaftliche Notwendigkeit ist bei der IT-Versorgung nicht vorhanden, da das Netz schon heute auf Standards basiert (basieren muß)

• Carr übersieht, daß schon heute wieder ein Umschwung auf dezentrale Energieversorgung zu beobachten ist
• denn »small is beautyfull« und machbar, Frau Nachbar

• aus dem zweifelslos zu beobachtenden Trend hin zu Cloud- und Utility-Computing ist nicht notwendigerweise ein Trend hin zur (globalen) Zentralisierung abzuleiten
• das bedeutet aber nicht, daß dieser Trend nicht existiert
• Und egal wohin die Richtung geht, Cloud- und Utility-Computing wird die IT-Landschaft verändern

• All die netten Widgets und Gadgets müssen ja nicht von Google & Co. kommen
• Sie können von der Community zur Verfügung gestellt und verteilt werden
• Ein Vorbild für so etwas wäre zum Beispiel GitHub (muß ich mir aber selber noch genauer anschauen)

Drei Stufen:

• Flickr, Facebook, Twitter, aber auch Wikipedia (mit Relevanzdiskussion und Server-Overload)
• Modell OpenStreetMap: Spiegelung des Datenbestands auf diversen Servern für unterschiedliche Projekte
• Echtes Peer-to-Peer

• Jeder Netzkonsument wird zum (potentiellen) Wissensproduzenten (dezentrales Netz)
• Dieses Wissen steht allen frei zur Verfügung (Open Access)
• Dieses Wissens wird mittels einfachster Tools (KISS) miteinander vernetzt (Open Protocols)
• Diese Tools können von den Wissensproduzenten selber auf ihre Bedürfnisse angepaßt werden (Open Source)

Es gibt also viel zu tun: Packen wir es an!

»Sollten Sie dies für utopisch halten, so bitte ich Sie, darüber nachzudenken, warum es utopisch ist.«

(Bertolt Brecht: Radiotheorie)

Danke für Ihre Aufmerksamkeit.

URL: http://www.cognitiones.de/doku.php/open_source_-_offene_protokolle_-_open_access

→ Zurück zum Wiki

Werbung