Making a Successful Mobile Developer Platform

As stimulus for the debates we'll be having at the Telco 2.0 Exec Brainstorm in Nice this week, below we discuss what distinguishes successful mobile development platforms from the many, many unsuccessful efforts we've seen before?

[NB: If you can't come to Nice this week, check out the new 'distance participation' packages which allow you to access all the brainstorming input and output without the travel, at a time that suits you.]

Everyone loves them these days, especially if they come in windows with bevelled corners and are called "app stores". But the idea covers a lot of very different practices and products. In order to understand it a little better, in this article we track its development and examine what it needs for success.


A brief history of mobile apps

The industry has been interested since the late 1990s in the possibility that some of the creativity and user-driven innovation characteristic of the software and Internet industry could be transferred into the networks we had just so expensively built. The underlying technological drivers were network convergence, the arrival of useful data services, and the increasing general-purpose processing power available on the devices, especially after the arrival of the ARM 7 baseband chip. But in practice one of the most important catalysts was the arrival of a new sensor on the mobile device - the camera.

Simultaneously, there was also the example of an existing mobile software ecosystem - the world of small developers around the Psion PDA platform. The capabilities of GSM devices rapidly converged with those of PDAs, and eventually the mobile industry bought Psion's operating system. But actually delivering on this prospect proved difficult; technical barriers (a lack of commonality between PC and mobile programming) and some bad decisions by the operator community (WAP and MMS, rather than just providing a TCP/IP stack and standardised device APIs) meant that the initial bloom of interest failed to survive the crash of the early 2000s. Things recovered, but only slowly, and take-off wasn't achieved until the launch of the Apple App Store - even i-mode didn't achieve much outside Japan.

What makes a platform?

What elements make up a developer platform? The first group consists of technical enablers - the development environment itself, with the interpreter, virtual machine, or compiler for the programming language used, any SDK associated with it, and any standard software libraries that may be provided. APIs go here as well. We've had these for many years now, and they've steadily improved as well. Nokia provides a positive embarrassment of developer resources - you can develop for Symbian in Objective-C, Python, or HTML/Javascript, there are SDKs for all of these, lots of documentation, and extensive APIs for the devices.

The second group is what you might call the social enablers - you need a community, in order to share both problems and solutions. This may sound wet, but just look at the sheer volume of forums, blogs, USENET groups, lists, wikis, IM nodes, twitter feeds etc devoted to discussing software development. Horizontal gene transfer accelerates evolution in software as much as it does for real viruses.

Another key social enabler comes later in the development cycle; you need the users to be able to discover, discuss and recommend products. After that, you need to deploy the products to the users, while balancing painlessness with security. As we've said so many times before, content is king but distribution is King Kong. You also need a mechanism to distribute updates and to collect bug reports.

But you still don't have a platform.

Finally, you need commercial enablers - a business model which routes money from the end user back up the value chain. Because of the strong trading-hub nature of development platforms, the end-user value of the service rises rapidly with more applications and more developers - ask Steve Ballmer. So, there's a need for two-sidedness; it's vital that the activation-energy required to get developing (and to get using applications) is as low as possible, and that the path to actually making money is short. Good software is scarce; therefore, that's the side of the two-sided model that you need to subsidise.

Three Telco 2.0 themes

Summing up, three familiar Telco 2.0 themes are represented here:
1.) the importance of being a much better wholesaler to your upstream customers, 2.) the vital importance of distribution, and 3.) the aim to improve other people's business processes.

So, how did they do?

So, how did they do? Apple is triumphant; Nokia has had some limited success; RIM and Windows Mobile have islands of success in some enterprises. The triumph of the iPhone, in this framework, is not difficult to explain - using Unix, an Apple-typical SDK for C, but mostly the technology of the Web, they had a lot of technical commonality with the rest of the world, every device came with the ability to search for, recommend, and install new applications, and their commercial terms provided for an unusually generous revenue share that was paid out quickly. Quite simply, it was an integrated combination of business, infrastructure, software, and hardware of the sort Apple historically specialised in.

Nokia can claim to have the most developers signed up, but there is much less sign that it's a meaningful contributor to their bottom line or anyone else's. (This may be blurred by the fact that Symbian applications don't have to be delivered from a central Nokia service.) It may change now that the Ovi Store is launching, and they have a number of advantages - huge scale is one, and their programming tools are powerful and increasingly available as open source software.

Despite all that, Microsoft Windows Mobile and RIM have both managed to carve out a niche serving enterprises; this is almost certainly because there is an existing, long-standing economy of IT departments and software companies that exist to serve this demand, and these vendors have simply extended onto another type of device. (Not that IBM and's mobile activities have been concentrated here.)

Conclusion: Distribution is still king

In conclusion, distribution is still the issue, even if it regularly causes headaches. Apple is constantly involved in disputes about applications it has denied access to; this is a downside of offering your users software with an implicit guarantee. But this is arguably better than Nokia's code-signing and testing process through Symbian Signed, which costs the developers time and money upfront whatever they plan to do with it and thus works against the fundamentally 'two-sided' business involved.

Because of this two-sidedness, it's very important to foster the community with cash. However, it's too early to say whether O2's bold Litmus project, which aims to provide a complete infrastructure for mobile developers including testing, hosting and access to VC funding as well as APIs, documentation, forums, and distribution, brings enough additional value to the game to take off. We think it's got a chance, but we are concerned that making it a "UK project" compared to the global App Store may be a mistake. Scale is vital in two-sided businesses.

An integrated view of this two-sided business opportunity is crucial

  1. Mobile app platforms require integrated technical, social and commercial enablers
  2. Apple's success to date is explained by this integration
  3. Scale is crucial, good software is scarce
  • Therefore a two-sided approach that leans towards the upstream developers is appropriate
  • Ed. More on this topic at the Telco 2.0 Executive Briefing service: