Pages

Pages

Wednesday, October 20, 2010

Will telcos have a positive "balance of trade" in APIs?

I had an interesting discussion today, about mobile cloud applications and syncing.

In part, it covered my regularly-expressed disdain for social network aggregation, and the metaphor of the extended address book on mobile phones. I remain unconvinced that users really want to have their contact lists heavily integrated with Facebook, Skype, Twitter or whatever.

Nevertheless, it highlighted an interesting angle I wasn't previously aware of. I'd recognised that most of the major Internet players had exposed APIs so that developers can hook into them for various mashup purposes - but I hadn't realised how the terms and conditions worked.

In particular, I didn't realise that if you're a large-scale user of some APIs (Facebook, say), then you have to pay. So an operator or handset vendor wanting to do a complex enhanced-phonebook with imported photos & status updates, for millions of users, is not only competing with the standalone downloadable Facebook client, they may also be writing a cheque for the privilege. Ditto if they want to give an MNO-customised variant to their users out-of-the-box.

I've been saying for a while that the power of Apple, Google, Facebook et al was such that operators play Net Neutrality games with them at their peril ("No, how about *you* pay *us*?") . I hadn't realised that they - or some of them, at least, I don't have details which will undoubtedly by confidential - were already throwing their weight about.

Now, I've also been talking and writing about operator-provided APIs for a long time as well, including through my work with Telco 2.0. Initiatives like the GSMA's OneAPI, as well as telco-specific services like BT Ribbit and many others in the mobile world, point the way towards operators selling access to messaging, billing, authentication, voice call control and numerous other features and functions.

In theory. In the real world, telcos' commercial sales of API access has been evolving at a glacially-slow pace, hamstrung by painful back-end integration work and lots of design-by-committee delays. In the meantime, some supposedly valuable telco "assets" have now depreciated to being (essentially) worthless, such as location. I expect "identity" to be the next to be replicated and improved by Internet players.

So... the telcos' API revenue streams haven't yet materialised to a meaningful degree. But instead, they're starting to have to spend money on other companies' APIs in order to provide the services their customers actually want.

I wonder where we'll be in a few years time, in terms of the "balance of trade" in APIs - will operators be "exporting" or "importing" more? In which direction will the net flow of cash be going? It will probably be difficult to measure, but it's certainly going to be an important analytical question to answer.

7 comments:

  1. Telcos are such slothful lumbering incompetent beasts they don't stand a chance making anything actual users want. Their core competencies are lobbying to prevent competition, and having trenches dug for them, and they should stick to them.

    The only APIs they can sell are the CALEA ones allowing law enforcement to initiate a wiretap, and the ones allowing the media cartels to identify users from their IP address when copyright infringement is claimed.

    ReplyDelete
  2. once telcos have 100% of penetration and voice and data prices are being lowered, their space to grow is "commercializing the enablers as cloud communications" and the cloud computing/storage of solutions based on those enablers.
    APIs for each telco enabler, based on web services, rest, very close to internet programmers, and opening from the beginning common enablers as RCS to create services on top and mash-up's with internet tools will help carriers to keep a role and generate new revenue streams.

    ReplyDelete
  3. Juan - RCS will never be a "common enabler". At most, it will reach a tiny fraction of handsets, if it actually ever gets deployed in reality.

    There are at least 12 reasons why RCS will fail.

    http://disruptivewireless.blogspot.com/2010/10/new-report-zero-chance-that-ims-rcs.html

    Operators have gone about the "enabler" pitch the wrong way around, and still think that services should be tied to access accounts.

    ReplyDelete
  4. Dean - First, I absolutely disagree that users do not want contact sync w/ one of their identity services (eg Google, FB, Yahoo, MSFT, LI or Twitter etc). (But maybe, that's b/c I live in the Bay Area and I'm 31).

    Second, I don't think your API charges comment is correct? Are you certain Twitter/FB are charging for large-scale integration? I haven't checked w/ Twitter but I know at least 1 OEM that does not pay for FB.

    ReplyDelete
  5. Dean, I've actually verified that this is def. not true w/ Twitter (I don't know about FB yet but I'm verifying).

    Where did you hear this?

    ReplyDelete
  6. Hi Raj

    Thanks for your comments.

    I didn't say that sync was completely without use - what I definitely believe is that the *aggregation* of social networks into someone else's middleware layer is worse than useless.

    See:
    http://disruptivewireless.blogspot.com/2010/07/death-of-kin-proof-point-that-mobile.html
    and
    http://disruptivewireless.blogspot.com/2010/04/mobile-social-networking-doesnt-really.html

    Interesting feedback on APIs. I heard it from someone in a much better position than me to know these things, but haven't independently verified it as I have limited direct contacts at FB and LI and similar services. In any case, I'm pretty certain that there's a ton of NDAs in places.

    Twitter probably isn't large enough / important enough yet, in comparison, plus its data is much more predominantly "public" anyway.

    More generally, in the past I've certainly expected some of the web companies to use their power to push back against any network non-neutrality.

    Bear in mind the earlier (unconfirmed) rumours that Apple was taking a rev-share of some iPhone contract subscription payments, which is another example of the balance-of-payments maybe going the "wrong" way in future from telcos' point of view.

    Dean

    ReplyDelete
  7. Hi Dean,

    Slightly tangential (but in terms of the balance of payments), I do believe that OEMs and/or platform providers (which in many ways are the large web companies (eg if FB phone is real) are maintaining the new services billing relationship to the end-user (something that was previously owned and operated by the operator).

    Operators may become the billing experience for voice/data etc but OEMs/Platforms control all the other billing with the consumer.

    So you have a scenario where instead of the operator giving a rev-share to the OEM/Platform/Service from the revenue they collect, you have payment potentially flipped w/ the OEM/Platform paying a rev-share to the operator in exchange for operator promotion of the mobile device (eg carrying it in-store).

    Imagine a scenario, where your phone being in the store is directly related to how much revenue you can share back to them?

    In this model, operators are being relegated to dump pipes but I do think in one swift move (here in the US), they've taken that back by introducing data caps on flat rate data tariffs.

    Now you have a scenario where apps/services may want to partner w/ the operator again (on a rev-share basis) to zero-rate their data consumption.

    Anyways, all interesting to see how it all plays out.

    Raj

    ReplyDelete