Is there room for another player?
Today, Respoke officially launched.
Respoke is yet-another-WebRTC-PaaS-vendor, so the question to ask is why? Why do we need another WebRTC PaaS vendor? Aren’t there enough of them?
I met the Respoke team for the first time on June 2014. It was during the week of Google I/O and the first Kranky Geek event (the second one was just announced). I got an invite from them to check out their service. At the Kranky Geek event itself, Tim Panton used Respoke for one of his live demos (you can see his session here – Tim will be joining us for Kranky Geek @London as well). Twice in the same week is was interesting.
At the time, Respoke was at its infancy, so I haven’t added it into the September update of my WebRTC API Platform report. I am glad that it is part of the latest update of the report, coming out end of this week.
I like to think of Respoke as a company within a company. On one hand, they are part of Digium, the company behind Asterisk. On the other hand, Respoke has little to do with traditional VoIP at its core – it is designed and built with the web in mind. Connectivity to the Asterisk assets of Digium are there, but not front and center – a good thing for a WebRTC service if you ask me.
But why one more vendor?
Because WebRTC PaaS comes in different shapes and sizes. The vendors are different. I can’t suggest TokBox or Twilio (call them the elephants in this market) to everyone – these are great platforms, but not always a fit for the given use case. This is what makes working with these vendors when updating my report so much fun – it gives me better understanding on where each one of them is headed, and in which cases they make sense.
Respoke plays two cards today:
- Simplicity – they have API that are simple to use, and a pricing scheme that is both simple and somewhat different than most of the rest of the players
- Openness – being Digium, they had to be. They haven’t open sourced their infrastructure (I don’t think any of the other players have), but they are the first ones I am aware of who placed their documentation on GitHub, effectively open sourcing it
If you are looking for a vendor to use, check if Respoke fits your needs. Or look at the other vendors on my report. You might just find a vendor that matches your needs.
–
I have been hired by Respoke for consulting. That said, it has nothing to do with this write up. Take it with a grain of salt and a critic eye (as you should with any of my posts, and with anything you read online anyway).
I love Respoke’s tagline: “Add live voice, video, text and data features to your website or app” … very very close to ours “Add Real Time Voice, Video, Messaging into your VoIP, Web & Mobile Apps” 🙂
This shows at least the difficulty to differentiate in the PaaS space !
🙂
Taglines are nice, but the essence of the platforms are different.
As an example. Luis – you’ve invested in the past 3 months on things that most other platforms haven’t as far as I am aware.
Tsahi and Billy, I agree with both of you.
I will try to be more differentiating for our next tagline 🙂
Luis,
Yes, it is difficult to show difference in 140 character tag line. I think this is true for any PaaS, not just WebRTC. Consider the email realm – mandrill, mailgun, sendgrid, et al. do the same thing “email service” as an API on their platform. So in our space we are seeing the effects of a concept that is broad-reaching in the larger developer community.
Thanks, Tsahi. One other item on the “open” front: our JavaScript client libraries for browsers and for Node.js are both open sourced under the MIT license. The Asterisk channel driver (chan_respoke) is released under the GPLv2 – the same license as Asterisk. We’re planning on licensing our mobile SDKs for iOS and Android under MIT. This makes it much easier for devs to tweak the library to better fit their use cases.
Would be nice to see an MIT library of a WebRTC mobile SDK out there.