Das Potential von App.net richtig verstehen

Heute war ein heißer Tag und ich hatte viel Zeit in meiner super kühlen Altbau Wohnung Podcasts zu hören und nachzudenken, und habe dabei viel über App.net gelernt und dabei festgestellt, dass ich eine völlig falsche Vorstellung davon hatte, was es ist, bzw. sein kann.

Wer denkt, dass App.net ein werbefreier Twitter Clone ohne Werbung werden soll für den man als Nutzer bezahlen muss – und wer dabei skeptisch ist, dass das jemals genug Traktion bekommen wird – der sollte jetzt weiterlesen!

Ich hatte viel über App.net in letzter Zeit gehört und hatte auch neulich mal kurz zufällig mit @horax darüber gesprochen – aber erst durch die aktuelle Episode von TWiG – bei der der Gründer Dalton von App.net zu Gast ist – wurde mir klar, welche Idee wirklich dahinter steckt.

Um es so einfach wie möglich zu erkären: Twitter hat sich dafür entschieden – bzw. hat nach diversen Anläufen gesehen, dass es damit am meisten Erfolg hat – auf Werbung als Revenue Stream zu setzen und ist daher dabei seine API einzuschränken, denn wenn man Werbung verkauft, möchte man, dass möglichst viele Leute die eigene Webseite, die eigene App nutzen, um diese Werbung zu sehen.

Damit ist die Idee von Twitter als globale Infrastruktur für viele unterschiedliche Apps zu Ende. Was fein und ok ist. Warum auch nicht – ich freu mich schon auf die von Twitter produzierte Fernseh-Serie.

Was nun wichtig ist zu verstehen: App.net versteht sich selbst NICHT als kostenpflichtige Client seitige Twitter Alternative – sondern primär als Infrastruktur Anbieter für die Technologie die auch hinter Twitter steckt – und dass was jetzt die ersten Leute in der Alpha zu sehen bekommen, ist lediglich eine Referenz-Implementation eines Interfaces zu Demo zwecken.

Dalton sagt in der Sendung sehr klar, dass er nicht das Interface bauen will, sondern eine kostenpflichtige Infrastruktur und API bereitstellen möchte. 

Das ist in der Tat eine andere Story als ich zunächst dachte. Was ebenso in keiner Weise die letzten Tage/Wochen für mich erkenntlich gewesen ist, ist die Tatsache dass alles auf dem Standard pubsubhubbub aufsetzen wird und der Gedanke zu App.net auf dem letzten Foo-Camp geboren wurde, dadurch dass er dort die Köpfe hinter pubsubhubub kennelernte und viel über die Idee des offenen Webs gelernt hat.

Pubsubhubub ist in der Geschichte offener Standards sichherlich der mit dem lustigsten Namen und der schnell zu Knoten im Kopf führt beim Versuch es genau zu verstehen, obwohl es ganz einfach ist – man muss nur wissen: pubsubhubbub sorgt einfach dafür, dass in Echtzeit mehrere verteilte Systeme darüber informiert werden, wenn es was Neues gibt.

Konkreter: auf Basis von App.net können jetzt Entwickler eigene Applikationen entwickeln, die darauf basieren, dass es eine asynchrone Kommunikation gibt. (übersetzt: ein Follower System wie bei Twitter)

Stellt euch vor ich entscheide mich dafür Client A zum posten von Status-Updats zu benutzen und @horax Client B. Horax folgt mir. Ich poste etwas in Client A und pubsubhubbub “weiß bescheid” dass Horax mir folgt, aber dafür Client B benutzt und sagt ihm kurz bescheid.

Zack: Horax sieht meine Nachricht in Client B. Fein. Alle sind glücklich und das ganze passiert in de-facto Echtzeit. Sprich Horax sein Client B muss nicht die ganze Zeit nachfragen, ob ich was neues gepostet habe, sondern bekommt aktiv bescheid gesagt. Push statt Pull.

Pubsubhub ermöglicht diese Funktionsweisen in verteilen Systemen und nicht nur innerhalb eines geschlossenen Systems. Unterschiedliche Anwendungen können sich gegenseitig bescheid geben, wenn sie pubsubhubub nutzen.

Im Prinzip ist App.net daher nichts anderes wie eine gehostete kostenpflichtige Implementation von pubsubhubbub, die jetzt dafür wirbt, dass Entwickler auf Basis dieser Infrastruktur anfangen Applikationen zu entwickeln.

Das gewählte Revenue Model soll dafür sorgen, dass nicht der gleiche Konflikt wie bei Twitter auftritt und dadurch die API wieder eingeschränkt wird, sondern dieses Ökosystem an sich das tragende Geschäftsmodell ist.

Daltons Annahme für App.net ist jetzt nicht primär, dass es unwahrscheinlich viele Menschen auf der Welt gibt, die nicht so gerne das Produkt für Werbetreibende sein möchten und sich davon lieber für 50 Dollar im Jahr befreien wollen – (und die Wette würde man auch verlieren m.E., da dieses Problem weder schmerzt noch von vielen wahrgenommen wird) – sondern er setzt viel mehr darauf, dass es unwahrscheinlich viele Entwickler gibt, die wie zu früheren Zeiten von Twitter, scharf darauf sind auf Basis einer solchen offenen Infrastruktur tolle Applikationen zu entwickeln, die dann wiederum viele Leute attraktiv finden.

Und wenn ihr jetzt mal einen Blick auf Github werft, scheint er was die Annahme angeht auf einem gutem Weg zu sein, denn ich zähle dort aktuell weit über 50(!) eingetragene Apps, die gerade auf Basis von App.net entwickelt werden.

Spannend ist jetzt die Frage: wird eigentlich für den User eine Applikation auf Basis von App.net immer kostenpflichtig bleiben?

Die Antwort gibt Dalton aktuell laut meine Rechecher noch nicht, ich wäre aber mal so frei eine Vermutung anzustellen: “Nicht unbedingt.”

Er will ein Business aufbauen, was die Infrastruktur verkauft und er vergleicht sich in dem Interview bei TWIG sogar eher mit einem ISP.

Ich halte es daher für hoch wahrscheinlich, dass es in Zukunft – auch, aber nicht nur – Modelle geben wird, wo App Entwickler die Kosten für die Nutzung der Infrastruktur zu 100% tragen werden und diese Kosten beim Nutzer letzten Endes gar nicht ankommen (zumindest mal nicht plump als jährliche Nutzungsgebühr), sondern diese Kosten durch andere in der App verankerten Revenue Streams gedeckt werden könnten.

Und da würde ich mal auf die Kreativität von Gründern setzen, so dass es nicht zwingend wieder Werbung sein muss ;)

Es geht primär um die Beziehung zwischen Entwickler und App.net – weniger um die Beziehung zwischen App-End-Nutzer und App.net – und das ist auch gut so, um der Sache eine Chance auf Traktion zu geben.

Wenn andere werbefreie Dienste auf Basis von kostenpflichtigen App.net Accounts für Nutzer enstehen, die so attraktiv sind, dass Nutzer dafür gerne zahlen – great! Mehr Revenue für alle, wenn es ein gutes Revenue Sharing Modell geben wird. (ist wohl angedacht)

Ich denke aber, dass stellt eher ein Problem für das Wachstum und die notwendige Traktion des gesamten Öko-Systems dar.

Ich muss sagen, ich finde die Situation aktuell wirklich spannend! Denn bisher ist es niemandem wirklich gelungen ein verteiltes Ökosystem auf Basis eines offenen Standards wie pubsubhubbub aufzubauen, so dass Apps eine solche Infrastruktur wirklich nutzen könnten. (siehe status.net aka identi.ca oder andere Ansätze)

Und wenn man den Gedanken konsequent fortführt heißt dies auch, dass App.net auch durchaus Konkurrenz bekommen könnte und nicht der einzige Service-Provider für Entwickler für diese Art von Infrastruktur bleiben muss.

Ich kann mir daher durchaus vorstellen, dass der Schritt zu App.net zur richtigen Zeit kommt und eine Traktion durch Third-Party Apps gewinnen könnte, die ausreicht so dass wir Apps sehen werden, die wir mögen zu nutzen – die dann auch wohlmöglich gar nicht so unmittelbar in Konkurrenz zum existierenden Twitter stehen müssen.

Um mal ein konkretes Beispiel zu machen – und vorweg klarer Disclaimer: d.h. jetzt nicht, dass wir das machen werden, es ist jetzt nur eine einfache Möglichkeit, das ganze Potential hinter App.net zu verdeutlichen:

Wir bei The Otherland Group (arbeite zur Zeit halbtags bei Pixelpark und bin mit 250% meiner restlichen Zeit als Co-Founder mit Markus Breuer zusammen unterwegs) arbeiten doch gerade an einem Dienst der thin.gs heißt.

Was jeder über diesen Dienst offiziell schon weiß – auch ohne Teil der Alpha gewesen zu sein – ist, dass man mit thin.gs seinen Freunden mitteilen kann, welche Dinge man besitzt, gekauft hat, sich wünscht, generell liebt oder selbst erstellt hat.

 

Ich könnte mal stark vereinfacht sagen, dass das ein sehr spezifisches Status-Update ist, was man bei thin.gs über seine Beziehung zu Dingen erstellt, um damit seinen “Material Graph” aufzubauen (und durch die Strukturiertheit dieser Aussage, kann man dann mit Hilfe von thin.gs mehr über diese Dinge, sich, seine Freunde und die Welt lernen, was super spannend ist – aber dazu mehr ein andermal) 

Wir könnten jetzt überlegen thin.gs in ein zukünftig entstehendes App-Öko System auf Basis von App.net über die kostenpflichtige API zu integrieren, um z.B. für ein sehr eng integriertes Messaging zwischen Nutzern zu sorgen.

Jeder Nutzer kennt den Mechanismus um mit @pixelsebi mich auf Twitter zu adressieren. Dieses Meme wird gerade von Moped in einem anderen Kontext adaptiert. Dieses wird sicher auch innerhalb von App.net implementiert werden.

Wir könnten dies bei thin.gs genauso übernehmen und wenn ich z.B. dem guten @horax in thin.gs über das “@”-Symbol adressiere, macht auch sein dann bevorzugter App.net Client “PEEEP” und zeigt ihm an, dass er auf thin.gs auf diese Art und Weise angesprochen worden ist und kann aus seinem Client direkt antworten, ohne direkt die thin.gs App aufzurufen.

Zwei unterschiedliche verteilte Syteme (Apps), die gewisse Muster teilen – in dem Fall “Status-Updates” und Kommunikation via “@”-Symbol – könnten via pubsubhubbub – kostenpflichtig bereitgestellt von App.net – miteinander kommunizieren. 

Ob wir das wollen und gut finden, sei jetzt mal dahingestellt – aber es ginge :) und das soll zur Verdeutlichung des Potentials reichen ;)

Ich hoffe ich könnte damit ein wenig mehr Licht ins Dunkle bringen und einfach klar machen, welches Potential hinter App.net steckt.

Trotzdem gibt es sicherlich noch viele Fragezeichen und man sollte niemals vergessen, dass Dalton von Anfang an klar gemacht hat, dass es ein langer Prozess sein wird, dieses Öko-System ans Laufen zu bekommen.

Aber ich denke die richtige Zielgruppe hat er erstmal erreicht und es wird fleißig überlegt und gebastelt, was man damit jetzt alles machen kann.

Ich wünsche auf jedenfall viel Erfolg!

 

Permalink | Leave a comment  »

The Restless Mind

am 19.08.2012

Social

Hinterlasse eine Antwort