tiny little gizmos

facebook vs. StudiVZ

Mal abgesehen, daß ich weder das eine, noch das Andere mag – ich frage mich, welche von den Firmen dreister ist:
Die Firma, die das Produkt einer anderen 1:1 kopiert, oder die Firma, die einen Konkurrenten verklagt, weil sie selber (in Deutschland) nix auf die Reihe bekommt.

Ich meine: klar ist StudiVZ ursprünglich ein facebook-Clone. Na und? Das ist Für StudiVZ zwar irgendwie peinlich, aber letztlich völlig egal. Den Erfolg haben sie nicht dadurch erreicht, daß sie genauso aussehen, sondern, daß es ihnen gelungen ist, den deutschen Markt in Rekordtempo zu besetzen. Und das hat herzlich wenig mit dem Layout der Site zu tun, sondern mit der Art, wie StudiVZ damals unter den Studenten bekannt gemacht wurde.

Mal abgesehen davon: Die ursprüngliche Version von Facebook hat ja auch nicht gerade durch besonderes Design oder innovative Features bestochen. Ich wüsste jedenfalls keine Funktion, die nicht vorher schon in anderen Communities vorhanden war. In einem amerikanischen Artikel, in dem über StudiVZ hergezogen wurde (sorry, Quelle finde ich nicht mehr) sind einige der “innovativen” Features aufgezählt, die kopiert wurden. Darunter fand sich zum Beispiel auch eine “Nachrichtenwand”.

Ein supercooles Feature! Hatten etliche BBS (Mailboxsysteme in der Vor-Internet-Ära) in den späten 80ern auch schon. Ach ja – extern eingebundene Doorgames um die User zu unterhalten übrigens auch. Soviel zum angeblichen “geistigen Eigentum”.

Was bleibt? Facebook klagt in den USA. StudiVZ ist aber in Europa aktiv. Hier hätte eine Klage aber wohl kaum eine Chance, denn es wurde keine Software kopiert. Nachprogrammieren ist völlig legal. Man könnte letztlich wohl höchstens auf Verletzung des Urheberrechts bzgl. des Designs klagen, aber damit kann man keinen großen Schaden anrichten.

Stellen wir uns aber mal eben vor, daß Facebook mit seinem Vorstoß wirklich durchkommt und StudiVZ ernsthaft beschädigt. Werden die dann “heimatlosen” User dann in Scharen zu Facebook wechseln? Ich glaube nicht. Warum sollten sie? Es gibt so viele Alternativen.

In meinen Augen ist das nur peinliches Sommertheater – für beide Firmen.

Nachtrag:

Eine interessante juristische Fussnote zum Thema Gerichtsstand und Eigentümerhaftung im Fall StudiVZ ist in einem Kommentar bei heise online zu finden

Gestern ICQ weg – heute update

Gestern hat ICQ mal wieder das Protokoll geändert und als Nutzer von anderen Clients stand man plötzlich draussen – wie z.B. mit Adium (für Apple Mac). Seit heute morgen gibt es die aktuelle Version 1.2.6 und alles läuft wieder.

Das war ein fixer Fix!

zzap auch für das iPhone?

Eigentlich isses ja ein bischen bescheuert: Fast niemand in Europa hat ein iPhone – warum sollte man dan auch noch zzap daran anpassen?

Vielleicht, weil ich auch ein bischen bescheuert bin? Oder neugierig? Oder weil ich einfach gerne mal neue Sachen ausprobiere? Oder weil ich damit die VC’s im Valley blenden will? Ich weiss es nicht.

Aber ich habe gestern mal ein wenig rumgespielt und habe eine Seite nutzbar gemacht. So langsam bekomme ich ein Gefühl für die Philosophie dahinter. Erinnert mich übrigens ein bischen an WAP1.1 mit den Decks. Hier sind es dann eben mehrere Listen in einem Dokument.

Online ist aber noch nix davon. Ich bin mir noch nicht sicher, wieviel Aufwand das wirklich wird. Wenn es lange dauert, lasse ich erstmal die Finger davon. Web/mobile/iPhone und dann noch in zwei Sprachen ist schon etwas Arbeit. Dabei fehlt momentan noch Funktionalität. Die ist eigentlich erstmal wichtiger.

Ich kann mich auch nicht dazu durchringen, die passende Hardware zum Testen zu besorgen – bei diesen besch…eidenen Vertragskonditionen, Netlock-Spielchen usw. Egal, ich behalte das mal im Auge. Ein Preview sieht übrigens so aus:

zzap auf iPhone

zzap iPhone Preview

1000 mal gesperrt…

Neulich habe ich einige follower auf twitter geblockt – Leute die ich nicht kenne und die schon über 10.000 anderen folgen – was soll denn sowas? Dann war mein Account für einige Tage clean und heute ist die Anzahl meiner follower von 10 auf 16 hochgeschnellt.

Ist ja toll, daß mir so viele Leute auf twitter folgen wollen. Ich frage mich bloß – wozu? Spannend auch, daß es sich überwiegend um attraktive junge Frauen handelt…

Kann sein, daß ich irgendwie zu langsam im Kopf bin. Ich verstehe den Sinn nicht ganz. Glauben die, daß ich ihnen auch folgen und mich dann zuspammen lasse? Oder geht es darum, soviele public messages wie möglich abzugreifen? Und was macht man dann damit? Ich denke, daß es sich bei den drei jungen Damen von heute tatsächlich um Bots handelt, die Nachrichten von anderen Usern recyclen, um eine eigene Aktivität vorzutäuschen. önnte man mal eine interessante Studie draus machen, wie “echte” User auf sowas reagieren. Das bringt mich zu folgenden Fragen:

  • Sind die User seit ELIZA klüger geworden?
  • Ist es wirklich nicht mehr möglich, offene Systeme zu betreiben, ohne gleich zugemüllt zu werden?

live zzapping

Das Wochenende war nicht nur sehr schön, sondern auch ein erfolgreicher Test der nächsten Version von zzap. Aufmerksame Leser dieses Blogs werden an der rechten Spalte bemerkt haben, daß ich meine Kurzstatements nicht mehr per Twitter verschicke, sondern über den neuen Prototypen von zzap.

Während ich in Ahrenshoop und auf dem Darß die tolle Landschaft genoß, habe ich viel mit dem Handy fotografiert und ein paar Bilder mitsamt Kurznachricht verschickt. Die Textnachrichten werden auch an twitter weitergereicht und sind so auch meinen followers dort zugänglich, aber die Fotos entgehen ihnen dort. Die Software habe ich erst am Freitag abend installiert und ich war gespannt, ob alles funktioniert. Wie man am Blog sehen kann – es funktioniert.

Microblogging Skalierungsprobleme

In letzter Zeit wird Twitter recht viel abgewatscht, weil der Dienst ziemlich instabil läuft. Das ist zwar weniger wichtig, solange man “nur” private Statements wie “Bin verkatert – erstmal’n Käffchen” schreibt, aber der Dienst wird zunehmend auch für ernsthaftere Anwendungen genutzt. Zum Beispiel für Terminhinweise von Veranstaltern oder sonstige Veröffentlichungen.

Kurz: Twitter hat alle Hände voll zu tun, den Dienst stabil und skalierbar zu machen. Von Außenstehenden wurde viel über die Ursachen der Probleme spekuliert. Die beliebtesten Vermutungen: Ruby on Rails skaliert nicht richtig und der Hoster bekommt Last und Traffic nicht in den Griff. Auf dem Entwicklerblog stellt Twitter mit dem Artikel “Twittering About Architecture” nun klar, daß beides nicht die Ursachen sind, sondern grundlegende Fragen der Softwarearchitektur gelöst werden müssen. Zudem ist die Entwicklungsabteilung personell unterbesetzt.

Eine detaillierte Beschreibung der komplexen technischen Herausforderungen für einen Microblogging-Dienst hat Eran Hammer-Lahav in einer kleinen Artikelserie “Scaling a Microblogging Service” beschrieben. Er sah sich bei seinem eigenen Start-up Nouncer mit ähnlichen Herausforderungen konfrontiert und ist daher kompetent. Er unterteilt den Dienst unabhängig von der jeweiligen Implementierung in zwei Bereiche: delivery und retrieval.

Delivery
Hereinkommende Nachrichten zu nehmen und per Instant Message, SMS oder Email an diejenigen weiterzuverteilen, die Follower sind, ist zwar nicht völlig trivial, aber dennoch vergleichweise einfach und es lässt sich leicht skalieren.

Retrieval
Das Problem und die Komplexität steckt in der Abfrage. Hammer-Lahav schreibt dazu:

Unlike webmail services where refreshing a user’s inbox only queries a very simple data set (is there anything new in MY inbox?), refreshing a user’s home page on Twitter queries a much more complex data set (are there any new updates in ALL my friends’ pages?) and the nature of the service means that the ratio of reads to writes is significantly different from most other web services.

Eigentlich sind die Abfragen ja noch komplexer, etwa “Gib mir die letzten 20 Nachrichten von allem meinen Kontakten die nicht gesperrt sind und die mich nicht gesperrt haben, sowie alle privaten Nachrichten an mich, absteigend sortiert nach Uhrzeit”. Das funktioniert tadellos, sonlange es nur einige tausend User und einige -zig oder hunderttausend Nachrichten handelt. Die große Menge ist das Problem: partitionierte Datenbanken, was und wie ist zu indizieren, was kann gecached werden etc.

Der Autor vertritt weiterhin die Meinung, daß ein Push-Service mit Inboxen ähnlich wie E-Mail das Problem genausowenig löst, wie ein (in letzter Zeit ja häufig diskutierter) verteilter Service; ja im Gegenteil die Probleme dann nur umso größer würden. Um das zu verdeutlichen entwirft er ein Szenario, in dem 3 User bei verschiedenen Providern (twitter, pownce und Jaiku) sind.

Wirklich interessant: Das nämlich genau das Szenario, für das ich seit kurzem ein simples Push-Protokoll entwerfe. Der Autor kommt auch tatsächlich zu den selben Punkten wie ich, z.B. echte (lokale) Accounts und virtuelle (remote) Accounts. Allerdings bewerte ich sie etwas anders.

Richtig ist: Bei einer zentralen Lösung hat twitter mit einigen Millionen Usern das Skalierungsproblem. Bei einer dezentralen Lösung hat ein Service mit einigen Millionen Usern immer noch dasselbe Skalierungsproblem plus noch einigen anderen Fallstricken, weil er von (vielen) externen Services abhängt.

Aber: Das Problem wird in der Praxis kaum noch auftauchen, wenn die meisten User auf kleineren System sind oder sogar einen eigenen Server betreiben, wie es heute bei E-Mail der Fall ist. Es interessiert mich einfach nicht, wenn Yahoo, GMX, MSN oder wer auch immer ein dickes Problem mit seinen Mailservern hat – ich bin trotzdem per Mail erreichbar. Twittern kann ich aber nur, wenn twitter funktioniert.

Twitter Extender benötigt?

Interessant. Je beliebter Twitter wird, desto mehr stören sich manche Nutzer an den Beschränkungen. Ich bin gerade durch eine Nachricht von Nicole Simon auf den Dienst TwitterBudgi aufmerksam geworden. Offensichtlich vermissten die Gründer so einige Features, die sie nun selber nachbauen:

  • Nachrichten mit mehr als 140 Zeichen Länge
  • Kein Dateitransfer
  • Keine Gruppenbildung
  • Fehlende Jabber-Einbindung (m.E. hat Twitter aber eine XMPP-Schnittstelle)
  • Erinnerungen

Interessant finde ich das vor allem deshalb, weil einige dieser Funktionen und noch einige mehr in meinem ersten Prototypen von zzap enthalten waren. Das war 2006 kurz bevor Twitter online ging. Der Grund dafür war die Erkenntnis, wofür mobile Kommunikation im Wesentlichen genutzt wird:

  • Verabreden
  • Verabredungen ändern (!!!)
  • Soziales Geplauder (“Ich muß Dir schnell mal was erzählen…”)
  • Kurze Statusangaben (“Bin in 15min. zuhause.”)
  • Ortsangaben (“Bin in Hamburg auf dem Kongress”)

Dementsprechend hatte ich Features vorgesehen, die sich auf schnelle, kurze Nachrichten, Gruppenbildung, Zeit- und Ortsangaben konzentrierten. Ich hatte einige Tags für die Kurznachrichten vorgesehen: ‘#’ für Orte, ‘@’ für Personen ‘!’ für Zeitangaben – kommt das jemandem bekannt vor? ;-). Man konnte Bilder und Kartenausschnitte an die Nachrichten hängen, um den Kumpels zu zeigen, wo man ist und warum es da gerade so toll ist…
Theoretisch war das alles sehr toll, es gab nur ein Problem:

Das war den Testpersonen zu komplex. Sie haben es entweder nicht verstanden, oder keine Lust das alles zu erlernen.

Und dann kam Twitter und konnte – fast nichts. Und genau das war der Urknall für das Multichannel – Groupmessaging, oder Microblogging, oder wie immer man das nennen will. Und jetzt kommt ein Service, der auf Twitter aufsetzt und all diese Features nachrüsten will? Ich bin da sehr, sehr skeptisch…

Nochmal: Twitter dezentralisieren

Dave Winer hatte sich ja bereits Gedanken zu einem dezentralen Twitter gemacht. Er ist absolut dafür. In seinem Artikel “Why decentralizing Twitter is hopeless” zitiert er nun echovar. Die Aussage ist sinngemäß, daß es aussichtslos sei, twitter dezentralisieren zu wollen, weil man ja auch New York nicht einfach an einer anderen Stelle aufbauen könnte.

Was zum…

Wer redet denn hier von physischen Städten? Twitter ist keine Stadt und ehrlich gesagt nicht mal eine Community, sondern ein Kommunikationskanal. Und natürlich ist es überhaupt kein großes Problem, so etwas wie Twitter zu dezentralisieren. Das funktioniert mit Websites, Newsservern, E-Mail und so weiter ja schließlich auch ganz hervorragend. Man benötigt dazu vor allem ein vernünftiges Protokoll und dann kann es losgehen.

Ich würde sogar weiter gehen: Es ist nicht nur möglich, sondern sogar unabdingbar Twitter zu denzentralisieren. Stellt Euch vor, wir wären alle bei einem einzige Mailprovider. E-Mail hätte sich nie auf so breiter Front durchgesetzt.

So was…

Twitter dezentral

Twitter hat ein Problem: Entweder es setzt sich nicht durch – dann ist die Firma wertlos. Oder Der Dienst setzt sich durch, wird dann aber durch dezentrale Lösungen substituiert. Die Forderderung nach letzterem wird von einigen Vordenkern bereits seit einiger Zeit geführt, in letzter Zeit erhält diese Diskussion langsam Schwung, wie man an dem Artikel “Twitter Can Be Liberated – Here’s How” auf Techchrunch sehen kann.

Ein offenes Twitter auf der Basis von XMPP (Jabber, Google Talk, iChat) hatten Marco und ich uns auch schon mal im April 2007 überlegt, als ich Ihn in San Francisco besucht habe. Die Frage ist – warum haben wir es nicht einfach gemacht? Die Antwort ist: Weil wir beide andere Dinge zu tun haben.

Boy – that’s LAME!!!

Okay, also fange ich mal an, mein bestehendes zzap zu strippen. Bin gerade bei einer neuen extrem reduzierten Version. Komplett neu in PHP5 aufgesetzt. Hat jemand Lust mitzumachen? Infos folgen.

« Previous PageNext Page »