[In a game of ecosystems, it it possible to bend the rules? Research Director Andreas Constantinou examines the few technologies that can bring the Android ecosystem on non-Android devices – compatibility layers, virtualisation or emulators – and their impact in a post-‘Googlerola’ world] A game of ecosystems The mobile industry in 2011 is an industry ruled by ecosystems. The Android and iOS platforms are jostling for the top spot in terms of number of applications and developer mindshare. Earlier this year, Nokia had to jump from a burning platform (its in-house Symbian OS) into an ocean of uncertainty (Microsoft’s Windows Phone).  MeeGo has to find foster parents, as both Nokia and Intel (its founders) seemed unable to gather enough momentum. Nokia is re-launching its effort at building the Qt ecosystem through a more ‘open’ platform governance model. Qualcomm is trying to rebuild loyalty in BREW MP by investing in online marketing. The platforms today are fighting for who can build the biggest, most active and most sustainable developer ecosystem. What determines the success of a platform? We know it’s the wealth of its ecosystem (lets call it developer ‘mindshare‘) as well as its consumer reach (the ‘market share’). It’s also patents, as these legal instruments can create not just barriers to entry (see how Apple barred Samsung tablet), but also market costs (see how HTC, Acer and Viewsonic are paying patent royalties to Microsoft). Therefore, ecosystem wars are fought on three fronts: mindshare, market share and patents. Let’s focus on developer mindshare. Developers are extremely critical as ‘platform consumers’. Anyone who has tried to recruit developers through traditional outbound marketing has failed. Developer marketing is about evangelising developers to a higher cause, more like crafting a software-centric religion – what can be called “religion engineering” (see evidence here on Apple as a religion). More importantly, building developer mindshare is extremely costly and tricky – you need software marketing know-how to execute successfully. Which is why many ecosystem-building efforts, including Java ME, Symbian, MeeGo and Palm OS 5, have failed. Crashing the party Developer marketing needs a very different toolbox and billions of investment; unless you can crash the party. Two types of solutions exist that allow OEMs to piggy-back the Android ecosystem on non-Android devices: compatibility layers from Myriad, OpenMobile and virtualisation technologies from OK Labs, Red Bend, and VMWare. RIM has also been using an emulator approach to bring Android apps on QNX. Myriad (www.myriadgroup.com) (SIX Symbol: MYRN). is a mobile technology company that offers browsers through to messaging infrastructure, with mobile software deployed in more than 2.2 billion mobile handsets. Based on the earlier acquisition of Esmertec (the early Google partner on the Java virtual machine) Myriad offers an Android emulator it calls Alien Dalvik. Launched in February 2011, the emulator allows “thousands of Android apps” to run on non-Android platforms like MeeGo. Myriad claims that once the APK files are repackaged for Alien Dalvik, applications can run unmodified and with no loss of performance. The company is focused on making its emulator compatible with popular apps like Dropbox, IMDB and Evernote, presumably focused at OEMs that want to bring the out of box apps experience on proprietary platforms. OpenMobile (www.openmobileww.com) is a Massachusets-based company founded in 2010. The company is privately funded and led by Nachi Junankar, a serial entrepreneur, and Bob Angelo, a software veteran who, as COO of Phoenix Technologies, led the team that opened up the clone business and later created the PC BIOS. OpenMobile has developed an Application Compatibility Layer (ACL) that claims to bring all 250,000 Android apps to non-Android device. The ACL is available for MeeGo (webOS and Windows support are in the pipeline), and claims 100% compatibility as “all Android Apps run exactly as they do on an Android device”. Moreover, OpenMobile says that app developers don’t have to modify, recompile or repackage their Android apps to run under ACL.  OpenMobile doesn’t use virtualisation or emulation, but integrates the Android application runtime into the native OS and supports Android API Level 4 or higher, as well as NDK 6 or higher. The alternative approach to bringing Android apps on non-Android devices is to use a virtualisation technology from Red Bend, OK Labs or VMWare (see our earlier analysis of virtualisation technologies). Virtualisation allows the Android OS (including the apps ecosystem) to run in sandbox, completely isolated and independent of any other platform (including OEM proprietary OS). Like on desktop virtualisation, the apps from both platforms can surface on the same menu, so that virtualisation remains transparent to the user. Challenges and the new shape of Googlerola Can an OEM crash the Android party? Yes, but only with a bodyguard. We suspect that the above vendors will be facing two primary challenges that they‘ll need to muscle their way through. Firstly, keeping in sync with the Android upstream changes is no small task, as new Android (including NDK) APIs have to be integrated into the target platforms and Google introduces API changes every two months on average. Secondly, OEMs who use an Android compatibility layer will also be exposed to potential patent lawsuits. Now getting access to an Android Insurance Policy (see our Googlerola article) from Google will also mean complying with Google’s tight software/hardware specs. The one region which seems opportune for Android-compatible technologies is China, where telcos and OEMs have long been trying to develop their own OS flavour, but have been stuck with antiquated OS versions as they haven’t been able to keep up with Android upstream. So can an OEM crash the Android party? Yes, but you‘ll need some pretty good bodyguards to escort you in. – Andreas you should follow me on Twitter #virtualization #rim #openmobile #myriadgroup #Android

A recent rumor placed the current value of HP’s webOS at hundreds of millions of dollars, but in all likelihood less than the $1.2 billion the company paid for Palm Inc in 2010. Would they settle for even less? Here’s our second comic strip – hope you like it! #comicstrip #hp #webos

[Google’s pending acquisition of Motorola creates a dilemma: Google must choose between staying true to its core business or reshaping into the new vertical giant that will challenge Apple at its own game. Research Director Andreas Constantinou discusses Google’s dilemma and why both outcomes stand to radically change the rules of the Android Empire] Google’s forthcoming acquisition of Motorola for $12.5B has been largely dubbed a patent deal. And it is. But beyond the patents, Google faces a fundamental dilemma for its core business, and one that will determine the future of the Android Empire. In mid-August Google announced it intends to buy Motorola Mobility Holdings (MMI), which includes the mobile phone, set top box and DVR businesses, for $12.5B. The true cost to Google is much less though, given that MMI has cash and accrued tax benefits. The move has seen an unprecedented amount of analysis in the blogosphere, with a fair amount of guesswork as to what Google’s motivations were in buying a hardware company. We believe that Motorola’s acquisition is not just about patents. The move marks a major turning point in how Google runs the Android Empire. Let’s see why. The post-Motorola dilemma We believe that the Motorola acquisition was sold to the Google board as a patent deal, with the hardware business being an unwanted but inseparable part of the package. Now Google faces a fundamental dilemma. The combination of Google and Motorola is like building a skyscraper in the middle of the ocean; the two companies are built on very different business models. Google is a profitable, 28,000-strong direct marketing company. Google uses Android as a platform with which to commoditise mobile handsets, flatten network access and reach billions more consumer eyeballs. Motorola, on the other hand, is an unprofitable, 19,000-strong hardware company, one that uses Android as a ticket to sell more hardware to more consumers and more carriers in the form of smartphones. We have no doubt that Google will divest a large part of the Motorola business. A hardware business would not help Google sell more ads, i.e. drive its core business. Motorola accounts for less than 10% of Android devices sold in Q2 2011 – third after Samsung and HTC who shipped 18 million and 11 million Android devices, respectively, according to data from Gartner and Arete. By fully incorporating Motorola, Google would be just nudging forward Android device sales, while at the same time upsetting all of its major OEM partners. In other words, incorporating Motorola would have the same market impact as buying a local network carrier. The question then is which parts of Motorola Google plans to keep, besides the patents. This presents a major strategy dilemma for Google – and one whose outcome will have fundamental impact on how Google runs the Android Empire. Android as a software autocracy Motorola’s IPR portfolio is substantial: 15,000 wireless patents, another 6,200 pending, and 3,000 granted or pending patents in the Home division, according to Arete research. More importantly, Motorola has a host of essential (blocking) patents around GSM. These patents buy an Android Insurance Policy that Google can issue to “compliant” OEMs that are intended to protect these OEMs from “patent taxes” levied by Microsoft, Nokia and others. This Insurance Policy is essential to protect the vast Android handset population from stalling its so-far phenomenal growth. At the same time, this insurance policy is not sufficient if Apple does attack the mid-priced smartphone segment, as it is rumoured to do. Android has been built on very shaky legal grounds, heavily “borrowing” from the Java language, the Java SE APIs and integrating with copious amounts of GPL-licensed code. Contrast that with how iOS, Symbian and Windows Phone platforms were built from scratch with very little inbound software licensing above the kernel. In other words, Google is buying Motorola to remedy the lack of IP strategy that threatens to undo 5 years of software craftsmanship. Google is paying for its past sins. Moreover, the Motorola patent portfolio is comparable to Nokia’s, which not only buys Google insurance but puts Apple and Microsoft on the defensive – see the outcome of the Apple-Nokia patent dispute in which Apple has to pay Nokia 8 EUR per iPhone sold in the future, in addition to a substantial one-off payment. But beyond the Android Insurance Policy, Google is getting something much more important: it strengthens the Android software dictatorship. As we discussed here and here Google licenses the Android platform under an open source license but uses several control points to incentivise OEMs to stick to a tight software implementation (and one that goes way beyond APIs). Google’s Schmidt explains eloquently how “OEMs feel like they have a choice” with how they implement Android  [see video segment starting at 28m 50s] but in fact, they have to comply with Google’s requirements as they need G’s permission to add Android market and use the relevant trademarks on their handsets. What patents buy by extension is practically a software autocracy; Google is now going to extend its Android Insurance Policy only to compliant OEMs. This means that if an OEM doesn’t follow Google’s precise software requirements, they will be prey to patent taxes by Google competitors. This now makes it untenable for an OEM to not pass Google’s Android certification. Android as an Experience Licensing business Besides software, there is a great deal of value that Google can leverage from Motorola. But that means a substantial change to Google’s business model. Google’s business strategy is based on the economics of complements – that is, if you want to sell more cars, you need to lower the price of gas. In Google’s case, if you want to sell more ads, you need to lower the prices of smartphones (Android), commoditise the networks (GTalk, Google Voice) and advance the state of web browsers (Chrome). Notice how everything complementary to Google’s business is “open”, while everything core to Google’s business is closed (Adwords, Android Market, Google Maps) The Google strategy is to make Android smartphones as ubiquitous and as cheap as possible, with the lowest possible barriers to entry for OEMs and ODMs, so that the last citizen on Earth can be exposed to Google inventory. However, the trouble with Android is that it has turned into a price-driven battlefield. The vast majority of devices compromise on the industry design and experience with cheap me-too plastics and poorly tested OEM apps and UI overlay. So far Android has managed to grow impressively fast as most devices are well below the iPhone and iPad price points. But with Apple rumoured to be releasing a lower-priced phone design, we expect Google’s empire of Android me-too clones to be challenged by the integrated, consistent and entwined experience that Apple offers. This is where Motorola comes in. To counter Apple mid-priced phones, Google needs to tightly define and control the experience delivered on OEM licensee phones. In this scenario, Google would use Motorola’s design teams to develop a complete “reference experience” that encompasses industrial design, hardware specs, complete software specs, marketing specs, pricing norms and of course the Google app suite. The Android open source “take it and fork it” mantra becomes much closer to a contractually enforced “experience licensing” business, in which OEMs that choose Android can compete with Apple on the same level, and get guaranteed margins through Google’s contractually-specified boundaries for Android handsets. How are OEMs going to differentiate you ask? Through regional marketing deals, retailer agreements and pre-loads with local service providers that deliver an additional rev share. We envisage Android’s Experience Licensing scenario as borrowing heavily from the franchise business model widely practiced in the retail industry.  In franchise stores, the experience is as tightly controlled as the products, the marketing strategy and the pricing policy. In other words, Experience Licensing is about running the Android Empire with Apple’s grip. To accomplish this strategy, Google needs to seed the market with “Hero” devices that epitomize the Android experience. Here is where Google can leverage on Motorola’s device production assets. A quick backgrounder: so far, Google has designed Android to offer three types of handset projects: Experience handsets (based on Google specs and branding), Partner handsets (compliant with Google’s Android specs, but with no Google involvement or branding) and DIY handsets (take the source code and fork it, but you ‘re on your own, e.g. China Mobile’s oPhone). The purpose of Experience handsets is to advance the state of the platform, by working closely with 2 pre-selected OEMs 6-9 months prior to the public release of the codebase under an open source license. Experience handsets (see full list here) are run under tight Google control and co-marketed by both Google and the OEM. Google would be adding “Hero” handsets to the existing three tiers, which delivers two benefits. Firstly, it allows Google to divide and conquer among OEMs without giving anyone “special privileges” or know how – it is rumoured for example that Google has been unhappy with the know-how HTC developed as a result of their long-standing relationship in the early Android days which has given HTC the fastest time-to-market for handsets based on the public codebase (note how HTC is no longer involved in Experience handsets for some time). Secondly, it allows Google to better compete for carrier deals with Apple, by offering carriers exclusive access to the latest and best Android features on Motorola hardware. As we know, carriers die for exclusives, so rather than run Motorola device business at cost, Google can just keep the crown jewel features for carrier-exclusives from Motorola. Redefining how Google runs the Android Empire The purchase of Motorola makes Google the emperor of the Android Empire. Whichever parts of Motorola Google decides to keep, the laws of the Empire would be irreversibly changed. The how depends on which scenario Google opts for. 1. In the software dictatorship scenario (which we take as the default option), Google would make it untenable for OEMs not to follow its software specifications to the letter or to fork Android. Google stays true to its core ad business and divests everything apart from patents to a Taiwanese OEM wanting to break into the North America market. 2. In the Experience Licensing scenario, Google keeps the hardware design and device production capabilities to allow Android to compete head-to-head on every Apple price points, both the current high-end iPhone/iPad pricing and the rumoured mid-tier pricing. Here Google would have to take a hit on its cash flows and profitability by putting its hand deep in its pocket (both in terms of CAPEX and OPEX) to more favourably compete with Apple. Irrespective of Google’s mobile plans, the Motorola acquisition offers the search giant a means to control the hardware and software make up of set-top boxes and offer a similar licensing program to Android TV licensees. We know that the first attempt at Android TV failed because there was very little premium content as content producers were concerned with DRM and content security. By controlling the hardware and software specs for Android TV, Google could bring the content producers back on board. Historically, Apple has been fundamental to the success of Android. As it turns out, it is going to fundamentally challenge the Android business. Stephen Elop noted in June 2011 that “Apple created the conditions necessary for Android”, by incentivizing carriers and OEMs to offer iPhone-killers at less than profit-killing prices. Now Apple is creating the conditions necessary to challenge Android’s growth, by milking Android OEMs for patent taxes and challenging the Android clone empire with unique product experiences at more price points. Whatever route Google chooses to take, it will fundamentally change the rules of the Android Empire. – Andreas you should follow me on Twitter: @andreascon [Mystified by the intricacies of Google’s  Android strategy? Check out our Android Game Plan workshop!] #Android #handsetmanufacturer #iphone #motorola

[Much has been said about open source projects – and open source platforms are now powering an ever-increasing share of the mobile market. But what is “open” and how can you measure openness? As part of our new research report (free download), VisionMobile Research Partner Liz Laffan introduces the Open Governance Index – a new approach to measuring the “openness” of software projects, from Android to WebKit] Update: We have been amazed by the amount of interest to our Open Governance Index (OGI) report that we published just over two weeks ago. Our report was covered in mainstream media across Wired, ZDnet, PCPro, Gizmodo, ARS Technica, BGR, Zeit Online and ReadWrite Mobile. Our intention was to start a debate around ‘what’ openness is, ‘how’ it can be measured and ‘why’ it is important – and we certainly got the ball rolling! Openness = governance We at VisionMobile have been researching, investigating and helping to educate the industry about open source for the past five years.  In this time open source software has been transformed from geekware to business as usual. Much has been written and debated regarding open source licenses – from the early days of the GPL license to the modern days of the Android platform. Despite the widespread use of open source, from Android to WebKit, there is one very important aspect that has been neglected: openness and how to measure it. Openness goes far beyond the open source license terms and into what is termed Governance. While licenses determine the rights to use, copy and modify, governance determines the right to gain visibility, to influence and to create derivatives of a project, whether in the form of spin-offs, applications or devices. And while licenses apply to the source code, governance applies to the project or platform.  More importantly, the governance model describes the control points used in an open source project like Android, Qt or WebKit, and is a key determinant in the success or failure of a platform. The governance model used by an open source project encapsulates all the hard questions. Who decides on the project roadmap? How transparent are the decision-making processes? Can anyone follow the discussions and meetings taking place in the community? Can anyone create derivatives based on the project? What compliance requirements are there for creating derivative spin-offs, applications or devices, and how are these requirements enforced?  It is governance that determines who has influence and control over the project or platform – beyond what is legally required in the open source license. In today’s world of commercially-led mobile open source projects, it is not enough to understand the open source license used by a project. It is the governance model that makes the difference between an “open” and a “closed” project. Measuring openness Our research (free copy of full report here) showcases eight mobile open source projects: Android, MeeGo, Linux, Qt, WebKit, Mozilla, Eclipse and Symbian.  We selected these projects based on breadth of coverage; we picked both successful (Android) and unsuccessful projects (Symbian); both single-sponsor (Qt) and multi-sponsor projects (Eclipse); and both projects based on meritocracy (Linux) and membership status (Eclipse). All of these are open source projects, whether platforms (Android, MeeGo, Qt, Symbian) or engines (Linux kernel, WebKit) or multi-project initiatives with a single, uniform governance. We appreciate that these projects are unique in many ways but they are all ultimately open source projects and to that extent our governance measures can be applied to them all equally. For example all of these projects have decision-making groups and processes that are directly comparable. In the Open Governance Index we attempted to document who these decision-makers are, how they operate, what processes are used to determine project decisions and how easily is to influence these project decisions. Our research, carried out over a six-month period, included analysis of these popular open source projects, through discussions with community leaders, project representatives, academics and open source scholars. This research was partially funded by webinos, an EU-funded project under the EU FP7 programme, aiming to deliver a platform for web applications across mobile, PC, home media (TV) and in-car devices. We quantified governance by introducing the Open Governance Index, a measure of open source project “openness”. The Index comprises thirteen metrics across the four areas of governance: 1. Access: availability of the latest source code, developer support mechanisms, public roadmap, and transparency of decision-making 2. Development: the ability of developers to influence the content and direction of the project 3. Derivatives: the ability for developers to create and distribute derivatives of the source code in the form of spin-off projects, handsets or applications. 4. Community: a community structure that does not discriminate between developers The Open Governance Index quantifies a project’s openness, in terms of transparency, decision-making, reuse and community structure. Does openness warrant success? But what is it that makes an open source project successful? Why do some projects become an immediate success, while others barely get off the ground before crashing and burning? We know that just like commercial ventures, open source projects have different cultures and drivers – but we do believe that you should be able to measure the way that open source projects interact with the community of users and contributors that they build up around themselves. Our research suggests that platforms that are most open will be most successful in the long-term. Eclipse, Linux, WebKit and Mozilla each testify to this.  In terms of openness, Eclipse is by far the most open platform across access, development, derivatives and community attributes of governance.  It is closely followed by Linux and WebKit, and then Mozilla, MeeGo, Symbian and Qt. Seven of the eight platforms reviewed fell within 30 percentage points of each other in the Open Governance Index. Moreover, our research identified certain attributes that successful open source projects have.  These attributes are timely access to source code, strong developer tools, process transparency, accessibility to contributing code, and accessibility to becoming a committer.  Equal and fair treatment of developers – “meritocracy” – has become the norm, and is expected by developers with regard to their involvement in open source projects. The Android Paradox We found Android to be the most “closed” open source project. In the Open Governance Index, Android scores low with regard to timely access to source code in that the platform does not provide source code to all developers at the same time; it clearly prioritises access to specific developer groups or organisations and has acknowledged this with the delayed release of Honeycomb. Additionally Android scores low with regard to access to developer support mechanisms, publicly available roadmap, transparent decision-making processes, transparency of code contributions process, accessibility to become a committer (in that external parties cannot ‘commit’ code to the project) and constraints regarding go-to-market channels. Android ranks as the most closed project, with an Open Governance Index of 23%, yet at the same time is one of the most successful projects in the history of open source. Is Android proof that open governance is not needed to warrant success in an open source project? Android’s success may have little to do with the open source licensing of its public codebase. Android would not have risen to its current ubiquity were it not for Google’s financial muscle and famed engineering team. More importantly, Google has made Android available at zero cost, since Google’s core business is not software or search, but driving eyeballs to ads. As is now well understood, Google’s strategy has been to subsidise Android such that it can deliver cheap handsets and low-cost wireless Internet access in order to drive more eyeballs to Google’s ad inventory. Equally importantly, Android would not have risen were it not for the billions of dollars that OEMs and network operators poured into Android in order to compete with Apple’s iconic devices. As Stephen Elop, Nokia’s CEO, said in June,2011, “Apple created the conditions necessary for Android”. Moreover, our findings suggest that Android would be successful regardless of whether it is an open source project or not, to the extent that the vast majority of developers working on the project (the platform itself) are actually Google employees. Evolving the Open Governance Index Having published the report, we aim to continue the discussion on governance, to refine our criteria even further and to make the OGI measure as meaningful as possible for the open source community. One of the first suggestions has been with regard to having a time dimension to the criteria i.e. does openness change over time. Mature open source projects such as Eclipse, Linux and WebKit that have stood the test of time, score quite highly with regard to openness of governance. But this has not always been the case. For example consider the following. Apple forked KHTML to create WebKit in the early 2000’s, releasing the first WebKit open source project in 2005 but with reviewer and commit rights restricted to Apple personnel only which effectively sidelined the KDE community. In 2007 however Apple reversed this decision allowing allow non-Apple developers to have full commit access to the WebKit source code version control system. This shows that openness can and does change over the project lifecycle. Our vision for the Open Governance Index is to for it to be a robust, and as much as is possible, an objective measure of Governance for open source projects. We believe that this is necessary such that users and contributors to open source projects, including commercial entities, understand the means by which they can, or cannot, influence the direction and content of the project. Download the full report for an in-depth analysis of the openness of Android, MeeGo, Linux, Qt, WebKit, Mozilla, Eclipse and Symbian. Drop us a line and tell us what you think. – Liz Addendum – Is copyleft more or less open? We awarded a higher score to those licenses that are permissive and not copyleft licenses. Firstly it should be noted that all the licenses used by the eight mobile open source projects are Open Source Initiative (OSI) approved and meet the Open Source Initiative Definition, which provides for free redistribution of source code, access to source code and ability to create derived works amongst other requirements. We believe that the OSI is the appropriate arbiter of the appropriate Open Source License definition and all of the licenses used by the open source projects researched in this report meet this definition of being ‘open’. However we also believe that from a commercial viewpoint there is still some concern about using code that is under a copyleft license – our experience of working with mobile software development organisations confirms this. Our findings suggest that organisations will be more comfortable using permissive licenses which do not mandate copyleft requirements and we reflect this in our criteria and scoring. We are happy to continue debating these findings further with the community. For example it has been suggested that the problem here is not with copyleft licenses but with the business model used by those organisations. Be that as it may, our experience is that this concern is still a valid one being expressed by many organisations, especially in the mobile device domain. Finally we had a methodology typo which unfortunately survived the proof reading: assigning a bonus to “copyright assignment”. We fully acknowledge that copyright assignment is unnecessary – indeed we state this in our analysis of Qt whereby we acknowledge copyright assignment as inappropriate and a heavy-handed requirement. [Liz Laffan is a Research Partner at VisionMobile. Liz has been working in the telecoms and mobile industry for over 20 years, with large telco organisations, start-up technology ventures, software development and licensing firms.  Liz’s interests lie in open source software governance and licensing and in particular how best can commercial organisations interact with open source projects.  She can be reached at liz [at] visionmobile.com] #meego #eclipse #qt #opensource #webkit #linux #symbian #Android #mozilla

[The term ‘platform’ is used for describing things as diverse as social networks, web browsers, on-line retailers and open source software. VisionMobile Research Partner Michael Vakulenko delves into the platform economics to uncover why not all platforms are born equal.] Since different platforms types have very different origins and purpose, it is close to impossible to evolve one platform type to another. And while platforms can be compared in terms of adoption, direct comparisons of platforms of different types is like comparing oranges to apples.Platform typePurposePrimary audienceNetwork effectsExamplesSoftware platformSharing of software development costs and risksDevice makersNoneSymbian, BREWApplication platformConnecting app developers and users (and handset OEM in some cases)Developers– Users to developers – Users to users – Developers to developersAndroid, iOS, Windows PhoneCommunication platformFacilitating communication between usersUsers– Users to usersTelephone, fax, BlackBerry Messenger Software platforms A software platform is a common software stack that is used for developing multiple products. As such, software platforms are optimised for flexibility and sharing of development costs when building products based on the same technology foundations. The technology platform approach is also used in other industries such as the automotive or construction industries. Many open source projects have evolved into successful software platforms, such as Webkit, Apache and Linux operating system. Symbian is a characteristic example of a software platform. Symbian Ltd. was established by Nokia, Ericsson and Motorola in 1999 for the purpose of sharing the costs of building a mobile software operating system. The Symbian software stack was subsequently used by these handset makers as a basis for wide range of mobile devices introduced in the last decade. Symbian is still the most widely deployed mobile platform ever with over 480 million devices shipped up until Q2 2011. As a software platform, Symbian has been optimised for flexibility in customizations by handset makers and mobile operators. Symbian served its purpose quite well until Apple changed the basis for competition by introducing a different kind of a platform. Applications, developers and app stores suddenly became more important than serving OEM needs. Changing design focus of the platform proved to be impossible for Symbian and Nokia.  Changing the license terms to open source only  further sidetracked the platform. Application platforms Application platforms, often also referred to as computing platforms, are designed from the ground up for connecting two disjoint markets: users and application developers. Application platforms are a special case of so called two-sided networks, in which platform owners extract value by allowing members of disjoint markets to transact through the platform. Two-sided networks describe businesses as diverse as dating agencies (match.com), credit cards (VISA), stock exchanges (NYSE) and digital media formats (Blue-ray).Application platforms live and die on the applications built for these platforms. Users consume applications to satisfy a wide spectrum of needs, from word processing to killing time. Since applications are locked to the platform, users need to obtain the platform in order to benefit from applications. Microsoft Windows is a classic example of a successful application platform. Since application developers drive adoption of a application platform, the platform is only as successful as the developers who build apps for the platform. Even though the number of apps is frequently considered as an ultimate measure of application platform success, it’s really the long-term health and sustainability of the developer ecosystem that will determine if developer investment will sustain, grow or decline. Application compatibility is the key success factor for a application platform; applications must work unchanged on different variants and versions of the platform (imagine if Microsoft Office would only run on Dell computers). Raymond Chen’s blog on the New Old Thing offers a flavour of the lengths that Microsoft went into ensuring application compatibility. When a application platform reaches a critical mass of developers, applications and users, it starts to grow exponentially. This is because of network effects, i.e. a positive feedback loops between users and applications, users and users, and developers and developers. Applications attract users, which motivate developers to create more applications, which attract more users, which attract more developers, and so forth. From the end-user perspective each new application adds value to the platform. From an application developer perspective, a platform becomes more valuable with each and every new user. Apple iOS set a gold standard for a mobile application platform. It’s hardly surprising that iOS comes from a company with decades of experience in personal computing. iOS is end-to-end optimised for nurturing and reinforcing network effects between users and developers. With each of over 400,000 apps adding to the reasons to buy an iOS device, Apple reported all-time record revenue and earnings for Q2 2011. For now, Google’s Android is the only close competitor to iOS. Google comes from a background of advertising platforms. An advertising platform is also a special case of a two-sided network connecting two disjoint markets of on-line users and advertisers. It’s hardly a surprise that Android has been designed from the ground up as a free application platform, which is monetised by driving traffic to Google on-line advertising services. Communication platforms Communication platforms are designed to facilitate communication between people. Examples are telephone networks, email, fax, and social networks (Myspace). Communication platforms also exhibit network effects: Every new user makes the network more valuable for other users. BlackBerry has the history and DNA of a communication platform. It was originally designed to extend an email communication platform to the mobile domain. BlackBerry exploits network effects of the email platform and creates value on top of it by improving  the availability and usability of email communications. Once the BlackBerry email platform reached significant scale in 2005, RIM introduced a proprietary communication platform, BlackBerry Messenger (BBM) service. BBM is a proprietary instant messaging service that uses the BlackBerry PIN programed in the device to identify users. In other words, someone needs a BlackBerry device to join the social network formed around BBM. It’s like a members-only club for BlackBerry users. Because of the narrow focus on communication needs, the user-to-user network effects in the BlackBerry communication platform are weaker than those in iOS and Android. Moreover, the benefits of mobile email and mobile instant messaging are no longer exclusive to BlackBerry. Mobile email is used today by 80% of US phone subscribers, and multi-platform mobile messengers such as Whatsapp, Kik and KakaoTalk are quickly gaining in popularity, each amassing audiences of millions of users. So how does RIM remain competitive? RIM needs to evolve BlackBerry into an application platform. So far, the company has not been successful in achieving this goal. On the contrary, given the direction and speed of innovation of BlackBerry platform, RIM’s chances to achieve this goal looks less and less promising. Much like Symbian, changing platform focus on the fly proved to be extremely difficult for RIM. Moreover, replacing the legacy BlackBerry OS with the “high-performance” QNX operating system will not make much of a difference. It could even make things worse by making the platform even more fragmented and confusing developers with multiple development alternatives. Platforms are not born equal Mobile application platforms will always have significant advantages over software and communication platforms. Mobile application platforms exhibit multiple, self-reinforcing network effects, user lock-in and the ability to attract external investment. Nokia stood not only on a burning platform, but also on the wrong kind of a platform, trying to reinvent the Symbian software platform as an application platform. The self-reinforcing network effects of iOS and Android application platforms are much stronger than Nokia’s scale and distribution power. The stark contrast between the Q2 2011 Nokia and Apple quarterly results is excellent example of the power of application platforms. On the contrary, Windows Phone, Nokia’s only hope to get back into smartphone game, has all the characteristics of an application platform: from application compatibility to the steadfast commitment towards app developers. Application platforms are bread and butter for Microsoft. Yet, the jury is still out on whether Microsoft will be able to grow Windows Phone into a credible competitor to iOS and Android. It is very difficult to displace leading application platforms like iOS and Android which are protected by self-reinforcing network effects and user lock-in (think of firefighters trying to contain large-scale wildfires). It is not enough to be marginally better. To win, Windows Phone will need to offer users and developers something radically new, over and above the current leaders. Only time will tell if Microsoft will be able to achieve that by combining the resources of Skype, the partnership with Nokia and the relationship with Facebook. Platforms will continue to be a central theme in the evolution of mobile ecosystem. It will only become more interesting with the recent entry of Facebook (social platform) and Amazon (retailing platform) into the mobile scene. – Michael [Michael Vakulenko is a Research Partner at VisionMobile, where he focuses on mobile platform research. Michael has been working in the mobile industry for over 16 years, starting his career in wireless in Qualcomm. Michael has a broad experience across many aspects of the mobile industry, including smartphone ecosystems, mobile services, handset software, wireless chipsets and network infrastructure. He can be reached at michael [/at/] visionmobile.com] Want to know more about mobile platform strategies and economics? See our Software Economics in a Telecoms World, an executive, 360° seminar on how the telecoms industry is being disrupted by the new software economics. #ios #mobileplatforms #symbian #Android #windowsphone #Blackberry

We’re proud to present our latest infographic, The Mobile Platform Race, showcasing some of the most important findings and insights from our Developer Economics 2011 report (free download here). Developer Economics is the definitive report on mobile developers, apps and brands going mobile. Developer Economics was created by VisionMobile and sponsored by BlueVia. We hope you enjoy the infographic – and feel free to embed it in your own website. Comments welcome, as always. Feel free to copy the infographic and embed it in your website. 600 pixels wide version 760 pixels wide version 1000 pixels wide version [sociable_code] #ios #mobiledevelopers #java #mobileweb #symbian #Android #windowsphone #Blackberry

[Developers are currently the hottest property in the mobile industry. Tens of developer programs have sprung up, aiming to woo developers.  However, besides Apple, Google and perhaps Microsoft, other developer programs have had at best a lukewarm response. Guest author Gyanee Dewnarain investigates what makes developers tick and the faux-pas to avoid.] Have you been ramping up your developer marketing efforts lately with a view to attracting more developers to your programme? How are your efforts faring? Let’s have a look at what works and what does not. First and foremost – who to target? Before you set out on your quest, it is important to know who you are targeting. We have all come across the perennial cliché of a developer as being the unshaven geeky guy with long hair and sandals. This image is outdated: developers nowadays are a rapidly expanding community that includes software engineers (architects, implementers, discoverers, thinkers, inventors) within small, medium and large enterprises, hobbyists or indie developers (working on open source or proprietary software), high school kids aspiring to go to MIT, commissioned developers, brands developing  B2C apps, system integrators targeting B2B apps, investors funding mobile development and 100s of start-ups. Each developer segment has varying goals and incentives and the ways of engaging with them vary too. It pays to do your research first and understand who you are targeting and how to do so. However, irrespective of the segment you are targeting, there are a few key ingredients (so-called hygiene factors) that need to be in place in your developer program for the greatest chances of success. These hygiene factors are covered extensively in VisionMobile’s Developer Economics 2010 and 2011 reports. This post focuses more on developer marketing strategies and tactics. First Impressions Matter The first step in a developer marketing program is to create a solid first impression. Developers expect you to invest considerable effort in the way you present your tools, APIs and documentation to them as well as the way you present their applications to your customers. This is a competitive marketplace and if you want to stand any chance of getting noticed, your offering needs to stand out from the other developer programs which are vying for developers’ attention. It is equally very important that your messaging and your branding are consistent across all your digital assets – website, blog, storefront etc. If your branding and messaging is confused, developers’ confidence in your developer program will erode rapidly. Developers also have an aversion to long, convoluted, legal terminologies; don’t make them read and sign long T&C’s before they can access any of the exciting stuff (code, APIs, tools and documentation). Second opportunities come seldom in this market. The “coolness” factor Developers like cool companies (think slide, smoothie bar, collectable pins) and cool brands and if you appear stuck-up, they will run a mile. If you want to engage with them, you have to think about the image you and your company project – you have to speak their language and dress like them. The language on your website should be simple and straightforward (cut back the marketing blurb). While more technically inclined, developers still like devices which have mass market appeal (both from the perspective of personal interest and also from the perspective of user reach and revenue generation). Engage with other brands and channels to increase the desirability of your device, your storefront or your cloud platform. In addition, make sure that your products are able to get developers excited (from the development tools, emulators and documentation through the storefront to the actual devices that you are selling in the market). Encourage openness and interaction Do not bind your developers into contracts and NDAs that forbid them from sharing useful hints and tips. Even Apple realised the mistake it was making by preventing discussions amongst its developers and had to retract its NDA three months after the launch of its iPhone developer program. You should encourage your developers to share their experiences, best practices and code snippets by creating places and opportunities for them to meet and interact with each other. Online forums, blogs, mailing lists (both on your own website and on popular 3rd party fan websites) are must-haves. Such communication amongst developers helps build a sense of community.   Developer events are equally de rigueur in any developer program. Your events should ideally favour hands-on code oriented tutorials and workshops as opposed to marketing presentations. Learn the art of listening Building communities means extending bridges. The mantra is – communicate, communicate, communicate; whether it’s through one to one e-mails, social media, developer forums or third party developer events. Keep in touch with your most loyal developers, as much as you can, and in a personalised manner. Formulate your message in such a way that you make them feel important; the focus should not be on your company but on them. The worst thing you can do is have a big developer bash and disappear off the radar for a while. That might have worked a few years back but in the current market, with everyone competing for your developers’ attention, if you do not constantly keep in touch, someone else will snatch your developers away in the blink of an eye. Honesty is the best policy Changes to existing APIs and introduction of new APIs are a natural part of software development. However, be as transparent as you can with your developer community. Inform them about the changes that you have made to your APIs and try to have a sensible upgrade path so that there are no rude awakenings. Ensure compatibility with previous versions; this would show that you are respectful of the time and effort that developers are committing to your program.  Despite facing a lot of criticism with regards to fragmentation risks across its multiple releases, Google has gone to great lengths to explain API updates to new Android releases. Share your vision of the future Sharing your vision for the future is a critical part of engaging with developers. It is therefore essential that you communicate the rationale behind your business strategies, technology decisions (e.g. moving from native to web) and the future direction of your program very clearly to your developer following.  Endeavour to provide your developers with the opportunity to provide their feedback, comments and suggestions. Arguably, developer programs such as BONDI and JIL failed due to their inability to communicate any tangible vision to developers. Unfortunately, WAC seems to be following a similar path. Favour substance over style If your platform does not ship; if your tools look good but do not deliver;  if your code samples are too difficult to learn and use, your developers will churn to greener pastures. This means: If you are going down the route of having your own platform, then you have to ensure that the tools that you provide are easy to learn and your programming paradigms enable quick coding and prototyping. Provide APIs that are rich and that offer developers the opportunity to go the extra mile in creating truly innovative applications. These could include select hardware APIs (that are normally hidden) and in some cases network APIs such as billing, location, user profile etc. Provide debuggers and emulators that are fast and provide accurate target device mirroring. Make sure that your development environment includes an app porting framework and solid emulator integration. Choice is good – provide options for advanced use cases for example both a basic command line text editor and a web based IDE. Moreover, if you get lethargic and do not constantly look at ways of evolving your tools, being innovative with your business models, and seeking newer markets, boredom is likely to set in and your developers may start looking at other alternatives. Therefore, continuously check how your program is faring against competition. Several operators dismissed Apple and Google for more than 2 years until it was too late to figure out a positioning strategy. Bridges to developers need constant maintenance You’ll need to set aside a significant budget to finance various types of seed programs as well as developer competitions. Seed programs include many incentives for developing such as: Releasing early builds of your platform/ SDK version to developers, both to get feedback about bugs and other issues as well as to give developers lead time to test software or experiment with adding new features. Commissioning developers to develop apps specifically for your platform or port existing apps from other platforms. Fast tracking the certification of apps for a select group of your target developers (especially useful when you need to get an app ported from a competitive platform to your own) Distribution of free reference hardware or commercial devices to your installed base of developers in order to build loyalty. Show me the money Many of the developers that you want onboard (especially those with a commercial role) want to see a return on their investment. From the outset, it should be clear in your own mind how your developers are going to make money from their apps and you should communicate this in a very clear manner to them – what are the devices that you support, how many people are using those devices, how do they get their apps on those devices, how do customers find, download and pay for the apps and how, when and how much do developers get paid. The other thing to note is that developers are smart and discerning consumers who will fact-check you before they can trust you – make sure you have the figures to back your marketing assertions. One of the critical issues facing developers currently is “discovery” of their apps by customers. The developer programs which come up with the most original ideas to improve discovery and present new business models for increased monetisation are likely to gain traction with the largest number of developers. Casual settings work better When socialising with your developers, small informal events work much better than large formal conferences. Make sure that the developers and software engineers from within your company get the opportunity to interact with each and every developer, answering their questions, listening to their issues, encouraging them to interact regularly and share experiences and difficulties. So far, BlueVia has been amongst the operator developer programs that have most successfully embraced this philosophy by holding small developer events in pubs around London. Jump onto the social bandwagon – Facebook It, Tweet It Studies show that over 60% of people within the 15-35 age group (and that includes the vast majority of your developers) spend on average 20 hours per month on social networking websites. This is where you are likely to find them and this is the medium they will use to spread the word about you if they like you enough (viral marketing). Social media is where you need to advertise your events, inform developers about the availability of the latest release of your SDK or the latest device you are planning to launch. Locate your Evangelists Find out who are the people who believe in your platform – the fans, the early adopters– the people who would be willing to fly the flag for you. Check the people who write favourable blog posts about you, who comment on your blog posts, tweets, participate in your forums and Facebook or LinkedIn discussion groups. Approach them and provide them further incentives to spread the good word. Developers listen to their fellow developers – therefore, get your early adopter developers to talk about how easy it is to create apps using your APIs and SDKs and how fast it is to certify the apps and get them published. Reward your successful developers – promote their apps in the media, ask them to come and talk about their success stories at your events; publish their success stories on your website and in your marketing collaterals; encourage them to publish stats about number of downloads and the amount of money they’ve made. Putting it all together In summary – decide who you want to target, make sure the hygiene factors are in place, keep your messaging and branding consistent, keep legal blurb to a minimum, be a cool brand, encourage your developers to share experiences and best practices, value feedback from your developers, be transparent about changes to APIs and code, communicate your vision and roadmap, provide high quality tools that are on par with competitive offerings,  prepare to invest, show developers the return on their investment, interact frequently with your developers preferably via small informal events and via social networks, locate and draw upon your evangelists and last but not least, reward your successful developers.  Many have tried and many have failed over the years. Sometimes, a few decisions can make or break your program. Be quick to learn both from the failures and the success stories! Happy Community Building! – Gyanee [A mobile technology aficionado, Gyanee Dewnarain has 8 years’ experience working within the international telecoms business environment. Gyanee has worked for a host of companies within the mobile industry ranging from consortia (LiMo Foundation) and start-ups (Carrier IQ) to large corporations (Gemalto and Alcatel). Prior to that, Gyanee was involved with the International Telecommunications Union (ITU) and co-chaired the ITU Youth Forum in Johannesburg. Gyanee holds an MSc in Telecommunications with Distinction from University College London (UCL). She can be reached at gyanee.dewnarain (at) gmail.com] #developercommunities #mobiledevelopers

[Are cross-platform tools a better solution than HTML5 to the challenges of platform fragmentation? Guest author Jonas Lind reviews the landscape of cross-platform tools and argues that such tools may become as important as the native platforms themselves.] The Android vs. iOS vs. Windows Phone platform battle has been the talk of the industry for the last year. But the market share battle between handset platforms might not be as critical for the industry as many believe. A popular view in the industry is that the market is inevitably moving towards an Apple-Google duopoly. Apple’s app store has more than 400,000 apps. Android is growing quickly from a base of more than 250,000 apps and is predicted to catch up with Apple later this year. Nearly 80 percent of all apps in app stores are controlled by these two market giants according to Distimo. Figures for Q1 2011 from Gartner show that the market share in the smartphone market for iOS and Android combined is 53 percent and rising. But the duopoly may be challenged by the mobile web and cross-platform tools. HTML5 empowers all other platforms to offer apps through the browser. VisionMobile’s recent Developer Economics report shows that the mobile web (of which HTML5 is a subset) is already the third most popular platform in terms of developer mindshare after Android and iOS. At the same time, HTML5 is overhyped and the belief that HTML5 will replace almost all native apps is in need of a reality check. Native apps will still offer richer functionality, better performance, and higher security compared to HTML5-based apps. A study by quirksmode.org has shown that every mobile WebKit implementation is slightly different, which could cause a problem for HTML5-based apps. In a recent whitepaper, Netbiscuits measured smartphone support for 18 features in HTML5 and showed that leading smartphones only offer partial (or no) support for a significant number of these features. Implementation is also fragmented. What works on iPhone will probably not work on RIM or Samsung handsets and vice versa. Or to quote Forrester’s take on the HTML5 vs. native debate: “The ‘Apps vs. Internet’ Debate Will Continue…to be irrelevant.”, “it’s not a question of ‘either/or’ when it comes to a choice between apps vs. the mobile Web, but both.” The Landscape Of Cross-Platform Development Tools The new types of cross-platform tools are more interesting than plain HTML5 because they can deliver higher performance and functionality than browser based HTML5. These tools produce apps as output and fall roughly into two categories: 1) Web apps/hybrid apps. These apps exploit the web engine (“web browser”) and are typically written in HTML/CSS/JavaScript. 2) Native apps. These apps are compiled into machine code and often written in C++ or similar languages. Cross-platform tools are a nascent market with a flurry of startup activity over the last few years. The following diagram illustrates different trade-offs between complexity and performance in the cross-platform tools market. Traditional websites: In the lower left corner is the traditional website, limited in performance but providing access to all platforms with no added complexity. Plain HTML5 could be included here once all browsers support the standard. Web apps/hybrid apps: Adjacent in the diagram are HTML5 web apps that can be downloaded to the browser’s cache and run offline. They will offer better performance and only slightly higher complexity. One step up in the diagram is a market segment of cross-platform tools running simulated native. These tools deliver better performance but the complexity is also higher if the tool has to support multiple platforms. Here we find tools that produce web apps built on HTML5/CCS3 and JavaScript, with some added native elements, typically inside a native wrapper. These cross-platform tools often add native extensions that provide access to some low level native functionality. An example of a player in this market segment is PhoneGap, which is often used in tandem with the Sencha Touch framework. Other tools that run on top of PhoneGap are WorkLight and appMobi. A closely related market segment is hybrid tools, where the HTML5/JavaScript input is translated into actual native source code. An example of a hybrid tool vendor is Appcelerator‘sTitanium. Other types of solutions which fall under the main heading of web/hybrid apps are based on Java, Lua, ActionScript or less common languages. The diagram shows how the heavily-fragmented Java ME offers inferior performance in spite of high complexity. The cross-platform tools Corona SDK and DragonRAD are based on Lua. Rhodes is based on HTML/Ruby while OpenPlug uses ActionScript (Flash) as source language. Kony uses drag-n-drop for building enterprise web apps. There is no reliable information about the performance/complexity trade-off for most of these solutions, so their exact position in the diagram above should be viewed as illustrative. In general, tools in which the resulting code is compiled or recompiled to native ARM machine code will have a higher performance. Native apps: The second main category is native apps. In cross-platform tools for native apps, developers often work with a codebase in C/C++ or C# which is then semi-automatically ported to the target platform and device. Performance is significantly higher with native code, but so is the complexity. Players in this sector include Airplay, Qt and MoSync. The Airplay SDK (now Marmalade) originates in 3D gaming but can also be used as a general C++ cross-platform tool. Qt is a cross-platform UI framework that also can be used for native C++ porting. Qt primarily supports Nokia’s legacy platforms. MoSync is a cross-platform tool for general purpose C++ development, integrated with the Eclipse IDE and also available under an open source (GPL) license. Cross-Platform Beyond Java – Native Extensions The traditional approach to cross-platform development has been a lowest common denominator one – much like that taken by Java, Flash Lite and mobile HTML. This approach sacrifices performance, UI pizzazz and access to specific device features. A workaround is to add native extensions. These can provide additional SDK/NDK libraries for the IDE and also give access to low level hardware functionality. Access to low-level hardware functionality can be managed by a device database that controls which conditional code will be executed on a given device. Several of the cross-platform vendors have built such device databases with various levels of detail. A device database contains information on screen size, input modality and exact OS version, extending to detailed hardware configurations and known bugs with workarounds. Using native extensions, it is possible to overcome the inherent limitations that plagued Java. Instead of “write once, run everywhere”, developers can spend 90 percent of their time developing a common codebase and 10 percent adding native tweaks and extensions for each platform and device. For software purists, the 90/10 solution might not seem very elegant, but it is a way forward that can handle the incredible complexity with thousands of devices running more than five OS platforms. In this way, app developers can manage one codebase and port it to target devices without losing functionality. In principle, using a (C++) cross-platform engine with extensions should be able to offer similar functionality with minimal performance penalty as compared to direct development for the target device. There will be significant economies of scale when the common codebase is tweaked for 100s of devices. The Disruptive Potential Of Cross-Platform There are few signs that platform fragmentation will disappear. It’s not just Android, iOS and Windows Phone 7, which are backed by corporate giants with deep pockets, but also smaller players like QNX (RIM), WebOS (HP), MeeGo (Intel, China Mobile) and Bada (Samsung). Add to that legacy platforms, which will be around for at least a few years: Windows Mobile, Blackberry OS, Symbian, BREW, Java ME and Flash. If we also include the main desktop platforms (Windows, Mac OS, Ubuntu), gaming consoles, set-top boxes, cars, and other gadgets, the number of platforms becomes unmanageable. App developers whose clients need to reach the entire market, face the formidable task of supporting all platforms and devices. If they can use a cross-platform engine the productivity gains will be dramatic compared to paying for separate in-house dev teams for each platform. Early adopters of cross-platform will most likely be large consumer businesses who need to target the mass market such as media companies, games houses, entertainment companies, banks, and any brand developing B2C apps. Similarly, government agencies are often required to provide non-discriminatory access to their services and cross-platform tools will enable them to do just that. Another group of early adopters of cross-platform tools is CIOs of larger corporations. They face increasing demand from senior staff who want to use their favorite smartphone for secure access of internal company data. Once these early adopters have driven down the prices and sorted out stability issues we should expect to see a fast uptake of cross-platform tools in the mainstream app development market. Assuming more developers move to cross-platform tools, the power distribution in the mobile sector will be challenged. The difference in the number of available apps between dominant and up-n-coming platforms will be reduced. This will allow smaller platforms to compete on a level playing field. Web apps and HTML5 should make the largest dent in the market power of traditional platforms. But the final nail in the coffin will come when C++ cross-platform engines can offer almost the same performance and functionality as coding directly on the target platform. This is possible if the cross-platform engines can fully integrate native platform and device extensions. In that case, developers of native apps might reconsider Android, iOS and WP7 and choose to code to a cross-platform IDE, not to the platform. In this scenario, the cross-platform IDEs would become players of equal or even greater importance than the native platforms. At the very least, today’s OS platform wars will move to a totally different level. Jonas Lind [Jonas Lind has been working in the TMT sector since the late 1990s. Among other things, he has worked as an industry analyst for TeliaSonera HQ, with trend forecasting and scenarios in a project commissioned by Ericsson Research, as a strategy consultant during the dot com bubble and with femtocell concept development. He runs the blog Mobileforsight and is currently a strategy analyst at the seed stage VC fund STING Capital.] #developertools #html5 #mobileweb #softwareplatforms #webkit

[Which are the top app distribution channels for developers? Which platforms offer the highest revenue potential? In this part 2 of our 3-part Developer Economics blog series, Marketing Manager Matos Kapetanakis looks at how app stores have effectively re-written the distribution landscape] App Store Boulevard Since the launch of Apple’s App Store in 2008, developers found a market delivery channel that greatly reduced time-to-market and time-to-payment and provided a direct channel to consumers. The result: users started buying more and more smartphones, accessing app stores and downloading billions upon billions of apps. Today, app stores have become the a one-way street for developers. Over 45% of the respondents in our Developer Economics 2011 report used an app store as their primary route to the market, climbing nearly 30% since last year. At the same time, we found that the use of other distribution channels (own portal/website, 3rd party aggregators, via customers, Telco portals) has greatly decreased since last year’s research. The decline of traditional challenge comes as no big surprise; Telco portals, that once upon a time dominated content distribution in the US and Europe, have now lost their allure. “Downloads through operator portals are still less than one million per month on average per operator. Compare that to one billion per month downloads from the Apple App Store”, noted an executive at a mobile app development house who participated in our research. But why do developers choose app stores over other distribution channels? Reach is by far the most important reason behind developers’ preference for app stores as a distribution channel. More than 50% of developers distributing through the Apple, Google, Nokia or BlackBerry app stores cite the ability to sell to more users as the primary reason for app store selection. (also, see individual app store ratings in the full report) However, the use of app stores as a primary distribution platform varies greatly by platform. As we found in our research, the use of app stores is much more pronounced for platforms that have a native app store. As some of you will be quick to point out, Windows Mobile/Phone developers use their own portal/site to an almost equal extent as their platform’s native app store.  We attribute that to three factors: First, as we discussed in the previous post, Microsoft has tapped into two developers segments (Xbox, Silverlight), which are new to mobile. Second, the Windows Phone Marketplace is rapidly growing, but still lagging behind in terms of app volumes. Third, distributing through the Windows Marketplace has only become mandatory with Windows Phone. The app store duopoly Despite the many opportunities in this accelerating app economy, not all app stores enjoy the same level of success. Out of the 70+ app stores currently out there, only a handful have managed to emerge as winners. Out of those, the Apple App and Android Market are in a league of their own. Together, the Apple App Store and Android Market hold over 700 thousand apps, while their cumulative downloads are somewhere in the area of 20 billion. While other app stores have also enjoyed a level of success, this huge gap means we are in effect witnessing an app store duopoly. Theoretically, the most reasonable approach for developers would be to distribute their apps via multiple app stores. However, in practice, the app store landscape is far more fragmented than one might think; each app store has its own developer sign-up process, app submission process, artwork and paperwork requirements, app certification and approval criteria, revenue model options, payment terms, taxation and settlement terms. This implies that the marginal cost of distributing an application through one more app store is significant, contrary to popular perception. Plus, there are added entry costs to each platform, in the form of time and money spent. Some platforms have a steep learning curve (see full report for each platform’s learning curve), while others have expensive tools or poor documentation. Looking at Android, we see that more and more independent app stores, like Andspot, AndAppStore, SlideME and Amazon, are competing with Android Market for user attention and developer app submission. The same also applies to operator and OEM app stores. There is simply too much app store fragmentation. We believe that the app economy needs a single entry point for application submission (one per platform), along with a million distribution channels: – one app submission process, i.e., a single website, single contract, single approval process, single billing & settlement and a single mix of business models per platform – a million distribution channels, i.e., a million different channels through which to retail and sell apps to consumers with a variety of prices, promos, bundles, and regional access that help developers more effectively market their applications. App revenues and monetisation The single most important aspect of any business is monetisation. But, in this gold rush of apps, not everyone is making money. Around 30% of our respondents make less than $1,000 USD per application in total, which means they’re actually losing money, considering it takes months to develop an app and that some platforms have expensive tools. Which platforms have the largest revenue potential? Monetisation differs from platform to platform, with Symbian having the lowest revenue potential, as our research indicated. Taking Symbian as having a revenue index of 1, we can compare its revenue potential with other platforms. iOS topped the chart, making 3.3 times more money per app than Symbian developers followed by Java ME (2.7x) and BlackBerry (2.4x). Another interesting aspect is how the actual revenues compared to the expectations our respondents had. For example, while Java ME offers relatively high revenues per app, Java ME developers did not necessarily respond positively when we asked about their level of satisfaction with revenues (i.e. whether revenues were above or below their expectations). The previous graph is quite telling. The good news? One in three developers see the level of revenues they expected. The bad news? On average, there are five times more developers who are dissatisfied with their mobile application revenues than there are satisfied developers. To see the top revenue models, download the full report. The big picture What does it all mean? First and foremost, apps have irreversibly changed the way we discover, monetise and distribute content. Second, it’s not Android Market vs. the Apple App Store, but app stores as a whole that have become a one-way street for distributing apps, leaving Telcos, aggregators and OEMs in a diminished role as distribution channels. Third, monetisation may still be a pain point for a significant portion of the developer base, but at the same time 1,000s of companies are after commissioned iPhone or Android work and salaries are on the rise. One last note: We have yet to see the potential of handsets as app retail outlets, but we believe that OEMs will soon be leveraging on their potential to bundle apps anywhere on the handset real estate and to any region. And, as we know, there’s a higher profit margin in real-estate than in the manufacturing business. – Matos For more Developer Economics updates, follow us on Twitter (@visionmobile). …and for those of you who still haven’t done so, download a free copy of the Developer Economics report. #mobileapps #appleappstore #blackberryappworld #ovistore #androidmarket #mobiledeveloper #mobileapplications #appstores #windowsmarketplace

[Who is leading in the platform race – and who’s lagging behind? Marketing Manager Matos Kapetanakis examines the flow of developer mindshare and discusses how success is measured in the app era – in part 1 of our 3-part blog series on our newly released Developer Economics 2011 report.] Developer Economics 2011 – free download here – has been created by VisionMobile and sponsored by BlueVia. Developers driving innovation The role of mobile developers has changed dramatically over the past three years, from a lowly position as back-room engineers to the much-sought-after engine that drives mobile software innovation. Never before have developers, from big development houses to aspiring students to garage entrepreneurs, had such an enormous impact in mobile industry innovation and dynamics. Handset manufacturers, platform vendors and even network operators (or carriers to our American readers) are competing over who’s going to build the biggest developer community, as success today is measured in terms of thousands of apps and billions of downloads. Platform and OS vendors are the most active in this game, trying to steer developer mindshare towards their platform and create a new plateau of innovative services, as well as a whole ecosystem around them. So, which platforms lead the race and which are lagging behind? The platform race In the platform race for developer mindshare, there are some clear winners. According to our research, the developer mindshare is firmly flowing towards Android and iOS, with 67% of developers currently using Android and 59% using iOS. These figures show a considerable increase since last year, with the two platforms climbing nearly 10%. In contrast, the ‘old guard’ comprised of Java and Symbian are leaking developer mindshare. However, the most surprising finding is the adoption of mobile web, i.e. the platform for apps written in HTML or JavaScript, which claimed the 3rd spot in terms of developer mindshare, being used by over 55% of the developers. We do not attribute this to the ease of learning this platform (which has a deceptively steep learning curve, as you can see in the full report), but rather the influx of non-mobile developers to the industry. Also, mobile web is fast becoming the de-facto cross-platform choice for developers, especially now that Java and Flash are waning. In addition, there is a veritable host of HTML-to-native development tools that are helping HTML/JavaScript developers target smartphone native app markets. More on Developer Mindshare in the full report. It’s also worthwhile to take note of the Developer Intentshare, i.e. the platforms that developers are planning to use. Android still reigns supreme, but the surprise comes in the form of Windows Phone, which is fast becoming a developer favourite. Despite lukewarm sales in 4Q10 and 1Q11, the newly revamped Microsoft platform has managed to gain the vote of developers. This can be attributed to a number of reasons: First and foremost, Microsoft has actually released a competitive platform with a strong toolset. Also, the platform’s future seems bright, after the now-famous Finnish Deal. Finally, Microsoft has invested a lot of time (and money) into attracting developers, tapping into the Xbox and Silverlight developer communities to divert the flow of mindshare in their favour. The inclusion of Chrome OS in the top 5 platforms in Intentshare is more a result of curiosity for Google’s dark horse platform – how will it stack up to other platforms? MeeGo also seems to be vibrant, which goes to show that strong developer communities go a long way in this software era. In contrast, BlackBerry has lagged behind in Intentshare, suffering from fragmentation issues (see our full report for the surprising answer to which platforms are the most fragmented), as well as minor fixes to an aging platform. Who’s lagging behind in the platform race? Symbian and Java have suffered the biggest losses in terms of developer mindshare. Nearly 40% of developers currently using Symbian and 35% of developers currently using Java ME are planning to abandon the platforms. No surprises there, especially in the case of Symbian, which carries an expiration date, despite Nokia’s slow transition to the WP platform. Java’s loss of mindshare is less expected, especially considering the platform’s reach as global sales are still dominated by feature phones – but developers are not sticking around for that. Palm’s platforms are also being rapidly abandoned by developers, since Palm is all but dead and HP has still to ship its first webOS handset. What’s in a platform? How do developers make that all-important decision of which platform to select? Well, according to our research, the biggest driver in platform adoption is large market penetration – a sentiment shared by 50% of our respondents, irrespective of the platform they spend most of their time on. But what exactly is market penetration? A platform’s installed base is an important aspect – i.e. just how many actual handsets can run a given app – but that is not all. Penetration is also measured in terms of a platform’s ability to reach users and that is also a factor of how and where that content is available. – a centralised distribution and discovery point, such as an app store, accessible by mobile devices, tablets and PCs goes a long way towards providing developers with a direct access to their customers. Proving that there’s more to market penetration than a large installed base, we present the case of handsets sold vs. apps. There is a large discrepancy between the number of handsets sold and the number of apps available on a given platform. In an app economy with close to 1 billion [Update: million] apps, more than half of those are concentrated on two platforms: iOS and Android. It’s easily apparent from the graph that vastly more pervasive platforms in terms of total shipments, like S40 and Java claim just a fraction of the app pie. Granted, this is a smart-centric game, but even a pervasive smartphone platform like Symbian cannot much app to the two app moguls. Do apps mean money? Not directly, but it’s no coincidence that 2011 marks the first time Apple overtakes Microsoft in terms of revenues and Android rushes past the finally burned-out Symbian platform in terms of shipments. -Matos Want more Developer Economics? Follow us on Twitter (@visionmobile) for updates and stay tuned for part 2. And for those of you who still haven’t done so, don’t forget to download the full report! #meego #ios #flashlite #javame #mobiledevelopers #mobiledeveloper #symbian #Android #windowsphone #Blackberry

[HTML5 has been tipped to be a game-changer, with some predictiving it will take over most mobile platforms. But what is its real impact to the mobile industry? VisionMobile Research Director Andreas Constantinou evaluates HTML5 vs apps and what it means for the mobile industry as part of our newly released report – free copy here] Background: Web vs. apps In today’s world of apps, the web seems to have taken a seat in the back row. But many industry observers are predicting a comeback with HTML5 advancements, the proliferation of smartphones and ubiquitous backing by both telcos and Internet players. Is the web as we know it about to change? First things first: what is the web? Firstly, the web is a language for creating interactive, navigable content, which consists of three main parts: HTML (the language used to define the static text and images), CSS (the language defining styling and presentational elements) and JavaScript (the language describing the interactions and animations). Secondly, the web is a paradigm for open, unfettered access to content that is not controlled by any single entity. In the era where apps distribution is controlled by single vendors like Apple and Google, the web seems to challenge the status quo. There are many ways in which web pages differ from mobile apps today, as shown in the next table. From web 1.0 to the mobile web The web has gone through two major phases: Web 1.0 and Web 2.0. Web 1.0 was the era of the dumb terminals and static web pages. The first generation of the web assumed all intelligence was in the network; the device had to issue a simple request to fetch a page and then present it on the screen. Web 2.0 was is the era of smarter terminals and interactive pages. This second generation was designed around the ‘read-write web’ where the user is not just a consumer but also an editor, curator and producer of content. Web 2.0 helped create today’s phenomena of Wikipedia, Facebook, Twitter, blogs and nano-publishing. Despite starting off as an outsider to the web, the mobile industry has been rapidly catching up since the early WAP days. WebKit, the Apple-born browser engine is now the common ‘circuitry’ behind more than 500 million devices shipped to Q1 2011, by all major smartphone vendors. Opera, the mobile browser vendor, counts over 100 million monthly active users on its Mobile and Mini browsers. In the manufacturer camp, smartphones are expected to reach well into sub-$100 retail price points in 2011. In the operator camp, content delivery optimization solutions from the likes of ByteMobile, Openwave, and Ortiva Wireless are being deployed across tier-1 operators, facilitating efficient use of the network while browsing the web. Mobile industry initiatives such as the Wholesale Applications Community (WAC) are pushing the envelope for web applications (also known as widgets) while EU-funded initiatives like webinos aim to use the web as a medium for deploying applications across mobile, PC, TV and automotive screens. HTML5 as a technology change The hype surrounding HTML5 has peaked in 2011. HTML5 promises to push the capabilities of web applications to the point of making web apps as engaging as Flash applications and as integrated with the device as mobile applications. HTML5 introduces several technology improvements in these domains by adding off-line storage, 2D graphics capabilities, video/audio streaming, geo-location, access to the phone’s camera and sensors, as well as user interface tools. This next generation of web languages in the form of HTML5 is being standardized by the W3C and the WHAT working group who are driving forward web apps as equal citizens to mobile applications. The W3C consists of 51 member organizations, over 440 participants with strong backing from Google, Apple, Opera, IBM, Microsoft, and Mozilla. In parallel the WHAT working group is working closely with Mozilla, Opera and WebKit who are implementing and testing the latest browser features. Yet HTML5 is still work in progress and even standards bodies show fragmented approaches to HTML5 completion. The W3C expects official completion of the HTML5 set of standards in 2014. In parallel, WHAT has taken a different approach to completion and is now working on ‘HTML’ as a continually evolving set of specifications. Despite the adoption of the WebKit engine as a de-facto standard, HTML5 implementation on mobile devices is both fragmented and incomplete. Independent studies by quirksmode.org and NetBiscuits have shown that every mobile WebKit implementation is slightly different. In addition, the leading smartphone platforms show inadequate HTML5 support; iOS, BlackBerry OS and Android devices show partial HTML5 support (at best 2 our of 3 HTML5 features supported), while Symbian and Windows Phone devices are lagging further behind. Much like history has shown with the PC browser wars of the 1990’s and the Java ME fragmentation of the 2000’s, mobile browser fragmentation in 2010’s will be driven by the need to differentiate (’embrace and extend’), and the varying speeds among vendors in implementing the latest WebKit engine. What about HTML5 app stores? Already a number of start-ups such as OpenAppMkt, Openspace and Zeewe have proposed app stores focused on web apps. The key advantages of HTML5 app stores are cross-device portability and a buy-once-use- everywhere application model. Unfortunately, supply does not always imply demand; HTML5 app stores can’t deliver a business model change if demand is not there, for three reasons. Firstly, users care about availability of popular content (see Angry Birds, Skype and Facebook) most of which are not available as web apps often due to HTML technology limitations. Secondly, users care about choosing among hundreds of thousands of apps, which is currently a 2-horse race (Apple and Google) with the web lagging far behind in terms of number of apps. Thirdly, users are becoming loyal to their smartphone platform (Android, iOS or BlackBerry) where the native app store dominates. How to compete in a software world HTML5 introduces several technology innovations. However HTML5 remains a technology change that is not designed to solve discovery, distribution or monetisation problems – in other words it is not designed to change the business model. What *will* be changing the business model of the web are the innovations introduced in the apps economy – where content is created with semantic tagging (description, category, user ratings, etc), discovered via web stores (much like app stores), distributed within walled gardens (much like Facebook), and monetised through micro-payments (much like apps). We call this web 3.0 – and we expand on its implications in the full research paper. The question is: how can the mobile industry leverage on the web, and the native platforms that dominate the apps world?  The trick here is not to compete, but to leverage on the network effects of the Apple, Google and Microsoft platforms where handset OEMs or network operators can position themselves as a new generation of over-the-top players. For example, operators can act as the matchmakers between developers and end-users by helping developers get the right apps in front of the right users through techniques such as featured placements, social- graph-based recommendations and segment targeting. Similarly, handset OEMs can act as on-device retailers, connecting the developers to the right audience, in the right region, through white space across the handset real-estate. This is also where we believe WAC has the best chances of success but helping operators reposition as over-the-top players on top of the Android and Apple app stores – that is by helping developers reach out to users with ubiquitous billing, quality assurance, content curation, local content deals, privacy and security assurance, and help extend app stores away from the virtual and into the physical retail space. In parallel, network operators and handset OEMs can help push the web into a viable alternative for native platforms in many ways. They can push the development of WebKit towards better bandwidth management, and closer integration with hardware multimedia acceleration. Moreover, the mobile industry can sponsor the development of better cross-platform developer tools that allow HTML and JavaScript developers to target multiple native platforms and mass-market browsers. No matter how telecoms players decide to compete in the software world, they need to adopt ‘agile’ development methods and move at software speeds to catch-up the platform players in controlling the last mile to the consumer. One thing is certain; the future of connected web and devices is going to surprise us – much like how applications turned telecoms economics upside down. Like Bill Gates once famously said “we always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next ten”. Web is going to be a game changer, but not in the way we expect it. Read our full report for more. – Andreas you should follow me on Twitter: @andreascon #mobileapps #network #html5 #mobileoperators #mobileweb #webkit #wac #handsetmanufacturers #mobileapplications

[The Netphone is a bold attempt by Smart Communications – one of the top 20 MNOs globally – to bring telco services to the mass market But will the Netphone’s blend of WAC and Android succeed?  Research Director Andreas Constantinou goes behind the scenes into the Netphone project to find out, as part of our latest case study, sponsored by Red Bend Software – click here for a free download] Smart Communications: sophisticated services in an unsophisticated market Smart Communications – the telco behind the first WAC phone – has over 50% market share in the Philippines with 46M wireless subscriptions, which puts them within the top-20 operators globally. Smart has a record of service innovation that is akin to what operators in North America and Europe have achieved in more developed markets. Smart has one of the widest service portfolios among global mobile operators, including mobile payments, mobile banking, money transfer, mobile streaming TV, maps, push email and propositions for niche segments (e.g. MomsClub). Data services currently make up just over 50% of Smart revenues, as of Q1 2011, with the majority coming from the one billion SMS texts being sent each day. Smart Money, a service that allows users to pay for goods by transferring money from their bank account, was launched in 2001, and counts more than 8.5 million customers. However, like many operators in developing economies, Smart is in a low-ARPU, pre-paid market. Some 99% of Smart subscriptions are pre-paid, with the blended, pre-paid ARPU reported at just 169 pesos ($3.9 USD) in Q1 2011. Faced with decreasing ARPU in a competitive market, Smart has embarked on a handset-led strategy to increase its revenues by bringing over-the-top services to the mass market of pre-paid customers. An Introduction to Netphone: The first WAC phone The Smart Netphone presents a new series of mobile phones and tablets developed by Smart, aimed at bringing smart devices and services to the mass market. The first device – expected to launch in July, 2011 – is a rebranded, revamped ZTE Blade. This is the same handset that has been rebranded by Orange UK as the San Francisco and priced at 99 GBP (around $160) without contract, and not dissimilar to the Vodafone Smart handset by Huawei priced at 90 EUR (around $130). Although Smart has not announced pricing, we expect its Netphones to target image-conscious, affluent Filipinos willing to spend an estimated $120-$140. The Netphone comes with a suite of widget-like applications on the phone’s home screen that provide access to Smart and partner services: – Balance Check for prepaid users, which comprise 99% of Smart’s subscription base – Unified Chat, allowing users to message their contacts with emoticons and video animations. Chat integrates with Yahoo Messenger and Facebook – Sender Pays Email, which follows the SMS cost paradigm, but adds richer emoticons and video expressions to the messages – Connected Address Book, which integrates the user’s address book with Gmail and Facebook contacts – Global Directory, which integrates local Yellow Pages, and lists all users who use the Netphone (subject to privacy settings) – Social radio, which lets users share an FM station with a friend and tune into it in parallel – Smart Money, a service that allows users to pay for goods directly from their bank account or credit card – Emergency app, which offers one button calling to a doctor or other contact that can be assigned by the user – Partner apps like Jollibee (the number one fast-food chain in the Philippines), which allows users to browse the food menu, check out special offers, and order and pay for food delivery, directly from their phone. Behind the scenes: the making of Netphone The Netphone is not just an experiment for Smart. It represents a major effort for the operator, with a team 300 staff developing the phone series over the last 18 months, together with an array of tens of partners across six countries. As a phone series, the Netphone hits several firsts: it’s the first phone to be based on WAC widget specifications (see next section); it’s the first fully customized handset from a mobile operator in an emerging economy; and, along with the Orange San Francisco and Vodafone Smart, it’s one of the first attempts to sell smartphones to prepaid users. The Netphone has been designed with tangible revenue goals. Besides increasing own service revenues for Smart, the Netphone generates revenues by enabling partner transactions. For example, Smart gets a percentage of the revenue from every Jollibee fast food delivery transaction. Smart lined up several partners to realize the Netphone concept, including ZTE and Huawei (handsets), Qualcomm (Android chipset platform), IBM, Oracle, Huawei (back-end integration) and Red Bend Software (software management over the air). According to Smart, a key design decision has been using a software update technology that allows the Netphone platform and applications to be updated continually over the air (OTA). With the OTA update technology, Smart can minimize the runtime age of the WAC-based platform runtime, ensuring that its Netphone applications run on the latest version of the platform. This addresses a common challenge faced by mobile application developers, who must port new applications to older runtimes. For example, about 25% of active Android handsets run on platform versions that are more than 18 months out of date, according to Google data released in May 2011. Similarly, 20% of existing Apple 3GS devices had not yet been upgraded to the latest platform version two months after the introduction of iOS4, according to app analytics firm Localytics. Building on WAC technology The Netphone series includes the first phones based on specifications defined by the Wholesale Applications Community (WAC). Launched in February 2010, WAC is a cross-operator initiative aiming to develop a cross-device platform and app store framework to drive operator services. Since its foundation, WAC has amassed 34 operator members and 39 other partners, bringing in a total of over $10 million in annual funding. Smart has a seat on the board of directors of WAC, alongside Vodafone, AT&T, China Mobile, NTT DoCoMo and other major telcos. The Netphone represents an important breakthrough for an industry initiative that has been criticized for its slow device rollout. For Smart, WAC represents an industry-endorsed software platform on top of which its partners can build HTML-based applications (also known as widgets). Moreover, widgets are familiar to a broad base of web developers, who are accustomed to HTML or JavaScript development. On top of the WAC widget specifications, Smart has layered its Looking Glass, a device and network technology umbrella that implements the array of Smart services on the Netphone. On the device side, Looking Glass includes technology that WAC does not yet cover, such as over-the-air software updating (based on OMA DM SCOMO standard) and additional access into device capabilities like FM radio. On the network side, the Looking Glass technology umbrella provides access into Smart’s services, such as connected address book, advanced messaging, email integration, location-based services and Smart Money. Smart’s network APIs extend the GSMA One API specifications by adding XMPP for advanced messaging, billing & payment, and SIM-encrypted (DUKPT) transactions. The agile telco: What other operators can learn from Smart Many telcos have ventured into the world of handset software to deliver their own services and differentiated user experience. The most well-known examples are Vodafone (Live!, VFX, VSCL, 360), Orange, Verizon and, of course, DoCoMo. Smart also has had a tradition of developing services in-house, including Smart Money and its own airtime pre-loading solution. Yet, Smart has taken a different approach from most operators. That approach offers three important lessons for the operator community. Short tail. First, rather than deploying own-brand services exclusively, the operator has focused squarely on business partners with established consumer brands. It has allowed brands to deliver local consumer differentiation, and to share revenue on transactions. In so doing, it has provided brands with an additional channel to consumers. Agile development. Second, the operator has used an agile development process. Rather than set specifications in stone at the beginning of the project, Smart’s featured Netphone applications have been iterating continually through a cycle of development, testing and user feedback. Moreover, rather than use the traditional RFI/RFQ ‘waterfall’ software procurement process, Smart has established joint operational and R&D teams with its many suppliers for Netphone, and has adapted the software specifications during the course of the Netphone project. The project has already cycled through four iterations, averaging once every 3 months. Another iteration is planned before launch. “An RFP or waterfall development process clearly wouldn’t work here,” comments Ibasco, who has been a key proponent of the Netphone project since its inception. Ongoing updates. Third, the over-the-air software update mechanism allows Smart to deploy new features and updates throughout the lifetime of the device. It also allows Smart to extend its addressable market for new services to the entire base of deployed Netphones, not just the most recent line-up of handsets shipped. The future of the Netphone Initial rollout goals are modest, with Smart planning to sell 200,000 Netphones by the end of 2011. Assuming Smart can hit sub-$100 price points in early 2012, it has a chance to rapidly ramp up these volumes, and address a substantial portion of its 46M subscriptions base. For now, the operator community is looking at the Smart initiative with anticipation; Netphone marks the latest telco attempt at innovating in the era of software, by building on both the telco (WAC) and software (Android) worlds. Read the full case study and tell us what you think. – Andreas #redbend #smartphone #wac

[There’s 10s of telco programs targeting developers. But they all lack commercial traction. Isn’t it about time for telcos to question their approach? Guest author Jose Valles argues for a ‘polarity change’ in the telco business model and discusses the need to rethink the telcos’ relationship with developers.] In life, we tend to take many things for granted; the Sun will rise and set every day and a compass will always point North. But we mustn’t forget that things do not, and in some cases should not, remain constant. The Earth’s magnetic poles are known to reverse their polarity every few hundred thousand years and then, the compass no longer points North, but South. In business, we also need to question assumptions and remember that things do change. In the mobile industry, telcos (mobile network operators) have been around for over 20 years – many many generations in telco speak – but their relationship with developers has always been lukewarm at best ; telco APIs haven’t seen any significant take-up by developers. What telcos need to do is to fundamentally question their assumptions about the software world and change their business model towards developers – in other words change the ‘polarity’ of their business model. Here’s why: Some historical context It is widely accepted that telcos desperately need developers; in today’s app economy, developers are a key source of innovation. If telcos want to capture value and innovation, they need to capture developer mindshare. In the past 5 years, we have seen 10s of telco developer programs launch with different end-goals and flavours but with the same result: lack of commercial traction. Why have so many telco investments failed to see significant developer adoption? Failure is not such a bad thing, provided we can understand what went wrong and how we should fix it. I would argue that most telco API programs have lacked two key ingredients; the lack of web mentality and a developer-centric business model. The Web mentality If you go to www.programmableweb.com, you can find thousands of APIs that allow developers to enhance their software and mobile apps with functionality coming from third party businesses. Functionality ranging from Google maps and eBay purchases to Tesco grocery lists, New York Times articles and pizza ordering can be accessed through cloud APIs. For a developer, this is an unprecedented source of content for their apps. How do businesses like eBay, Tesco or NYT make it appealing to developers to use their APIs? How does the web world attract developers? It’s the business model; in the web world APIs are often free (or freemium) so that developers don’t need to worry about upfront costs. It’s about ease-of-use; they’re also plug-and-play so that developers can experiment with functionality and see how it works. It’s also about adaptability; web businesses also adapt and change their APIs based on how developers use them. That sounds easy. But what about telcos? The telco mentality: the developer pays If you go to any of the telco API programs that are out there and check their SMS API specifications, the first thing you will come across is the PRICE LIST. Well, that may work if you have a strong developer brand or if the attractiveness of your APIs are top-notch but, honestly, that’s not the case with telcos. Developers dislike telcos – and I can say that working for a telco. We telcos don’t have a good reputation in the developer space. And what do we telcos do?  We charge developers! That’s not a developer proposition; it’s a wholesale mentality. And how do telcos think we are going to be able to compete in this space when much more agile voice application platforms like Twilio, Teleku, Jaduka or Vivox get fremium pricing and technology right? The business model polarity change If telcos are to grab developer attention, we need to see developers not as wholesalers – that is not a source of revenue but as the missing link between customers and telco services. When developers drive traffic or service usage we need not charge them, we need to thank them. And we need to charge not developers but end customers. We need to let developers focus on finding new ways to innovate with apps using telco capacities, not to worry about whether they have enough cash flow. In other words, we telcos need to change our business model polarity; rather than using a “developer-pays” model, we need to move to a “customer-pays” model. If developers create apps that use telco APIs, they drive traffic or usage which benefit both the user and the telco. It’s not the developer that needs to pay – it’s the user. Consider this; a developer builds an SMS-to-Twitter service; the user sends a new tweet by as a text to a shortcode. The reply, an SMS back to the user, is then paid by the developer. The developer is penalised for generating traffic to the network. This is the “developer pays” model and it doesn’t work. In the “consumer pays” model, a single API allows the user to pay for both outgoing and return SMSes in one shot and the developer gets to use the API for free. The developer can focus on building a viral service and won’t have to worry about success costs. This is a fundamental polarity change; instead of the developer paying for access to network resources, the consumer pays, and the network benefits from increased messaging revenues. APIs like SMS or voice can also be exposed under both polarities. In this case, the developer can choose if they want to use SMS or voice APIs in a developer-pays or customer-pays polarity, depending on the nature of their app or service. Winning with developers We telcos need to experiment with business models. We need to learn from how developers adopt and use APIs and pivot our business model until we get to a proposition that’s truly win-win for both developers and telcos. As the Earth’s magnetic poles shift naturally, telcos also need to question assumptions. We need to reverse the business model polarity for telco APIs in tune with the web and look for new ways to attract developer talent and new ways to satisfy customer needs. We need to fundamentally change the developer perception towards telcos if we are to succeed in helping telcos capture a share of the innovation out there. – Jose Valles Head of BlueVia @josevalles49 [Jose has been working for over 10 years in different parts of Telefonica. Since 2009, Jose has been building a concept under the working name “Open Telefonica”, which ended up bringing BlueVia to life. The BlueVia business model does not just make APIs free, but it also pays the developer. “If developers use our APIs, we pay them back for the usage”. Check it out.] #networkapis #mobiledevelopers #mobileoperators #carriers #mobiledeveloper #networkoperators

[Is telco voice innovation dead? Or will smartphones and LTE deliver a much wider breadth of voice applications? Guest author Dean Bubley argues that ‘voice’ is about to experience several discontinuities as it goes beyond  our limited notion of ‘telephony’.] Telecom operators are facing a huge problem: in developed markets, we are close to the point of “Peak Telephony” – or maybe even past it already. Peak Telephony – inspired by the notion of reaching “Peak Oil” production – refers to the point after which voice revenues will face terminal decline. Already the traditional fixed and mobile telecoms industry is potentially facing a bleak outlook as call volumes stagnate and prices are eroded. While fixed operators have long recognised the threat to their core telephony business, mobile networks are now also facing the inevitable as well. Globally, over 70% of wireless operators’ revenues still comes from voice services and SMS, so this is an existential threat – one which threatens profound change to business models and even extinction of some operators as we know them today. To an extent, many older telcos had a ten-year extension granted to them by the rise of mass-market mobile services. These appeared at exactly the right point, just as fixed voice prices (especially long-distance) started suffering the competitive onslaught from early VoIP players. But at a group level, declines in fixed-line profits were offset by the rise in mobile. The inherent value of mobility, and the convenience of handsets loaded with easy contact-lists and call-registers, postponed the onset of saturation and substitution. But now, finally, a combination of Moore’s Law, devices and the Internet are catching up – mobile voice is about to experience several discontinuities and radical change in coming years. The limitations of “distant voice” For the past 100 years, we have pretty much only had three ways to communicate over long distance between people: letters, telegraph and telephone (from the Greek words for ‘distant sound’). The traditional phone call has been wonderfully transformative and yet, at the same time, very limiting – even in mobile guise. It has enabled revolutions in both commerce and society greater than virtually any other invention since the wheel and printing press. But phone calls do not correspond to the way humans really communicate with each other. We don’t generally think of conversations as “sessions”, or measure their value in terms of their length. In essence, we have surrendered our natural modes of communication to the restrictions of telephony. We have boiled down “distant voice” interactions into Person A calling Person B for X minutes, via numbered identifiers. Compare that to the more normal style of “close voice” of dropping in and out of conversation, with interruptions, breaks in the flow, background tasks, simultaneous interactions with other people and so forth – using our names. Normal in-person conversation is enhanced by non-verbal communications, physical context and a multiplicity of other factors. We use a broad range of volume levels, tonal frequencies and gesticulation. Some conversations are synchronous, some asynchronous – people talking over each other, or speaking in turn, perhaps based on relative authority or another social construct. Some are unique to the specific two people or particular cultures, others are generally accepted universally. In a crowded room, we might hear snippets of other conversations, by chance or deliberately, through eavesdropping. The phone call has been an excellent lowest-common denominator baseline for “distant voice”. Telecom operators have profited immensely from its enablement, especially with the enhancements of mobility and the “wrapper” of a cellphone and its user interface. But in doing so, they have provided us with a single speech product that is intended to span myriad use cases and social/business needs. Only a few other distant-voice technologies have emerged to address niches: push-to-talk, voice messaging, walkie-talkies, CB radio and private radio systems addressing fringe-cases such as taxi dispatch or public safety services. But now, the landscape is shifting. The combination of smartphone platforms, thriving developer ecosystems, smartphones, PCs and the Internet have enabled new communications formats to evolve. These formats can map much better onto natural human communications preferences. We no longer need to constrain our innate ways of interacting, because of the constraints of a piece of wire (or air) and a switch. We can “politely interrupt” with a soft alert or IM before escalating to a call, locate team-mates in virtual worlds with stereo cues, or interact directly with a voicemail for simple tasks, rather than calling back. We already have in-game voice chat between players, remote baby monitors, always-on voice telepresence, audio surveillance and all sorts of other voice applications which really are not calls, as such. Numerous other voice communication modes are evolving, especially those linked to social and messaging applications. In a nutshell, we no longer need to shoehorn all of our “distant voice” communications needs into the unnatural format of a “phone call”. We are able to visualise, contextualise, obfuscate, interrupt, lie, drop in and out, waffle, multi-task, spy, listen, store, mumble, overhear, translate, declaim, announce and recall speech over a network in many, many different ways. Not only that, but the supply of basic “phone calling” functionality has grown much faster than demand. If we do want to make a traditional A-B for X minutes call, we have many modern variants on the theme of a “piece of wire and switch”, now over mobile networks as well as fixed lines. It’s not that hard to do. Sure, numbering is a constraint, and ultimate quality may be a limit – but that is quality measured against the yardstick of the “telephony application”, and not a more general measurement of social communications. We don’t really complain about the QoS of speech in a noisy pub – or pay extra for a quieter venue. Will LTE voice be “old telephony” again… or something new? But the final kicker is the imminence of a major transition point – the adoption of LTE and all-IP mobile networks which are not yet optimised for telephony. Although various initiatives – notably the GSMA’s VoLTE (Voice over LTE) specifications – are developing carrier-grade LTE telephony, the likelihood is that it will take several years to get to the quality, reliability, scalability and cost/power performance of today’s basic GSM. 4G networks have not really been designed with voice in mind – or viewed more cynically, it has always been “someone else’s problem” to solve. Nobody yet knows what happens when we have 1,000 mobile VoIP users in a cell, moving around, handing off to other cells, causing interference, audio glitches and so forth. Experience from fixed VoIP suggests that tuning networks to mass-market perfection takes a very long time, and it seems unlikely that the extra variables of RF and mobility will make the task easier. This implies that smartphones on LTE networks – and, by extension, 3G networks as well – risk creating a vacuum, which could well be filled by other “non-telephony” voice applications, while we wait for “plain vanilla mobile calling” to catch up to the realities of wireless IP. The telecoms standards and market representation bodies (3GPP, GSMA and others) have made little effort to diversify efforts into the more generic “distant sound” world, instead focusing on replicating what we have today. Much-trumpeted enhancements such as “HD” (high-definition) codecs go only a tiny distance towards the more complex human-interaction models discussed above. There is an argument that plain-old telephony (fixed or mobile) can be packaged up and “distributed” through various new “delivery” channels. Linked to the Web and appropriate call-control APIs, many operators are hoping to create new “cloud communications” platforms. But it is unclear whether the underlying telephony control mechanisms and the “session philosophy” of calling really represent the best possible basic ingredient. Add in the usual rigid telco attitudes towards numbering, security, pricing and specific acoustic mechanisms and it seems unlikely that telco-powered telephony will be the best way of creating all of the new “distant voice” applications that will emerge. Filling the voice innovation gap What will fill the gap, becoming the platform(s) of choice for the plethora of innovative voice apps and services? It is still too early to tell. It could be some of the larger VoIP incumbents such as Skype or Google, or an established software-client provider like CounterPath. But it could also be one of the new breed of speech-centric application developers such as Viber, Vivox or RebelVox. Major carrier-voice infrastructure vendors such as Cisco, Sonus, Acme Packet and Broadsoft also have roles to play, with some attempting to become more open platforms – although with an eye to their traditional operator customer base. From a handset standpoint, things are likely to get quite complex. Ordinary phone calls are not going to disappear – but we will start to see multiple voice applications present on each device. This is already happening with Skype and GVoice apps, but looking further ahead, more fragmentation is probable. This will present huge challenges for UI and “contact” applications, as well as a debate about which voice and audio/acoustic components are best installed in the OS, on the baseband or apps processors, in individual apps or even in dedicated audio chips. One thing is certain however; making a clear and careful distinction between “voice” and “telephony” is a critical starting point for understanding the landscape. Telephony is what telcos do today. It’s a closely-defined service, subject to rules and regulations, and billed in a structured way. But increasingly, general voice applications will go beyond homogeneous “calls” – for example, chat between players of an online game. This will require new business models, new platforms, and new forms of user interaction. How the traditional telephony industry deals with these new voice innovations will be fascinating to watch. – Dean Dean Bubley is the founder of research company Disruptive Analysis. He is currently developing a programme of “Future of Voice” master-classes together with communications industry visionary Martin Geddes. Dean can be reached at AT disruptive-analysis DOT com. #volte #pushtotalk #voip #voice #skype #vivox #carriers #innovation #lte #mobile