Herbst 2012
Steve Yegge’s im Herbst 2011 versehentlich an die Öffentlichkeit gelangter Rant über seinen Arbeitgeber, Google, vermittelt uns das Credo, dass IT-Produkte ohne (offene) Plattform dahinter so wehrlos und verloren sind wie ein Kaninchen im Angesicht eines T-Rex. Zum Jahrestag von Steve’s Rant knöpften sich die IT:Agenten das Thema in ihrer Freitagsrunde bei Keksen und Mate vor. Hier berichtet Thomas Fuhrmann, was er aus der Diskussion mitgenommen hat; folgen Sie ihm in die tiefsten Tiefen des Kaninchenbaus und schauen Sie, ob ein T-Rex da mithalten kann.
© Noah & Harvey / photocase.com
In seinem Rant vergleicht Steve zwei Platzhirsche im Internet: Amazon baut sein Produkt, ein Internet-Kaufhaus mit angeschlossenem Flohmarkt, auf eine Plattform auf, die es auch anderen Firmen vermietet. Google betreibt eine Ideen-Werkstatt, aus der die Produkte nur so herauspurzeln, denkt aber gar nicht daran, anderen auch mal das Werkzeug in die Hand zu drücken. Steve hält Google’s Strategie für gefährlich, weil es unglaublich schwierig ist, den Geschmack der Kunden zu treffen. Steven Jobs gelang dieses Kunststück immer wieder; die meisten anderen scheitern aber dabei. Macht ein Unternehmen jedoch sein Kerngeschäft zugänglich, so dass es andere neu verpacken können, ist die Wahrscheinlichkeit größer, dass sich irgendeine dieser neu verpackten Ideen schlussendlich auch am Markt durchsetzt.
Trotz dieser an sich einleuchtenden Hypothese scheinen sich zurzeit einige der erfolgreichen Plattformen wieder abkapseln zu wollen: Twitter schlägt LinkedIn die Tür vor der Nase zu und kauft lieber Spezialisten zu, um so ein besseres Produkt zu werden; ähnliches macht Facebook mit Zynga, das bislang hervorragend davon gelebt hat, seine Spiele bei Facebook einzubauen. Statt Kooperation geht es jetzt um die eigene Gewinnmaximierung. Die Platzhirsche verkaufen dem Entwicklervolk nur noch Subprime-APIs, wie es Matt Asay und Bill Davidow so treffend formulieren. Bei Steve Yegge hingegen, aus Sicht der Entwickler, hieß die Ethik noch: “You don’t eat People Food and give your developers Dog Food.”
Angesichts dieser Tendenz der Platzhirsche wird deutlich, dass viele Unternehmen in ein Lock-In geraten sind und sich so einer gewaltigen strategische Bedrohung ausgesetzt haben. Sie müssen nun zwischen Skylla und Charybdis navigieren; sie müssen den Spagat schaffen, weiterhin auf der Facebook-Welle zu reiten, ohne sich noch tiefer in Abhängigkeit zu begeben. Die Frage nach einer eigenen Kommentarfunktion in den Internet-Angeboten des Zeit-Verlags und der Süddeutschen ist nur ein Beispiel für die Unsicherheit die derzeit im Markt herrscht.
Die Gefahr des Lock-Ins ist aber nicht neu; sie hat auch nichts mit der Frage Plattform versus Produkt zu tun. Jedes Unternehmen, das sich von einem Zulieferer abhängig macht, begibt sich in Gefahr; aber auch der Zulieferer muss wachsam sein: In Kärnten lebte man einst gut vom Ferrum noricum; den Karthagern hingegen bekam ihre strategische Position in der antiken Nahrungskette weniger gut.
Die etablierte Lösung zur Vermeidung technologischer Lock-Ins bei Produkten sind Standards: Sie beschreiben Bauteile und Schnittstellen so, dass andere Gleichartiges fertigen können und man daher jederzeit zu einem anderen Zulieferer wechseln kann. Dem freien Nachbau könnten zwar gewerbliche Schutzrechte entgegenstehen; sie würden es dem Patentinhaber ermöglichen, fast den gesamten Gewinn eines Produkts abzuschöpfen, sobald sich dessen Produzent in die Abhängigkeit begeben hat. Meist begrenzen Standards aber dieses Abschöpfen (ebenso wie die Monopolisierung des Patents), indem sie eine faire und diskriminierungsfreie Lizenzierung verlangen.
Neu an den Web-Service-Plattformen ist, dass neben den bisherigen Konflikt zwischen Standard und gewerblichen Schutzrechten ein weiterer Konflikt tritt, nämlich der über Besitz und Eigentum an den Daten. Hier fehlt eine den Standards analoge Lizenzierungsregelung für die bei Facebook oder Google eingeschlossenen Daten; im Zweifel liegen die Rechte sowieso beim Urheber und nicht beim Service-Betreiber. Überdies sind die Eigentumsrechte in der Praxis nebensächlich; wichtig ist der Besitz, denn kein Unternehmen ist gerne auf einen langen Klageweg angewiesen, um Zugriff auf seine Daten zu erhalten.
Selbst wenn man hypothetisch annimmt, dass Plattform-Betreiber nie in Versuchung gerieten, unfaire und diskriminierende Zugangsbedingungen zu diktieren, sind meine Daten dort Dritten ausgeliefert. Die Datenverluste in den Plattformen von Apple und Amazon sind hier wohl nur der Anfang. Je mehr Plattformen ein Produkt nutzt, desto größer das Risiko; und wenn Plattformen auch andere Plattformen nutzen, wird das Risiko schnell unüberschaubar. Systemrelevante Web-Services! Wo bitte kann ich den Bail-Out beantragen, um meinen Bonus zu sichern? Da hilft es nur wenig, dass die wachsende Latenz das Auftürmen allzu hoher Web-Service-Stapel verhindert.
“To promote the progress of science and useful arts”, so begründet die US-Verfassung die Existenz gewerblicher Schutzrechte. Es stellt sich also die Frage, wie man die Vorteile offener Plattformen, die seit dem IBM PC die Welt der IT-Produkte befeuert haben, in die Welt der Web- und Cloud-Service-Plattformen retten kann; denn Steve Yegge’s Argument ist ja trotz der Gefahr eines Data-Lock-Ins richtig: Mit Plattformen kann man bessere Produkte bauen! – Bei der Suche nach einer Lösung hilft es, den Blick etwas schweifen zu lassen.
Auch Java, Linux und “das Internet” sind Plattformen; sie unterliegen aber nicht der Gefahr eines Data-Lock-In, denn man muss eigene Maschinen betreiben, die die Daten speichern. Die Plattformen sind standardisiert und offen, in dem Sinn, dass jeder frei ist, die Schnittstellen der Plattform nachzubauen: Man kann eigene Java-Compiler und -Maschinen bauen, man kann Linux nach eigenem Gutdünken erweitern, und man kann eigene Internet-Router bauen und betreiben.
Allerdings werden das die wenigsten tun, denn es ist nicht nur teuer; Software ist in der Praxis auch immer fehlerhaft, so dass man die einmal gebaute bzw. übernommene und angepasste Software fortlaufend pflegen müsste. Google kann Linux und Java zur Android-Plattform erweitern; den meisten anderen fehlt dazu die Kraft. Man muss also immer auch auf die Community hinter der Plattform schauen: Baue ich auf die Android-, iOS- oder WindowsPhone-Plattform auf? Wo ist meine Investition am besten geschützt?
Der Vorteil von Web-Service-Plattformen ist der, dass sie die Implementierung verbergen. Man muss sich eben nicht um Installation, Betrieb und Wartung kümmern; der Zugriff auf die Schnittstelle genügt. Die Plattformen und ihre “Meshability” ermöglichen es, “im Netz” betriebene Dienste zu verbinden. So erlauben sie es Unternehmen, rasch innovative Produkte zu schaffen.
Der Nachteil dieser Annehmlichkeiten ist der Data-Lock-In: Wären Facebook und Google nur Eigentümer schlauer Algorithmen und nicht Besitzer unser aller Daten, könnte jeder wählen, welches Produkt er nutzen möchte, auf welcher Plattform er aufbauen möchte. So aber haben wir alle keine Wahl mehr. Wir müssen uns mit dem “Dog Food” zufrieden geben und fürchten, jederzeit ausgesperrt zu werden. If you don’t pay you’re the product.
Es wäre also an der Zeit, mehr über Eigentum und Besitz der Daten zu sprechen. Patente verlangen die Offenlegung der Erfindung. Sollte man nicht genauso die Öffnung aller internen Schnittstellen der Web-Dienste und -Plattformen fordern? Dann könnten neue Marktteilnehmer eine gute Plattform dort verbessern, wo sie (vermeintliche) Schwächen hat. Und sollte man nicht ebenso immer auch Schnittstellen zur Übernahme der Daten verlangen? Dann könnten die Nutzer jederzeit zum Anbieter mit der ihrer Meinung besten Plattform wechseln. Ich denke, solche Regeln brächten uns mehr Innovation und Vielfalt “im Internet”.
Dieser Artikel entstand im Herbst 2012 im Nachgang einer IT:Agenten-Veranstaltung. Irgendwie fiel er in eine Ritze unseres virtuellen Büros, wo wir ihn jetzt beim Aufräumen wiedergefunden haben. Da das Thema aber aktueller denn je ist, hat Thomas ihn noch rasch etwas entstaubt und geglättet, bevor er sich ab 1. Mai neuen Aufgaben zuwendet.