Since the release of the Manifesto it’s been an intense week, thank you for all the feedback, keep it coming.  We’re receiving lots of excellent advice; and having many discussions addressing confusions in the market.  This will help make the Manifesto easier to understand, especially on some of the assumptions and defining some of the terms used; as well as firming up the needs and responsibilities on which the ecosystem is built.

Common Questions include:

“What has changed compared to the past?”
The underlying question is how can this succeed where others have failed.  The three main changes are:

• No Gatekeeper.  There are now proven channels to market like Apidaze, Bandwidth, Tropo, Twilio, Plivo, OpenCloud, Telestax (Restcomm), hSenid Mobile, OnMobile, TelAPI, etc.  Twilio claims its revenues will be $50M this year, this is not a niche businesses, this is the start of a telecoms application revolution.  So in creating this ecosystem, it is NOT wholly dependent on the Telco, they are no longer the gatekeeper.  The role Telcos play in this emerging ecosystem is dependent on their ability to fulfill their responsibilities towards the needs of the other actors.  The pie will be much bigger with all three actors working together as they can rapidly expand the ecosystem across the world, but it’s an expansion that will happen regardless of telcos’ ability to execute.
• Focus.  The ecosystem is initially focused on the core service of communications.  This means embedding communications in many business ecosystems, and delivering more communication services through all possible channels to market.
• Motivation.  Telcos’ communication service revenues are finally being impacted, so there is a clear and present danger in doing nothing.  In the past it was the possibility of future revenue erosion that perhaps limited motivation.  At the TADS Summit we have a number of case studies from Celcom, Orange, Algar Telecom, Etisalat, and more, demonstrating Telcos can be effective members of this emerging ecosystem and sharing best practices.  Since the success of OpenCloud, Twilio, Tropo, etc. we’ve seen many more start-ups come into this sector like Apidaze, Telestax, Plivo, etc..  This is driving innovation in making telecom services ever easier to consume by developers and businesses and vastly more powerful in meeting their specific needs.

How can TADS succeed given the struggles of GSMA OneAPI?
OneAPI failed because it did not meet the needs of developers, it was created to fulfill the needs of telcos.  Tropo, Twilio, etc. deliver what developers need, and it’s much more than an API.  This is the key example of why we need to take an ecosystem-based approach and meet the needs of all actors.  Apidaze, Tropo, Twilio, Plivo, RestComm, etc. show now to make a Telecom API work both technically and operationally.  RestComm copies the Twilio API making it easy for developers.  And it’s not just the API it’s web scripting that makes it just a matter of copy and paste and a business has an IVR or alerting system.  See the Apidaze’ slides in the Independent Telecom API workshop to see how powerful this can be.  Support is more important than the API itself, and is the common theme for success in the Telecom API business.

Is the brokering function you describe in the Manifesto the same as the GSMA OneAPI Exchange?
No, the brokering in the Manifesto is about business model and cultural brokering as the gap between telcos and developers is large.  The Manifesto includes a broader range of technologies including application platforms like OpenCloud’s Rhino and Tropo’s Ameche; it includes free and open source telecom software like Mobicents; it includes WebRTC and Telecom APIs (and don’t forget web-scripting).  The focus of the GSMA on API standards and API routing (it’s not API aggregation as the business models remain in the control of each telco) are not addressing developers’ needs.  We must take an ecosystem based approach.  Telecom API aggregators that fulfill developers’ needs already exist like Tropo, Twilio and the Telefonica/Telenor partnership.  Businesses use many APIs with no difficulties, some use  BOTH Twilio and Tropo, it’s just a HTTP request and switch statement (IF statement).  In the Manifesto we’re trying to build an ecosystem of telecom application developers using vendors to broker (manage the business and cultural gap between devs and telcos) and share best practices on embedding telecoms everywhere and launching more services.  We are building an ecosystem around an existing business, not implementing another ‘build it and they will come.’

But API fragmentation will kill the business?
Fragmentation is not an issue, APIs are easy, it’s a HTTP request.  3UK can simply copy AT&T’s communications APIs.  API exchanges are not necessary for communications, as communication services are interconnected and roam.  For calling / messaging / RCS (Rich Communications Service) / WebRTC (Real Time Communications) a developer can just use one provider whether it be AT&T, Verizon, Tropo or Twilio, the rest is simply interconnect.  See the later discussion on the importance of telcos using each others’ APIs.  The key to understand is the service is where the value/money resides, not the API as that is simply one way of delivering the service in an easy to consume way for the developer/business.

But the OTT’s have won, communications is just a client on the smartphone?
Any IP based service provider (OTT if you want to use that term) can deliver voice and messaging provided both users have downloaded their application and are connected to the internet.  BUT businesses need to run their business on communications that simply work across all customers, they need ubiquity, they need support, they need someone they can talk to.  A telcos’ value is partially in its network (in-call services and avoiding back-haul into a cloud (a significant problem outside the US)), but its also in its local presence, the bundle of services, its enterprise relationships, ability to support, etc.

How can Telcos win developers’ hearts and minds?
Developers are a diverse group.  Part of the contention in the Manifesto is telcos should NOT target mobile application developers, that is those focused on direct access to a large engaged customer base that are prepared to pay in time, cash and privacy.  Focus where the ‘channel to market’ requirement is not the primary need because the developer already has a channel to market.

Telcos need to focus where they are more likely to win today. Hence why we refer to telecom application developers as a lead-bowling pin to the broader developer community.  These developers include internal telco developers, using platforms such as Opencloud, Tropo’s Ameche, and Telestax’s RestComm.  A Telco’s existing ecosystem has much value, AT&T’s announcement of an enterprise focused Telecom API program provides a good example.  And there is a broad category of independent telecom application developers using the cloud communication capabilities of the TADS sponsors that in many cases will work with telcos if the right recipe can be found in using them as a channel to market – but note this is not the reason they selected a Telecom API, rather a fringe benefit.

Commentary and Advice on the Manifesto

Where the text is in “quotes” its paraphrasing feedback received.

Comments from VCs have been interesting.  Remember, most walked away from investing in the telecom industry many years ago.  They consider the TAD ecosystem as “possibly making telecoms invest-able again.”  Perhaps we’ll hear the phrase, “we will pass on this investment,” a little less often whenever the word telecom appears in a business plan.

Telcos being a channel to market comes up time and again; telcos are still promoting themselves as a channel to market to developers, yet are not delivering on that claim. Some of the comments include:

• “Telcos need to open up a channel for devs to their customers.  They say they have 100 million subscribers, but they don’t really allow devs a direct way to access them unlike Apple and Google.
• One telco is not enough of a market for a developer when the focus is channel to market.  When you factor in device and operating systems, the actual addressable market gets smaller and smaller.
• Telcos are still trying to develop proprietary platforms, e.g. proprietary healthcare platforms.  This is not a viable channel to market for most developers, only a focused niche.
• Enterprise mobility is taking off, telcos need to get their dev programs and various vertical divisions working together and aligned on incentives.  So many still focused on mobile games and the long tail….  long tail especially and all of the so called accelerators and start-up frenzy is mostly a waste of time and money.”

The above channel to market issue needs to be explained in the Manifesto.  An assumption in the Manifesto is the role of a telco as a channel to market will be limited and will need vendor support, with innovations coming through internal branded services (using existing marketing), with partners (perhaps co-marketing and the partners’ channels to market), and developers (businesses) just using the capabilities with no need for telco as a channel to market – note this is how Tropo, Twilio, Apidaze, Bandwidth etc. position their offers to developers.

There is a group of commentators that think telcos have made “no significant contribution to service innovation in decades and should just be a dumb fat pipe.”  They are generally complementary of the objectives of TADS but pessimistic on its chances given telcos “want to innovate but are institutionally incapable.”  Here all we can do is show a path and publicize those getting it right.  As explained at the start of the weblog, things have changed so we must at least try from the grassrooots to build a telecom application developer ecosystem given the existence proof is there thanks to Tropo, Twilio, OpenCloud, OnMobile, APIdaze, Telestax, etc. and many businesses are benefiting from running on cloud communications.

There is strong support for approach we’re taking with the TADSummit in “bringing all relevant technologies together: FOSS, app platforms, APIs/web scripting, and WebRTC.  Rather than a silo’ed discussion, its a practical discussion across all relevant technologies and businesses.  Its not easy what you’re trying to do, but the TADSummit is unique and important.”

More great comments on the need for Telcos to work together and on the need for telcos to both consume and expose APIs:

• “Telcos should sell APIs and capabilities to EACH OTHER, and be involved in each others’ developer ecosystems. If Vodafone can’t/won’t sell to Orange, it sure won’t be able to sell to Google or Facebook or a mobile app long-tail developer.”  This is likely a better approach than the ‘build-it and they will come’ approach of OneAPI Exchange.
• “Telco management should empower individual business units’ developers to both act as internal customers for APIs, but also to look outside for best-of-breed (or timeliness) if appropriate. They need to be pragmatic about being both sellers AND buyers of platform capabilities, both strategically and tactically.”  Here the AT&T announcement on the an enterprise focused Telecom API program is a great step in the right direction.

A common comment was the need to define the needs and responsibilities in more detail and make them much stronger as other actors are relying on them.

As you can see in the above questioning and commentary we’ve got lots to work to do in building the Manifesto, the great thing is the actors in the ecosystem are driving the TAD Manifesto forward.  Please continue to send in your comments and advice, thank you