**NEW Feb 2013 - Disruptive Analysis WebRTC report - details here**
I'm in two minds here.
It's deeply awkward for the "mainstream" WebRTC community that Microsoft appears to have demo'd cross-browser support first, using its alternative proposed standard, CU-RTC-Web.
(If you're new to WebRTC, it's worth noting that at the time of writing in January 2013, development of the "core" IETF standard is progressing, and browser support is improving, but there are still a lot of issues around stability and interoperability that need to be resolved. Notably, as far as I know, nobody has demonstrated a call directly between Chrome and Firefox browsers, both of which support early implementations of the standard. Microsoft arrived late to the party with a different and more flexible-but-complex technology which claims to fix some of the issues, and there is considerable hand-wringing about this. Some worry about a delaying plan to protect Skype, others fear fragmentation. A good articulation of the arguments is here).
On the other hand, it's easy to argue the "traditional WebRTC" corner: Having a single, easy-to-implement standard is essential for the vision of extending WebRTC to the mass of "normal" web developers, even if VoIP/video specialists and some enterprise IT developers would rather have a bit more flexibility in choosing codecs, managing the vagaries of the network and so forth.
The current argument for the draft WebRTC standard is that web-developers will be "disenfranchised" - or at least deterred - by more complex options like CU-RTC-Web, which give more choices and decisions, such as picking codecs rather than just using an "official" one.
But this is rather undermined by the fact they're also being disenfranchised by the current version, which is certainly not as easy to use as many hoped. A quick look on the Google or IETF forums, or on Twitter, shows that experienced developers are often struggling to get the technology to work properly. Yes, there's a lot of cool demos about - but relatively few "mature" products, and even fewer that are stable. And, it seems, none that are properly interoperable.
And if you look at who's doing WebRTC app development today, it is primarily "VoIP guys", either from Internet or enterprise or telco backgrounds. You can spot this easily, as they're debating about whether WebRTC enhances SIP's applicability, or makes it obsolete. These are communications experts, not Mr Average Web Developer. Again, there are some exceptions such as Wello (Tsahi Levent-Levi has a good interview here), but they are heavily reliant on 3rd-party frameworks such as AddLive's to make it work.
Indeed, the fact that the most vibrant bit of WebRTC at the moment seems to be the SDK/API guys (AddLive, Hookflash, TokBox/Telefonica, Voxeo Labs etc) who are ultimately just about "making it easy" for developers rather proves the point - it isn't that simple to begin with.
There don't appear to be many people playing with WebRTC who've never heard of, nor used, SIP. Yet that's the constituency it's supposed to appeal to. People who've never even considered putting real-time comms in their websites or apps, or who briefly considered it and then gave up because it was too hard.
It's all very well saying "look what you can do with just 5 lines of code!" as long as it actually works properly afterwards, rather than just being a wobbly demo that works long enough to get a video to put up on YouTube.
I'm not going to pretend that I understand all the politics going on behind the scenes. But what it comes down to, I think, is this:
Google, Mozilla and other supporters of the current IETF WebRTC standard need to *prove* that cross-browser development of web-apps is not just feasible, but easy. And soon. Like in the next few weeks.
Otherwise, there is a risk that others will start to ponder whether Microsoft has in fact got a good point. It's also worth noting that some of the more classical "telco" participants here (both operators and vendors) have a bit of a vested interest in minimising the ease - and maximising timelines - for widespread browser-to-browser WebRTC app development, as they ultimately make money from servers/gateways and services in the middle. If, or how, that plays out from a standards point of view is anyone's guess, especially as many are genuine enthusiasts, not Machiavellian schemers.
My personal view is that Microsoft is playing a clever game here: deliver something useful, but late. By forcing Google's hand on getting interoperability between browsers sooner, they are performing a useful service for the WebRTC community, which should earn them some grudging thanks. If that leads to a couple of elephants in the room being addressed - perhaps with elements of CU-RTC-Web - then they win as well. And if that forces a couple of bits back to the drawing board and causes a bit of delay, that's beneficial for Skype and other products.
**NEW Feb 2013 - Disruptive Analysis WebRTC report - details here**
I'm in two minds here.
It's deeply awkward for the "mainstream" WebRTC community that Microsoft appears to have demo'd cross-browser support first, using its alternative proposed standard, CU-RTC-Web.
(If you're new to WebRTC, it's worth noting that at the time of writing in January 2013, development of the "core" IETF standard is progressing, and browser support is improving, but there are still a lot of issues around stability and interoperability that need to be resolved. Notably, as far as I know, nobody has demonstrated a call directly between Chrome and Firefox browsers, both of which support early implementations of the standard. Microsoft arrived late to the party with a different and more flexible-but-complex technology which claims to fix some of the issues, and there is considerable hand-wringing about this. Some worry about a delaying plan to protect Skype, others fear fragmentation. A good articulation of the arguments is here).
On the other hand, it's easy to argue the "traditional WebRTC" corner: Having a single, easy-to-implement standard is essential for the vision of extending WebRTC to the mass of "normal" web developers, even if VoIP/video specialists and some enterprise IT developers would rather have a bit more flexibility in choosing codecs, managing the vagaries of the network and so forth.
The current argument for the draft WebRTC standard is that web-developers will be "disenfranchised" - or at least deterred - by more complex options like CU-RTC-Web, which give more choices and decisions, such as picking codecs rather than just using an "official" one.
But this is rather undermined by the fact they're also being disenfranchised by the current version, which is certainly not as easy to use as many hoped. A quick look on the Google or IETF forums, or on Twitter, shows that experienced developers are often struggling to get the technology to work properly. Yes, there's a lot of cool demos about - but relatively few "mature" products, and even fewer that are stable. And, it seems, none that are properly interoperable.
And if you look at who's doing WebRTC app development today, it is primarily "VoIP guys", either from Internet or enterprise or telco backgrounds. You can spot this easily, as they're debating about whether WebRTC enhances SIP's applicability, or makes it obsolete. These are communications experts, not Mr Average Web Developer. Again, there are some exceptions such as Wello (Tsahi Levent-Levi has a good interview here), but they are heavily reliant on 3rd-party frameworks such as AddLive's to make it work.
Indeed, the fact that the most vibrant bit of WebRTC at the moment seems to be the SDK/API guys (AddLive, Hookflash, TokBox/Telefonica, Voxeo Labs etc) who are ultimately just about "making it easy" for developers rather proves the point - it isn't that simple to begin with.
There don't appear to be many people playing with WebRTC who've never heard of, nor used, SIP. Yet that's the constituency it's supposed to appeal to. People who've never even considered putting real-time comms in their websites or apps, or who briefly considered it and then gave up because it was too hard.
It's all very well saying "look what you can do with just 5 lines of code!" as long as it actually works properly afterwards, rather than just being a wobbly demo that works long enough to get a video to put up on YouTube.
I'm not going to pretend that I understand all the politics going on behind the scenes. But what it comes down to, I think, is this:
Google, Mozilla and other supporters of the current IETF WebRTC standard need to *prove* that cross-browser development of web-apps is not just feasible, but easy. And soon. Like in the next few weeks.
Otherwise, there is a risk that others will start to ponder whether Microsoft has in fact got a good point. It's also worth noting that some of the more classical "telco" participants here (both operators and vendors) have a bit of a vested interest in minimising the ease - and maximising timelines - for widespread browser-to-browser WebRTC app development, as they ultimately make money from servers/gateways and services in the middle. If, or how, that plays out from a standards point of view is anyone's guess, especially as many are genuine enthusiasts, not Machiavellian schemers.
My personal view is that Microsoft is playing a clever game here: deliver something useful, but late. By forcing Google's hand on getting interoperability between browsers sooner, they are performing a useful service for the WebRTC community, which should earn them some grudging thanks. If that leads to a couple of elephants in the room being addressed - perhaps with elements of CU-RTC-Web - then they win as well. And if that forces a couple of bits back to the drawing board and causes a bit of delay, that's beneficial for Skype and other products.
**NEW Feb 2013 - Disruptive Analysis WebRTC report - details here**
0 comments:
Post a Comment