How to simplify WebRTC?

Holidays are a great time of reflection. In 2016, I traversed the world talking up WebRTC at events, groups, and gatherings and meeting with other WebRTC advocates. But in the quiet silence of the end of the year, I realized that “we” the WebRTC Community are failing at our primary directive to make WebRTC accessible.

It hit me when I asked my colleague, Chad Hart (editor of WebRTC Hacks) how long it would take to get a simple Co-TURN server up and running. He said it would take someone who knew what they were doing a few hours of work. A few hours? For a TURN server? Really?

In fact, the GitHub directions for installing co-turn assume you are a rocket scientist. The directions are ambiguous and assume a high level of knowledge. I use this as a mere example.

But why does it have to be so difficult?

I am not a developer. I am not a DevOps person. Yet, I managed to install OpenStack on a test server all by myself. I installed MongoDB. I even got GE’s IOT Predix up and running (now I just need to find a jet engine to ingest data from). LAMP and MEAN installs take just a few minutes from scratch. Yet the minute I touch anything comms related, I look like an idiot. I may not be alone.

But a Co-TURN server takes a “couple of hours.”

Imagine your classic developer. Not in San Francisco, but Des Moines, Iowa. They live in a LAMP world. It’s PHP and a MySQL database and they’re working on the new inventory management system. Their last excitement was rounded CSS boxes. They don’t read TechCrunch but they do coach the local softball league.

So one rainy afternoon, our classic developer has heard about this WebRTC thing and wants to add a video chat to the inventory management system so that the Omaha office can beam in. That would be cool. They’d read an article about how WebRTC has made communications easy. So off they go. This won’t take long, so they think.

But layer by layer, the complexity builds. Remember, this is a LAMP developer, distributed state computing is Cape Canaveral stuff.

You need a signaling server. Where do I get one of those? Who knows. What protocol are you going to use? I have to figure that out? Are you planning on doing any SDP munging? Should I? I hope you’ve given consideration to how you’re gonna deal with your ICE candidates. I thought I already voted. You are going to use VP8, right? Is there a 6-cylinder version? Do you think you will need TURN because that’s gonna take you 2-3 hours and that’s IF you know what you’re doing?

This is just for a simple 1:1 application. You wanna get more complex. Go look at the directions on how to install any of the open source selective forwarding units (SFU). Note: 99.99% of the world has no idea what an SFU is. No matter, it’s faster to put a man on the moon than figure out how to get these platforms up and running.

Is there any surprise only the hardcore make it through this gauntlet?

In the early days of WebRTC, great work was done by Priologic and &yet in offering open source base component solutions. But these were commercial businesses and while they seeded the early work, the broader community needed to take rally around it.

Now before you come after me. I’m simply asking you, the WebRTC community, the true experts – what can we collectively do to make WebRTC easier to implement. That was our original objective, right?

Our position isn’t unique. Many technologies have suffered this before. Usually, there is a small group of well meaning, highly intelligent and equally highly opinionated people who have sparked the initial creation of a piece of technology. The group is eager to be heard, but at some point, it switches from trying to include to trying to exclude newcomers. And like old men at the coffee shop, we sit and argue amongst ourselves in a language only we understand.

We know the technology works and due to the hard work of many, we know that it works pretty well. However, those who have implemented WebRTC applications did so after crawling across broken glass. The word ‘fun’ wasn’t in the equation.

So as 2017 moves in, I’m focusing more and more on the developer in Des Moines Iowa. How can we make WebRTC more approachable to a broader market of developers and applications? Easier is always harder.

Here are my thoughts if we want to include the other 95% of the world.

Documentation is important. Don’t assume people are following your scripted notes. Digital Ocean documentation is a great reference, the idiot’s guide to installing virtually anything. I don’t buy that true experts are annoyed by great documentation. We all need help periodically.

Most developers don’t write distributed state applications. So we need to guide them to the correct choices. It’s not necessarily important for them to understand exactly how something works, just that it works. Usable and supported modules are needed.

Minimize the noise on the edges. A new comer walking into the room with a heated argument underway on whether H.264 or VP9 is better can be a bit scary when that person has no idea what a codec even is.

Return to basics. Don’t assume everyone has been on this journey the whole time. Many of the early samples that were written don’t work as WebRTC and the browsers migrated. It’s OK to re-do and improve. Everyone likes the classics.

With a little help we can continue to evolve and include WebRTC to a broader audience.