Wahrscheinlich können sich nur noch wenige an die wilden 90er des Webs erinnern, als Microsoft mit allen Mitteln — und letztendlich auch erfolgreich — versuchte, Netscape vom Markt zu verdrängen: Einerseits wurde auf Betriebssystemebene gekämpft und mehr oder weniger aktiv versucht, den Konkurrenten zu behindern. Andererseits wurde mit diversen proprietären Features versucht, Anwender an die eigene Lösung zu binden. Noch heute gibt es deshalb Unternehmen, die für schrottige ERP-Software noch immer IE6 benötigen…
Doch gewissermaßen ist es heute nicht viel anders, nur sind die Mitspieler und die Mittel andere: Google hat sich seit Jahren an die Spitze der Entwicklung gesetzt und teils aus eigenen Labs und Teils auch durch „Übernahme“ öffentlicher Arbeitsgruppen diverse Erweiterungen und Standards am Markt eingeführt: Aus einer recht überschaubaren Hypertext-Sprache wurde ein nicht mehr überschaubares Ökosystem aus diversen unterschiedlichen Technologien, Erweiterungen und Workarounds:
Nehmen wir mal als Beispiel WebSockets, Server-Sent Events und WebRTC: Für sich und rein technologisch betrachtet sind es coole, innovative Features um bidirektionale Kommunikation in Browsern zu ermöglichen. Doch bis auf Chat, Videochat, Voicechat und eventuell Aktienkurse sind bis heute wenige sinnvolle Anwendungsbereiche aufgetaucht. Ich bin mir nicht sicher, ob wir hier noch welche sehen werden oder ob die Technologien schon „Zombiestatus“ erreicht haben.
Jedenfalls erhöhen sie die Komplexität der Netzinfrastruktur erheblich: Einerseits durch komplexere Browser, massiv erhöhte Angriffsvektoren was Netzsicherheit betrifft und natürlich auch durch erforderliche, skalierbare serverseitige Infrastrukturen.
Wer solche Dienste betreiben möchte, sollte damit kein Problem haben. Aber jeder Nutzer und jeder Browser-Hersteller muss dafür den Preis bezahlen: Über WebSockets kann man vieles und über WebRTC quasi alles tunneln, was über TCP oder UDP laufen kann. Durch jede content-aware-firewall hindurch.
Das kann in undemokratischen Staaten für Nutzer von Vorteil sein und eine freie Meinungsäusserung ermöglichen, die Schattenseiten betreffen trotzdem alle Nutzer weltweit.
Gerade Features/Technologien, die nicht besonders häufig eingesetzt werden, aber aus einer mehr oder weniger alten „Tradition“ unterstützt werden, sind ein willkommenes Ziel für Bughunter: Hier schauen nicht viele Leute drüber, viele kennen die Features und die Sicherheitsimplikationen nicht…
Jeder, der in der Software-Entwicklung arbeitet, kennt das Feature-Creep-Problem und trotzdem ist es die Geissel unserer Branche: Microsoft, SAP, Lotus Notes… muss mit dem ganzen alten Dreck von vor 15 Jahren kompatibel sein. Dabei wäre es so einfach: Ein neues Feature würde nicht nur technologisch evaluiert, sondern auch wirtschaftlich bzw. hinsichtlich der Adaptionsrate: Man gibt als Hersteller eine Ansage ab, die Technologie bswp. 5 Jahre bis zum x.y.2019 zu unterstützen und dann weiter, wenn folgende Verbreitungskriterien erreicht werden: …
Damit könnten sowohl die early adopters starten und zumindest ein paar Jahre auf diese Technologie setzen. Andererseits gibt es den Herstellern auch die Chance, ungenutzte Features ordentlich zurückzubauen und den Code und die Komplexität ihrer Software wieder zu verringern.
Google macht dies bisher nicht oder behält die politischen Entscheidungen, wie lange und wie intensiv etwas unterstützt werden soll, zurück. Schlimmer noch: Google fördert aktuell massiv Feature-Creep und zwar nicht nur bei sich selbst sondern auch bei Konkurrenten und unabhängigen Entwicklern. Auch eine Lösung sich die Konkurrenz vom Leibe zu halten…