After a few months of rumors and speculation from those in the know, Twilio has made it’s debut. Twilio is the latest in a march of Web telephony service providers like IfByPhone, Jaduka, Ribbit and CloudVox, all vying for programmer’s hearts and minds. I’ve had a brief opportunity to peruse the functionality and documentation on the site…. here’s my two cents:
- Good job on Twilio’s straight-forwardness. Twilio has an easy to understand pricing model, well within reason for application developers, and one that assures that they have some sort of decent margin. Although I personally think they could have made even more money by charging by the transaction, the minute model is no shock and is quite fair.
- I’m happy to see the RESTy nature of the API, making it fairly easy to pull out your PHP, Ruby or Objective-C tool-kit for application development.
- At the risk of alienating my friends at Voxeo, I’ve had it with XML-based languages. Twilio’s language, unfortunately, captures the worst of all worlds. Unlike Voxeo with their pre-eminant VoiceXML and CCXML hosting, you can’t take your application anywhere else because the Twilio XML language is proprietary. Ick. Did I say I’ve had it with XML based languages? Ick ick. (Actually, if I search my heart, the only reason I ever put up with CCXML in the first place is because Voxeo does such a damn good job hosting it. Otherwise, I have no patience for it.) That said, the language does span the most imporant five verbs for Voice Mashup development, so I’ll give it a few points for that. In general, though, hard to see that somebody who actually likes CCXML would choose Twilio over Angel, Voxeo or TellMe.
- I’m also thinking that web designers will prefer ifByPhone’s HTML centric approach over on the fly XML creation or REST interfaces. The ifByPhone technical approach favors those who are DHTML centric; not really thinking that Twilio will be something they will prefer. So, as far as adoption, my bet is that the creative Ad agencies continue to favor the folks from Chicago.
- How about those flex and flash developers? Given the choice between Ribbit and Twilio, who do you think they’ll choose? If you are in the Adobe camp, I think Ribbit’s a better choice for you.
- Perhaps you’ll be like me, and be a Ruby-ist and a fan of Adhearsion. In that case, go off to CloudVox and check out what they’ve got cooking. Not everyone ends up as a Ruby guy, and that’s just fine, but every really creative mashup guy I know uses it exclusively. (Should give a telegraph shout out here, but I still can’t get my head around a MVC treatment of voice. I probably need to evolve.)
Ok, so if you aren’t a VoiceXML guy, or an DHTML dude, or a Adobe jock, or a Rubyist, you are still in the Twilio camp. I happen to favor now prime competitor Jaduka here, if only for their labs-application creativity and massive head start.
Ok – in all seriousness, what am I looking for? Where’s the hole?
- Give me some unique functionality. I love what Orange is doing with their developer program. Isn’t there anyone else out there that can bring that amount of richness in an API? There must be.
- Give me something that integrates really, really well. Twilio gets high marks from me in making it easy (really, very easy) to signup and deploy a service. Now, make it really easy for me to integrate into my exisiting infrastructure and applications. Even better, make it easy for anyone who’s a Serena or Jackbe developer to integrate.
- Can we just get a little smarter about our APIs? If you are BT or Deustche Telekom, you really have to supply solid and basic APIs – your ten thousand large companies need them, and you need to provide them. But, if you don’t have a footprint the size of a continent, you gotta move the ball forward.
That all said, congratulations to the Twilio team on their launch. If I were an investor, would I go in on this one? Yes, but only on the fall down theory: there are enough large carriers that need this functionality that one will fall down and need to purchase them for it. Oh shoot, I forgot about Broadsoft’s Xtended developer program. I take it back.
Hi Thomas,
Great, thoughtful industry assessment. It’s certainly an exciting time for people looking to build voice apps.
The question we ask about telephony APIs is… what can I really accomplish with a given API? Can I solve real voice communication problems? At Twilio, we strive to balance power with simplicity in order to enable more developers to participate in this field, to build useful, real-world applications.
Again, great analysis. Keep up the great coverage of the industry.
-jeff
Hi Jeff –
Thanks for that, and good luck to you at Twilio. One thing is for sure – the market is massive, so there’s room for everyone. And yes, I do think it’s fair to say that the initial Twilio offering has a decent mix of power and poise, and if you capture the hearts and minds of your developers – game over and you’re the winner. Lots of opportunity out there – I’m rooting for you.
Thomas
Great post.
I have not studied Twilio’s XML language in great depth yet, but it’s clear that they try to offer a simpler alternative to VoiceXML/CCXML. And with reason. VoiceXML is such a beast. (And wait for VoiceXML 3.0…)
But developing DTMF only applications in VoiceXML is not necessarily much more difficult than with TwiML. You can easily abstract a subset of VoiceXML in your application and stick with that. Use VoiceXML as an interface between the voice resources (telephony, speech rec, etc.) and let your application drive the show. That’s what most service creation environments (VoiceObjects, Cisco CVP, etc.) do, btw.
Remember that Microsoft tried to offer an alternative with SALT not so long ago and did not really succeeed. I wish Twilio good luck!
You mention Cloudvox – I like ruby and I’d like to see more of their service. I emailed them but heard nothing back… any idea when they’re likely to be handing out more keys?
The issue is TwiML is that it is proprietary. That said, VXML is tough. Both are based on serving ML pages, so that means you need to run a webserver to serve the ML pages.
What if you want to integrate voice into a standlone EXE, where the logic is determined by your standalone app. To add telephony you will need 3 systems to interact, Standalone app., a webserver to server ML pages and the telephony could (Twilio or Voxeo).
If telephony is controlled by SOAP based webservice calls, then any app can consume it. For each action send in a ML payload, which has the instructions for the telephony could to perform
The issue is TwiML is that it is proprietary. That said, VXML is tough. Both are based on serving ML pages, so that means you need to run a webserver to serve the ML pages.
What if you want to integrate voice into a standlone EXE, where the logic is determined by your standalone app. To add telephony functionlity (Make a call, read out status, take a command and then hangup) you will need 3 systems to interact, Standalone app., a webserver to server ML pages and the telephony could (Twilio or Voxeo).
If telephony is controlled by SOAP based webservice calls, then any app can consume it. For each action send in a ML payload, which has the instructions for the telephony could to perform
Our company is looking into ways of reducing costs and Twilio is one of the options we are looking into. Thanks for the interesting review and for pointing out some additional options which we had no heard of yet.