Open Web

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..