[The Wholesale Application Community has made big headlines in the last two months. But beyond the affectionate operator feelings and investments this signals towards developers, will the initiative succeed where JIL has failed? Guest author Simone Cicero digs behind the hype to see what lies behind the WAC buzz]
Despite its impressive line up of network operators, the Wholesale Applications Community initiative has been greeted with skepticism across both industry-insider and developer audiences.
Founded in February 2010, WAC is an initiative backed by 24 operators with the incredibly audacious vision of unifying apps distribution, packaging and execution. WAC’s mission is about realising “write once deploy everywhere” for mobile applications and enabling developers to “create applications for the long tail” (a concept that dates back to 2004)
So how does WAC plan to achieve such ambitions? The operator-backed initiative has indicated it will provide: – a reference implementation for a web runtime environment as well as Network Operator APIs – tools for development including an SDK and an emulator – billing enablers and specifications for WAC compliant application stores (as mentioned in the FAQ)
WAC = BONDI + JIL Like a phoenix, WAC seems to be born out of the BONDI and JIL initiatives and has committed to evolving BONDI and JIL into a common specification within the next 12 months.
OMTP’s BONDI has been the most-successful operator-backed initiative aimed at developers. BONDI is in essence a specification of Device APIs for securely accessing device functionality (incl. status, sensors, telephony and SIM APIs) and user data (incl. phonebook, location and gallery). BONDI APIs are accessible from widget runtimes and should (theoretically) also become available via browsers.
The BONDI project has attracted the interest of a few thousand developers and provided an official Windows Mobile reference implementation (with more unofficial implementation projects in the pipeline). We should also see deployment on commercial handsets by the end of 2010 with the first BONDI-compliant widget SDK already appearing from LG.
The JIL (Joint Innovation Labs) project was created by four mega network operators (Vodafone, Softbank, China Mobile and Verizon) to hook operators within the App Store game, and control the app submission, billing and distribution process. JIL is a realisation that the standards route (read: OMA or GSMA) is a turtle-speed approach in a rabbit-speed market. As such, JIL embraced and extended the existing W3C widget specs, adding its own APIs and security model. However, despite the operator investments and ambitions, to date JIL has not delivered much beyond a widget spec and SDK.
A third operator initiative that is part of the WAC scope is Network APIs, i.e. APIs allowing resources from the network (e.g. location, presence, user info) to be exposed programmatically to developers: in this area WAC will build on early achievements of GSMA OneAPI Initiative.
In essence WAC is an attempt to wrap BONDI, JIL and Network API specs and tools into a single operator-led initiative.
In parallel to the technical objectives, WAC aims to define a simplified distribution and deployment model for mobile apps. Rather than build its own Market WAC will probably seek to certify “associated WAC application stores” as well with third party markets offering WAC compliant applications.
WAC challenges ahead To pragmatically assess WAC’s potential, we need to consider how it differs to what’s come before, the environment in which it plays in, and its stated ambitions and roadmap.
Some industry observers compare the Wholesale Applications Community with the JCP (Java Community process) and Java ME in terms of the challenges of standardising app development and distribution. Despite being still the most used and, for sure, the runtime with the largest installed base, the story of Java ME as a platform has been undoubtedly fraught with strategic and execution flaws.
Sun failed to see the opportunity of an app store; Java store is both a half-baked effort and a latecomer to the App Store market considering that Java ME was launched in 2001. Neither did Sun succeed at its main goal – promulgating a consistent runtime (open source or closed source) within the 1B-a-year device market by choosing to over-protect its traditional revenue streams coming from licensing and TCK testing. Sun also chose to license its reference implementation rather than impose a Sun-brewed, mobile Java runtime with consistency and compatibility as the first priority.
In parallel, the design of JCP proved too slow and bureaucratic. The JCP members spent too long entangled in preferred ballots, drafts, reviews, public vs private releases, resulting in specs that were just too late to market. The best testament to that was probably the MIDP3 saga, which arrived at the era of Android and iPhone development that doesn’t need Java ME any more. With 24 operator members behind the WAC initiative, it’s going to prove hard to reach consensus amongst competitors.
It’s also worth realizing that whereas Java ME has been loosely governed by Sun Microsystems (an entity external to the mobile value chain) the WAC consortium is led by operators who play a critical role in the mobile value chain and can, at least in the developed mobile markets, drive the product customization phase – and as such WAC is better positioned at – for example – mandating WAC runtime specs to be preloaded on an Android handset. At the same time, operator specs are seen by handset OEMs as long wishlists with the device compliance index being on continual decline for European operators.
The timing of WAC is another challenge. Given that it will take (at least) 12 months to merge BONDI and JIL, the first WAC-compliant device won’t hit the market before mid-2011. Where will iPhone, Android, Windows Mobile and the other competing platforms be in the next 12 months? What features should a developer expect from a runtime hitting the market in 18 months’ time? Not to mention that developer choices are already being set in stone as the major platforms lock-in developer mindsets (just look at how fast iPhone/iPad apps are ramping up now that that OSX is the number one choice for many mobile developers).
Is there a future for WAC? The apps market is showing worrying signs for operators: mobile app stores are depriving operators from new revenue streams and pushing them further away from the customer front – only leaving operators with the cost burden of supporting customers in the post-sales phase and building out bigger, fatter bit pipes to carry the app-induced traffic.
Once upon a time, operators were responsible for most technology innovation like voicemail, the 2-line-in-1-SIM, premium SMS and Multimedia MMS and high speed networks.
Operators are still in the driver seat with 70% of the mobile trillion-pie flowing through the networks. In Europe, North America and the Far East, network operators still play the dominant role whilst in control of product ranging, subsidy, distribution and retailing decisions.
Yet during the last few years, the ownership of innovation in mobile services and handset products is migrating from the operator hands to Internet/PC players, with operators left to play the role of bureaucrats, support providers and handset subsidization agents. The latest operator innovation like RCS, JIL and network-exposed location seems only to reinvent the wheel. All this, while players from the PC/internet industry like Apple exploit the rivalry between operators by soliciting major subsidies.
At the end of the day, the Wholesale Applications Community initiative is a knee-jerk reaction on the part of operators – an effort towards embracing developers and seizing the community of value-adding actors away from the likes of Nokia, Apple and Google. Now the question is how well and how quickly can WAC execute on the ambitious declaration of intents that WAC is today.
WAC should exploit its stronghold to add value where gaps exist at present, rather than reinventing the wheel. As such, instead of specifying runtimes or gating (and chocking!) the application submission process, WAC should focus on mandating an affordable and consistent revenue sharing policy across operators. By facilitating micro-payments WAC could enable new service charging models such as pay per (single) use, giving developers important alternatives to the free, ad-supported or paid app options.
Another key focus for WAC should be to empower developers with unique network-based APIs like user demographics and targeting and provide decent usage analytics (as mentioned by O2’s James Parton) and a recommendation engine to allow developers to better target the user audience and their application features based on the vast amount of demographics and usage information the operators/carriers hold in their network.
Finally, rather than specifying a web runtime spec based on a lowest-common-denominator approach, WAC should embrace existing runtime specs as much as possible, and consider embracing HTML5 which seems to be unanimously adopted by the major players of the industry, including Nokia, Apple and Google.
[Update: On May 5, WAC held an analyst webinar outlining a few important points. Specifically, Tim Raby, CEO of OMTP is acting as the interim CEO of WAC, while a formal Board for the non-profit organisation will be elected in July 2010. Secondly, WAC indicated it’s planning to standardise the commercial model (perhaps extending to the revenue share formula) for developers and ‘compliant’ app store owners. Developer documentation, developer events and further details on the mission and deliverables of WAC are planned for the second half of 2010.]
What are your thoughts on WAC and the role of operators in mobile apps?
– Simone
[Simone is an mobile strategist, innovation specialist, technology addict and open source enthusiast, having followed the disruptive changes of the mobile industry over the last few years. Simone has served at Three’s Global Device and Application group and at as a consultant at Altran. You can also follow Simone on his personal blog at meedabyte.wordpress.com]