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

About Marcel Weiß

Marcel Weiß, Jahrgang 1979, ist Gründer und Betreiber von neunetz.com.
Er ist Diplom-Kaufmann und lebt in Berlin. Marcel Weiß ist seit 2007 als Analyst zu Themen der Internetwirtschaft aktiv. Er ist ein Autor bei Exciting Commerce, schreibt Artikel für verschiedene Publikationen und ist unter anderem ein Coautor von im Springer Vieweg Verlag verlegten "Erfolgreich publizieren im Zeitalter des E-Books". Er unterrichtet als Gastdozent an der Popakademie Mannheim und hält Vorträge zu Themen der digitalen Wirtschaft. Mehr zum Autor.
Marcel Weiß auf Twitter und auf App.net folgen und auf Facebook abonnieren.
Mehr Möglichkeiten zur Vernetzung finden sich hier.

  • http://notsorelevant.com/ Carsten Pötter

    Ich bin mir nicht sicher, ob die Weiterentwicklung von Webstandards unbedingt von den großen Firmen wie Google und Facebook kommen muss. Die meisten der von mir genannten Leute arbeiten schließlich genau bei diesen beiden Firmen.

    Sie arbeiten nur m.E. relativ unabhängig von ihren Arbeitgebern. Das mag auf den ersten Blick dem widersprechen, was ich auf G+ gesagt habe und Du hier zitiert hast. Was ich meine ist Folgendes: Sie haben die Freiheit, während ihrer Arbeitszeit zu irgendwelchen Treffen, Workshops,… zu gehen und dort mitzuarbeiten. Dabei fließen natürlich die Erfahrungen und Erwartungen ihrer Arbeitgeber mit ein. Aber sie können nicht in jedem Fall absehen, ob und wie ihre Entscheidungen sich auf die weitere Produktentwicklung ihrer Arbeitgeber auswirken werden.

    Eines ist natürlich auch klar: Webstandards ohne die Beteiligung und ausdrückliche Unterstützung (=Implementierung in den eigenen, wichtigen Produkten) der großen Player wird es vorerst nicht mehr geben.

    Kleine Berichtigung: Der (ehemalige) Entwickler von NetNewsWire ist Brent Simmons, nicht Nick Bradbury.

  • http://www.neunetz.com/ Marcel Weiss

    Ja, das meinte ich auch damit:
    “Eines ist natürlich auch klar: Webstandards ohne die Beteiligung und ausdrückliche Unterstützung (=Implementierung in den eigenen, wichtigen Produkten) der großen Player wird es vorerst nicht mehr geben.”

    Es gibt aktuell einfach keine dezentrale Anlaufstelle, von der irgendetwas ausgehen könnte. Wobei es natürlich zum Beispiel immer noch WordPress gibt, das wohl die am weitesten verbreitete Open-Source-Software (im Sinne von auf Servern installiert und im aktiven Betrieb) sein dürfte. 
    Dass von WordPress und Automattic nichts, überhaupt nichts, abseits von Backend-Feinjustierungen kommt, ist allerdings auch richtig frustrierend.
    Vielleicht wäre es Zeit für ein WordPress-Fork.

    Danke für den Hinweis auf den Fehler, entferne ich gleich.