Import.io verwandelt Websites in Programmierschnittstellen

Import.io erstellt aus den Daten herkömmlicher Websites eine API, also eine machinenlesbare, weiter verarbeitbare Version. Import.io wurde auf der Disrupt Europe Konferenz vorgestellt:

To turn a web page into a developer-friendly API (in this case, that meaning something which developers can use to programmatically pull selected chunks of data from a page), import.io provides what is essentially a bespoke, sandboxed browser.

You load the browser, open the URL for the page you’re interested in turning into an API, then start selecting the specific elements of the page (like, say, each result on a search page) that you want to be able to extract. After you’ve picked a few elements, import.io starts to figure out which data you’re aiming for. Hit save, give it a name, and bam — you’ve got your API. This data can also be exported as HTML, CSV, or XLS.

With their new Data Factory, import.io is mostly gettin’ rid of the need for that standalone browser, and doing away with much of the clicking. While they will continue to offer the standalone browser option, they’re also launching a Chrome extension that adds an import.io button to your browser.

Das ist eine typische Art, wie das Web sein Potential entfalten kann. ‘Small pieces loosely joined.’

Und es ist die Art, gegen die sich Deutschland mit seiner Gesetzgebung stellt, namentlich dem Presseleistungsschutzrecht. Tatsächlich könnte Import.io wegen des Presseleistungsschutzrechts besonders in Deutschland größere Probleme bekommen, auch wenn sie sich selbst nur als Leitung, als ‘pipe’, verstehen.

Google, Facebook, Twitter und LinkedIn setzen bei Werbegeschäft auf APIs

TechCrunch:

What Google and Facebook found, and Twitter and LinkedIn are now exploring, is that by offering programmatic access to their ads inventory, third parties solve the problems for them.

In exchange, the platforms allow providers of full-service advertising or ad tool licenses to earn a margin. Typically that comes in the form of a 10 percent to 20 percent cut of total spend by clients that typically goes down the more they spend. Otherwise the margin comes by charging a "cost per action" where clients pay a certain amount per click, download, or certain level of downstream engagement, and the provider keeps the difference between what they paid and what they charged. Sometimes there’s a monthly fee, too. Twitter refused to specify whether there were any restrictions for businesses built on its new ads API, saying "We’re not commenting on partnership terms."

Regardless, the idea is for the platforms to share the wealth, and thereby align their goals with the ad tool and service providers. This way they both can make a fortune when the third parties evangelize the channel. And my oh my can ads APIs bring in the dough.

APIs sind eine skalierende, und deswegen im Zweifel vorzuziehende Form der Geschäftsentwicklung.

Mit der damit verbundenen Aufgabe von Kontrolle haben sich deutsche Webdienste traditionell immer schwer getan, was zu weniger APIs und zu weniger damit verbundenen (Plattform-)Erfolgen geführt hat.

Twitter unterbindet Senden von Tweets an IFTTT und will sich offensichtlich komplett abkapseln

Ab den 27. September werden IFTTT-Rezepte, die Tweets an Facebook, Evernote und andere Dienste schicken oder etwa auch in Dropbox archivierbar machen, nicht mehr funktionieren.

IFTTT-CEO Linden Tibbets in einer Email an Nutzer des Dienstes:

In recent weeks, Twitter announced policy changes* that will affect how applications and users like yourself can interact with Twitter’s data. As a result of these changes, on September 27th we will be removing all Twitter Triggers, disabling your ability to push tweets to places like email, Evernote and Facebook. All Personal and Shared Recipes using a Twitter Trigger will also be removed. Recipes using Twitter Actions and your ability to post new tweets via IFTTT will continue to work just fine.

Das heißt, alles, was Tweets aus Twitter herauszieht, wird verboten; was Inhalte in Twitter hineinführt, bleibt erlaubt.

IFTTT erlaubt das Verbinden von Diensten mit verschiedenen Triggern und auswählbaren Aktionen. Dadurch lassen sich verschiedenste Dienste intelligent und trotzdem einfach miteinander verbinden. Ich habe IFTTT zum Beispiel dafür genutzt, Tweets an Facebook und App.net weiterzuleiten und habe zum Beispiel auch IFTTT genutzt, um Tweets weiterhin an LinkedIn zu senden, obwohl Twitter die Kooperation mit LinkedIn beendet hatte.

Dank IFTTT blieb Twitter das Zentrum meines Mikroblogging-Workflows. Das ändert sich nun. Wahrscheinlich werde ich dafür auf App.net umsteigen, wo ich bereits einen Account habe und das bereits dank IFTTT-Channel für Endnutzer rudimentär programmierbar ist. Mit dem Ende der IFTTT-Rezepte, die das Extrahieren von Tweets erlauben, stirbt enorm viel von der Attraktivität von Twitter für mich ab. Das dürfte vielen Vielnutzern ähnlich gehen.

Im Verbund mit den Client-Beschränkungen und der Entfernung der  Kontaktabgleichungen auf anderen Diensten ist das Ende dieser IFTTT-Trigger ein weiterer Beweis dafür, dass sich Twitter tatsächlich sehr stark abkapseln will. Das überrascht mich obwohl ich seit Jahren über diese Entwicklung schreibe, denn ich bin immer davon ausgegangen, dass die IFTTT-Nutzung von Twitter-Usern so gering ist, dass sie für Twitter keine Rolle spielt und ihnen das deswegen herzlich egal ist.

Twitter scheint den Strategieschwenk aber kompromissloser durchziehen zu wollen, als viele bisher angenommen hatten. Was meine Theorie unterstützt, dass Twitter großen Wert auf die Multiplikatoren legt, die man unbedingt auf Twitter, und zwar nur auf Twitter, halten will. (Etwas, das meines Erachtens nach hinten losgehen wird.)

Das Endziel von Twitter ist jetzt klar: Tweets dürfen nicht mehr Twitter verlassen.

Der Aufstieg von Twitter dank dessen API ist beispiellos, nun wird uns Twitter ein weiteres Mal eine beispiellose Geschichte liefern, deren Zeuge wir werden können. Dieses Mal lediglich in die andere Richtung.

Siehe zur Entwicklung von Twitter:

Twitters Kampf gegen die eigene Plattform geht in die nächste Runde

Twitter hat am letzten Freitag neben dem Ende der Kooperation mit LinkedIn bekanntgegeben, dass in den nächsten Wochen striktere API-Regeln eingeführt werden.

AllThingsD berichtet über die wahrscheinlichen Konsequenzen, die ein weiteres Ausbluten der Twitter-Clients bedeuten könnten:

While ending the LinkedIn deal was big, I’ve heard from several sources that we should expect more of the same in the not-too-distant future. Just give a close read to product manager Sippey’s blog post, which went up just minutes before LinkedIn’s post. Sippy’s missive contains some especially strong wording, a harbinger of what’s to come for other developers:

“…we’ve already begun to more thoroughly enforce our Developer Rules of the Road with partners, for example with branding, and in the coming weeks, we will be introducing stricter guidelines around how the Twitter API is used,” Sippey wrote.

Das ist lediglich die nächste Runde des Kampfes, den Twitter gegen die eigene Plattform führt, weil sie in ihrer aktuellen Form nicht mehr mit dem gewählten Geschäftsmodell kompatibel ist. Warum Twitter das macht und warum es für den Dienst nicht die beste Richtung ist, hatte ich in den letzten Jahren seit der Übernahme des Twitter-Clients Tweetie bereits mehrfach ausgeführt.

Hier die Kurzform: Das auf Werbung setzende Geschäftsmodell setzt voraus, dass die User die Werbung auch sehen. Wer weder die Website noch einen der offiziellen Clients benutzt, bleibt außen vor. Ab einem bestimmten Anteil an Nutzern wird das für Twitter inakzeptabel. Twitter muss also entweder die über Clients stattfindende Nutzung seines Netzwerks mit den eigenen Angeboten dominieren oder sie anderweitig kontrollieren. Daraus folgt der Verlust des Mehrwerts der Plattform für das Unternehmen wie seine Nutzer.

Der höchstwahrscheinlich nächste Schritt von Twitter, den ich seit längerem erwarte: Twitterclient-Anbieter, die mit ihren Angeboten eine normale Twitter-Nutzung abdecken, müssen die Werbeformen und andere ‘Features’ wie etwa Trending zwingend auf eine von Twitter vorgegebene Art integrieren. Angekündigt wird das indirekt bereits mit dem PR-Geschwurbel der ‘consistent Twitter experience’. Wie diese Vorgabe aussehen wird? Analog zu denen in den offiziellen Twitter-Clients. Twitter macht bereits über die Hälfte der Werbeeinnahmen über mobile Wege (Website, eigene App). Auf Smartphones dominieren Clients noch mehr als am Desktop. Der Schritt war unvermeidbar für ein rein auf Werbung fokussiertes Twitter.

Den Niedergang der Twitterplattform verfolge ich seit April 2010. Hier die Analysen in chronologischer Reihenfolge:

Das Problem für Twitter: Die für das Geschäftsmodell notwendige stärkere Kontrolle des User Interface steht diametral der Position von Twitter im Internet gegenüber.

Sichtbar wird das etwa am ersten Opfer, der Kooperation mit dem Businessnetzwerk Linkedin. Natürlich will Twitter lieber nicht, dass Tweets auf Linkedin statt auf dem werbefinanzierten Twitter gelesen, kommentiert und weiter verarbeitet werden. Aber erstens ist das Senden von Tweets an Linkedin dank Diensten wie ifttt ohnehin auch weiterhin einfach möglich, und zweitens, was wesentlich wichtiger ist, gehört dieses Multihoming für Poweruser zu den wichtigeren Eigenschaften des Mikrobloggingdienstes.

Das Dilemma: Twitters Position als einfacher Dienst ist auf die externen Erweiterungen über die API angewiesen. Jede kleinste Änderung am Kernprodukt kann sich sofort in der Nutzung bemerkbar machen und weitreichende Auswirkungen haben. Kein anderer Dienst, der auch nur ein Zehntel der Größe von Twitter erreicht hat, stand je vor diesem Problem in dieser Größenordnung.

Wahrscheinlich haben auch die Risikokapitalgeber diese Sonderstellung von Twitter bei ihren Bewertungen ignoriert. (Bei aller persönlicher Begeisterung dem Dienst als Nutzer gegenüber erschien mir Twitter immer als der am extremsten überbewertete Dienst der Web2.0-Ära. Bemerkenswerterweise sehen das bis heute die wenigsten Beobachter ähnlich, obwohl die Zeichen immer deutlicher werden.)

Diese Sonderposition von Twitter macht eine vertikale Integration strategisch genau so gefährlich wie das für andere Dienste offensichtliche Geschäftsmodell Werbung. Twitter hätte ein Grundstein der Webarchitektur werden können. Es hätte Geschäftsmodelle wie Yammer verfolgen können, das just für eine Milliarde US-Dollar von Microsoft übernommen wurde. Twitter hätte, genauer gesagt, in jede Richtung gehen können, die das asymmetrische Followerprinzip erlaubt; von Instagram bis Moped. Auch mit Nebenprodukten, die das Haupttwitter nur noch als Distibutionskanal und Identitätshub nutzen. Das alles wäre auf den ersten Blick riskanter erschienen, aber mit einem konsequenten Plattformansatz bei all diesen Richtungen aller Voraussicht nach erfolgreicher gewesen als die seit längerem eingeschlagene werbezentrische Richtung, die offensichtlich diesen Sommer zum lange erwarteten großen Clash führen wird. Gemeinsam mit Werbung als einer Einnahmequelle von vielen hätte Twitter sich mit diesem Ansatz tief in das Web verankern können. (Etwas, dass das aus unerfindlichen Gründen sehr viel stärker kritisierte Facebook erfolgreich macht.)

Tatsächlich scheint es laut Dalton Caldwell intern bei Twitter zwischen diesen zwei Ansätzen eine Debatte gegeben zu haben, deren Ausgang heute bekannt ist:

As I understand, a hugely divisive internal debate occurred among Twitter employees around this time [ca. 2008/2009]. One camp wanted to build the entire business around their realtime API. In this scenario, Twitter would have turned into something like a realtime cloud API company. The other camp looked at Google’s advertising model for inspiration, and decided that building their own version of AdWords would be the right way to go.

As you likely already know, the advertising group won that battle, and many of the open API people left the company.

Dalton Caldwell kommt zu dem gleichen Schluß, zu dem auch ich vor einiger Zeit gekommen bin:

While I can understand why the latter camp wanted to build an ad-based business, the futurist in me thinks this was a tragic mistake. If you are building an advertising/media business, it would then follow that you need to own all of the screen real-estate that users see. The next logical step would be to kill all 3rd-party clients, and lock down the data in the global firehose in order to control the “content”.

Dass Twitter die Ankündigung an einem Freitag Nachmittag veröffentlicht hat, zeigt, dass das Unternehmen weiß, welchen Shitstorm bei Entwicklern und Usern die eingeschlagene Richtung mit sich bringen wird. Eine gefährliche Richtung: Die Monetarisierung steht bei Twitter heute vor den Interessen der Entwickler und der User, und damit also der Plattform. Die Plattform hat Twitter groß gemacht. Das weiß man spätestens seit 2007. Ein plattformfeindliches Geschäftsmodell könnte bedeuten, dass Twitter wieder in die Bedeutungslosigkeit abrutscht.

6.000 APIs

Programmable Web zählt mittlerweile 6.000 APIs von Internetdiensten:

One in three social APIs is less than a year old. Already in 2012 we’ve seen well over 100 of the 691 social APIs added to our directory. That puts us on pace for 325 added by the end of the year, which would be about 50% more than were added in 2011.

APIs

In der Tat ein programmierbares Web.

Die exponentiell steigende Anzahl der APIs macht auch das Web selbst exponentiell komplexer.

Box OneCloud ist Dateimanagement für die Post-PC-Welt

Box ist neben Dropbox der spannendste Dienst in Sachen Onlinespeicher, die im von Cloud-Computing bestimmten Post-PC-Zeitalter nach und nach das Dateimanagement an sich neu zu denken.

Box hat in den letzten Jahren bereits eine Plattform aufgebaut, die über APIs erlaubt, bearbeitenderweise auf die auf Box gespeicherten Dateien zuzugreifen.

Mit OneCloud hat Box jetzt ein Angebot vorgestellt, dass sich konkret an mobile Apps richtet und auch dort eine solche Plattform etablieren soll. Damit bekommen mobile Apps plattformübergreifend die Möglichkeit, auf Dateien zuzugreifen.

TechCrunch:

Box OneCloud represents the company’s vision for how businesses and their workers will access, edit and interact with documents on their mobile devices, including both smartphones and tablets. In basic terms, Box OneCloud is a new set of APIs and an all new directory for mobile that will introduce users to applications powered by Box within the Box interface. “This is how the enterprise use applications in post-PC world,” Levie says emphatically.

Today, the company is debuting 30 Box OneCloud apps that help users discover, create and share content from their mobile devices. Partners that will be launching apps include Podio, Quickoffice, Adobe EchoSign, Nuance PaperPort Notes and PDF Expert. With new APIs, content updates for each app are instantly stored and secured on Box. Partners provide a variety of services that are complimentary to Box’s storage offerings including advanced document editing, secure e-signature, digital note taking and PDF annotation.

Noch wird dafür die Box-App benötigt. Es dürfte aber bereits auf der Roadmap stehen, diese Synchronisationsplattform im Hintergrund laufen zu lassen. Sprich: Auth statt App.

Box arbeitet mit OneCloud letztlich am gleichen Ziel wie Apple mit iCloud: Das Dateimanagement für eine Welt neu zu denken, in der man permanent Internetzugang hat, jeder mehrere Geräte benutzt und potentiell mit anderen zusammenarbeitet.

Auch bei Box ist man sich dessen bewusst. Venturebeat:

[Box VP of platform Chris Yeh] said that this is an exciting development for the mobile cloud because no one has achieved anything like it yet. A close comparison, Yeh said, might be Apple’s iCloud solution. But iCloud is squarely focused on consumers rather than businesses and does not give users serious file management abilites.

Die Unterscheidung zwischen Consumer und Enterprise ist allerdings auf lange Sicht belanglos.

Der einzige, aber entscheidende Unterschied zwischen den beiden Angeboten: Während iCloud auf die Apple-Welt beschränkt sein wird, wird OneCloud überall laufen können, wo es von Drittentwicklern unterstützt wird.

iCloud wird den Vorteil einer tiefen, reibungslosen Integration in alle Apple-Geräte und dort laufender Apps für sich verbuchen können. Auf der anderen Seite kann Box’ OneCloud etwas bieten, was iCloud immer fehlen wird: Plattformagnostik.

Falls das bis hier noch nicht klar geworden ist: Box hat meines Erachtens alle Voraussetzungen, um ein Majorplayer in der Post-PC-Ära zu werden.

Je nach Definition sind sie das bereits:

Box, which now has over 10 million users with more than 200 million files accessed via Box each month, is a cloud storage platform for the enterprise that comes with collaboration, social and mobile functionality. Box has evolved into more than just a file storage platform, and has become a full-fledged, multi-platform collaborative application where businesses can actually communicate about document updates, sync files remotely, and even add features from Salesforce, Google Apps, NetSuite, Yammer and others. The company says 80 percent of the Fortune 500 are using Box.

APIs als wichtige Werkzeuge des Datenjournalisten

Kai Biermann auf dem Data Blog von Zeit Online:

Seit einiger Zeit entwickelt sich auch in Deutschland eine neue Arbeitsweise, Daten-Journalismus genannt. Noch beschränkt sich der auf kleine Teams, die frei oder für ein paar große Verlage arbeiten. Das aber wird sich ändern, und APIs werden schon bald eines der wichtigsten Instrumente von Journalisten sein. Sie werden die Bedeutung haben, die früher das Telefon für die Arbeit von Medien hatte und die derzeit Google hat. Denn sie sind ein machtvolles Werkzeug, um an Informationen zu gelangen.

Programmierschnitstellen (APIs) ermöglichen den Zugang zu Informationen. Und der ist der erste Schritt des Journalisten.

Google+ bekommt keine Read/Write-API, weil Google kein Streamdesign kann

Vic  Gundotra, der für Google+ verantwortliche Manager, gegenüber TechCrunch:

The problem with allowing third-party apps to contribute content is that “if ranking is not good in the stream”, single apps could publish too many posts and push out authentic content from the people you follow. Gundotra said that “When Google opens an API, we want you to know we’re not going to revoke access.” Moderator Guy Kawasaki quipped that developers are used to rapidly changing APIs from Facebook, but Gundotra snapped back, “We hold ourselves to a higher standard”.

Auf der einen Seite kann man Google verstehen. Google hat sich mit Google Buzz, dem Google+-Vorgänger, auf vielerlei Arten verbrannt. Unter anderem wurde Google Buzz vorgeworfen, dass der Stream von automatischen Updates überschwemmt wurde.

Das will man für Google+ nicht. Was Google nicht erwähnt: Die Überflutung des Streams kommt nicht durch eine Read-/Write-API, sondern durch schlechtes Streamdesign. Wie Facebook und wie andere Plattformen mit Stream und APIs auch, muss Google+ einen Weg finden, wie es die Funktionalität anbieten kann, so dass die Nachteile die Vorteile überwiegen.

Denn nur mit Read/Write-API bekommt man eben eine blühende Plattform. Und last not least die Poweruser, die man auf einem teilöffentlichen Angebot, das auch von der Verbreitung von Inhalten lebt, dringend(!) benötigt. Genau die letzte Usergruppe verliert man ohne APIs, weil nur mit APIs effizientes Arbeiten, wozu auch Multihoming gehört, möglich wird.

Offensichtlich ist man bei Google aber noch nicht so weit.

Aber warum nicht zugeben, dass man nicht weiß, wie man das am besten implementiert oder, dass man findet, es sei noch zu früh? Stattdessen nutzt Google die Gelegenheit, auf Konkurrenten einzuhauen, die sehr viel erfolgreicher in dem selben Bereich sind.

Was wurde aus ‘release early, release often’? Was wurde aus dem Google, das die ewige Beta für neue Produkte salonfähig gemacht hat? Was wurde aus der Erkenntnis, dass gute Produkte nicht vom Himmel fallen, sondern durch ständige Iteration entstehen, die gerade beim zahlenfixierten Google auch vom Userfeedback lebt?

“We hold ourselves to a higher standard.”

Der Google-Standard, wie man ihn aus der Wir-sind-offen-Argumentation bereits kennt: Doppelmoral, Arroganz und Bullshit, mit einer kräftigen Brise Unfähigkeit.

Xing wird für API auf manuelle Freigabe setzen

Xing wird für die geplante Programmierschnittstelle auf händige Kontrolle und Freischaltung setzen. Martin Weigert auf netzwertig.com:

Xing wird in jedem Fall Personal dazu abstellen, übermittelte Anwendungen mit Xing-Integration einer Qualitätsprüfung zu unterziehen, BEVOR die API für sie freigeschaltet wird.

Irgendjemand überrascht? Ich nicht.

Das wird natürlich nicht funktionieren, denn der größte Konkurrent LinkedIn (Disclosure: Ich besitze Aktien.) wächst auch aufgrund seiner immer stärker verbreiteten Anbindung mit selbständigen Diensten jeder Art. Ein deutsches Netzwerk mit dem Bruchteil der User, das nur noch in Deutschland und Österreich führend ist?

Dafür zu entwickeln, wenn nicht im Vorfeld klar ist, ob die investierten Kosten überhaupt sinnvoll angelegt sind, weil die App vielleicht nicht zum “Kontext” des Netzwerkes passt, dürfte nur für wenige verlockend sein.

Xing fährt zwar noch Rekordumsätze ein, zog sich 2011 aber endgültig von allen nicht deutschsprachigen Märkten zurück.

Siehe auch:

Verteiltes Social Network: EyeEm-Fotos jetzt auch vollwertige Facebook-Fotos

Das Berliner Fotosharing-Startup EyeEm folgt Instagram und macht seine Fotoimports in Facebook zu vollwertigen Fotos mit eigenem Foto-Album:

From today on, EyeEm offers you to share your photos big time on Facebook. This means that whenever you choose to share an EyeEm image on Facebook, it will now appear full-sized in the news feed and, if you have Timeline, the photos will be displayed beautifully on your profile. All photos will be collected in the photo album “EyeEm Photos” and each photo caption also includes the URL to your image on EyeEm.

Als Instagram den Schritt letzte Woche bekannt gab, schrieb ich:

Statt selbstgehosteter vernetzter Software auf eigenen Servern sind es Webdienste von Unternehmen, die sich via APIs verknüpfen und so den Anfang für ein verteiltes Social Network legen, für ein wahres Social Web.

Je mehr Fotodienste dem Vorbild von Instagram und EyeEm folgen, desto weniger können sich andere Fotodienste den Luxus erlauben, darauf zu verzichten. (klassischer Sog zweiseitiger Märkte)

Damit könnte wir nun endlich, 2012, den Anfang von etwas sehen, über das schon lang diskutiert wird.

Der nächste Schritt wären API-Standards. Anfang 2010 schrieb ich:

Die APIs sind die Links des Social Web.

Man stelle sich eine Welt mit umfangreichen, weit verbreiteten API-Standards vor. Das Web wäre nicht wiederzuerkennen.

Heute sehen wir vor allem noch proprietäre APIs. Bei Twitter zum Beispiel. Dort sieht man auch bereits, wie wenig die Entwicklung zu Standards in den meisten Bereichen aufzuhalten ist: Die Twitter-API wird bereits über Reverse Engineering – siehe WordPress- und Tumblr-Unterstützung der Twitter-API – Schritt für Schritt zum Standard.

Wer über die Implikationen nachdenkt, sieht die Richtung, in die das Web die nächsten 10 Jahre gehen wird.

Wenn Instagram und co. bereits die Facebook-API implementiert haben, wäre es für ein neues Startup, das Funktionen rund um Fotos anbieten will, sinnvoll, die entsprechenden API-Funktionen via reverse engineering zu kopieren, um mögliche Einbindungen für andere so kosteneffizient wie möglich zu gestalten…

EyeEm versucht etwas, an dem so ähnlich das US-Startup Color schnell gescheitert ist: Fotos rund um Plätze, Themen und Events gruppieren als Alleinstellungsmerkmal. Colors ursprüngliches Konzept scheiterte unter anderem an einer dummerweise fehlenden Facebook-Anbindung.

Sind Like-Button-Gegner gegen ein dezentrales Web?

Ist denen, die gegen eine möglichst einfache und damit datenweiterreichende Einbindung des Like-Buttons argumentieren, eigentlich klar, dass sie gegen Dezentralisierungstendenzen im Web argumentieren?

Jede Einbindung von Funktionen eines Dritten in eine Website wird Daten an diesen Dritten weiterleiten. Die Zwei-Klick-Lösung von heise (Erst nach dem Ja-ich-will-sharen-Klick erscheint der eigentliche Like-Button.) ist bestenfalls eine Lösung nur für den Like-Button. Dieser Button ist eine sehr simple Funktion, die 2010 eingeführt wurde.

Was ist mit eingebetteten YouTube-Videos? Was ist mit externen Kommentarsystemen von Livefyre oder, wie hier, Disqus? Soll alles erst nach einem “Ja, zeig mir das bitte.”-Klick eingeblendet werden?

Was ist mit den von Netzaktivisten verzweifelt herbeigewünschten dezentralen Alternativen zu Facebook und co.? Dort würden hinter den Kulissen sehr viel mehr Parteien eine Rolle im Datenverkehr spielen.

Ich bin auf meinem eigenen Server, ein Freund von mir auf seinem eigenen und fünf weitere Freunde von mir nutzen einen Knoten in den USA.  Der Knoten meiner fünf Freunde benutzt zusätzliche Funktionen, die auf meine privaten mit ihnen geteilten Daten zugreifen können und unter anderem von einem neuseeländischen Anbieter bereitgestellt werden. Mein anderer Freund benutzt auf seinem Server Zusatzfunktionen von russischen, französischen, schwedischen und einem Dutzend weiterer Anbieter.

Nach deutscher Like-Button-Datenschutz-Vorstellung darf nichts davon ohne meine explizite Zustimmung passieren.

Man stelle sich etwa die Registrierung auf  einem erfolgreichen Diaspora mit vielen Netzwerkknoten vor:

“Bitte bestätigen Sie mit 1.000 Klicks die Weiterleitung Ihrer Daten innerhalb unseres dezentralen Netzwerks.”

Der Like-Button ist ein Problem? Nein, wie bei Street View ist wieder eine deutsche Debatte das Problem, bei der selbst die meisten netzaffinen Menschen den Wald vor lauter Bäumen nicht sehen.

Denksportaufgabe: Wie soll ein deutscher Datenschutz so umgesetzt werden, dass er den Nutzern ihre Kontrolle gibt ohne die Entwicklung dezentraler Alternativen zu hemmen?

Oder ist das egal und Like-Button-Gegner sind auch Gegner eines dezentraleren Webs?

Das Versagen der offenen Webstandards

Auf Google+ habe ich einen Artikel von Nick Bradbury, unter anderem Entwickler von FeedDemon/NetNewsWire, verlinkt, in dem dieser die Abhängigkeit von Web-APIs und das damit verbundene Problem für Entwickler anspricht:

we’ve also learned that while web APIs enable us to tap into a wealth of data, they can only be relied upon in the short term. The expiration date of software we create has been shortened due to the whims of those who create the web APIs we rely on. [..]

You might think you’re immune to this problem if you only integrate with APIs created by large players such as Twitter, Facebook and Google. But in recent years we’ve seen Twitter switch to a new authentication system, Facebook deprecate FBML, and Google discontinue several APIs. All of these changes have, or will, break existing apps.

The end result is that developers are spending more time upgrading their software to ensure that it continues to work with web APIs they’ve integrated with, and less time adding the features and refinements that would really benefit their customers. That’s a long-term failure, any way you look at it.

Das Zitat hat einen interessanten Dialog zwischen Matthias Pfefferle und Carsten Pötter ausgelöst, in dem Punkte  zum breitflächigen Versagen der verschiedensten, in den letzten Jahren veröffentlichten Webstandards angesprochen werden, die dringend weiter diskutiert werden sollten. Deshalb dokumentiere ich das hier einmal.

Matthias Pfefferle stellt die langlebigen Standards POP3 und SMTP kurzlebigeren Standards wie OpenID gegenüber gegenüber:

Leider verhält es nicht nur mit den APIs der großen Plattformen so! Webstandards im Allgemeinen sind viel zu kurzlebig geworden! Während POP3 und SMTP jetzt über 20 Jahre alt sind hält OpenID beispielsweise keine zwei Jahre mehr durch ohne von einer nicht abwärtskompatiblen Version (aus den eigenen Reihen!) abgelöst zu werden… RSS und ATOM werden durch JSON Versionen ersetzt… RDFa wird schon vor seinem produktiven Einsatz von Microdata abgelöst,

Es ist schon lange nicht mehr attraktiv eine generische Lösung zu bauen oder anzusprechen. In der Zeit die ich brauche um OpenID zu implementieren hab ich mehr als 10 Facebook Clients gebaut und bin immer noch Zukunftssicherer! Das Web ist viel zu kurzlebig geworden!

Carsten Pötter merkt zu recht an, ob man überhaupt von Standards reden sollte, wenn diese sich erst gar nicht durchsetzen bis sie vom nächsten heißen Standardding abgelöst werden:

Ist es dann nicht falsch, von Standards zu reden, wenn sie sich so schnell ändern? Waren wir – ich schließe mich da durchaus mit ein – nicht zu schnell, irgendwelche Ideen und Protokolle als Standards auszurufen?

Wenn man das alles kritisch und vielleicht auch ein wenig bösartig betrachtet, identifizierten die immer 10 selben talentierten Kids im Silicon Valley ein Problem, saßen zwei Nachmittage zusammen und haben einen neuen “Standard” begründet. Grundsätzlich wäre das nicht so schlecht, wenn sie nicht entweder bereits für die großen Firmen im Valley gearbeitet (oder kurze Zeit später dorthin gewechselt wären) und damit – gewollt oder nicht – auch deren Anforderungen mit eingebracht hätten.

Wir erinnern uns noch, wie OpenID 2.0 zustande kam? Yahoo wollte Mitglied der OpenID Foundation werden, aber die Version 1.1 von OpenID passte nicht ins Konzept, um eigene Vorstellungen eines Identity Service zu verwirklichen. Die Realität heute: Yahoo spielt fast keine Rolle mehr, die beiden bekannteren Namen des Yahoo Identity Teams sind heute bei Google (Shreyas Doshi) und bei JanRain (Allen Tom). Ach ja, und alle Welt erkannte, dass OpenID 2.0 zu kompliziert, zu komplex,… war.

Es fällt auch auf, dass einfache und für interessierte Laien nachvollziehbare Lösungen immer mehr verschwinden. Du hast sie bereits erwähnt: Microformats, RDFa, Microdata. OpenID 1.1, OpenID 2.0, OpenID Connect. RSS, ATOM, JSON. Irgendwie nicht schön.

Matthias Pfefferle führt die Misslage weiter aus:

ich glaub das trifft den Nagel auf den Kopf: “Waren wir – ich schließe mich da durchaus mit ein – nicht zu schnell, irgendwelche Ideen und Protokolle als Standards auszurufen?”. In den Zeiten in denen #DataPortability und #OpenWeb hip waren und es zum guten Ton gehörte “Standards” einzubauen wurde alles implementiert was von den Jungs der OpenWeb-Fondation als solcher definiert wurde. Dann hat jemandem irgendentwas an dem Format nicht gepasst und es wurde wieder ein neues entwickelt und natürlich auch gleich wieder von allen eingebaut. “Discovery” ist da ein schönes Beispiel: Zuerst setzte man auf HTML und HTTP Header, dann kam XRDS und YADIS, dann wurde XRDS-Simple gebaut, noch bevor XRDS-Simple produktiv eingesetzt wurde, hat man XRD entwickelt, dann kamen well-known und host-meta auf den Plan, dann hat man Webfinger erfunden… und was macht OpenID? Für OpenID Connect wird jetzt gerade wieder alles über den Haufen geschmissen und man arbeitet an “Simple Web Discovery”…

Neben dem Chaos, das das Einbinden offener Standards, oder Möchte-gern-Standards für Entwickler unattraktiv macht, gibt es noch ein weiteres Problem, dem sich das Open Web, das dezentrale Web, gegenüber sieht: Die Protagonisten, also die Fürsprecher und die, welche die Grundlagen entwerfen und weiter entwickeln, haben es bis dato versäumt, einen effektiven Hebel zu erschaffen, um Anreize für alle Seiten zu generieren, die dann zu den virtuosen selbstverstärkenden Effekten führen.

Die im Gespräch angemerkte Kurzlebigkeit der Standards ist das Gegenteil eines effektiven Hebels: Sie treibt die notwendige Entwicklerseite frustriert weg.

Ich bin im übrigen mittlerweile fast der Meinung, dass jede signifikante Weiterentwicklung von Webstandards von Unternehmen wie Google und Facebook kommen wird und muss. Denn in deren Produkten steckt der Hebel schon drin. Das bringt uns allerdings wieder zurück zu den Argumenten von Bradbury zur Abhängigkeit bei Web-APIs..

GoogleMaps wird teurer, und könnte die Onlinekartenvorherrschaft verlieren

Das GoogleWatchBlog fasst die Preis-Änderungen bei Google Maps, die ab 2012 gelten sollen, so zusammen (hatte ich schon heute früh hier verlinkt):

Im schlechtesten Falle kann es, wie auf der Tabelle ersichtlich ist, schon ab 2.500 Abrufen am Tag richtig teuer werden – nämlich bis zu 8$ für 1.000 weitere Abrufe. Und ganz wichtig: Als Abruf zählt nicht nur der komplette einmalige Aufbau der Karte, sondern jedesmal wenn eine Anfrage an den Server geschickt wird – von der Suche auf der Karte über die Routenplanung bis zum Abruf von Sateliten-Fotos. Diese Grenze wird also sehr viel schneller erreicht als es klingt. Abhängig sind die Preise auch von der verwendeten API-Version.

landkartenblog.de über die Preisänderungen bei Google Maps ab 2012:

Dies ist eine Abzocke von Google, sind die wahnsinnigen Preise für gerade mal 1.000 Karteneinblendungen viel zu hoch angesetzt. 1.000 Einblendungen am Tag sind im optimalfall 1.000 Besucher. Auf einer Hotelbewertungsseite sind 3 bis 8 Karteneinblendungen, pro Benutzer noch wenig. Wenn dann dort 30.000 Besucher am Tag kommen, kann man sich denken wie teuer das wird.

Und da alles jetzt viel Geld kostet, hat Google auch noch, vor lauter Irrsinn, eine Begrenzung eingebaut. So wird die API, je nach Version, bei 2.500 oder 25.000 Karteneinblendungen deaktiviert. Also 50.000 Einblendungen (sprich 50.000 Besucher) können es nur maximal werden. Dann ist alles vorbei (bis morgen früh).

Das ist eine interessante, weil eher untypische, Richtung für Google.

Spannend in diesem Zusammenhang wird auch, dass Apple just ein 3D-Mapping-Unternehmen übernommen hat, was auch nicht die erste Übernahme von Apple in diesem Feld war.

Es wird seit längerem gemunkelt, dass Apple die Maps-App in iOS, die zwar von Apple designt wurde, aber mit Google Maps läuft, von Google Maps trennen will. Wenn Apple das erst einmal mit eigenen und eingekauften Daten umgesetzt hat, ist es kein weiter Schritt mehr das einfach auch für das Web anzubieten. (iCloud Maps)

Nur dürfte Apple kaum Interesse am Anbieten einer Web-API haben, wie man sie von Google Maps kennt.

Gemeinsam mit dem Apple-Vorstoß könnten die neuen Preise von Google Maps vor allem kleinere Websitebetreiber zu günstigeren Alternativen treiben, wie das Landkartenblog auch anmerkt:

Eine große Chance bedeutet das jetzt für OpenStreetMap bzw. Openlayers und andere OpenStreetMap Entwickler, dem Platzhirsch Google mit seinem Eigentor, vom Tron zu jagen. Nur muss vor allen OpenLayers, die tolle Möglichkeiten mit der Kartensubstanz von OpenStreetMap weiter ausbauen. Bis 2012 muss man hier das Realisieren, was Google Maps API so stark gemacht hat. Die API muss auch generell für mobile Endgeräte funktionieren, bessere MySQL- und KML-Einbindung und endlich eine API mit Routenplaner, Landkarten und Satellitenbilder.

Ordr.in zeigt, wie eine Plattformstrategie für Essensbestellungen aussieht

Ordr.in, in das just Google Ventures investiert hat, fährt eine klassische Plattformstrategie für Online-Essensbestellungen über seine API (Programmierschnittstelle). TechCrunch:

Ordr.in’s solution has been to parter with 72 local food ordering sites (and counting) across the United States, which let users order from some 7,000 restaurants. It then normalizes all of that data, and gives other apps and services access to it via an API.

It’s this API that lets any app or service integrate food ordering. Say, for example, Netflix wanted to integrate an option to oder dinner alongside your evening streaming movie. With Ordr.in, they could do it. And they have a financial incentive to do so — they get a cut of each transaction (as does Ordr.in).

Wenn man sich den Konkurrenzkampf der deutschen Lieferdienste anschaut, dann ist es wirklich erstaunlich, dass den Gründern der deutschen Lieferdienste nur juristische Scharmützel einfallen, um sich gegen die Konkurrenz zu wehren.

Dabei zeigt Ordr.in, wie man sich potentiell im Markt verankern kann. Ganz ohne Justiz und Schlammschlacht und dafür mit einer API und einer Plattformstrategie.

Man muss nur einmal etwas größer denken und über den lokalen Markt hinausschauen.

Programmierer erstellt Blog aus Inhalten von Google+ mittels API

Der Entwickler Daniel Treadwell hat aus seinen öffentlichen Inhalten auf Google+ ein Blog mit Hilfe der Programmierschnittstelle erstellt.

Das Blog kann man hier sehen. Wie das für den eigenen G+-Stream aussehen würde, kann man testen, indem die Google-ID an die Blogadresse angehangen wird. Hier sieht man zum Beispiel meinen Stream.

Das Ganze ist noch eine recht simple Umsetzung, zeigt aber, wohin die Reise gehen wird.

Interessant wird es, wenn ein WordPress-Plugin erscheint, das Inhalte von Google+ herausziehen kann.

Dann kann man etwa die sehr guten Vernetzungs- und Verbreitungsmöglichkeiten von Google+ nutzen, ist aber nicht auf Google+ für Zugang und Archivierung der eigenen Inhalte angewiesen.

Center Networks über eine mögliche Umsetzung eines solchen Plugins:

Perhaps the right solution is similar to how Disqus handles comments – when you use the Disqus comment plugin on a WordPress blog, Disqus saves the comment to Disqus but also back to the source blog so you can remove Disqus and keep all of the comments left on your blog. The Google+ plugin could work the same way allowing you to remove the plugin but keep the content created on Google+.

Man benötigt nicht viel Phantasie, um sich auszumalen, was eine Integration zwischen Google+ und dem Google-Dienst Blogger bedeuten würde. Zum ersten Mal seit Tumblr wäre das eine tatsächliche konzeptionelle Weiterentwicklung des Bloggens.

Und die Unterschiede zwischen Google+ und Blogs, sie verschwimmen langsam aber sicher.

1. Google+-API veröffentlicht, kann nur öffentliche Updates lesen

Google hat die erste Google+-API veröffentlicht. Die API kann nur öffentliche Postings lesen.

Das ist also ein sehr zaghafter Schritt von Google, der außer mehr Öffentlichkeit und Sichtbarkeit für Nutzer und öffentliche Inhalte keinen Einfluss auf die Nutzung von Google+ selbst haben wird. (Eine API, die schreiben kann, wird das genaue Gegenteil sein: Neben Clients wird dann auch das automatische Posten mit Apps hinzukommen. Wahrscheinlich lässt sich Google deshalb damit Zeit.)

Dave Winer hat allerdings nicht ganz unrecht:

They should just support RSS, and forget APIs to read publicly available content. All that’s going to happen now is people are going to write apps that produce feeds from their API so they can hook into the reading tools that were written a hundred years ago, like the one Google itself has. What is it about BigCo’s that keep them from paying any attention to things they didn’t invent?

Auch eine gute Nachricht: Atom/RSS-Feeds kommen bald.

Die ersten Reaktionen von anderen Entwicklern reichen von “umständlicher als die Facebook-API” bis hin zu “gute API-Dokumentation“.

Nischenangebote werden zu Plattformen. Heute: Kik und RunKeeper

Egal in welcher Nische ein Startup aktiv ist: Wenn es erfolgreich ist, ist ab einem gewissen Punkt der nächste logische Schritt der zur Plattform. Mit einer Programmierschnittstelle (API)  lässt sich im Idealfall der Marktanteil weiter ausbauen und verfestigen, weil so eine Andockstelle für Randangebote von Drittanbietern entsteht, die insgesamt den Markt besser abdecken können als es der eigentliche Anbieter jemals könnte.

Diese Entwicklung kann man vielerorts mittlerweile auch abseits der bekannten Beispiele (Facebook, Twitter etc.) beobachten. Der ortsbasierte Dienst Foursquare etwa war von Anfang an darauf ausgelegt, eine mobile Plattform zu werden. (Die Berichterstattung über Foursquare a la “Checkins und Badges? Was wollen die denn damit erreichen?” deutet darauf hin, dass die wenigsten Beobachter Produktlebenszyklen bei Webstartups einbeziehen oder überhaupt verstehen. Am Anfang steht in der Regel erst einmal die Anreizschaffung für die Endnutzer.)

Zwei jüngere Beispiele zeigen recht schön, dass sich diese Entwicklung mehr oder weniger auch in kleineren (RunKeeper) wie potentiell größeren (Kik) Nischen vollzieht.

1. Beispiel: Die auf mehreren Plattformen vertretene mobile Messaging-App Kik hat ein SDK (Software Development Kit) herausgebracht, mit dem das Andocken für andere mobile Apps möglich wird.

ReadWriteWeb über Kiks SDK:

The SDK, available for both iOS and Android, is simple to use, says the company. It can be integrated into your app in just 10 minutes, they claim. All you have to do is drop in the library and paste in some code. The rest is handled by the Kik API.

When users share something from the app with a friend not using Kik, it offers to take them directly to a download page for the application. So yes, this is sort of back-handed way for Kik to boost its own app installs. Still, if you have an app that could benefit from this type of sharing mechanism, it may be worth a look.

2. Beispiel: RunKeeper ist eine mobile App, mit der man seine Joggingtouren tracken kann. Vor einem Monat hat RunKeeper mit der Veröffentlichung einer API sich für Entwickler geöffnet.

GigaOm über die Health Graph API:

RunKeeper, which began as a way to track runs for users, is now poised to become a full-fledged fitness network with the release of a Health Graph API that lets developers and device makers tap into its growing data set and community. The API opens up the RunKeeper experience enabling a host of apps and devices to publish to RunKeeper’s FitnessFeed and contribute to its Health Graph.

Die Ergebnisse:

Kik: Aus einer einfachen Messaging-App wird eine Plattform für das schnelle mobile Austauschen von Inhalten jeglicher Art.

RunKeeper: Aus einer nützlichen mobilen Fitness-App wird eine Community und Plattform für Fitnessaktivitäten und deren Abbildung in mobilen Apps.

Der Club der API-Milliardäre

Seit einigen Jahren schreibe ich über die steigende Bedeutung von Programmierschnittstellen (APIs) im Web. Manchmal sagen Zahlen mehr als Worte:

Api milliardaere

Weitere Fakten von Programmable Web:

Other API Billionaires may only measure in billions per month, but its as impressive given their own scale. Hardly a Google or Facebook, NPR used its API and the 1.1 billion API-delivered stories to double its web traffic. The single Netflix API supports hundreds of devices. And the Salesforce.com API, which makes up 50% of the company’s traffic, is often credited with the Software-as-a-Service pioneer’s success.

Programmierschnittstellen werden von den meisten deutschen Startups leider immer noch sträflich vernachlässigt. Rühmliche Ausnahme ist SoundCloud mit seiner populären API.

LinkedIn baut Plattform massiv aus. Was ist mit XING?

LinkedIn-Dev

Das 100 Millionen User große Business-Network LinkedIn baut seine Plattform nach dem Vorbild von Facebook weiter aus:

In addition to support for OAuth 2.0 and Javascript APIs, this release also includes our new Plugins — self-contained features that can be customized and embedded on your website with minimal effort. Within minutes, you can now enhance your site with LinkedIn’s professional network.

LinkedIn bekommt damit auch einen eigenen Like-ähnlichen Button für das gesamte Web und weitere spannende Erweiterungen:

The plugins include:

Sign In with LinkedIn, which makes it easier for users to authenticate or register for your site using their LinkedIn identity
Share, a button which enables users to share your website with LinkedIn’s professional audience
Member Profile, which brings LinkedIn profiles to your site
Full Member Profile, which brings larger, more detailed LinkedIn profiles to your site
Company Profile, which displays key company info at-a-glance
Company Insider, which shows rich company data from several different views
Recommend, a button which enables users to recommend your products and drive traffic back to you

Es ist die Öffnung nach außen, wie es sie Facebook vor einem Jahr vorgemacht hat.

LinkedIn wird damit zum Infrastrukturanbieter für Social-Graph-Daten im Business-Bereich wie es das Facebook bereits für private Vernetzungen ist:

While developers can build applications that run on LinkedIn itself, perhaps the most promising part of the platform involves the ability to access LinkedIn data from beyond the LinkedIn site, on other sites and apps. Think of how Facebook has used Facebook Connect and its various social plugins to expand beyond Facebook.com, approaching its vision of becoming your social identity wherever you are on the Web. LinkedIn seems to be attempting something similar with your professional identity.

Als Login-Angebot ist LinkedIn bereits auf dem Vormarsch. (Im Gegensatz zu XING.)

Diese Entwicklung ergibt Sinn. Viele Menschen bevorzugen die Trennung zwischen geschäftlichen und privaten Kontakten. Damit gibt bzw. gab es im Web ein Vakuum für ein der Facebook-Plattform ähnliches Angebot im geschäftlichen Bereich.

Und das bringt uns zu XING, dem deutschen Konkurrenten von LinkedIn.

XING ist im deutschsprachigen Raum recht etabliert aber nicht darüber hinaus. LinkedIn ist der große globale Konkurrent von XING. LinkedIn ist außerdem dabei, technologisch und konzeptuell XING weit hinter sich zurückzulassen.

Woran erinnert uns das? Genau. An Facebook und StudiVZ.

StudiVZ war der Marktführer in Deutschland. Facebook startete 2007 seine Plattform. Und langsam aber sicher gewann Facebook weltweit immer mehr Nutzer und Entwickler und war recht früh bereits überhaupt nicht mehr in der selben Produktkategorie wie StudiVZ oder wer-kennt-wen. Heute steht Facebook auch in Deutschland an der Spitze. Und das hat Facebook in erster Linie der eigenen Plattformstrategie zu verdanken.

Das Traurige an der Tatsache, dass sich diese Geschichte bei XING und LinkedIn zu wiederholen scheint, ist, dass XING die Zeichen der Zeit mit Facebooks enormen Plattformerfolg ebenso sehen konnte wie LinkedIn.

XING hätte mit einem konzeptionellen Befreiungsschlag genau diese Plattformstrategie vor LinkedIn umsetzen können, um dem großen US-Konkurrenten endlich etwas entgegensetzen zu können. Stattdessen ist es das (in anderen Ländern außerhalb Deutschlands) zahlenmäßig bereits übermächtige US-Netzwerk, das sich jetzt anschickt, genau so wie Facebook sich in seiner Nische sicher zu verankern.

Könnte XING mit einem ähnlichen Plattformansatz noch erfolgreich nachziehen?

Die Chancen dafür sind mittlerweile klein, bestehen aber noch. Aber das Zeitfenster hat sich fast geschlossen. Einen Erfolg einer vergleichbaren Plattform von XING zu diesem Zeitpunkt ist fast schon ausgeschlossen.

XING wird aber wahrscheinlich daran auch zunächst gar kein Interesse haben. Dort glaubt man laut Interview des XING-Chefs vom März daran, das Kerngeschäft verdoppeln zu können. Man wird notfalls behaupten, dass hierzulande im Business-Bereich kein Bedarf an dieser technischen Spielerei besteht. Und man wird LinkedIn beim zunehmenden Erfolg zusehen und irgendwann später doch etwas ähnliches machen, wenn die eigenen Zahlen stagnieren und dann langsam fallen. Eben wie wir es bereits von dem anderen großen ehemaligen deutschen Marktführer im Social-Network-Bereich, studiVZ, und seinem Verhalten gegenüber Facebook-Innovationen kennen.

Das Fazit? XINGs Tage sind gezählt. Selten wurde es so offensichtlich wie diese Woche.

Die SoundCloud-API und andere deutsche APIs

Vor einigen Wochen hatte ich SoundCloud als das einzige deutsche Startup bezeichnet, das das Zeug hat, zu einem globalen Player zu werden (wenn es das nicht bereits ist). SoundCloud scheint in allen Feldern aktuell alles richtig zu machen. Und das nicht zuletzt auch bei der API. Erstaunlicher- und verwunderlicherweise gibt es auch 2011 noch ausgesprochen wenige offene und erfolgreiche APIs von deutschen Startups.

Wie wichtig eine Programmierschnittstelle sein kann, sieht man exemplarisch an der SoundCloud-API. SoundCloud selbst listen in ihrer App Gallery all die unzähligen, die API nutzenden Applikationen auf. Dank der API gibt es mittlerweile zum Beispiel einige iPhone- und iPad-Applikationen, mit denen man Musik machen oder aufnehmen kann und diese Musik anschließend direkt bei SoundCloud hochladen kann.

Bei einer erfolgreichen API gewinnen alle, wie man bei SoundCloud sehen kann:

  • Die User bekommen eine bequeme Möglichkeiten, ihre Musik hochzuladen oder auf sie zuzugreifen.
  • Die Entwickler können ihren Apps einen tatsächlichen Mehrwert hinzufügen und erhalten zusätzlich mehr Aufmerksamkeit für die eigene App über die SoundCloud App Gallery.
  • SoundCloud gewinnt an Attraktivität gegenüber den Endnutzern, weil es bereits überall integriert erscheint. (SoundCloud entwickelt sich diesbezüglich gerade zum Instapaper für Sound. Es taucht überall auf.)

Zum letzten Punkt hatte ich bereits vor wenigen Tag den Investor Fred Wilson (Investor in Twitter, Tumblr, Etsy, SoundCloud etc.) verlinkt, der über SoundClouds API Folgendes zu sagenhat:

Those developers and their products pulled Twitter into the market. Soundcloud is another great example. There are a ton of apps that people use to create music and other audio experiences that have “soundcoud inside.” Each and every one of those apps is a distribution channel for soundcloud. They are pulling Soundcloud into the market.

Es gibt auch neben SoundClouds API einige weitere offene, wenn auch nicht vergleichbar erfolgreiche APIs aus Deutschland. Martin Weigert sammelt gerade einige auf Quora:

mite http://mite.yo.lk/api/index.html
SoundCloud http://soundcloud.com/developers
Billomat http://www.billomat.com/api/
Salesking http://dev.blog.salesking.eu/api/
moviepilot https://github.com/moviepilot/moviepilot-API/wiki/
Qype http://apidocs.qype.com/start
cobot https://www.cobot.me/pages/api