Ein Blick auf den derzeitigen Stand von WebRTC und wie die Normen die Unternehmen beeinflussen
Die IT-Administratoren in den Unternehmen geben wenig auf Abkürzungen, obwohl diese in der IT-Industrie zur Alltagssprache gehören. Ob es sich um WebRTC, IMS, ORTC, RCS, SIP, VoIP, oder was auch immer handelt ist eigentlich egal, solange die damit verbundenen Produkte ihre Funktionen erfüllen. Alle Produkte und Technologien, die die IT-Prozesse potenziell stören könnten, werden daher intensiv auf ihre Funktionen und ihre Einsatzbereiche geprüft. Für den Einsatz neuer Technologien gilt: Etwas was neue zusätzliche Arbeit für die IT-Abteilung bedeutet, muss erhebliche Vorteile bieten. Als Faustformel kann ein Verhältnis von 10:1 des Spaßfaktors/Erkenntnisgewinns zu möglichen Problemen angesetzt werden.
Die Unternehmen haben auch gute Gründe für ihre Vorsicht in Sachen „WebRTC“. Die Normungsgremien waren nicht sehr schnell mit der Standardisierung von WebRTC und es hat viel länger gedauert als ursprünglich erwartet, bis zufriedenstellende WebRTC-Spezifikationen veröffentlicht wurden.
Beginnen wir mit einem bisschen WebRTC-Geschichte. Meine WebRTC-Zeitmaschine verfügt über folgende Aufzeichnung: Während eines Bird of a Feather (BoF) Meetings (März 2011) im IETF zum Thema „RTC im WWW“ wurde diese Technologie erstmals öffentlich erwähnt. Damals verkündete Cullen Jennings von Cisco, dass er gerne eine Führungsposition in einer RTCWeb-Arbeitsgruppe einnehmen würde. Er gab jedoch zu bedenken, dass die Arbeit dieser Arbeitsgruppe mehr als fünf Jahre in Anspruch nehmen könne und kein Mitglied der Gruppe sollte die Herausforderung unterschätzen. Alle BoF-Teilnehmer hielten diese Aussage für einen Scherz. Wie konnte die Definition eines Stückchens Technologie so lange dauern?
Inzwischen schmunzelt niemand mehr über den prognostizierten Zeitrahmen, denn es sind mittlerweile mehr als 5 Jahre ins Land gegangen, ohne dass ein endgültiger WebRTC-Standard verfügbar wäre.
Was wurde in diesem langen Zeitraum erreicht? Welche Funktionen wurden in Tausenden und Abertausenden von Arbeitsstunden an Normungs- und Gremienarbeit festgeschrieben?
Projekt beenden vs. Standardisierung
Wenn wir die Mehrheit der in den letzten Jahren entwickelten WebRTC-Anwendungen betrachten, dann erkennen wir, dass die meisten Implementierungen für den mobilen Markt konzipiert wurden. Dies überrascht, denn mehr als die Hälfte der heute verfügbaren Smartphone-Browser unterstützen kein WebRTC. Der Smartphone-Gigant Apple hat offiziell noch kein Interesse an WebRTC gezeigt. Was treibt also die Entwickler dazu eine Technologie zu nutzen, die noch immer ihren Weg durch die Standardisierungsprozesse sucht?
Die Entwickler werden einem geschenkten Gaul nicht in sein Maul schauen und jedes Geschenk in Form eines Open-Source-Codes für ihre Arbeit nutzen. Man muss sich nur ansehen, was passierte, als Google die von Global IP Solutions bei deren Übernahme verfügbare GIPS-Media-Engine als Open-Source veröffentlicht hat. Viele Entwickler nahmen diesen Code und bauten diesen in ihre Anwendungen und Toolkits ein. Die Entwickler-Community wartetet nicht mehr darauf, dass die IETF, die W3C oder ein Browser-Hersteller das Nutzungspotenzial einer Technologie entdecken bzw. die endgültigen Standards einer neuen Technologie veröffentlicht sind. Stattdessen nutzen die Entwickler alle Technologien, die ihnen zur Verfügung stehen und bauen daraus neue Produkte. In den meisten Fällen funktioniert diese Strategie. Inzwischen stehen mehrere WebRTC-Entwicklungs-Kits für iOS und Android im Markt zur Verfügung – und dass, obwohl kein nativer Browser für die Apple-Geräte das WebRTC unterstützt.
Wo stehen wir heute mit der Standardisierung von WebRTC? Eigentlich wurde WebRTC dafür geschaffen, um die ewigen Plugins und die Erweiterungen für die Sprach- und Videokommunikation innerhalb der Browser zu ersetzen. Natürlich haben wir dieses Ziel immer noch nicht erreicht, aber ist diese Tatsache wirklich von Bedeutung?
Meine WebRTC-Zeitmaschine kann bis in das Jahr 2004 zurückschauen. Damals wurde gerade die Schlacht „SIP vs. proprietäre Signalisierung“ ausgefochten. Die damaligen Argumente lauteten: Warum können wir nicht ein besseres SIP entwickeln als die Normungsgremien? Warum müssen wir uns durch die Standards enge Handschellen anlegen lassen? Die Antwort auf diese Fragen wurde damals von Skype beantwortet: „Standards sind für das 21. Jahrhundert viel zu langsam und zu unflexibel!“
Skype befand sich damals auf einem kometenhaften Aufstieg und die Kommentare seiner Führungsriege hatten Gewicht. Diese Herangehensweise ist typisch für ein Startup-Unternehmen, welches sich schnell weiterentwickeln wollte und nicht ganz ausgereifte Normen bzw. Standards trotzdem adaptierte. Natürlich kann man diesen Unternehmen keine Schuld zuweisen, wenn diese sich schnell und unbürokratisch weiterentwickeln wollen. Die Weiterentwicklung eines Unternehmens mit „Internet-Geschwindigkeit“ bildet heute einen Grundstein der Software-Entwicklung. Das Motto vieler Entwicklungsfirmen im Software-Bereich lautet inzwischen: Schraube schnell einen Code zusammen und schaue welches Ziel du erreichst. Bleibt der gewünschte Effekt aus, dann schreibe einen neuen Code.
Standards stellen immer noch einen Wert dar
Ich stelle mir immer wieder die Frage: Wenn Entwickler ihre Sprach- und Video-Messaging-Anwendungen für die gängigen Browser im Bereich der mobilen bzw. den Desktop-Computer entwickeln, spielen hier die neue WebRTC-Standards überhaupt eine Rolle?
Die Antwort lautet: Unabhängig von ihrer Herkunft und ihrer Geschichte haben die Standards in den Unternehmen noch immer einen hohen Stellenwert. Dies hat folgende Gründe:
- Wird WebRTC in naher Zukunft zum Mainstream in allen Browsern werden und die vielen Plugins der Drittanbieter durch Javascript- und HTML ersetzen? Heute muss man noch teure Schwerstarbeit verrichten, will man alle Arten von Geräten mit WebRTC ausrüsten. Auch lassen sich gewisse Lücken bei der Realisierung nicht vermeiden. Beispielsweise steht noch immer keine generische WebRTC-Implementierung für Safari zur Verfügung und auf den mobilen Geräten funktionieren die Plugins einfach nicht.
- Die Unternehmen sind für ihre Zusammenarbeit mit anderen Unternehmen auf Standards angewiesen. Entspricht eine Technologie nicht den gültigen Standards, dann werden die Unternehmen nicht ernsthaft ein Produkt, eine Anwendung oder einen Dienst großflächig nutzen. Die Inkompatibilitäten kämen den Unternehmen viel zu teuer.
Aus meiner Sicht ist es in Ordnung, dass kleinere Startup-Firmen versuchen ihre proprietären Lösungen schnell vermarkten. Etwas anderes ist es, wenn die Kommunikation zwischen vielen Marktteilnehmern funktionieren soll. Wenn eine vollständige Interoperabilität gefragt ist und Skaleneffekte erzielt werden sollen, dann eröffnen Normen und Standards den einzigen Lösungsweg. Wer nicht bereit ist zu warten – was in Ordnung geht – muss damit rechnen, dass er zu einem bestimmten Zeitpunkt seine proprietären Lösungen austauschen muss. Dies gilt es auch bei der Realisierung des nächsten Projekts zu beachten. Abgesehen davon sind die Vorteile einer browserbasierten Viedeokommunikation immens, so dass WebRTC mittlerweile auch im Enterprise angekommen ist. Übrigens: Viele Probleme und Fragestellungen werden durch die harte Arbeit der Mitglieder im W3C und IETF im Vorfeld einer Technologie bereits beantwortet. (mh)
