Was 1&1 mit dem SmartPad falsch macht

Update: Google verwehrt Tablet-Herstellern noch den Zugang zum Android Market. Siehe diesen Artikel zum Thema. /Update

Im vorletzten Artikel schrieb ich über Kooperationen und das Netzwerk, das sich oft gegen die Hierarchie durchsetzt. Kontrollaufgabe von Unternehmen als gewinnträchtige Strategie:

Da solche Kooperationen im großen Stil oft in der dadurch entstehenden Gesamtheit wettbewerbsfähiger sind als die rein hierarchischen Alternativen, lösen sie diese oft ab. Anders gesagt: Nicht immer aber immer öfter schlägt das Netzwerk die Hierarchie. Aufgrund gesunkener Transaktionskosten.

[..]

Eine kurzfristige Sichtweise wird im Web stärker bestraft als in der Regel in der analogen Welt: Auch das ist eine Folge der Netzwerkeffekte, die zu exponentiellen Wachstumsraten führen.

Man könnte auch sagen, dass diejenigen, die niemanden auf ihren Schultern stehen lassen wollen, sich über die Opportunitätskosten dieser Entscheidung nicht im Klaren sind.

Im letzten Artikel hatte ich 1&1 und das SmartPad angesprochen. Dort findet man genau diesen falschen Ansatz vor. Quasi eine Fallstudie für das oben Beschriebene:

Deshalb ist es eine, vorsichtig ausgedrückt, eigenwillige Entscheidung von 1&1, das eigene Tablet vom AppMarket für Android abzuschneiden. Der Grund dafür ist zwar offensichtlich (Kontrolle des Distributionskanals für Applikationen), aber das macht es nicht minder widersinnig:

Das 1und1 SmartPad kommt mit einem 7 Zoll Touchscreen, der resistiv ist, einen 500MHz ARM11 Prozessor, 1GB Flashspeicher und Android 1.6 ohne Google App Store. Dafür ist ein 1und1 App Store vorhanden, in dem anfangs rund 100 Apps sein sollen (verglichen mit 50.000 Google Market Apps und 200.000 iPhone Apps lächerlich).

1&1 setzt auf die (eigene) Hierarchie, statt auf das Netzwerk der verteilten Plattform Android.

1&1 will auf seinem SmartPad die Kontrolle über den App-Distributionskanal halten. Was auf erste, oberflächliche Sicht wirtschaftlich sinnvoll erscheint, wird unsinnig, wenn man den Kontext, den Markt rund um das SmartPad betrachtet.

Um die Kontrolle zu erhalten, muss 1&1 das SmartPad vom Android-AppMarket abschneiden. Essentiell bedeutet das, dass das SmartPad kaum Applikationen zu bieten hat. Ein wesentlicher Wettbewerbsnachteil. Attraktiv wird das SmartPad damit nicht.

Android-basierte Tablet haben gegenüber Tablets mit anderen Betriebssystemen (bald kommend WebOS, oder auch neben Android noch andere auf Touch-Tablets spezialisierte Linux-Distributionen) vor allem einen Vorteil: Sie können auf das bereits große Angebot der Android-Applikationen zugreifen.

Die Vorteile einer verteilten Plattform wie Android sind oft auch gleichzeitig die Nachteile aus anderer Perspektive: Ein wesentlicher Vorteil von Android sind die bereits vorhandenen Apps. Natürlich bedeutet das nun, dass der Tablet-Hersteller auf die Kontrolle über den Distributionskanal der Applikationen verzichten muss, um diesen Vorteil zu nutzen. Und natürlich bedeutet es, dass die Android-Tablet-Hersteller andere Wege finden müssen, um sich voneinander abheben zu können. Aber nur mit dem Zahlen dieses Preises kann man von Android wirklich umfänglich profitieren.

Die Alternative ist, ein unattraktives Tablet anzubieten.

Bei 1&1 hat man diese Opportunitätskosten für die Entscheidung zur absoluten Kontrolle lediglich noch nicht realisiert. Es wird sicher noch andere auf Android setzende Tablet-Hersteller in den nächsten Monaten geben, die den gleichen Fehler machen. Gewinnen werden die anderen.

Android-Telefone und iPhone sind ‘App-Phones’

Treffende Bezeichnung für Android und iPhone, die David Pogue von der New York Times gefunden hat:

“Smartphone” is too limited. A smartphone is a cellphone with e-mail — an old BlackBerry, a Blackjack, maybe a Treo. This new category — somewhere between cellphones and laptops, or even beyond them — deserves a name of its own.

I invited suggestions on Twitter. The best came from @mentalworkout: “app phone.” Bingo. Apps distinguish iPhonish phones from mere smartphones, so “app phones” it is.

iPhone und Android kann man tatsächlich nur bedingt mit Smartphones vergleichen, weil die umfangreichen App-Ökosysteme ein nicht zu unterschätzender Bestandteil der Mobiltelefone sind. Sie sind sogar das definierende Merkmal.

Das Gleiche gilt in weiten Teilen auch für Tablets: It’s the apps, stupid.

Deshalb ist es eine, vorsichtig ausgedrückt, eigenwillige Entscheidung von 1&1, das eigene Tablet vom AppMarket für Android abzuschneiden. Der Grund dafür ist zwar offensichtlich (Kontrolle des Distributionskanals für Applikationen), aber das macht es nicht minder widersinnig:

Das 1und1 SmartPad kommt mit einem 7 Zoll Touchscreen, der resistiv ist, einen 500MHz ARM11 Prozessor, 1GB Flashspeicher und Android 1.6 ohne Google App Store. Dafür ist ein 1und1 App Store vorhanden, in dem anfangs rund 100 Apps sein sollen (verglichen mit 50.000 Google Market Apps und 200.000 iPhone Apps lächerlich).

(via)

Tabletmarkt: Multihoming hilft Amazons Kindle gegen iPad

Om Malik hat eine interessante Beobachtung bezüglich des Amazon-E-Readers Kindle und dessen iPad-Applikation gemacht:

The day I first laid hands on Apple’s iPad I banished my Amazon Kindle to the back of the proverbial drawer. And yet, I have been spending, on average, about $10 every 3-5 days on Amazon’s site buying a book to read using the Kindle application on the iPad.

[..]

This is a big advantage for Amazon, for as more people start living multidevice lifestyles, such cross-platform availability of content will increasingly become a big deal. Unlike Amazon’s Kindle store, iBooks is going to be limited to the iPad/iPhone platform — which is not good enough for me. I like the flexibility of the Kindle app, even if it offers books to me in somewhat of a less attractive format. In other words, Amazon should be thinking about Kindle as a platform that leverages other people’s hardware.

Mit Multihoming kann Amazon seinen Kunden etwas bieten, was Apple nicht bieten kann. Apple will schließlich seine iOS-Plattform stärken. Es wird iBooks also genau so wenig für Nicht-Apple-Produkte öffnen, wie es das mit itunes macht. (Palm zum Beispiel, das seine WebOS-Produkte an itunes andockte, wurde proaktiv von Apple immer wieder ausgesperrt.)

Gleichzeitig ist es für Apple nicht sinnvoll, Angebote wie Amazons- Kindle-Applikation auszuschliessen: Zwar würde das kurzfristig zur Stärkung von iBooks führen, aber langfristig würde es die iOS-Plattform schwächen. Wenn die Kindle-Applikation auf allen anderen Tablet-Plattformen verfügbar sein wird aber nicht auf iOS, würde das iOS schwächen. Besonders dann, wenn Apple jede Applikation ausschließen würde, die mit einem Apple-Produkt konkurriert und Multihoming über die Plattformen betreibt.

Apple muss also ein Stück weit damit leben, mit Amazon und anderen auf der eigenen Plattform zu konkurrieren.

Der Vorteil für Apple als Plattformprovider: Bessere Integration der eigenen Angebote in die Plattform selbst.

Der Nachteil: Kein Multihoming, sprich keine Bereitstellung der Angebote auf anderen Plattformen – die Plattformprovidersteuer. (Ähnliches Szenario bei Twitter: Twitters offizieller iPhone-Client wird aus den gleichen Gründen keine anderen Microblogging-Dienste oder ähnliche Angebote unterstützen, was den Client selbst in eine schwierige Konkurrenzsituation bringen wird.)

Natürlich hält Apple nichts davon ab, iBooks irgendwann auf Android- bzw. Chrome-Tablets oder WebOS-Tablets etc. anzubieten, aber mittelfristig ist das eher unwahrscheinlich.

Tatsächlich hängt das von der Marktentwicklung auf dem Tabletmarkt ab:

Szenario A: Hoher Marktanteil von iOS, geringe Fragmentierung. Apple kann sich auf iOS konzentrieren. Amazon Kindles Multihoming ist eine wünschenswerte Funktion, aber kein Muss für die Konsumenten.

Szenario B: Relativ hohe Fragmentierung des Tablet-Marktes mit verschiedenen Betriebssystemen: Multihoming wird von Konsumenten vorausgesetzt. Das bedeutet einen wesentlichen Nachteil für vertikal integrierte Plattformprovider wie Apple. Apple müsste dann iBooks etwa für Android und andere Tablet-OS bereitstellen, um konkurrenzfähig zu bleiben. In etwa so, wie heute itunes für Windows bereitgestellt wird.

Warum würde in diesem Szenario Multihoming vorausgesetzt werden? Weil Tablets relativ günstig sein werden und bei hoher Fragmentierung die Konsumenten zwischen den OS-Varianten wechseln wollen, ohne ihre Medienbibliotheken zu verlieren.

Das Berliner Startup txtr verfolgt mit seiner iOS-Applikation und seinem (seit längerem) angekündigten E-Reader eine ähnliche Plattformstrategie wie Amazon, die entsprechend erfolgversprechend klingt. Auf txtr vom User hochgeladene oder direkt auf txtr bereitgestellte Inhalte sind auf der Website selbst, der iOS-Applikation und dem künftigen txtr-E-Reader, so er denn irgendwann kommt, abrufbar.

iPhone4-Apps sind iPad-kompatibel und umgekehrt

Dem speziellen Retina-Display sei Dank: iphone4Speziell für das iPhone 4 geschriebene iPhone-Apps werden auf dem iPad nutzbar sein. Ebenso werden iPad-Apps auf dem iPhone 4 laufen. Macnotes.de:

Die Auflösung des iPhone 4 ist mir 960×640 Pixeln die höchste auf dem Gebiet der Smartphones derzeit, und insgesamt viermal so groß wie die des iPhone 3GS. Die angepasste Auflösung des Retina-Displays hat einen Vorteil für App-Entwickler: Für das iPad entwickelte Apps passen relativ unproblematisch auf das Display des iPhone 4, im Umkehrschluss laufen iPhone 4-optimierte Anwendungen zumindest in Sachen Auflöung auch auf dem iPad.

(Hervorhebung von mir)

Herkömmliche iPhone-Applikationen laufen zwar theoretisch auch auf dem iPad, sind in der Regel aber entweder unnutzbar (in ihrer Original-Größe) oder unansehnlich (mit Pixel-Verdoppelung) und damit nutzlos.

Die Verbindung zwischen Retina-Display des iPhones und iPad-Displaygröße ist deshalb insofern wichtig, als das Fragmentierung der Plattform zu erheblichen Zusatzkosten bei den Entwicklern führen kann.

Die Android-Plattform, die auf vielen verschiedenen Modellen mit unterschiedlichen Ausstattungen und Display-Größen vertreten ist und zusätzlich noch mit unterschiedlichen OS-Versionen auf den Geräten zu kämpfen hat, wird stark von Fragmentierung bestimmt. Das ist ein Problem für das App-Ökosystem:

However, with all these phones, such as the Nexus (3.7 inch screen), the Droid (480 x 854 screen), the HTC Evo 4G (4.3 inch screen), the Dell Streak (5 inch screen), and many many more, each with its own unique feature set, how is a developer expected to make an Android app? Which phone should he/she make it for? What processor should they optimize their app to work with? What kind of resolution should they assume their users will have? It is impossible for developers to have one app that works on all Android phones.

Die Frage bleibt allerdings, was passiert, wenn eine zukünftige Version des iPads ebenfalls mit dem Retina-Display ausgestattet wird. Es ist unvermeidlich, dass mit einer Ausdifferenzierung des iOS-Systems verschiedene Geräte unterschiedliche Angebote seitens der Entwickler notwendig machen.

Eins dürfte aber sicher sein: Das Apple-System wird nicht so stark fragmentieren wie Android. Das liegt schon allein in den unterschiedlichen Ansätzen begründet.

iPad: Native Apps vs. HTML5

Auf Exciting Commerce habe ich über die Entscheidung bei der Entwicklung für das iPad zwischen nativen Applikationen und der HTML5-Variante geschrieben:

Die Vorteile von auf Multi-Touch-Screens optimierten Webapplikationen, die auf HTML5 aufsetzen:

Der gewichtigste Vorteil ist Kosteneinsparung. Da der HTML5 Standard sowohl von Apple als auch von Google unterstützt wird, werden HTML5-Applikationen sowohl auf dem iPad als auch auf den bald auf den Markt kommenden Android-Tablets laufen.

Suboptimale Plattform-Strategie von Twitter ist gut für den Rest des Webs

twitter

Die Entscheidung von Twitter, im eigenen Ökosystem zu wildern, um umfänglich auf Werbung setzen zu können, zwingt auf Twitter setzende Drittanbieter zum Multihoming als Ausdifferenzierungsmerkmal. Das sind gute Nachrichten für Facebook, Google Buzz und auf offene Standards setzende Angebote wie StatusNet. Und für die Nutzer.

Inhalt:

Twitter setzt auf Werbung

Vor knapp zwei Monaten begann Twitter mit dem Kauf von Tweetie seinen Strategieschwenk, den ich seinerzeit als eine Fehlentscheidung bezeichnete.

Mittlerweile hat Twitter sein geplantes werbebasiertes Geschäftsmodell bekanntgegeben: Es beginnt mit “Promoted Tweets” von zahlenden Kunden, welche in den Suchergebnissen hervorgehoben werden (und entsprechend gekennzeichnet). Das (halbherzige) Vorgehen gegen Dienste, die Werbung direkt in Streams von Twitter-Nutzern verkaufen, deutet auf eine Ausweitung des Geschäftsmodells Werbung hin.

Auch der Kauf von Tweetie deutet auf eine Ausweitung der Werbung hin die auch das Frontend mit einbezieht. Dass Twitter nicht gleichberechtigt auf verschiedene Einkommensströme setzen wird, sondern Werbung in den Vordergrund rückt, legt auch ein Interview mit dem Ex-Twitter-Entwickler Alex Payne nahe. Dieser sagt:

The move toward making advertising a core part of the business makes a lot of sense for the company’s future and profitability, but from my perspective, that’s one of the things that let me know that it was time for me to leave … because I wasn’t interested in working for an ad company. For a long time, the promise at Twitter was that we were going to look at different ways of making money, and to some degree I feel that hasn’t happened .

(Hervorhebung von mir)

Dass Twitter Werbung als einen wichtigen Standpunkt einsetzt, ist nicht verwunderlich. Wenn das Unternehmen der hohen Bewertung durch seine Investoren gerecht werden will, muss es jede Art von Einkommensstrom in Betracht ziehen.

Die Art und Weise, wie man dies angeht, ist aber strategisch unklug und deutet mittel- bis langfristig auf Probleme, die auf Twitter zukommen – was wiederrum gut für den Rest des Webs ist.

Plattform-Strategien: Twitter vs. Ökosystem

Twitter hat mit der Übernahme von Tweetie ein klares Zeichen in die Entwickler-Community gesendet: Künftig ist keine Kategorie vor möglichen Übernahmen sicher. Ich schrieb seinerzeit:

Wenn ein Plattformanbieter eine Applikation selbst anbietet, konkurrieren die Drittanbieter in dieser Kategorie mit einem übermächtigen Gegner. Hinzu kommt: Twitter braucht nur einen iPhone-Client – dieser Bereich hat sich also geschlossen. Mit jeder Übernahme einer Applikation beendet Twitter mehr oder weniger diese Kategorie[..]

Twitters Plattform wird durch diesen Schritt nicht attraktiver, eher im Gegenteil.

Twitter hat mit dem Kauf von Tweetie mehr noch als damals mit der Übernahme von Summize gezeigt, dass sich das Verhältnis von Twitter zu seinem Ökosystem ändert (denn die Hauptkategorie für Twitter-apps waren immer Clients).

GigaOm hat einige Investoren zur Attraktivität der Twitter-Plattform befragt. Die Ergebnisse bestätigen meine Analyse:

Many of them, who had themselves invested in Twitter-related startups, said they were stepping back from the Twitter ecosystem, even if only momentarily. They said that while they understood some of the onetime shifts that Twitter has made, and the necessity for the company to make money, its recent moves had given them reason to pause.

Die gegensätzliche, auf netzwertig geäußerte Annahme, die Übernahmemöglichkeit durch Twitter könnte von Entwicklern wohlwollend angenommen werden, hat sich also, wie erwartet, nicht bestätigt.

Warum bietet Twitter kein offizielles App-Verzeichnis an?

Nach der Übernahme des Tweetie-Clients habe ich über Twitter und das Verhältnis zu seinen Dritt-Anbietern intensiv nachgedacht. In diesem Zusammenhang ist mir wieder etwas eingefallen, das ich schon früher erstaunt zur Kenntnis genommen habe und das so offensichtlich ist, dass es verwundert, dass dies noch nicht von anderen aufgegriffen wurde:

Obwohl Twitter massgeblich von durch die auf die API aufsetzenden Clients und Zusatzdienste groß geworden ist, bietet es kein eigenes offizielles Verzeichnis der Applikationen an.

Das ist außerordentlich bemerkenswert.

Ich beschäftige mich seit einiger Zeit intensiv mit Plattformen im Internet. Eine Konstante bei allen Plattformen ab einer bestimmten Größe von der Plattform selbst und/oder dem Ökosystem ist das Anbieten eines offfiziellen Verzeichnisses von Applikationen. Beispiele:

  • Facebook
  • Salesforce
  • Apples Appstore
  • Android
  • Palm WebOS
  • Anbieter von addon-fähiger Software (Google Chrome, Firefox, Thunderbird, Songbird)
  • usw.

Die Gründe dafür liegen auf der Hand: Ein offizielles Verzeichnis verbessert die Sichtbarkeit der Angebote im Ökosystem; was wiederrum die Attraktivität des gesamten Systems steigern sollte. Zusätzlich ist so ein Verzeichnis für eine Internet-Plattform einfacher umsetzbar als beispielsweise für einen OS-Anbieter wie Microsoft vor dem Internet-Zeitalter:

Je nach Geschäftsmodell kann man der Plattformprovider die Drittanbieter ihre Angebote selbst eintragen lassen. Zusätzlich können Endnutzer mit Bewertungen und Kommentaren helfen, die für sie attraktivsten und damit für das System nützlichsten Angebote sichtbarer zu machen: Jedes Drittanbieter-Verzeichnis eines Plattformproviders bietet die Möglichkeit, nach Nutzerbewertungen zu sortieren. Diese Art der Darstellung des Ökosystems ist erst mit dem Internet möglich geworden.

Twitter, das bereits 2007(!) stolz verbreitete, dass zehn Mal(!) mehr Traffic über die API als über die Site selbst kommt (weitere Zahlen: 75% der Tweets sollen über Applikationen kommen), hat kein Verzeichnis für diesen wichtigen Teil des eigenen Geschäfts. Bemerkenswert. Das Einzige, was Twitter aktuell macht, um Drittanbieter und Nutzer zusammen zu bringen, ist eine willkürliche Auswahl von Angeboten, die einzeln in der Sidebar angezeigt werden:

Über die API wird noch über Twitter verbreitet, über welchem Dienst oder von welchem Client ein Tweet abgesetzt wird. Mehr Sichtbarkeit erhalten Drittanbieter über den Dienst selbst nicht. Dass das Ökosystem rund um Twitter trotzdem florierte, lag vor allem an drei Umständen:

  • Die grundlegende Architektur von Twitter erlaubt das rasche Verbreiten von Informationen. Wenn Nutzer also zum Beispiel einen Client für besonders nützlich empfinden, dann kann dieser über ihre Äußerungen schneller an Verbreitung finden.
  • Das Web außerhalb von Twitter hat sich mittlerweile so weit entwickelt , dass die Dienste außerhalb des Systems, auf dem sie aufbauen, bekannt werden können.
  • Die Twitter-API hatte gegenüber anderen APIs immer einen entscheidenden Vorteil: Die Entwickler wussten, dass sie immer maximal 140 Zeichen, manchmal mit Link, manchmal ohne, bekommen würden. Diese Vorhersehbarkeit des Formats der Inhalte machte und macht Mashups und auch Clients für Twitter einfacher umsetzbar als beispielsweise für Facebook oder Google Buzz, wo man jeweils mehr als dieses eine Format in Informationsarchitektur und Interface des Angebots einbeziehen muss. (Die Schwierigkeit der Umsetzung sieht man aktuell an den jeweils ersten Iterationen der Google-Buzz-Implementation bei Seesmic und Tweetdeck.)

Trotz dieser Gründe steht es für mich außer Frage, dass ein offizielles, speziell auf die Plattform zugeschnittenes Verzeichnis, das Ökosystem massiv stärken würde.

Was Twitter mit einem solchen Verzeichnis machen könnte:

  • Prominent platzierte, bezahlte Werbeplätze für Drittanbieter
  • Kostenpflichtiges Verified-Programm
  • Drittanbieter, die den kostenpflichtigen Firehose-Zugang nutzen, gesondert hervorheben
  • Sichtbarmachung miteinander verknüpfter Applikationen
  • Support-Community für die Entwickler
  • etc.

Mit einem Verzeichnis hätte Twitter die Möglichkeit, die eigenen Einkünfte stärker anreizkompatibel mit den Drittanbietern zu verknüpfen (gleichzeitig wären die Einkommensströme diversifizierter). Damit wäre, entsprechend umgesetzt, auch ein stärkerer Lockin für die Entwickler entstanden. Was nicht unwichtig ist, wie wir im nächsten Abschnitt zum Multihoming sehen werden.

Warum also hat Twitter bis dato kein offizielles Verzeichnis der Twitter-Mashups und Twitter-Clients? Dieser Umstand deutet meines Erachtens auf ein zumindest ambivalentes Verhältnis vom Plattformprovider zu den auf die Twitter-Plattform setzenden Drittanbietern hin. Diese Ambivalenz geht weit über den Kauf von Tweetie hinaus. Ein Verzeichnis hätte bereits 2007 oder 2008 eingeführt werden können.

Entwickler zum Multihoming gezwungen

Investoren zu GigaOm über die Twitter-Plattform:

Most said they were no longer interested in talking to pure-play Twitter startups.[..] However, there is still interest in startups that are using Twitter as a broad distribution platform and as part of an overall growth strategy.

Das bestätigt eine weitere Annahme, die ich nach Bekanntgabe des Tweetie-Kaufs machte:

In den nächsten Monaten werden wir von vielen Twitterclients lesen, die auf einmal etwas machen werden, was der offizielle Twitter-Client nie machen wird: Andere Dienste wie Facebook, Tumblr, Google Buzz und Status.net unterstützen. Denn das wird der einzige Weg sein, sicherzustellen, dass der eigene Client Mehrwert gegenüber dem offiziellen Twitter-Client haben wird.

Es ist kein Zufall, dass kurz nach der Tweetie-Übernahme die Clients Seesmic und Tweetdeck in ihren neuen Versionen vor allem mit neu unterstützten Diensten glänzen.

WordPress-CEO Matt Mullenweg hat vor einigen Wochen noch kritisiert, dass kein Client-Anbieter die von WordPress via Reverse Engineering implementierte Twitter-API unterstützt, obwohl dafür lediglich die Möglichkeit geschaffen werden muss, auf die Twitter-API über einen Proxy-Server zuzugreifen. Twitter kauft Tweetie und schon integriert Tweetdeck diese Funktion. Das ist kein Zufall. Das ist das einzige, was für Client-Anbieter wie Tweetdeck sinnvoll ist: Massiv Multihoming unterstützen.

Twitters eigene Applikation ist dabei gleichzeitig im Nachteil, wenn es keine Plattformen neben Twitter unterstützt; und das wird es natürlich nicht. (Ausnahme: Tweetie unterstützte eine eigentlich für Proxy-Server gedachte Funktion, mit der auch Twitter-API-kompatible Dienste angesprochen werden. Diese wird man wohl nicht abschaffen.)

Gleichzeitig:

Twitter ist nicht Microsoft

Wenn über Plattform-Strategien debattiert wird, wird oft Microsoft als Vergleich herangezogen. Microsoft hat mit Windows eine enorm erfolgreiche Plattform aufgebaut. Gleichzeitig hat Microsoft mit Microsoft Office erfolgreich ein Angebot auf der Plattform etabliert, dessen Funktionen vorher von Drittanbietern angeboten wurden. Das Argument geht also wie folgt: Microsoft war damit erfolgreich, also wird das ja wohl auch für alle anderen Plattformprovider gelten.

Das stimmt allerdings nicht. Man kann nicht alle Plattformen in einen Topf werfen und wild vergleichen. Es gibt wesentliche Unterschiede zwischen Betriebssystemen wie Microsoft Windows und Internetplattformen wie Twitter:

Zum einen sehen sich letztere in der Regel wesentlich niedrigeren Markteintrittsbarrieren gegenüber, was den Aufstieg eines Herausforderers auch für etablierte Plattformen immer real hält. Sie müssen also immer den Lockin für die verschiedenen Seiten auf der Plattform im Auge behalten.

Zum anderen ist Multihoming oft um ein Vielfaches einfacher umsetzbar, gerade und besonders bei Clients: Die Implementierung mehrerer APIs in Tweetdeck ist einfacher umgesetzt, als die Portierung eines Programms für Windows auf Linux und Mac. Gleichzeitig bedeutet Multihoming hier kein zusätzliches Angebot sondern eine Funktionserweiterung eines bestehenden Angebots.

Das heißt, dass Twitters offizieller Client nie zum Äquivalent von MS Office für die Plattform werden kann, weil ihm aus strategischen Gründen immer die Multihoming-Funktionalität fehlen wird.

Gerade Clients sind nun aber wichtig für die Plattformen. Für viele Nutzer sind die Clients der Zugang zur Plattform. Twitter hätte die Client-Anbieter näher an sich binden müssen, statt sie vor den Kopf zu stossen. Abgesehen vom offiziellen Twitter-Client wird man nun bald keinen Twitter-Client mehr vorfinden, der nur Twitter unterstützt.

Nun kann man argumentieren, dass Multihoming bei Twitter-Clients, sprich die Unterstützung anderer Plattformen, eine logische Entwicklung ist. Das ist in der Tat richtig. Die Frage, die sich aber stellt ist, ob Twitter gut damit beraten ist,

  • diese Entwicklung noch zu beschleunigen;
  • einen Client zu kaufen, der nie Multihoming unterstützen wird;
  • und, zumindest in Teilen, darauf ein Geschäftsmodell zu bauen.

Twitter macht seine Plattform nicht attraktiver für die Entwickler. Es mutet ein bisschen an, als ob Twitter glaubt, man würde nicht mehr mit anderen Plattformen konkurrieren müssen.

Twitter liegt damit aus dem gleichen Grund falsch, warum Drittanbieter-Verzeichnisse für Internetplattformen sinnvoll sind: Das Internet bedeutet Vernetzung und diese hat Implikationen für das eigene Geschäft. So banal das klingt, so oft wird das von Anbietern im Web vergessen. Twitter macht es gerade vor.

Fazit

Was Twitter also mit der aktuellen Richtung macht ist, die eigene Zukunft langfristig aufs Spiel zu setzen. Twitter bringt den eigenen Drittanbietern gerade brutalstmöglich nahe, dass es neben Twitter noch mehr im Web gibt.

Das ist schlecht für Twitter. Es ist gut für Facebook, Google Buzz, StatusNet und andere auf offene Standards setzende Anbieter. Und letztlich ist diese Entwicklung mit der dadurch wieder entstehenden Konkurrenz zwischen Plattformen um Drittanbieter gut für die Endnutzer.

Es kommt wieder Bewegung in die Mashup-Welt.

App-Freemium-Strategien: Free Apps oder In-App-Verkäufe

iphone-appsAuf Exciting Commerce habe ich über die zwei Freemium-Strategien für mobile Applikationen geschrieben:

1. zwei (oder mehr) unabhängige Applikationen

2. In-App-Verkäufe

Nicht immer sind beide Strategien ebenbürtig sinnvoll. Sofern aber beide Möglichkeiten mit dem eigenen Angebot kompatibel sind, sollte man sich im Zweifel für In-App-Verkäufe entscheiden. Hierbei ist der Aufwand für die Nutzer geringer: Sollten sie sich für den Wechsel vom kostenfreien Angebot zum kostenpflichtigen Premium-Angebot entscheiden, können sie dies direkt in der Applikation machen. Sie müssen nicht erst eine weitere Applikation im App-Store herunterladen und die nun überflüssige Free-Applikation löschen und z.B. eventuelle Log-In-Daten erneut hinterlegen.

Exciting Commerce: In-App-Verkäufe oder Free Apps: Freemium-Strategien für mobile Apps

Kommende Disruption der PC-Branche & Apples Strategie

Charlie Stross hat einen sehr interessanten Artikel über Apples aktuelle Strategie verfasst:

I’ve got a theory, and it’s this: Steve Jobs believes he’s gambling Apple’s future — the future of a corporation with a market cap well over US $200Bn — on an all-or-nothing push into a new market. HP have woken up and smelled the forest fire, two or three years late; Microsoft are mired in a tar pit, unable to grasp that the inferno heading towards them is going to burn down the entire ecosystem in which they exist. There is the smell of panic in the air, and here’s why …

PCs werden zu Gebrauchsgegenständen mit geringen Gewinn-Margen für die Hersteller, gleichzeitig kommen mobile Breitband-Anbindungen. Und mit mobilem Internet-Zugang kommt die Massenbewegung der Nutzer in die Cloud. Stross:

Software will be delivered as a service to users wherever they are, via whatever device they’re looking at — their phone, laptop, tablet, the TV, a direct brain implant, whatever. (Why is this? Well, it’s what everyone believes — everyone in the industry, anyway. Because it offers a way to continue to make money, by selling software as a service, despite the cost of the hardware exponentially dropping towards zero. And, oh, it lets you outsource a lot of annoying shitty admin tasks like disk management, backup, anti-virus, and so on.)

Stross schlussfolgert, dass Apples iPhone/iPad-Ansatz nicht in erster Linie der Versuch ist, eine neue Produktlinie einzuführen, sondern um Apple eine profitable Position in einer Welt zu sichern, in der mit Hardware nach alter PC-Industrie-Lesart kaum mehr Geld zu verdienen ist.

Apple are trying desperately to force the growth of a new ecosystem — one that rivals the 26-year-old Macintosh environment — to maturity in five years flat. That’s the time scale in which they expect the cloud computing revolution to flatten the existing PC industry. Unless they can turn themselves into an entirely different kind of corporation by 2015 Apple is doomed to the same irrelevance as the rest of the PC industry — interchangable suppliers of commodity equipment assembled on a shoestring budget with negligable profit.

Schaut man sich das sich abzeichnende Bild mit ein bisschen Distanz an, wird klar, dass eine Disruption auf die PC-Branche zukommt, die weit über das iPad hinausgeht. Das iPad ist vielmehr nur Apples Versuch, aus diesem Umbruch hochprofitabel hervorzugehen, so Stross – und da stimme ich ihm zu.

Kurz gesagt: iPhone/iPad sind Apples Versuch, den durch mobile Internet-Zugänge und Cloud Computing kommenden Umbruch der Industrie zu überleben.

Interessant in diesem Zusammenhang ist natürlich, dass Google mit Android und ChromeOS an Betriebssystemen für Touchscreens und Cloud Computing arbeitet und diese Entwicklung eher beschleunigen will als alles andere. Google kann mit seinen Cloud-Computing-Angeboten nämlich natürlich zu den großen Gewinnern dieses Umbruchs zählen – und genau daran arbeitet man in Mountain View auch.

Wenig verwunderlich, dass die Google-Integration in Android so geschmeidig umgesetzt wurde und der Suchgigant an gleich zwei Fronten in das OS-Geschäft einsteigt. Letztlich verfolgen beide Unternehmen, Google und Apple, das gleiche Ziel: Sie wollen Gewinner des kommenden Umbruchs sein. Lediglich die Strategien, wie man dieses Ziel erreicht, unterscheiden sich. Diese Strategien entstehen dabei aus der jeweiligen Ausgangslage von Apple und Google.

Eric Schmidt hat die Aussicht auf die kommende PC-Welt aus Google-Sicht aufgezeigt:

But had you ever considered what the cloud meant for the hardware running it? CEO Eric Schmidt has. This week, he told the Atmosphere Cloud Computing Summit that Chrome OS devices will be “completely disposable” at netbook-esque price points of between $300 and $400.

“completely disposable” – Kein Wunder, dass Apple als Noch-Hardware-Unternehmen fieberhaft an einer Strategie feilt, diesem Schicksal zu entgehen.

(via u.a. twitter/oetting)

Zweiseitige Märkte: Multihoming bei Internetplattformen

Dieser Artikel ist Teil einer Serie über zweiseitige Märkte. Auf zweiseitigen Märkten treffen zwei unterscheidbare Gruppen aufeinander, deren jeweiliger Nutzen steigt, wenn die Marktteilnahme der anderen Gruppe größer wird.

Nachdem wir im vorhergehenden Artikel Multihoming , also die parallele Nutzung von Plattformen, und ihre Auswirkungen auf zweiseitige Märkte kennengelernt haben, werden wir uns nun Multihoming konkret bei Internetplattformen anschauen.

Inhalt:

Multihoming bei Internet-Plattformen

Die Möglichkeiten der Vernetzung über das Internet erlauben bei API-gestützten Internet-Plattformen verschiedene Arten von Multihoming. Plattformen können über APIs an andere Plattformen andocken. Applikationen, vor allem Clients, können Multihoming anbieten. Client-Anbieter finden darin ein zunehmend starkes Differenzierungspotential. Wenn eine Plattform in einem Bereich den Markt dominiert und damit zum Quasi-Standard wird, bietet es sich unter Umständen an über einen Adapter, also eine API, an diese Plattform, anzudocken.

Freiwilliges Multihoming der Plattformseite

Außerhalb des Internets ist Folgendes eher ungewöhnlich: Alle großen Netzwerkplattformen wie Facebook, MySpace, LinkedIn u.s.w. haben im Laufe des Jahres 2009 die Funktionalität implementiert, auf Twitter veröffentlichte Nachrichten auf ihren Angeboten automatisch ebenfalls zu veröffentlichen. Die Plattform-Provider haben sich dabei nicht auf Applikationen verlassen und diese Integration stattdessen selbst umgesetzt. Zumindest bei Facebook gab es bis zur Einführung der eigenen Implementation auch Applikationen, die diese Funktion übernommen haben.

Multihoming allüberall

Die Blogplattform Tumblr erlaubt mit Hilfe einer Facebook-Applikation das zusätzliche Veröffentlichen von Beiträgen auf Facebook, die ursprünglich auf Tumblr erschienen sind. Damit wird ebenfalls Multihoming auf Seiten des Endkonsumenten möglich.

Der Einsatz von standardisierten APIs beinhaltet bereits die Multihoming-Möglichkeit auf Applikationsanbieterseite. Google Buzz setzt unter anderem zum Beispiel durch die in offenen Standards immanente Multihoming-Möglichkeit auf den insgesamt geringeren Ressourcenaufwand auf Applikationentwickler-Seite als Wettbewerbsvorteil der Plattform .

Plattform-Provider die zum Beispiel Open Social integrieren, können theoretisch alle mit den gleichen technischen Spezifikationen von Applikationen angesprochen werden. In der Praxis versuchen Plattform-Provider allerdings zusätzliche proprietäre Bestandteile zur Implementation hinzuzufügen, um sich so von anderen Plattformen zu differenzieren und einen Lock-in-Effekt für das eigene Angebot zu erzeugen. Die Vorteile einer verteilten Plattform (hier im Sinne des Standards) werden damit negiert.

Bei verteilten Plattformen ist die Fragmentierung durch unterschiedliche Implementierungen immer eine Gefahr. Auch das Mobiltelefon-Betriebssystem Android, ebenfalls eine verteilte Plattform, kämpft zum Beispiel mit diesem Problem. Die andere Seite der Medaille ist natürlich, dass auf der gleichen Grundlage bei Erfolg eine wesentlich größere Masse an Endnutzern erreicht werden kann.

Multihoming und Twitter

Ob Multihoming ein Problem für eine auf Vernetzung setzende Plattform wie Twitter ist, wird sich erst mit der Zeit zeigen. Aktuell deutet einiges daraufhin, dass Multihoming Twitter zumindest mittelfristig hilft, die eigenen Nutzer auf der Plattform zu halten. Nur bei Twitter finden sie, zumindest heute, eine hohe Zahl an Clients für Desktop und Mobiltelefon. Sie können wahlweise über Clients oder über die Twitter-Integration Multihoming betreiben und mehrere Plattformen gleichzeitig befüllen. Gleichzeitig wird die Sichtbarkeit ihrer Aktivitäten über Mashups und Dienste wie zum Beispiel Favstar verbessert. Da die Nutzung dieser Dienste weitestgehend kostenfrei für den Endnutzer ist, weil sie entweder auf Freemium und/oder Werbung als Geschäftsmodell setzen, ist der Einsatz von mehreren Angeboten kein Nullsummenspiel. Bis vor wenigen Tagen sah es so aus, als bewegte Twitter sich in eine Richtung, ein rein datengetriebenes Angebot zu werden. Multihoming in beide Richtungen führt zu einer stärkeren Gewichtung der grafischen Oberflächen. Die für diese Strategie notwendige Generativität innerhalb des Twitterkosmos schränkt Twitter allerdings auch in den Handlungsmöglichkeiten ein, etwaige Restriktionen durchzusetzen.

Applikationen integrieren Applikationen: Multihoming am Beispiel Instapaper

Auch auf Applikationenseite gibt es vertikale Integration. So ist es etwa möglich, dass ein Client einen anderen Dienst integriert. Dieser Dienst kann ebenfalls auf die Plattform aufsetzen, auf die der Client aufsetzt, muss das aber nicht.

Erreicht ein Client einen entsprechend hohen Marktanteil, kann er selbst zu einem zweiseitigen Markt werden. Durch die Integration von anderen Diensten bringt er diese und die den Client einsetzenden Endnutzer zusammen. Der Entwickler des Twitter-Clients Tweetdeck, der einen Marktanteil von 20 Prozent bei den Twitter-Clients innehat, zog for geraumer Zeit bereits ein kostenpflichtiges Integrationsangebot in seinen Client in Erwägung .

Integriert ein Client den Zugang zu mehreren Plattformen, kann er damit die Multihoming-Kosten absenken. Das kann die Nutzung der Plattformen intensivieren. Es sorgt aber auch dafür, dass der Zwang, Alleinstellungsmerkmale zu finden, für die Plattformen ansteigt.

Instapaper ist einfaches Werkzeug, um Artikel für späteres Lesen über ein Bookmarklet online abzuspeichern. Die Bookmarklet-Funktion „Speichern des Textes“ wird in anderen textanzeigenden Applikationen implementiert. So hat man die Möglichkeit, Texte auf Instapaper direkt in den Applikationen zu speichern.

Die Integration dieser Funktion führt zu einem zweiseitigen Markt: Je mehr Webdienste und lokale Applikationen, für die diese Funktion sinnvoll ist, sie integrieren, desto nützlicher wird die eigentliche Applikation für den Endnutzer (weil er sie überall vorfindet). Daraus resultiert, dass mehr Menschen Instapaper einsetzen, was wiederum den Anreiz für Anbieter von anderen Applikationen erhöht, diese Verbindung zu integrieren. Denn je weitverbreiteter die Nutzung von Instapaper und damit die Integration in Applikationen, desto eher kommt der Punkt, an dem das Fehlen der Integration ein Ausschlusskriterium für einige Endnutzer wird.

Auch hier zeigt sich wieder, wie die potentiell mögliche Verknüpfung über das Internet mit einfachen Mitteln Zusatznutzen stiften kann. Die Betreiber der jeweiligen Applikationen, hier Instapaper und die Funktionalität des Textspeicherns integrierende Applikationen, müssen für diese lose Kooperation nicht in direkten Kontakt treten. Eine so einfache Integrationsmöglichkeit fördert Multihoming auf beiden Seiten. Instapaper ist in vielen Clients vertreten. Die Hersteller der Clients können viele so einfach integrierbare Dienste unterstützen. Allerdings wird jeder künftige Konkurrent von Instapaper es schwerer haben, eine vergleichbare Marktpenetration zu erreichen, je später er den Markt betritt. Die Client-Anbieter integrieren nur eine begrenzte Zahl an auswählbaren Diensten mit vergleichbarer Funktionalität. Clients die dagegen selbst eine Schnittstelle für solche Fälle anbieten, verlagern die Integration auf die Seite des Integrationswilligen. (Ein Beispiel dafür wäre die Addon-Schnittstelle von Firefox.)


Dieser Artikel ist Teil der Serie “Zweiseitige Märkte: Die ökonomische Theorie hinter Facebook, Twitter und co.”

Alle Artikel findet man hier:

  1. Zweiseitige Märkte: Die Grundlagen
  2. Wie Multihoming zweiseitige Märkte beeinflußt

iAd: Apples Rundum-Plattform schreitet voran

Auf netzwertig.com wird iAd, die von Apple geplante neue Werbeplattform für Apps vorgestellt und beleuchtet:

Unter dem Namen “iAd” wird Apple ab Sommer Werbung verkaufen, die in iPhone- und iPad-Apps eingeblendet wird. Dabei wird es sich nicht nur um einfache Banner handeln, sondern um komplette Sub-Applikationen, die die Werbebotschaft mit Videos, Spielen und kostenlosen Goodies an den User bringen sollen.

Besser auf den App-Kontext abgestimmte Werbung könnte für alle Beteiligten ein Gewinn sein.

Interessant in diesem Zusammenhang auch, dass Apple die Auswertung der App-Nutzungsdaten durch Dritte untersagt:

Bemerkenswert ist dieses neue Verbot aber auch im Kontext von Apples geplantem Einstieg in den Werbemarkt, denn der Konkurrenz in Form von Admob (und damit Google) wird dadurch der weitreichende Einblick in die Nutzungsgewohnheiten der iPhone-Besitzer verwehrt. Inwiefern Apples kommende eigene mobile Werbeplattform ‘iAd’ Nutzerdaten sammelt, ist noch offen – von der neuen Klausel dürfte diese kaum betroffen sein.

Apple plant strategisch Schritt für Schritt die Rundum-Plattform und wandelt sich als Unternehmen damit radikal. Epicenter schreibt dazu sehr passend:

Most of its money still comes from selling computers, iPhones, iPods and iPads. But with its move into advertising, the spike in revenue from selling iPhone aps (four billion downloads and counting), as well as its move to take a percentage of book and other content sales on the iPad have NEW MEDIA COMPANY written all over them. It is moving to build the self-perpetuating effects that come with such a platform with astonishing speed.

[..]

What is not debatable however is that what Apple is doing has the potential to be a colossally huge business.

Mit dem (funktionierenden) Markt auf der Plattform und der Unterstützung des selbigen könnte Apple mit seinem Angebot schaffen, was die Web1.0-Portale vorhatten, aber mittelfristig nicht vermochten zu leisten:

Für viele Konsumenten die einzige Anlaufstelle werden.

Wie Multihoming zweiseitige Märkte beeinflußt

Dieser Artikel ist Teil einer Serie über zweiseitige Märkte. Auf zweiseitigen Märkten treffen zwei unterscheidbare Gruppen aufeinander, deren jeweiliger Nutzen steigt, wenn die Marktteilnahme der anderen Gruppe größer wird.

Multihoming allgemein

Multihoming ist der parallele Einsatz mehrerer Plattformen auf einer der Nutzerseiten. Mitglieder einer Gruppe findet man also auf mehr als einer Plattform wieder. Das erlaubt der anderen Gruppe einen größeren Spielraum bei der Wahl der jeweiligen Plattform.

Beispiele für Multihoming:

  • Eine Familie, die mehrere Spielkonsolen besitzt
  • Ein Softwareentwickler, der für Windows und Mac entwickelt
  • Ein Geschäft, das mehrere Kreditkarten akzeptiert
  • Ein Endkonsument, der mehrere Kreditkarten besitzt
  • Ein Werbekunde, der Werbung in mehreren Medien schaltet

Man sieht: Multihoming kann auf beiden Seiten stattfinden: Bei der Seite, die auf dem zweiseitigen Markt etwas anbietet, und bei der Seite, die auf dem zweiseitigen Markt etwas nachfragt.

Multihoming wird notwendig, wenn konkurrierende Plattformen inkompatibel sind, aber Nutzen aus ihnen gezogen werden kann. Sofern mehrere konkurrierende Plattformen auf dem Markt sind, ist es nicht ungewöhnlich, dass mindestens eine Seite Multihoming betreibt.

Auswirkungen von Multihoming

Wird Multihoming auf einer Seite betrieben, lässt der Wettbewerb zwischen Plattformen für diese Nutzerseite nach. Der Einsatz von Plattformen auf dieser Seite nimmt zu, selbst wenn die Anzahl der einzelnen Akteure gleich bleibt, da der Einzelne mehr Plattformen nutzt. Um Wettbewerbsvorteile zu erhalten, werden die Plattform-Provider verstärkt um die Seite werben, welche kein oder wenig Multihoming betreibt oder betreiben kann.

Was heißt das konkret? Schauen wir uns als Beispiel Spielkonsolen an. Wenn viele Spiele-Entwickler anfangen, ihre Spiele von einer Spielkonsolenplattform auf die andere zu portieren, sinkt der Anreiz für die Anbieter von Spielkonsolen (Sony, Nintendo und co.) die Gebühren für die Entwickler niedrig zu halten. Gleichzeitig werden die betroffenen Spielkonsolen aus Konsumentensicht austauschbar. Das Resultat: stärkerer Kampf um die Endkunden über zum Beispiel niedrigere Konsolenpreise.

Je nach Preisstruktur der Plattformen kann Multihoming auch begünstigt werden. So findet man Multihoming beispielsweise im Spielkonsolensektor oft auch auf Konsumentenseite vor. Da die ursprüngliche Hardware oft unter Kosten verkauft wird, können die Konsumenten für verhältnismäßig wenig Geld leistungsstarke Hardware erstehen (warum Konsolen unter Kosten verkauft werden, werden wir in einem späteren Artikel behandeln). In diesem Sektor spielt auch der Wunsch nach Vielfalt bei den Endkonsumenten eine Rolle. Das deutet darauf hin, dass je nach Wirtschaftszweig und Präferenzen der betroffenen Gruppen Multihoming unumgänglich ist und starken Einfluss auf die Preisstruktur der Plattformen haben kann. (siehe zum Thema Multihoming unter anderem Evans, David S. / Hagiu, Andrei / Schmalensee, Richard, Invisible Engines, How Software Platforms Drive Innovations and Transform Industries, Cambridge/MA / London 2006, S. 67-69)

Im nächsten Artikel: Multihoming bei Internetplattformen


Dieser Artikel ist Teil der Serie “Zweiseitige Märkte: Die ökonomische Theorie hinter Facebook, Twitter und co.”

Alle Artikel findet man hier:

  1. Zweiseitige Märkte: Die Grundlagen
  2. Wie Multihoming zweiseitige Märkte beeinflußt

Zweiseitige Märkte: Die Grundlagen

zweiseitigemärkte

Was haben Einkaufszentren, Kreditkartensysteme, Spielkonsolen, Tageszeitungen, technische Standards wie VHS und Blu-ray, Betriebssysteme, Appstores, eBay, Facebook und Twitter gemeinsam?

Sie alle sind zweiseitige Märkte.

Inhalt:

Was sind zweiseitige Märkte?

Zweiseitige Märkte finden auf von einem oder mehreren Unternehmen angebotenen Plattformen statt, auf welchen zwei unterscheidbare Nutzergruppen zusammen kommen. Die Inanspruchnahme der Plattform durch die zwei Nutzergruppen wird durch zweiseitige, indirekte Netzwerkeffekte beeinflusst. Das bedeutet, je mehr Teilnehmer einer Gruppe die Plattform einsetzen, desto attraktiver wird die Plattform für die Nutzer der anderen Gruppe und umgekehrt.

Das erste Mal wurden zweiseitige Märkte von Jean-Charles Rochet und Jean Tirole 2003 formuliert (in Rochet, Jean-Charles / Tirole, Jean, Platform Competition in Two-sided Markets, in: Journal of the European Economic Association, Vol. 1, Nr. 4, Juni 2003, S. 990-1029).

Aber machen wir zunächst einen Schritt zurück und schauen uns erst einmal an, was Netzwerkeffekte konkret sind.

[Anmerkung zum Begriff der zweiseitigen Märkte: In der Literatur wird abwechselnd von zweiseitigen Märkten (engl. "twosided markets"), mehrseitigen Märkten (engl. "multisided markets") oder zweiseitigen Plattformen (engl. "twosided platforms") geschrieben. Ich habe mich für "Zweiseitige Märkte" entschieden, weil

  1. sich alles anschaulicher anhand einer Zweiseitigkeit beschreiben lässt, auch wenn vor allem im High-Tech-Bereich oft mehr Seiten involviert sind (tatsächlich werden wir in einem späteren Artikel sehen, dass zum Beispiel Facebook und Twitter mindestens drei Seiten bedienen) und
  2. eine Unterscheidung zwischen der zugrundeliegenden Plattform und dem auf ihr stattfindenden Markt notwendig ist.

Zusätzlich wird in der entsprechenden akademischen Literatur mehrheitlich von "twosided markets" gesprochen.]

Netzwerkeffekte

Wirtschaftszweige im Informationsbereich werden maßgeblich von Netzwerken bestimmt und geformt. Das bestimmende Element von Netzwerken sind Netzwerkeffekte.

“Virtuelle” Netzwerke ähneln physischen Netzwerken wie das Telefonnetz oder das Eisenbahnnetz. Nutzer des gleichen Betriebssystems gehören zum gleichen Netzwerk. Das Gleiche gilt für Nutzer von Technologien wie CD-/DVD-Laufwerken oder Spielkonsolen. Teilnehmer befinden sich im gleichen Netzwerk, wenn sie Komponenten des Systems verwenden.

Alle Netzwerke haben in der Regel ein gemeinsames Merkmal: Solang alle anderen Umstände gleich bleiben, steigt der Nutzen für den einzelnen Teilnehmer je mehr zusätzliche Teilnehmer das Netzwerk nutzen. Dieses Merkmal kann man als Netzwerkeffekte, Netzwerkexternalitäten oder positive Skaleneffekte auf Nachfragerseite bezeichnen.

In den in dieser Artikelserie betrachteten Fällen äußern sich die Netzwerkeffekte positiv, also nutzensteigernd. Netzwerkeffekte können aber auch negative Auswirkungen hervorrufen, sprich sich als Kosten bemerkbar machen. Dann sinkt der Nutzen für den Einzelnen je mehr Akteure ein Angebot nutzen (zum Beispiel übermäßig viel Werbung, die auf Endkonsumentenseite als negativ empfunden wird, wäre ein indirekter negativer Netzwerkeffekt).

Netzwerkeffekte können unterschiedlich stark auftreten. Auswirkungen auf ihre Ausprägung hat die Höhe der Wechselkosten bei den Mitgliedern der Netzwerke und die Möglichkeit von Multi-Homing, auf das ich in einem späteren Artikel gesondert eingehen werde. In ihrer stärksten Form führen Netzwerkeffekte zu Winner-takes-it-all-Märkten, und das heißt damit zu Märkten, die von ihrer Struktur her zur Monopolbildung neigen.

Da der bei zunehmender Größe des Netzwerks stärker werdende Effekt sich damit auch gleichzeitig selbst verstärkt, spricht man in diesem Zusammenhang auch oft von positivem Feedback.

Direkte Netzwerkeffekte

Wenn im Zusammenhang von Social Networks wie StudiVZ und Facebook oder auch bei Twitter von Netzwerkeffekten die Rede ist, dann sind damit gemeinhin positive, direkte Netzwerkeffekte gemeint.

Direkte Netzwerkeffekte kann man auch als symmetrische Komplementaritäten bezeichnen (siehe z.B. Varian, Hal R., Competition and Market Power, in: Varian, Hal R. / Farrell, Joseph / Shapiro, Carl, The Economics of Information Technology, An Introduction, 4th printing, Cambridge/MA 2008, S.1-47., S. 42).

Je mehr Anwender ein Netzwerk verwenden, desto nützlicher wird es für alle Beteiligten. Ein Faxgerät ist am nützlichsten, wenn viele andere Faxgeräte damit ansprechbar sind. Das Gleiche gilt für Telefone, die am gleichen Telefonnetz angeschlossen sind (oder in Netzen, bei denen die Teilnehmer von einem Netz in das andere kommunizieren können).

Ebenso gilt das natürlich für Social Networks. Je mehr Personen auf Facebook sind, desto höher ist die Wahrscheinlichkeit, dass meine Freunde dort auch sind, folglich wird das Angebot attraktiver für mich, und damit auch gleichzeitig attraktiver für meine Freunde.

Je stärker die Penetration eines Marktes ist, sprich je größer das Angebot wird, desto stärker macht sich der direkte Netzwerkeffekt bemerkbar. Der zusätzliche Nutzen steigt mit der Gesamtgröße. Eine Folge dieses Umstands sind die exponentiellen Wachstumsraten, die man bei erfolgreichen Webangeboten beobachten kann.

Jede Website, bei der es um die Vernetzung von Mitgliedern geht – man nenne es Social Media -, wird mindestens von einem direkten Netzwerkeffekt getrieben: Entweder positiv, weil viele Mitglieder auf der Site sind, oder negativ, weil eine konkurrierendes Angebot größer ist.

Indirekte Netzwerkeffekte

Indirekte Netzwerkeffekte hängen nicht direkt von der Größe der Gruppe des betroffenen Nutzers auf der Plattform ab. Sie sind, allgemein ausgedrückt, ein Nebenprodukt der Tatsache, dass viele Akteure ein Netzwerk nutzen.

Im Kontext der zweiseitigen Märkte entstehen indirekte Netzwerkeffekte aus dem Umfang, in dem das Netzwerk von einer anderen Nutzergruppe genutzt wird. Das heißt, Mitglieder der Nutzergruppe A gewinnen einen Zusatznutzen daraus, dass mehr Mitglieder der Nutzergruppe B auf dem Netzwerk sind.

Ein Beispiel: Einem Nutzer von Windows (Nutzergruppe A) entsteht ein Zusatznutzen, wenn möglichst viele Entwickler (Nutzergruppe B) für das Betriebssystem seiner Wahl entwickeln. Je mehr Entwickler Programme für Windows entwickeln, desto größer wird die Auswahl für die Endkunden von Windows (Nutzergruppe A) und damit steigt ihr Gesamtnutzen an Windows.

Zweiseitige Märkte allgemein

Das wesentliche Merkmal zweiseitiger Märkte sind gegenseitige, indirekte Netzwerkeffekte. Auf zweiseitigen Märkten treffen (mindestens) zwei unterscheidbare Gruppen von Akteuren aufeinander, deren Nutzen an der Plattform steigt, wenn die jeweils andere Gruppe auf der Plattform größer wird.

Nehmen wir das Beispiel von eben noch einmal auf: Betriebssysteme wie Windows sind zweiseitige Märkte. Warum: Weil, wie eben beschrieben, die Attraktivität des Betriebssystems für den Endnutzer (Gruppe A) steigt, wenn viele Programme dafür zur Verfügung stehen. Gleichzeitig steigt die Attraktivät des Betriebssystems für die Entwickler (Gruppe B), wenn es von sehr vielen Endnutzern (Gruppe A) und damit potentiellen Kunden eingesetzt wird.

Microsoft muss also einen Weg finden, wie es beide Gruppen dazu bringt, das Betriebssystem einzusetzen, weil erst dann die Plattform attraktiv und damit erfolgreich wird.

Weitere Beispiele für zweiseitige Märkte mit den entsprechenden Gruppen:

  • Einkaufszentren: Läden, Kunden
  • Spielkonsolen: Spiele-Entwickler, Spieler
  • Kreditkartensysteme: Kreditkarte akzeptierende Läden, Kreditkartenbesitzer
  • Werbefinanzierte Medien: Werbende, Konsumenten (hier können negative Externalitäten auftreten, wenn die Werbung als störend wahrgenommen wird)
  • Blu-ray: Anbieter von Inhalten auf Blu-ray-Discs, Besitzer von Blu-ray-Playern

In allen Fällen profitiert jede Gruppe davon, wenn die jeweils andere Gruppe die Plattform einsetzt.

Der Provider der Plattform internalisiert die Externalitäten (die Netzwerkeffekte) über Architektur der Plattform und vor allem über die Preisstrategie. Der Provider muss für einen Erfolg der Plattform sicherstellen, dass die Netzwerkeffekte und verschiedenen Preissensitivitäten in die Kalkulation seines Angebots einfliessen.

Aus den unterschiedlich starken Netzwerkeffekten für die Gruppen folgen unterschiedliche Preissensitivitäten. Das macht sich dann fast immer darin bemerkbar, dass die zahlungswilligere Gruppe die andere Gruppe subventioniert.

Das ist beispielsweise der Grund, warum werbefinanzierte Medien wie Tageszeitungen mit einem Preis unterhalb der Kosten verkauft werden. Auch Spielkonsolen werden oft zumindest in der Einführungsphase mit Verlust verkauft. Auch die Tatsache, dass vieles im Web für Endkonsumenten kostenfrei ist, lässt sich darauf zurückführen. Zu Preisstrategien von Plattformprovidern folgt später noch ein gesonderter Artikel.

Nicht immer ist die Unterscheidung der verschiedenen Nutzergruppen offensichtlich. Wir werden in einem späteren Artikel noch sehen, dass Plattformprovider auch manchmal die Gruppen nicht erkennen und eine suboptimale Preisstrategie fahren, weil sie alle Nutzer gleich behandeln.

Wer ein System mit zweiseitigen, indirekten Netzwerkeffekten aufbauen will, steht vor einem Henne-Ei-Problem. Gehen wir von zwei Nutzergruppen aus, A und B:

Der Nutzen des Systems für Gruppe A entsteht nur, wenn Gruppe B an Bord ist. Das Gleiche gilt umgekehrt für Gruppe B wenn zweiseitige indirekte Netzwerkeffekte vorliegen. In diesem Fall wartet jede der Seiten darauf, dass die andere Seite die Plattform annimmt.

Zweiseitige Märkte im Internet

Werbefinanziert

Sehr viele Internetangebote sind zweiseitige Märkte. Immer, wenn ein Dienst werbefinanziert ist, entsteht auf ihm automatisch ein zweiseitiger Markt.

Social Media und Co.

Ob werbefinanziert und/oder mit APIs: Soziale Netzwerke oder andere auf die Vernetzung zwischen den Endnutzern setzende Internet-Plattformen zeichnen sich neben den zweiseitigen, indirekten Netzwerkeffekten zusätzlich durch einen starken direkten Netzwerkeffekt auf der Seite der Endnutzer aus. Das ist ausgesprochen wichtig, wie wir später noch sehen werden.

Plattformen mit APIs

Wenn Internet-Plattformen eine API (Programmierschnittstelle) einführen, werden sie ebenfalls zu einem zweiseitigen Markt: Auf der einen Seite die Entwickler, die auf die API setzen. Auf der anderen Seite die Endnutzer, die vom reichhaltigen Ökosystem profitieren.

Einige konkrete Beispiele:

  • Facebook Plattform und Facebook Connect: Anbieter von Apps wie FarmVille und Webpublisher auf der einen Seite, Endnutzer auf der anderen Seite.
  • Twitter: Wohl neben Facebook das bekannteste Beispiel für eine populäre API im Internet. Anbieter von Twitterclients auf der einen und Endnutzer auf der anderen Seite dürften in diesem Ökosystem die stärksten zweiseitigen, indirekten Netzwerkeffekte verspüren.
  • Apples Appstore: Auch der Appstore für iPhone, iPod Touch und iPad ist ein zweiseitiger Markt. Je mehr Endnutzer diese Geräte einsetzen, desto attraktiver wird das System für die Entwickler, was sich wiederrum in einem Angebot äußert, dessen Vielfalt ein wesentlicher Erfolgsfaktor auf Endnutzerseite ist. Der Appstore von Apple ist aktuell ein Paradebeispiel für einen florierenden zweiseitigen Markt.

Eines haben all diese Beispiele gemeinsam: Sie sind auch ohne die Zusatzangebote von Drittanbietern nutzbar. Das ist notwendig: Damit der zweiseitige Markt funktioniert, muss der Provider wie oben beschrieben eine Henne-Ei-Problem lösen. Wie auf dem Desktop die Betriebssysteme, die von Haus aus alle mit Programmen ausgeliefert werden, die Grundfunktionen erfüllen, können auch die Internetplattformen genutzt werden, ohne dass der Endnutzer auf Drittanbieter setzen muss.

Dass er es bei den erfolgreichen Angeboten kann, sichert ihnen weiteres Wachstum.

Auch addon-fähige Software wie die Browser Firefox, Chrome und andere sind zweiseitige Märkte: Je mehr Addons, desto nützlicher werden sie. Je nützlicher sie sind, desto mehr Menschen setzen die Browser ein.

Zunehmende Komplexität

Das bringt uns gleich zu einem Punkt, der in den kommenden Jahren an Bedeutung zunehmen wird: Zunehmende Komplexität im High-Tech-Bereich.

Plattformen können auf andere Plattformen aufsetzen oder mit diesen verbunden sein. Dafür gibt es unterschiedlichste Beispiele: Facebook hat eine eigene Applikation für das iPhone. Die iPhone-Applikation Boxcar ermöglicht anderen, auf ihre Push-Funktionalität zu setzen und wird damit selbst zu einem zweiseitigen Markt. Der Twitterclient Seesmic ist Drittanbieter im Twitter-Ökosystem. Mit der kommenden addon-fähigen Version wird Seesmic selbst zu einem zweiseitigen Markt.


Dieser Artikel hat die Grundlagen zweiseitiger Märkte allgemein und im Internet behandelt. In den kommenden Artikeln werden wir uns mit Preisstrategien von Plattformanbietern, Geschäftsmodellen, den Auswirkungen von Multihoming und weiteren Aspekten von zweiseitigen Märkten im Internet auseinandersetzen.

Dieser Artikel ist Teil der Serie “Zweiseitige Märkte: Die ökonomische Theorie hinter Facebook, Twitter und Co.”

Alle Artikel der Serie findet man hier.

Neue Artikelserie: Zweiseitige Märkte – die ökonomische Theorie hinter Facebook, Twitter und Co.

Über die nächsten Tage verteilt wird auf neunetz.com eine mehrteilige Artikelserie über die Theorie der Zweiseitigen Märkte erscheinen. Mit dieser recht jungen ökonomischen Theorie lassen sich neben Erfolg und Misserfolg von Einkaufszentren, Kreditkartensystemen und Spielkonsolen auch jene von Internet-Plattformen wie Facebook, Twitter und Appstores von iPhone, Android und co. erklären.

Anhand dieser Theorie werden in dieser Artikelserie Erfolgsfaktoren, Preisstrategien und strategische Herausforderungen für Plattformprovider und Appanbieter erörtert.

Besonders die sogenannte Appökonomie lässt sich mit den Zweiseitigen Märkten erkenntnisreich beleuchten.

Die Themen umfassen unter anderem:

  • direkte und indirekte Netzwerkeffekte und ihre Auswirkungen,
  • Multihoming allgemein und an konkreten Beispielen,
  • Preisstrategien allgemein und an konkreten Beispielen,
  • und warum ‘Freeconomics’ und die Paid-Content-Debatte eng mit zweiseitigen Märkten verbunden sind.

Nach Abschluss der Serie wird man die Artikel gesammelt als kostenloses E-Book im PDF- und im EPUB-Format herunterladen können.

Ich werde außerdem auf der re-publica 2010 am 14. April (voraussichtlich um 14 Uhr) einen Vortrag zum Thema im Blauen Saal halten.

Alle Artikel der Serie werden unter diesem Tag gesammelt.

iPad: Absurd hohe Abopreise für Springerapps

ipad

fscklog fasst die Abopreise für Apps der Springergruppe zusammen:

die ‘Welt’ kostet 30 Euro pro Monat, die ‘Welt Kompakt’ 13 Euro pro Monat und die ‘Welt am Sonntag’ lässt sich für 8 Euro pro Monat abonnieren.

Das kommt mir nicht sonderlich niedriger vor als die Printabos (Printabo der Welt kostet z.B. regulär 36,9€/Monat). Indem man nicht einmal teilweise die Kostensenkungen an die Kunden weitergibt, erhofft man sich wohl in diesem Umfeld eine Cash Cow. Das könnte nicht weiter von der Realität enfernt sein.

Was mich nach wie vor verwundert zurücklässt, ist die Tatsache, dass man bei den Verlagen der Ansicht zu sein scheint, man könne mit Tablet-Apps erfolgreich das machen, was im Internet seit einer Dekade nicht funktioniert hat: Das Print-Angebot ungeachtet aller veränderter Rahmenbedingungen 1:1 in das Digitale zu übersetzen.

Eine schöne, leicht zu bedienende Oberfläche hebelt nicht die Dynamiken des Internets aus. Der Apple-Appstore mag geschlossen sein, aber einen Browser wird das iPad trotzdem haben.

Volker Weber teilt meine Bedenken und hat den Umstand auf Buzz heute gut zusammengefasst:

I am reading about some offerings for the iPad that look quite expensive. Do publishers believe that people will buy the iPad, pay for a monthly data plan, and on top of that spend a lot for a subscription of their e-paper?

That might work, under the assumption that the rest of the web suddenly becomes boring, starting next Saturday. But what are the chances?

Die zwei wichtigen Aspekte, die man auf Verlagsseite völlig zu ignorieren scheint:

  1. Die Leute bezahlen bereits für das iPad und eventuell den Internetzugang für das iPad, und sollen dann noch zusätzlich für E-Paper-Abos monatlich zahlen? Wer wird bereit sein, so viel Geld aufzubringen?
  2. Das Internet bleibt erreichbar, vielfältig und bietet weiterhin kostenfreie Alternativen. Wie viele werden sich angesichts dieser Tatsache für die Springerapp-Abos entscheiden?

Brettspiele auf dem iPad: Killerapplikationen?

Das ist eine Anwendungsart, an die ich noch nicht gedacht hatte: Brettspieladaptionen auf dem iPad. TUAW stellt eine iPad-App namens Game Table vor, die Dame, Schach und weitere Brettspielklassiker vereint (siehe die Homepage von Game Table). Für 99 Cent wird die App äußerst günstig sein.

Auf einmal erscheint mir das iPad und die gesamte kommende Tablet-Klasse viel familienfreundlicher.

Vielleicht wird ein Wirtschaftszweig vom iPad und den bald folgenden Tablets getroffen, die mit einer Bedrohung durch Digitalisierung nun gar nicht gerechnet hatte: die Brettspielbranche.

largecheckers2

 

largechess1

Seesmics addon-fähiger Twitter-Client kommt

seesmicSeesmics Strategie, einen addon-fähigen Twitter-Client zu bauen, ist ziemlich clever. Tatsächlich kann man sich fragen, warum es erst jetzt passiert, dass jemand einen ausbaufähigen Twitter-Client veröffentlichen wird.

Seesmic-CEO Loic LeMeur hatte eine Desktop-Version von Seesmic mit Plugin-Schnittstelle schon vor einer Weile angekündigt. Jetzt soll sie in 2 bis 4 Wochen für interessierte Entwickler verfügbar sein. Es dürfte von da an nicht mehr lang bis zur Veröffentlichung der ersten Version dauern. The Next Web:

With the introduction of a plugin architecture, Seesmic will become the facilitator for your perfect social media experience, so long as someone has built a plugin for it.

Interessanterweise setzt Seesmic auf Silverlight:

The new app, which will be let loose on developers in “2 to 4 weeks” is a brand new build using Silverlight 4. You don’t need to worry about the ‘back end’ – it just means the app can work on more platforms than ever before, including the Windows 7 Phone.

An einem Addon-Verzeichnis mit Beschreibungen, Downloadzahlen, Reviews und Ratings arbeitet man auch bereits. Das typische Verzeichnis also, wie man es von den Addons für Firefox und Thunderbird oder von den Appstores von Apple, Android und Palm Pre etwa kennt.

Sehr clevere Strategie von Seesmic.