<< Themensammlung Netzwertig

Unter netzwertig veröffentlichen wir in unserem Blog Einschätzungen zu aktuellen digitalen Geschäftsmodellen und IT-Trends, Meldungen, Analysen, Reviews und Specials.

08.07.08

Twitter, Friendfeed, laconi.ca, gnip: Die Evolution des Lifestreaming geht weiter

Einer der wichtigsten Trends der letzten 18 Monate im Web – zumindest im Web der Vielnutzer – ist wohl der Aufstieg vom Micro-Publishing und Lifestreaming zur allgemeinen Lebensform und zur den Diskurs über das Web bestimmenden Grösse. Mit laconi.ca und gnip sind zwei Tools an den Start gegangen, die die Früchte von Twitter und Friendfeed ernten wollen.

Eine Leistung von Twitter war es, das Prinzip banale Aktivität zu verallgemeinern und gewissermassen auf den Punkt zu bringen. Natürlich haben wir auch zuvor schon auf hunderten Diensten unsere Spuren hinterlassen, wir haben gebookmarkt was das Zeug hält, Fotos veröffentlicht, Tracks geliebt, Videos favorisiert, auf Blogs kommentiert, etc.

Doch indem Twitter aus einer maximal 140 Zeichen langen Textnachricht einen fundamentalen Datentyp gemacht hat, der sich dann auch noch durchaus bewährt hat und als Input-Strom wesentlich wichtiger wurde, als so manches andere Format (im Bereich Technology-News etwa gibt es kaum eine Meldung auf Blogs und schon gar nicht auf News-Seiten, die man nicht schon Stunden oder Tage zuvor nicht auch schon gezwitschert gesehen hat), hat Twitter auch den Wert unserer ganz alltäglichen Aktivitäten auf den anderen Diensten aufgewertet.

Wenn Aussagen wie ‘sitze auf dem Klo’ oder ‘habe gerade Finanzierungsrunde abgeschlossen’ im Kontext von Twitter plötzlich stimmig sind, dann sind es die kleinen Aktivitäten bei anderen Diensten mit einem Schlag auch, wenn man den richtigen Kontext dafür findet.

Die Leistung von Friendfeed war es, dieser Aufwertung des Banalen zur richtigen Zeit eine Form zu geben. Im Grunde ist Friendfeed nichts anderes als ein Feedreader für die Aktivitätenströme unserer Freunde, oder von Personen, deren Aktivitäten uns interessieren. Auch vor Friendfeed gab es schon einige Dienste, die mehr oder weniger das gleiche gemacht haben (etwa noserub oder lifestrea.ms, beide übrigens aus Deutschland), aber Friendfeed war gerade zur richtigen Zeit neu, einfach genug und hatte das richtige Bündel an Features.

Weder Twitter noch Friendfeed sind Anwendungen, die für alle sinnvoll sind. Einerseits setzen beide einen gesunden Prozentsatz an Zeit, die man bereit ist, im Web zu verbringen, voraus. Andererseits erklären sich beide Seiten nicht von selbst und benötigen etwas Neugierde und Eigeninterpretation von Seiten des Benutzers. Wer Twitter in eine Bringschuld setzt, dass es sich ihm gefälligst ausführlich selbst erklärt, bevor man es auch nur ausprobiert, der wird nicht weit damit kommen. Auch Friendfeed ist nur lustig, wenn man proaktiv ein eigenes Interesse an den Aktivitäten von Bekannten und Verwandten mitbringt, und wenn man Freunde hat, die an mehreren Stellen im Web aktiv sind. Beide Seiten sind aber aus dem Kommunikationshaushalt für diejenigen, die sie für sich adaptiert haben, nicht mehr wegzudenken und haben deren Kommunikationsverhalten stark beeinflusst.

Aber die Welt dreht sich weiter, und nachdem Twitter und Friendfeed mit ihrem Wertvorschlag ein neues Paradigma etabliert haben, scharen schon die nächsten Startups in den Startlöchern, und denken Twitter / Friendfeed / Lifestreaming weiter. Letzte Woche gleich zweimal auf sehr grundsätzliche Art: gnip und laconi.ca .

 

Twitter’s Fail Whale

laconi.ca ist ein weiteres Microblogging Tool und nimmt sich dem Hauptproblem von Twitter an: der Tatsache, dass Twitter ein zentraler, proprietärer Dienst ist. Denn wenn ein solcher nicht verfügbar ist – und jeder Twitter-User kennt den niedlichen Fail Whale – dann kann man wenig dagegen machen. Je wichtiger die Kommunikation mit Twitter aber für die jeweiligen Benutzer wird, desto grösser ist der Leidensdruck und die Frustration, wenn etwas nicht reibungslos funktioniert.

laconi.ca steht unter einer Open-Source-Lizenz. Jeder, der will, kann also seine eigene Twitter-Instanz selbst hosten. Besonders interessant dabei: die jeweiligen Installationen können miteinander kommunizieren, Benutzer auf der einen Installation können Benutzer auf einer anderen Installation abonnieren.

Die Vorteile liegen auf der Hand:

  • Open Source ist sympathisch (und hat noch einige andere Vorteile)
  • das Prinzip Twitter wird distribuiert, niemand hat die umfassende Kontrolle
  • die Last wird verteilt und auch wenn einzelne Knoten ausfallen, bricht das System nicht zusammen
  • man besitzt seine eigenen Daten
  • usw.

Aber die Frage ist: will man wirklich 10.000 Twitter Klone, wobei wohl die überwiegende Mehrzahl 5 User oder weniger hat? Auch wenn sie miteinander kommunizieren können, alleine das Freunde-Management würde sehr anstrengend. Die pragmatischen Vorteile für Benutzer sind marginal, besonders wenn – und davon ist mittelfristig auszugehen – Twitter die Downtimes in den Griff bekommt.

Aber es gibt mehrere Nachteile: Bestehende Features von Twitter werden bestenfalls stückchenweise nachimplementiert. Sämtliche Netzwerkeffekte, die Twitter aufgrund der Userbasis hat, gehen auch für die User verloren. Es gibt kaum die Möglichkeit, Mashups bzw. sinnvolle Drittanwendungen über alle laconi.ca Installationen hinweg zu bauen, doch diese Drittanwendungen von Twitter sind es, die es zu einer so spannenden Plattform macht (etwa Summize oder Twittervision, viel mehr davon hier).

Unter dem Strich: laconi.ca ist eine Spielerei, die zwar notwendig war, die aber wohl kaum Twitter ablösen wird. Es wird sicher die eine oder andere populärere Installation geben, doch die werden dann bald und mit wesentlich weniger Usern mit ähnlichen Problemen wie jetzt Twitter zu kämpfen haben. laconi.ca ist für einige Anwendungsfälle wie für Intranets durchaus sinnvoll. Doch die meisten Installationen werden verschwinden und dabei hoffentlich nicht zu viele Tweets mit sich begraben. (Gefahr für Twitter sehe ich eher bei Jaiku. Wenn Google dieses endlich auf die Google App Engine portiert hat, dann haben sie einige Möglichkeiten, bestehene Dienste damit aufzuwerten.)

 

foto credit: gnipcentral.com

gnip andererseits denkt die Art und Weise weiter, wie unsere Aktivitäten, die auf den unterschiedlichen Diensten anfallen, einfacher weiterverwendet werden könnten.

Es hat sich in den letzten Jahren – Stichwort Data Portability – zwar durchgesetzt, dass Anwendungen irgendwelche Möglichkeiten bereitstellen, die Daten und Aktivitätenströme auch anderen Diensten zugänglich zu machen. Nach innen und aussen undurchlässige Silos sind eine vom Aussterben bedrohte Applikation-Art. Aber was in der Theorie funktioniert, stellt sich in der Praxis oft als mühsam heraus, weil es unzählige APIs gibt, die unterstützt und gewartet werden wollen, unterschiedliche Authentifizierungsprotokolle, die alle ihre Eigenheiten haben, usw.

Wie oben beschrieben, kam Friendfeed mitunter auch deshalb zur richtigen Zeit mit dem richtigen Featureset, weil es eine ausreichend grosse Zahl an Usern gab, die für den fragmentierten Gesamtoutput ihrer Freunde auf all diesen Services endlich ein geeignetes Gefäß fanden. Die technologische Leistung von Friendfeed war, diese Probleme im Hintergrund zu lösen, die User vor allen Umständlichkeiten abzuschirmen und ein sauberes Interface zu präsentieren.

Gnip geht jedoch einen Schritt weiter und will eine vereinheitlichte Schnittstelle für alle Dienste bereitstellen (zumindest für alle die dabei mitmachen), auf denen wir Aktivity-Streams erzeugen. Kein umständliches Herumfriemeln mit den APIs von digg, flickr, del.icio.us, disqus usw., sondern eine einzige Schnittstelle, mit der man alle Dienste auf die gleiche Art ansprechen kann.

Wenn man will ist gnip ein Friendfeed für Entwickler, ein Mashup-Paradies für das Erstellen von Anwendungen, die diverse, ohnehin entstehende Daten kreativ weiterverwenden oder neu visualisieren.

Die Idee für gnip hätte eigentlich von Google kommen müssen: ich sammle alle Aktivitäten aller User auf allen Services und biete eine einfache, extrem robuste Schnittstelle, über die alle an diesen Daten interessierte Dienste Zugriff darauf bekommen. Die Services können dann ihre eigenen APIs entlasten, viele haben ohnehin zuviel Aufwand damit und bekommen den Traffic nicht ganz in den Griff, wir machen gerne die Schwerstarbeit, sie können das an uns übertragen und sich auf ihr Kerngeschäft konzentrieren.

Bei gnip auch interessant: anders als die meisten APIs bietet gnip bald neben dem üblichen polling auch ein push Verfahren der Benachrichtigung an. Anwendungen, die etwa von der Twitter-API Gebrauch machen, müssen Twitter selbst immer und immer wieder fragen, ob sich was getan hat. Das tun sie oft, Twitter ist ein Echtzeitmedium, da will man natürlich zeitnah imformiert werden. Doch dadurch entsteht unnötiger Traffic und Serverlast, weil sich in den meisten Fällen nichts getan hat. Gnip hingegen könnte die Konsumenten darüber informieren, wenn es Neuigkeiten gibt.

Die Idee ist genial und das API von gnip ist sehr einfach und dürfte kaum einem Entwickler Probleme bereiten.

Eine der Fragen wird sein, wie viele Dienste sich als Data-Provider zur Verfügung stellen. Ohne in eine Glaskugel schauen zu können werden es wohl jene sein, die sich aus den neuen Möglichkeiten der Weiterverwendung ihrer Activity-Streams Vorteile versprechen (weniger Traffic auf die eigene API, mehr Traffic auf das eigene Angebot), aber dabei wenige Nachteile sehen. Digg und flickr etwa profitieren aus den genannten Gründen davon, geben aber auch nur wenig Kontrolle auf, weil die Activity-Streams ohnehin nur auf die jeweilige Story auf digg oder das Foto bei flickr verlinkt.

Doch alle Activity-Broker, Paradebeispiel natürlich Twitter, haben wenig davon, wenn gnip ihr eigenes Angebot subsummiert und in sich aufnimmt.

Die andere – und wichtigere – Frage ist, wie gut es für das Ökosystem Web ist, wenn sich ein Dienst als ultimative Zentralinstanz für Mashups aller Art etabliert. Der Nutzen (Entwickler haben es etwas leichter, es gibt ganz neue Möglichkeiten für Echtzeit-Mashups aller Art, …) steht dem Kostenpunkt gegenüber, dass man sich nicht nur in die Abhängigkeit bezüglich der Verfügbarkeit eines einzigen Dienstes begibt, sondern dass der Zugang zu allen Diensten plötzlich an einen einzigen Service gekoppelt wird.

Und es bleibt abzuwarten, ob es gnip im Falle einer breiten Adaption gelingen wird, den Lastspitzen standzuhalten, oder ob wir uns an ein weiteres Tier im Web2.0-Zoo der Nichtverfügbarkeit gewöhnen müssen.

Dennoch ist die Idee von gnip eine der spannendsten der letzten Zeit, und wenn es an Momentum gewinnt, dann dürfte das Interesse von Google, Yahoo & Co. durchaus geweckt werden. Eine Partnerschaft wäre dann auch deshalb sinnvoll, weil Google oder Amazon ganz andere Möglichkeiten zum Skalieren der Infrastruktur hätten.

Lektüre zum Thema:

Das könnte Sie auch interessieren

Förderland-Newsletter

Wissen für Gründer und Unternehmer