<< 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.08Leser-Kommentare

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:

Kommentare

  • Sven Drieling

    08.07.08 (17:15:03)

    Ich finde es gut, dass soviel gemacht und ausprobiert wird aber irgendwie habe ich das Gefühl, dass es immer nur neue Namen für "RSS-Reader" und "Blog" sind. Zum Beispiel Twitter: 140 Zeichen kann man auch regelmäßig in jedem Blog posten und per Technorati 'Tag: 140chars' bzw. im eigenen RSS-Reader zentral zusammenfügen. Sprich, dass sehr viel mit Produktnamen/Brandings für etwas unglaublich neues geworben wird, es aber nur eine neue Sichtweise, eine andere Art der Nutzung einer schon existierende Technik ist. Statt etwas wirklich neues zu finden habe ich eher das Gefühl von Produktnamen erschlagen zu werden, die nur eine leichte Variation von etwas schon existierenden bieten. Und es stärker im Vordergrund steht mit einem eigenen Dienst Geld zu machen als etwas neues auszuprobieren.

  • Marcel Weiss

    08.07.08 (19:55:25)

    Sven, in Deinem Beispiel mit Technorati setzt Du automatisch voraus, dass so eine Konversation in Echtzeit stattfinden könnte. Könnte sie nicht. Dafür reichen die Pingzeiten nicht aus. Und Technorati könnte auch nicht für diesen Usecase die Blogs im Sekundentakt abrufen, weil dann viele Server privater Blogs in die Knie gehen würden. Deiner Argumentation nach könnte man übrigens auch RSS als überflüssige Weiterentwicklung der Email bezeichnen. Immerhin können alle per RSS verbreitete Inhalte auch per Mail verbreitet werden. Auf dieser Argumentationsebene werden meines Erachtens die wesentlichen Unterscheidungsmerkmale zwischen den Technologien zu nebensächlichen Details degradiert. Grober Fehler. :)

  • Sven Drieling

    08.07.08 (22:10:00)

    Marcel warum sollen die Pingzeiten nicht ausreichen? Das ist ja nur ein technisches Problem. Mein Ping an einen Server ist ja sofort abgeschickt. Wie schnell ein Server darauf reagieren kann ist dann eine Sache der Infrastruktur des Servers. Als Alternative könnte statt nur der Ping auch gleich eine Kopie der 140-Zeichennachricht an einen Server geschickt werden. Das ist dann nichts anderes als die direkte Eingabe per Login auf dem Server. Nur das es dann eine Kopie vom eigenen 140-Zeichen-Blog ist. So mache ich das mit meinen Links. Einmal auf die Homepage und gleichzeitig eine Kopie zum Teilen mit anderen auf delicious. 1. Phase: Man hat alles auf der eigenen Homepage. 2. Phase: Man verteilt alles im Netz (delicious, flickr, twitter, facebook, ...) 3. Phase: Es wird auf einen externen Server wieder alles zusammengefügt (livestream.fm) 4. Phase: Wieder alles wieder auf dem eigenen Webspace auf dem man halbwegs Kontrolle über die eigenen Sachen hat und diese dann dort (gezielt) für Crawler bereitstellt oder per Push aktiv zeitgleich oder -versetzt auf Server wie delicious, flickr, facebook, ... verteilt, wo sie zentral für andere bereitstehen und geteilt werden? Mit der Option diese dort auch wieder leicht löschen zu können, sofern man dafür auf den Servern ein Login angelegt hat. Statt Neue Idee = Neuer Server. Neue Idee = Neues oder erweitertes Plugin für den eigenen Webspace (und externen Server).

  • Markus Spath

    09.07.08 (10:13:22)

    Sven, wie du sagst, es wird vieles ausprobiert, vieles ist auch nur alter Wein in neuen Schläuchen. Aber es gibt einen Unterschied zwischen dem Konkunktiv (hätte, täte, könnte, ginge auch schon mit exisitierenden Tools und Protokollen) und Tools, die ganz konkret irgendwas tun und einen Wertvorschlag machen, den man annehmen kann, oder nicht. Bei Twitter kann sich jeder jetzt schon in 2 Minuten anmelden, und es in der Folge via Web, SMS, anderen Medien befüllen und konsumieren. Man braucht keinen eigenen Server, man muss nicht darauf warten, dass es irgendwann auf eine mögliche Art von irgendjemandem implementiert wird. Zu deinen Phasen: deine Phase 4 ist ein klarer Trend (Stichwort Data Portability), da wird sich vieles tun, weil viele die Kontrolle über ihren Output zurückhaben wollen. Aber auch hier darf man glaub ich nicht vergessen, dass nicht jeder seinen eigenen Server herumstehen hat, auf dem er installieren kann was er will, und mit der nötigen Zeit und Wissen ausgestattet ist, diesen andauernd zu warten usw. Aus reiner Usersicht: alles was im Setup-Prozess länger als diese 2 Minuten dauert und was monatlich mehr kostet als 0 Euro ist ein Nachteil.

Diesen Beitrag kommentieren:

Die Kommentare können nur zwischen 9 und 16 Uhr
freigeschaltet werden. Wir bitten um Verständnis.

Um Spam zu vermeiden, schreiben Sie bitte die Buchstaben aus diesem Bild in das nebenstehende Formularfeld:

Das könnte Sie auch interessieren

Förderland-Newsletter

Wissen für Gründer und Unternehmer