The recent announcement by Skype "Please Welcome Skype for web (beta)" has initiated a tsunami of comments in the WebRTC community. As an example, we have received several questions from partners, customers and prospects about the reality behind this announcement, trying to understand if they should reconsider their WebRTC projects and strategies and wait for Skype's next move in this area. First of all, we should recall that WebRTC is nothing but a technology, not a service or a use case itself. Skype is embracing WebRTC technology to provide a existing service on web browsers. Similar announcements have been published during last months for other major CSP's and OTTs both in the consumer space (Telefonica's Tuenti is a good telco-OTT example) and business space (Citrix's GotoMeetingFree), but didn't get as much buzz as the Skype's one. They key difference here is that Skype has +600 millions of registered users and the "Skype-ID" is a really valuable asset, not only for consumers but also for enterprise users (you probably display it on your email signature or have used it at work at some time, didn't you?). In other words, Skype for web is just competing directly with Google Hangout (which also uses WebRTC as the underlying technology). So, how can the Skype-on-the-web offering impact the WebRTC industry as we know it today? The first idea that come into our mind was: Skype will be able to compete with cloud companies providing telephony API's such as Twilio, Tokbox, Tropo and others. But we don't think that might occur, at least in the API-centric way that we know it by now. Skype has a global VoIP network which has proven to scale but it does not make too much sense for them right now to “rent WebRTC capacity" to third parties. They seem to be more interested in building new products than monetising the infrastructure itself. Besides their residual "SkypeURI" initiative, Skype does not seem to give too much options for developers. Without an API strategy, it's almost impossible to integrate any Skype service into anything that an enterprise might have “behind the firewall”, as we're doing with our WAC with other online service providers. This can be an interesting move as Lync as Skype for Business are now the same solution and it has SIP integration with existing PBXs. And what about eCommerce sites? Skype already has an offering for "ClickToCall" buttons that basically trigger your Skype desktop application when you click the button on a eCommerce website. This service will be slightly improved as you will be able to establish a session with the eCommerce agent even if you don't have the Skype desktop application installed, but you'll need to be logged into Skype.com or provide your credentials before connecting. Obviously, they might allow anonymous users for this uses cases.. There are dozens of companies providing enhanced Click-To-Call and Click-To-Video solutions (Zingaya was one of the pioneers in the area) that will to differentiate to compete with Skype on this specific vertical, but we don't see any special advantage for Skype on the web as of today. This might change if Skype adds a directory of companies right into the web application, or partner with an external content provider such as Facebook. For example, if I can order a pizza just by looking for Domino's into a directory built into my Skype's address book. On the other hand, Skype is not offering as of today a federation service so that a third party application can make calls and send IMs to Skype users. As an example, I should be able to dial a Skype friend from my Google Hangout account. Such federation will be tricky as the media plane in WebRTC is standardized, but the signalling plane is not. To sum up, Skype is a great platform with millions of users and it's a good new to see Skype and also Microsoft moving to a browser-based solution and embracing WebRTC, regardless of the actual discussion of the video codec choice. But as long as they remain as an isolated island, without ID or services federation and without a clear strategy for a developer API, there's little room for manoeuvre and innovation.