We have all the features you are looking for! But here’s the list of exceptions…
As I work through my update to the Choosing an WebRTC API Platform report (due later this month), I have noticed something quite interesting.
Most of the WebRTC vendors have 3 types of features:
- Features they actually implement
- Features they have on their website, but
- are in beta
- or in alpha
- or being coded
- or being thought about hard enough
- Features they don’t have
The problem for those who wish to select a WebRTC API platform will usually be in the second category: the things vendors say they have but… don’t. Call it “the Everything and nothing WebRTC vendor syndrome”: They have everything in their feature list, but nothing really works as advertised.
When I assist companies with their vendor selection process, this is usually what comes up in our discussions – the fact that you can’t really tell what is fact and what is fiction. Some come back and tell me that a specific vendor feels too “beta” for them – the whole platform just acts as if things can fall apart at any moment. And it happens all too often.
What we need in this small corner of WebRTC these days is a bit more transparency and honesty from vendors. Some of the players are coming from the telecom space, where a feature set is just a starting point for negotiation (and potential customization work). This doesn’t work too well in the application developer domain. If you lose the trust of a developer once, he won’t be coming again any time soon.
My suggestion to platform vendors? Be more transparent. Say the truth on your website. This will give you points on honesty that aren’t easy to come by today. It will also reduce the noise you deal with from complaining customers and will make those you fit them happier in the long run.
My suggestion to companies on a vendor selection process? Don’t take the feature set of platform vendors at face value. Ask them. And then ask again. And then validate. And then check the documentation yourselves. While you’re at it, ask since when critical features you need were available – it will give you an idea of their potential readiness.
The day when WEBRTC is stable on all browsers , it will be everything syndrome
That’s thinking small. There are a lot of things that WebRTC doesn’t and won’t bring out of the box. Things like multipoint support, recording, etc.
My focus (and to some extent rant) here is about the promised features from a vendor and not from the adoption of the technology itself.
The truth is that none WebRTC solution will address all the requests that a customer might have. Transparency, full browser compatibility, simple porting on mobile devices, …
This is why is needed a solution that can be used in this different scenario, with the capability to detect the browser/device and define the best protocol to use.
Sandro,
I am not sure where you are going with this line of thought. For the apparent foreseeable future, no single vendor can provide all the answers to all the customers. But how does that even relate to detecting browsers and devices?