The Wholesale Applications Community has been abandoned by its mobile telco founders due to its almost total lack of traction in the market - the remnant is to be absorbed into the GSMA and applications programming interface assets transferred to specialist Apigee. By I.D. Scales.
Founded in early 2010, WAC's wheels were fairly obviously spinning by early 2011 and by this year it had practically disappeared from sight into the bog: always viewed with skepticism by observers, its demise comes as little surprise.
WAC started life as the Joint Innovation Lab project established by Vodafone, Verizon, China Mobile and Softbank. The idea was to innovate a joint telco alternative to the native OS-based app store and app environment so clearly taking hold in the smartphone market due to the efforts of Apple with its app store and SDK and, more latterly, Google which at the time was clearly determined to follow suit.
It was fairly quickly decided to extend what was initially seen as a technical effort into a broad, multi-carrier business model - the Wholesale Applications Community, WAC - which would involve as many mobile telcos as possible. WAC would develop a network-centred operating system for smartphones and APIs to tap them into telco network services.
But WAC went further. By working together, it was thought, the mobile operators would be able to create a sort of value chain for apps. Thus they could halt or slow all the 'user-engagement' (and revenue) which by 2009 could be clearly seen flowing to Apple, Google and (in those days) Nokia.
From another angle this was 'back to the future' - using technology and standards to construct a federated, telco-centred business model that might, in 3G, repeat some of the success of won by GSM in 2G,.
The WAC, if it worked, would construct a 'proper' and sustainable value chain for apps involving wholesale orchestration of the developer ecosystem and individual carrier retail stores from which mobile subscribers (rather than handset customers) would download apps. Carriers would get their proper share of the app revenues and, to cap it all off, a 'standard' carrier environment meant standard APIs for developers to write to, so apps could hook carrier assets such as billing services, location and er.. billing services.
There was one small problem though... apart from telcos nobody seemed to want a runtime web-based mobile platform. Developers and users were (and despite grumbling) still are, very happy using the Apple/Google SDKs and app stores and, as was abundantly clear in many of our interviews over the past two years or so, were averse to throwing in their lot with telcos. Developers tend to say in private that telcos are too slow-moving, don't really understand the mobile web and always want the major share in any 'distribution' deal.
So developers needed a lot of convincing to invest time and effort in a slow-moving telco environment that didn't offer native app performance.
As for APIs granting access to telco assets - it is hard to find anything behind a telco API that they couldn't hook on the Web. In-app payment, for instance, is available through the Apple App Store while 'good enough' location plus accelerometer and other 'native' facilities were available on the smartphones themselves.
What started life as a solution looking for a market problem, began to look even less relevant as 2010 and 2011 raced by. A year after launch the WAC changed tack to support Android and concentrate on the API side - a sure sign that it was all slipping away. And so it proved.
While the idea of a wholesale app store model might have gone with the demise of WAC, there is no doubt that telcos are still keen to pursue the 'open' web app approach as we can see with the 'Boot to Gecko' development with the open Firefox OS which is being supported by Telefonica and a plethora of other major mobile operators (see video below). The open HTML5 OS is an avenue that even Google is still fixed on with ChromeOS.
This approach quite legitimately aims to disintermediate the lock-down capability possessed by the handset OS owner (Apple and to a slightly lesser extent, Google itself, with Android) without necessarily substituting an alternative lock-in for users to the carrier platform via a wholesale/retail business model for apps and carrier APIs. This always seemed to be the goal of WAC.
But the failure of WAC also illustrates a failing in core telco strategy that seems to occur over and over - a seeming inability by telcos as a whole (clearly their 'innovation arms' are exempted here) to 'get' what's driving the mobile broadband market and mobile internet.
The idea behind both WAC and JOYN (the current instantiation of the Rich Communications Services (RCS) (see - RCS 5.0 is launched as JOYN
) is that you should build the infrastructure and services you think your users 'should' be using because it's just better and more 'sustainable' for the telco business model - good luck with that!
I had a JOYN proponent tell me this month that he bet my mother wouldn't download an app. That is probably true, but then she would never send a text or a JOYN multimedia message or conduct, without assistance, a video link either. The fact is that nobody who can and will use a smartphone in the first place finds apps installation difficult or in any way mysterious. But this - that apps are a bit clunky and unreliable - appears to be the pitch that JOYN participants hope to promote. Wrong. Users clearly love apps and if one doesn't work very well they download another.
So one has to worry, not only about JOYN but even about the new open OS, HTML5 initiatives. Although the concept of the Web app approach is sound, the current problem is that we're in a two mobile OS world. Yes, the Web-based OS approach may enable cheaper smartphones (the only possible gap for a third approach), but economies of scale are already making sub $100 and soon sub $50 Android smarties a reality today.
With both Nokia/Microsoft and RIM struggling to make headway in what now appears to be a two-OS world, how likely is a telco-supported OS to succeed?
please sign in to rate this article