opinion


WAC’s best bet is to focus on OneAPI aggregation

It’s perhaps too easy and fashionable to trash multilateral operator initiatives – to think they are doomed to failure from the word go. But their dismal track record supports such cynicism. And after attending Informa’s WAC Focus Day in Berlin a couple of weeks ago, one couldn’t help but leave the event with a pessimistic view of the prospects for the Wholesale Applications Community, or WAC for short.

The event attracted a good mix of delegates from the operator, developer and vendor communities, making for a lively and, at times, heated debate. Developers did the usual thing they do at such events: Pummel operators for what they see as their clumsy efforts to compete with the big over-the-top players on the content-and-applications front. Even the WAC spokespeople who were there to drum up support for the initiative sounded less than convincing when answering questions about the initiative’s chances of success.

Although WAC started off competently enough, diligently meeting the deadlines it imposed on itself through its strict rollout timetable, its hardest challenges are still ahead of it:

  • Attracting developer interest.
  • Getting handset makers to support WAC applications.
  • Getting member operators to move fast enough with its implementation.

All of these are huge challenges – and, many would argue, beyond WAC’s means to overcome.

Describing WAC

But before I continue I should explain what WAC is. And therein lies one of WAC’s problems: WAC is not easy to explain, since it’s trying to be more than one thing at once – and has probably bitten off more than it can chew. It essentially has three roles:

  • It is the inheritor of the JIL initiative started in 2008 by operators China Mobile, SoftBank Mobile, Vodafone and Verizon Wireless to offer developers a Web-runtime environment and retail channel for widgets capable of working across a wide range of devices and mobile networks. The underlying aim was to take some developer attention away from the native-app ecosystems, principally iOS and Android, which have become the focus of mobile-app activity and innovation.
  • It has also taken the baton from OneAPI, another cross-operator initiative, launched several years ago by the GSMA to get carriers to expose network APIs in a standardized way and provide developers with a single point of access to the network capabilities of numerous carriers at once – and eventually all carriers globally. WAC’s role is to provide that single point of access.
  • It is also meant to act as a wholesale channel for content and applications, supplying these to the retail storefronts of individual operators around the world. WAC widgets are not necessarily the only content that could be distributed through it.

Attracting developers

All this is a complex message to put across. But without a clear message of what WAC is about, it will be difficult for it to grab developers’ attention. And if it can’t attract developers – and significant numbers of developers at that – there won’t be any point in it.

It is hard enough for any operator-led initiative to attract the attention of developers – or, if it does get noticed, to be taken seriously. This is something operators that embarked a few years ago on ambitious plans to build developer communities around their brands have found out the hard way. If you attend any of the big developer get-togethers, the operators are hardly ever mentioned – they are not on the developers’ radar. And if they are mentioned, it is with contempt and derision.

Few developers are aware of WAC, and most of those who are, are unconvinced by it. WAC spokespeople say they are waiting until WAC can offer developers a fair crack at monetization before they launch a big outreach campaign to attract them.

Progress so far

WAC, which was unveiled by operator club the GSMA in February 2010 and constituted into a separate non-for-profit entity in July 2010, launched its first commercial service in February 2011, dubbed WAC 2.0 – a developer platform for HTML5 Web apps linked to the storefronts of eight major operators (China Mobile, MTS, Orange, Telefonica, Telenor, Smart, Verizon and Vodafone). Eight other operators were expected to hook up to WAC’s wholesale-applications offering in 2011.

But it is unclear how things have progressed since the commercial launch. There is no information on the number of developers that have signed up to the widgets platform – the vast majority are likely to have hailed from the JIL program – or on the number of widgets developed, placed on the storefronts of affiliate operators or downloaded/sold. And there has been no update on how many operators have joined the initial eight as WAC members.

Nor is there information on the number of handset models that have been launched this year supporting the WAC 2.0 Web runtime. Five major handset makers – LG, Huawei, Samsung, Sony Ericsson and ZTE – are signed up to WAC, but they have all been quiet about their WAC implementation plans. The handset makers will only bother preinstalling the Web runtime if operators placing large handset orders make WAC 2.0 a specification. But, with the exception of South Korean operators, there isn’t much evidence that operators are making a special point of demanding WAC 2.0 support on new handsets.

WAC is planning to give an update to journalists and analysts soon, so maybe we’ll find out the answers to these questions then. But that information was lacking at the WAC Focus Day.

And the fact that WAC doesn’t yet feel that it has a good monetization story to tell developers shows that it hasn’t met with much commercial success.

What’s coming up

WAC is now saying that the first commercial release of WAC 2.0 will happen this month in South Korea, where the three main operators will start offering WAC widgets to their subscribers – free at first and with a paid-for offering as of December.

On the network-APIs front, WAC is gearing up to launch an in-app payments API linked to the billing systems of several member operators, as part of its WAC 3.0 release. The API, which will be the first to be launched by WAC, is in a beta trial with a small set of developers and is expected to launch commercially by year-end or at February’s Mobile World Congress.

Some of the first operators to hook up to the WAC in-app billing API are likely to be Deutsche Telekom, Telefonica, Telekom Austria and Telenor, though it won’t be at group level. For example, Martin Prosek, manager of VAS-platform development O2 Czech Republic, part of the Telefonica group, told delegates that it would probably take the Czech carrier another year or two to roll out WAC APIs.

Sorting out priorities

There is much more enthusiasm among Western operators for WAC’s network-API offering than for its widgets offering. Speaking off the record with operator representatives at the show, it became clear that most don’t see much point in persisting with the Web runtime – or, at least, don’t think that the Web runtime should precede everything else in WAC’s rollout schedule, as it has until now.

WAC’s original vision was that the network APIs would primarily be used to enrich the widgets being created on its platform. But it doesn’t necessarily have to be that way. The APIs can be a separate offering in their own right and be offered to the far-more-sizable community of native-app developers out there. Furthermore, the operators see a much greater chance of monetization through the APIs than the widgets.

But, of course, reorienting WAC toward serving the native-app-developer community goes against one of the fundamental ideas behind the initiative – that of establishing an alternative apps ecosystem to iOS, Android and other native-app platforms. So it’s not an easy mind shift for WAC to make. Yet it is a shift that has already been made by many of the operators signed up to WAC. These operators will tell you – at least off the record – that there isn’t much point in trying to establish such alternative app ecosystems. They’ve tried to do that themselves and failed. Instead, they are now trying to piggyback on existing ecosystems – just as Telefonica is doing with its open-API program, BlueVia, which partnered with Microsoft’s developer community, for example; or just as Vodafone is doing with Android, offering carrier billing and its own content channels on the Android Market store.

Piggybacking on other communities

In off-the-record conversations, operator execs involved with WAC admit that the initiative doesn’t have much of a chance of directly attracting a large and diverse mass of developers. And they add that, although WAC might not be saying so in so many words, it too is aware of the problem. Therefore, WAC’s main strategy will be to go to existing developer communities, such as Android’s, and offer them its SDK. And, in this context, the network APIs will be the WAC asset most likely to be of interest to developers – as something they can mash up with the applications they are already creating within those communities.

Officially, WAC says it will be taking a two-pronged approach: It will try to recruit developers directly and will try to hook up with developer communities.

Network APIs

Although network APIs appear to be WAC’s trump card, there are doubts about the usefulness to developers of most of the network capabilities that operators are busily exposing through open APIs. There is high demand among developers and app-store owners for carrier billing. In a commercial trial conducted in Canada last year for the OneAPI initiative, involving all three main MNOs there, billing was by far the most requested API of the three that were offered to developers. The others were SMS and location.

When you speak to developers in developed markets, many don’t see much point in being able to add network-positioning (cell-ID) and SMS/MMS capabilities to their applications, because most smartphones – the handsets for which most developers want to develop apps – now come with GPS, offering free and far-more-accurate positioning than cell-ID, and because there are numerous IP-based messaging services available for mobile phones that offer far greater capabilities than SMS/MMS, also free (as long as the data consumed is covered by a flat-rate data plan, which almost all smartphone users have anyway).

The picture is different in emerging markets, where smartphones are still scarce and the vast majority of people wanting to engage in messaging or location-based services on mobile phones have to do so via SMS and cell-ID, respectively.

Telefonica, whose mobile-messaging APIs are central to the novel business model of its BlueVia program, in which developers get a share of what their application users spend on SMS/MMS via the BlueVia APIs, would argue that there is demand everywhere for mashing up SMS and MMS into mobile apps. Hence its alliance with Twitter in the UK, in which Twitter has hooked up to BlueVia’s MMS API to allow Telefonica (O2) subscribers to share photos on Twitter via picture messaging.

Operator curse

But, ultimately, it is the fact that WAC is primarily made up of operators that most conspires against its chances of success. And that’s for two reasons: the natural rivalry and distrust between operators, and antitrust regulations.

Although most operators have come to realize that their biggest competitors on the services front are no longer fellow operators but OTT players, such as Apple and Google, it is in their DNA to want to differentiate from their fellow operators – and to hold things back from them and strike out on their own – even when they put their signatures to multilateral initiatives such as WAC and pay lip service to the need to work together for the common good.

And even when there is a desire to do things together, it is often prevented by regulation. A big handicap for WAC is that it cannot go to developers with a clear message on the revenue-share/pricing model they can expect from selling widgets through operator storefronts or from hooking up to network APIs, because antitrust laws prevent operators from agreeing on common prices. That means that behind the common interface provided by WAC, developers will be offered different terms by different operators. But in the current app-store climate, developers have gotten used to, and demand, transparency on the business model being offered by store owners. So they are likely to view with suspicion any app-ecosystem proposition that doesn’t offer clear revenue-share terms.

In the OneAPI Canadian trial, pricing was one of the stumbling blocks. Developers that hooked up to the joint SMS API offered by the three Canadian operators found that the wholesale price charged per SMS was higher than the price offered by traditional SMS aggregators! That is absolutely crazy and another example of operators shooting themselves in the foot. After all, one of the main ideas behind OneAPI is that you cut out or reduce aggregator-middlemen fees, turning cross-network access to APIs into a more affordable, self-service activity.

Most valuable role

WAC has, potentially, a valuable role to play as an aggregator of OneAPI APIs. It is a not-for-profit organization and will be taking a small share – it won’t say how much exactly – of the revenue made through the network APIs and applications sold through it, just to cover costs. It will levy its share from the operators, not developers – though it will be up to operators to decide whether to make up for that cost in the wholesale price charged to developers for hooking up to the APIs or in the retail price charged to users for purchasing apps.

OneAPI desperately needs a global aggregator like WAC for it to start making progress and avoid ending up in the scrapheap of failed multilateral operator initiatives. Going about it on a country-by-country basis – where all the operators in each territory aggregate their APIs with the help of specialized third parties, as was done in Canada – is just not going to work. From what I’ve been able to find out, there is still no other country following in Canada’s footsteps on OneAPI. And it’s not even clear whether the service set up in Canada will persist.

The reasons for creating WAC, and for that matter OneAPI, were good. Operators desperately need to aggregate their offerings to have any chance of competing against the global reach of OTT players. But the clock is ticking, progress is slow and there is still a huge mountain to climb.

Tags:

One comment

  1. Avatar Land 22/02/2012 @ 12:56 pm

    good point

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Polls

Sorry, there are no polls available at the moment.