Moving WebRTC From Asterisk to Headline

Is WebRTC cool yet?
Amazon and Facebook are doing it; Microsoft is dreaming about it; even Hollywood has referenced it. It has seen a tremendous increase in popularity in the past few years with the creation of Meetups, dedicated hackathons and services.
However, WebRTC is still perceived as difficult for mainstream developers (read: hipsters with MacBook pros sipping soy Frappuccinos at workshop cafés in SOMA) as one of the lesser-used Javascript Web APIs in these groups. Why isn't WebRTC as popular as, say, WebGL? Why isn't everyone adding voice, data-channels and video to their services? What can be done to attract more developers to integrate WebRTC?
The issue here is that WebRTC is not yet a polished technology. At its core, WebRTC is a disruptor to the telephony industry. And like every industry disruptor, it needs constant iteration to get past roadblocks.
Though WebRTC is a set of JavaScript APIs, integrating WebRTC in your app is not a matter of simply adding a few HTML5 tags or copy-pasting some lines of JavaScript code. It is an entire environment, which needs to be set up. Web developers beginning to work with WebRTC need to understand multidisciplinary concepts that are often out of their grasp: codecs, gateways, signaling frameworks, STUN/TURN servers, mobile SDKs, unsupported browser fallback and much more.
So how can developers work together as a community to eliminate these roadblocks? I've listed a few of the top things I think need to happen for WebRTC to become what it deserves to be -- the most widely used Web API.
Send network operators and telcos to the rescue!
Network operators have resources, and know how to use them to take care of the difficult telco implementations. Network operators should expose the hard VoIP parts (TURN Servers, Gateways, etc.) as APIs for developers to access. This way, web developers can focus on what they do best: integrating APIs. At the same time, this would enable telcos to enhance their API onboarding and developer community interest.
Some great examples of companies doing this are, for instance, AT&T Inc. (NYSE: T) opening its network for WebRTC use with its Enhanced WebRTC API. Matrix.org and OnSIP (SIP.js) offering no-brainer signaling frameworks and libraries for developers to use with JavaScript. Hosted TURN server solutions such as Xirsys eliminating the hassle a developer must go through to ensure their solution works everywhere.
Other non-telco companies, like TokBox Inc. or Twilio Inc. (NYSE: TWLO), focus on bringing these features to developers in the form of an end-to-end PaaS served over APIs. Hence, eliminating the headaches web developers would normally go through to launch their service.
Browser vendors get their act together
One of the primary benefits of WebRTC is the fact that plugins are not needed, and therefore developers could assume full compatibility of platform with their users' browsers with their platform. However, this is not yet the case, as only some major browsers have fully implemented WebRTC. Two of the most notable browsers left out of the picture are Safari and Internet Explorer. These holes in availability add to the complexity of a WebRTC implementation in terms of user experience, as there is no native consistency. While there are companies such as Temasys who provide plugins for those browsers that do not support WebRTC, it's up to the vendors to get their act together and jump on the consistency bandwagon (ahem, Microsoft Corp. (Nasdaq: MSFT) and Apple Inc. (Nasdaq: AAPL)).
Big platforms need to advocate for WebRTC
Developers need to know they are not alone in these early days. The big names such as Facebook , Whatsapp, Amazon.com Inc. (Nasdaq: AMZN) and Slack, need to vocalize the fact they are actively integrating WebRTC to their services and document their initiatives. Hey, why not open source some of that, too? If they become advocates for the technology rather than being secretive about it then maybe others will stop unmasking them!
The developer community unites!
The developer community all wants the same thing: for WebRTC to be easy. Developers from all over have come up with great initiatives like WebRTC For The Web," which is an association of developers that build useful tools for the community such as IsWebRTCReadyYet.com. These groups are a great start, and I expect that they will mark the starting point for some of the most exciting WebRTC contributions. In fact, I would love to hear readers' comments on any positive experiences with these groups to date.
Open source frameworks also play a big role in the community. Projects like peerJS and simpleWebRTC considerably lower the barriers of WebRTC development and provide an easy way for developers to get started and get advised.
More initiatives like WebRTC Hacks and WebRTC Experiment help foster a sense of "schooling" for the developer community. Why not setup online WebRTC courses on Codecademy or Coursera? Let's get universities involved in this!
Offline, we've seen the rise of TADHack, which are a series of hackathons focused on WebRTC's role in the telco environment. Events like these provide the perfect environment to learn and collaborate with the best (and with the telco vendors themselves). Also, more "Meetup" groups dedicated to WebRTC are created and we should work hard to promote them to a bigger audience. This is where telcos can step in and leverage their resources to help organize or fund such events.
While it is valuable to have these resources at our disposal, they are starting to pile up and it is becoming difficult to keep up with the various initiatives happening all around the world. As a community, we need to communicate better on a more united channel. At the same time, WebRTC contributors (Google (Nasdaq: GOOG), Mozilla , Internet Engineering Task Force (IETF) , World Wide Web Consortium (W3C) ) have to work to remove the current obstacles so that providing additional resources is not necessary. This way, WebRTC can truly become as easy as WebGL or any other Web API and, more importantly, become just as popular!
— Sacha Nacar, Developer Community Manager, Voxbone SA