Twitters Ankündigung, seine Entwicklerplattform stärker zu reglementieren, offenbart einmal wieder den Nachteil kommerzieller Plattformen: Auf ihnen Geschäftsmodelle aufzubauen, ist riskant.

Eine Plattformstrategie gehört zu den klassischen Erfolgsrezepten führender Onlinedienste. Während Entwicklerschnittstellen (API) zwar auch von diversen deutschen Startups angeboten aber hierzulande maximal als netter Bonus angesehen werden, sind APIs bei den großen US-Services nicht selten ein elementarer Teil des Kernprodukts. Egal ob Facebook, Twitter, Google, LinkedIn, foursquare oder Dropbox – jede dieser bekannten Firmen hat in einer frühen Phase Drittanbieter und Programmierer mittels offener Schnittstellen dazu animiert, eigene Dienste und Anwendungen auf Basis der jeweiligen Plattform aufzubauen. Die zwei entscheidenden Vorteile dieses Ansatzes: Für Anwender eröffnen sich durch die externen Apps zahlreiche neue Einsatzszenarien, und der Plattformanbieter wiederum bindet die Entwicklergemeinde an sich und schafft einen zusätzlichen Lock-In-Effekt, wie das Beispiel Facebook sehr gut illustriert.

Eine API anzubieten und so externe Apps um den eigenen Dienst zu scharen, zahlt sich also aus. Doch wie so oft hat auch dieses Vorgehen eine Schattenseite. In einem aktuellen, heute früh bereits in Linkwertig empfohlenen Artikel beleuchtet Software- und Blogguru Dave Winer diese am Beispiel der Twitter-Plattform. Das kalifornische Unternehmen hatte in der vergangenen Woche verkündet, das Regelwerk für seine Entwicklerschnittstelle zu verschärfen und setzt damit die schon vor einiger Zeit eingeleitete schrittweise Demontage seiner Plattform fort. Konnten Programmierer vor drei Jahren noch beruhigt Twitter-Apps basteln und sich der vollen Unterstützung des Microbloggingdienstes sicher sein, drohen ihnen heute Sanktionen, sollten ihre Anwendungen den von Twitter selbst bereitgestellten zu ähnlich sein.

“Traue keiner kostenfreien, kommerziellen API”

Ausgehend von der jüngsten Entwicklung im Hause Twitter stellt Winer fest, dass Entwickler grundsätzlich keinem kostenfreien, werbefinanzierten Onlinedienst trauen sollten, der eine API anbietet. Das Risiko, dass die offenen Arme, mit denen Programmierer im frühen Plattformlebenszyklus empfangen werden, keinen dauerhaften Bestand haben, kann seiner Beurteilung nach zu keinem Zeitpunkt ausgeschlossen werden. “Kommerzielle APIs dienen den Unternehmen, die sie bereitstellen, aber sonst niemandem”, so Winers Fazit, der Drittanbietern und Programmierern empfiehlt, nur dann auf derartige Schnittstellen zu setzen, wenn sie grundsätzlich dafür bereit sind, dass ihre Arbeit kurzfristig und unerwartet vom Plattformbetreiber zunichte gemacht wird.

Der von Winer hervorgehobene Aspekt offenbart ein Problem, das Nutzer von zumeist werbefinanzierten Onlinediensten aus einer anderen Perspektive kennen: die Volatilität und Mortalität in der digitalen Welt, also die unvermittelte Schließung oder der radikale Umbau von Webangeboten, welche die Erwartungen ihrer Gründer und Investoren nicht erfüllen konnten. Ähnlich wie User jederzeit damit rechnen müssen, dass ihr Lieblingsdienst die Pforten schließt oder im Rahmen eines sogenanten “Pivots” die Funktionalität modifiziert, können auch API-Nutzer sich niemals sicher sein, für alle Zeit die Leistungen einer externen Plattform unverändert in Anspruch nehmen zu dürfen. Im Gegensatz zu den Endanwendern, die im schlimmsten Fall ihre bei einem Service hinterlegten Inhalte und geknüpften Kontakte “verlieren”, steht für API-Nutzer mitunter die wirtschaftliche Existenz auf dem Spiel. Würde Twitter etwa dem bei Intensivnutzern beliebten mobilen Client Tweetbot den Zugriff auf die Schnittstelle abklemmen, wäre die für 2,39 Euro angebotene App nutzlos und dieser Erlösstrom unterbrochen.

Es verwundert daher nicht, dass Onlinefirmen, die sich in besonderem Maße von einer einzigen Plattform abhängig gemacht haben, verstärkt versuchen, ihr Risiko zu streuen. Zynga, der führende Anbieter von Spielen auf Facebook, hat erst vor wenigen Tagen eine Plattform und Pläne für ein eigenes soziales Netzwerk abseits von Facebook öffentlich gemacht. Im Gegensatz zu Twitter war Facebook jedoch schon immer recht restriktiv mit den Freiheiten, die es Entwicklern einräumte, und deutlich mit den Einschränkungen seiner Plattform. Twitter hingegen streckte Entwicklern erst die ganze Hand aus, nur um später nach und nach einzelne Finger zurückzuziehen.

Dropbox und Spotify als positive Beispiele

Positiver steht Branchenkenner Dave Winer, ein bekennender RSS-Evangelist und Kritiker der die traditionellen Werte des Netzes vernachlässigenden Kommerzialisierung des Internets, APIs gegenüber, die eine unmittelbare Stärkung des Geschäftsmodells des Plattformbetreibers zur Folge haben. Als Beispiel führt er Dropbox an, das Anwender mit größerem Speicherbedarf zur Kasse bittet. Je mehr Apps mit Dropbox integriert sind, desto größer ist die Wahrscheinlichkeit, dass Dropbox-Mitglieder sich für eines der kostenpflichtigen Pakete entscheiden. Fließt bares Geld abseits der stark konjunkturabhängigen Werbevermarktung, hat ein Webunternehmen größere Anreize, seine Plattform auszubauen, statt sie einzuschränken.

Ein anderes Beispiel hierfür ist die Spotify Plattform: Externe Apps auf Basis des schwedischen Musikdienstes können ausschließlich von Personen verwendet werden, die ein kostenpflichtiges Spotify-Premiumkonto besitzen. Das verringert zwar die Attraktivität der Schnittstelle aus Entwicklersicht, weil sie mit ihren Projekten nur einen geringen Teil aller Spotify-Mitglieder erreichen können. Es schafft aber gleichzeitig eine höhere Sicherheit, dass Spotify nicht von heute auf morgen kritische Einschnitte an seiner Plattform vornimmt. Denn diese ist Marketing für Spotifys Premiumpakete und damit eine Maßnahme, um mehr zahlende Benutzer zu gewinnen.

Für das Groß der Startups, Onlineservices und Organisationen, die APIs kommerzieller Webkonzerne nutzen, wird es keine neue Erkenntnis sein, dass ihr Schicksal partiell in den Händen des Plattformanbieters liegt. Die Causa Twitter verschafft dieser Tatsache jedoch neue Aufmerksamkeit – besonders weil Twitter bisher zu den besonders flexiblen, offenen Plattformen gehörte. Auch wenn noch lange nicht klar ist, wie weit das Unternehmen aus San Francisco tatsächlich gehen wird, kann es nicht schaden, die eigene Abhängigkeit von kommerziellen APIs auf den Prüfstand zu stellen und einen Plan zu erarbeiten, wie sich diese verringern ließe.

Nachtrag: Passend zum Thema stellt Facebook die APIs des kürzlich übernommenen Gesichtserkennungsdienstes Face.com ein.

(Illustration: stock.xchng/leto)