One of WebRTC’s Job to be Done? Reducing the barriers of entry for vendors.
Off we go, into a weekend of WebRTC JTBD. The first aspect I want to touch is the one of barriers of entry. I did something similar recently on NoJitter, where I shared the thought processes and options of mobile developers with VoIP.
I’d like to do something a bit more focused here, and discuss the costs involved.
Let’s go back in time a bit, and jump back to 2010. That’s way before WebRTC in IT timescales. Let’s assume we’re Viber – the OTT player who started operating in 2010.
They had to do the following things:
- Recruit media engineers. In their case:
- Someone good with voice and echo cancellation. Maybe two of them, one for each “discipline”
- A developer that can handle device drivers and peripherals – to deal with the ugly realities of mobile operating systems
- Another guy for the jitter buffer and media processing
- License a media engine and codecs from someone
- GIPS (the company Google acquired and converted into WebRTC) was a good option then
- Viber actually leaned towards another player called Spirit-DSP at the time
- Develop, test, rinse and repeat
Recruit media engineers
I don’t know if you had the chance to work with media engineers, but they aren’t from the same planet as the rest of the software developers.
They are the most expensive ones and the hardest ones to find and recruit. Their social skills in general are even worse than mine (which isn’t easy).
And to top it all, when you have a bug that needs fixing – you can never get a definite date or even a guesstimate from them. It isn’t their fault mind you – it is just the type of problems they tackle.
This boils down to management time, development costs and calendar time.
License a media engine and codecs
No one in his right mind will go and implement a codec. Or a media engine. It is just not done.
You go and find a vendor that will license it for you and pay him what it takes. In 2010, that was anywhere between 50K USD to 200K USD, depending on what you wanted to achieve – and it didn’t include royalty costs that had to be paid for the vendor for each application installed – and additional royalties to those holding the patents over the codecs used.
This is big money. And headache in understanding the intricacies of who to pay royalties to, when, how much and how.
Develop, test, rinse and repeat
As you’re doing it all by yourself, with very little “external” assistance – it takes a lot of time. There’s development and integration involved, testing in multiple devices, scenarios, locations, networks, etc.
This is a large investment in time and resources.
The barrier?
So the barrier here?
If you wanted to start a service that required VoIP, you were looking at 2 million USD to begin with and anywhere between 6-12 months for an initial demo or proof of concept. And that is being optimistic.
And we haven’t even start discussing backend infrastructure costs and plugin and/or client application development costs.
Enter WebRTC
Today though, if you want to develop something with VoIP, you only need to go look at WebRTC.
Want a browser based solution? It’s there. Use it. I’ve talked and interviewed single developers who built services relying on WebRTC on their own during their free weekends.
Why is it important?
- Have an idea that requires an investment? Develop the proof of concept and then go raise money. That’s the way it is done today. WebRTC enables doing that for communication related products as well
- Viber manged. So did Tango. And ooVoo. And a lot of others. There will be money readily available for the next Skype. Snapchat anyone?
- BUT – if what you want is to add video calling capabilities to your picture sharing site for example, then you need it to be at zero cost (or close to it)
- WebRTC lowers the barrier of entry so significantly that VoIP has been relegated into just another feature within other services and apps
- If you are an incumbent who has VoIP, look at this as huge disruption to your business model and way of thinking
Tomorrow? Reducing friction with WebRTC
Well, now instead of hiring a bunch of media engineers you have to hire someone who understands enough about all the media and p2p stuff to talk with the engineers at Google/Mozilla and enough Javascript to talk to your web developers.
That combination of skills is pretty rare.
Developers will bitch whenever someone simplifies their lives a bit for not making sure they have no work left 🙂
Most use cases out there don’t need that level of expertise and understanding. The select few do.
I only tend to disagree when it comes to the tense — they will not require and should not. But progress re bringing WebRTC to the “open web platform” and adoption from web developers is pretty slow.