Search Results

Strategy Director, Michael Vakulenko is presenting Developer Economics on 2 September at MobileMonday Tel Aviv. Get in touch if you’d like to meet up.

Marketing Manager Matos Kapetanakis will be presenting Developer Economics on September 6 at Campus Party Europe, London. Get in touch if you want to meet up.

Managing Director Andreas Constantinou will be presenting ‘Developer Economics: How Does Your Business Compare?’ on September 5 at UPLINQ 2013 in San Diego. Get in touch if you want to meet up.

[In The M2M Ecosystem Recipe report, which we published in June, we presented some ideas on how the full promise of the Machine-to-Machine market might become reality. Not all aspects of M2M ecosystem thinking were fully explored, however. In a response to the report, telecom specialist Tsahi Levent-Levi posed several to-the-point questions and counter-arguments. We always welcome debate, so we invited Tsahi to have a conversation about the issue of fragmentation in M2M. In this blog post, Tsahi and Stijn Schuermans, the author of the M2M report, try to advance the thinking on the topic of fragmentation in the emerging M2M market. Read on – and join the debate!] Tsahi: I love what you guys are doing at VisionMobile. Most times I fully agree with the reasoning behind it. The M2M piece? I think there’s a real opportunity here – it is definitely a market that is bound to happen. My main difficulty is in envisioning how this will play out. The use of the analogy you did between smartphones and M2M it is the chart indicating the rapid growth of M2M. In a way, this chart suggest that a similar growth pattern can be achieved in M2M. To me, these businesses are apples and oranges. Where do you see the similarities between the two? Stijn: Rather than focusing on the uniqueness of M2M, we focus on the similarities with past industries. M2M and smartphone businesses are indeed not the same thing. This said, we see many parallels from an economic perspective with other industries that have made the transition from a fragmented vertical structure to an ecosystem-led business model. Smartphones, but also PCs, game consoles, or online retail. The conditions in the M2M market today closely resemble those in other markets before they made the transition to ecosystems. For example: A highly fragmented market, but with a technology that’s becoming more and more modular and affordable. A complex technology and an inefficient market that is mostly only accessible to highly skilled organizations with deep pockets, like utilities or car manufacturers, while a much larger group of small businesses or consumers is not participating in the market (due to the high costs of transacting) and therefore are not innovating or creating value. A focus on a few high-profile, uniform use cases. A lack of diversity that fails to address unexpected customer needs. (Some analysts still strive to map the entire spectrum of M2M use cases. Try that with iPhone apps.) We therefore think that the same principles that caused the flip in those historical examples also come into play with M2M. Tsahi: But what about the differences between these two markets? To me, M2M is about devices. Lots of devices. Varied ones. Each focused on solving a specific problem. Smartphones, on the other hand, are swiss army knives – they can do everything. That being the case, it is hard for me to see a clear single winner of the M2M ecosystem. Stijn: Smartphones were not always the swiss army knives they are today. The predecessors of the modern all-in-one smartphone were described at the time as feature phones (heavily sub-segmented, with very distinct features for distinct consumer groups), email/telephone combos (BlackBerry), but also PDAs (Pocket PCs, as one manufacturer called them), industrial mobile data collection terminals and even digital cameras or music players. A device designed to solve the needs of a Western businessman had a very different design from that of device for Asian youngsters. Of course there were similarities and common features as well, but that’s true of most M2M devices today. The core issue here is fragmentation. You’re absolutely right: it’s a major challenge in M2M and a big point of friction to the emergence of an ecosystem. (And admittedly under-addressed in the paper.) Today’s M2M devices are conceived as purpose-specific, vertical devices, and therefore highly fragmented. In most if not all of the historical examples in the history of computing, however, this situation was a temporary phase, followed by an era of modularization and multi-purpose devices. From computers designed for science or accounting (but not both) to personal computers with scientific and accounting software. From feature phones, email phones and PDAs to converged smartphones with apps. The modular solution was difficult to imagine back then, but looks completely natural today. A multi-purpose M2M device is not unthinkable; it’s actually likely to emerge if history is a guide. Arduino and the likes are early prototypes, if you will, of such devices. (Btw, there are literally hundreds of Arduino-compatible modules out there in all sorts of form factors, including tiny ones, cheap ones and with specific sensors already attached.) There is no fundamental reason why M2M devices must be developed for specific verticals only, just inertia. If you don’t assume that M2M devices will remain extremely fragmented and organized along vertical lines forever, then the presence of multi-purpose M2M devices opens up the possibility for a fundamental rearrangement of the value chain in M2M. Suddenly service and device don’t need to be manufactured by the same vendor anymore, or even sold together as a package. This opens up the market for 3rd party developers to create services based on existing modules, or even on top of an installed base of modules (abstracted as data streams) already deployed. Once multi-purpose M2M devices and/or abstraction layers like cloud services emerge, the road is paved for large service ecosystems, quite possibly with winner-takes-all market dynamics. Fragmentation must be managed, but not completely eliminated, for the benefits of modularity to emerge. Not all smartphones have the same capabilities, features, processing power, operating system version, screen size, quality and price points. Fragmentation is still an issue in smartphones: between OS’s (about five of them are seriously in the running at the moment) and notably within the Android ecosystem. However, we’re now at a much better situation than the “three million platforms with a hundred users each” from 2007-era mobile computing. At the moment there are thousands of incompatible M2M modules. Even reducing this to a few dozens would be a major breakthrough; one that could enable the transformation of the value-chain. Tsahi: I beg to differ. Smartphones are all alike. They come to solve the same job. They are personal. You carry them in your pocket. You do things with them. They might have some different types of accelerometers or different resolutions, but can you really distinguish between them? M2M? How does a toaster similar to a UPS package? How can a refrigerator behave like a humidity sensor on a farmland? Can you really say that these are only fragmentation scenarios of the same device? Sure – put an Arduino in all of them, but then you will see that the service being developed must come from the company that designs the hardware, as the use cases for each is extremely different. A refrigerator vendor might publish an API (or extend a baseline API), but that API has nothing to do with the people counter at the entrance to a shopping mall. Stijn: Smartphones are not just personal, though – they’re also personalized. While the devices might all be similar (nowadays, not in the past), the ways they are used are not. Users install apps to tune the device to their own needs, and apps cater to just about every need imaginable. Smartphones have commonalities (personal, pocketable, connected) but fundamentally cater to thousands of use cases. That’s what differentiates them from feature phones in the first place. M2M devices and services cater to many different use cases, but they also have commonalities. They all collect data, turn that data into actionable insights or automated response, and through actuators allow you to drive that response. The technologies needed to do that will be very similar across a very wide range of specific use cases. Farming, home automation, logistics, fleet management, and foot traffic measurement are the equivalent of apps that can be built on top of a common platform. Attributes like ruggedness, range or battery life are the counterparts of smartphone screen sizes or build quality. The co-design of hardware and service for every distinct use case, historically, is unlikely to last. It’s like saying that computers are mostly use-case specific devices, and therefore the motherboard, processor, memory, peripherals and software must all be co-designed by the same manufacturer. That was actually true at some point, but then minicomputers and PCs came along. Once the performance of a device becomes good enough for most use cases (in M2M that might mean lifespan, battery life or processing power, for example), modularization ensues and general purpose devices emerge. This is because once performance becomes good enough, the flexibility and “mix and match” possibilities of a modular design becomes more economical and more valuable than the expensive full co-design. You might argue that jet engine monitoring (the industrial internet), for example, will never use the same platform as say home automation. That might be true. The way it typically unfolds is that “easy” applications will start using the new technology (in casu the M2M platform) first, and then will suck in more and more advanced use cases. The industrial, high performance ones will be the last to succumb (if at all – people are still buying mainframe computers). However, are home automation, in-car connectivity, smart metering, etc so disconnected in people’s lives that they warrant different technologies? Tsahi: You gave the example of the app store and apps as a way to drive an ecosystem in smartphones, and the explosive growth we see there today. What do you think will happen in the M2M business? Can apps be the prevalent driving force as well or will there be a different ecosystem? Stijn: Digital ecosystems as we understand them emerge when separate groups, e.g. developers, consumers and device makers, are empowered to interact and transact with each other efficiently. In smartphones, the catalyst to this interaction are apps and app stores. Apps are where the value is created in smartphone ecosystems (but not necessarily where it is captured). Where will value be created in a possible M2M ecosystem? It could be devices, but that’s unlikely as devices by themselves don’t solve user needs. It’s rather the services which will be the focal point (fed with data by said devices). Services might be closely tied to devices, or not. If you’re monitoring a jet engine, then they likely are. If you’ve monitoring pollution or traffic conditions with thousands of sensors owned by a community of people rather than a single organization, then the link is more tenuous. Services can include centralized software components in the cloud, APIs, device management systems or managed services (i.e. involving actual humans). If you think about services as a focal point for the ecosystem, then the diversity in devices might become less important, as well. The ecosystem winner(s) could emerge on another layer, like cloud services. What are your thoughts on the M2M ecosystem? Join the debate! – Stijn (@stijnschuermans) – Tsahi (@tsahil) #digitalecosystems #internetofthings #iot #m2m

What motivates developers? Is it fame or fortune? Our new Developer Segmentation 2013 report addresses this questions, presenting a needs-bases segmentation model that focuses on developer goals, not just demographics. Based on data from our latest Developer Economics survey (6,000 respondents from 115 countries), this article gives you some insights from the report, discussing how the sense of achievement, not money is the prime motivator for developers. Forward-thinking businesses today realise that developers are their innovation engine, their most promising affiliates, their evangelists or their fastest growing resellers. Businesses are discovering that developers are modern-day channels that help them reach new consumers, discover new use cases and propel their growth. The millions of dollars in developer marketing efforts serve one purpose: to persuade developers to use a specific platform, network, tool or API set. Yet, in 2013, mobile developer attention is becoming extremely scarce, and dominated by the three leaders of developer marketing: Apple, Google and Facebook. Competition for developer attention is intensifying month by month, with players bombarding developers with promotions, organising developer events and preaching the advantages of their APIs or toolsets. The scarcity of developer attention has to do not just with skepticism to marketing. Learning a new platform takes months. Learning a new SDK can take weeks. Learning a new API can take days. It’s a serious investment of resources. As a result, developers take the decision to invest in a platform, tool or API seriously. Most business are resorting to traditional, textbook marketing techniques to segment developers – by technology (web, Java, Windows, Android, Apple), job function (coders, designers, architects, team leads, IT managers, CxOs), by company size, app category (games vs enterprise developers), by audience (B2C vs B2B) or by demographics (age, income, education or location). Yet all these segmentation models are bound to fail, as they fundamentally neglect to address how developers make investment decisions in a new platform, API or SDK. In other words, it’s not age, job function, audience or technology background that influences how a developer chooses between Apple, Google, Windows Phone, BlackBerry or Tizen. To understand the complex mosaic of developer personas we segment developers in terms of their outcomes, or what developers are trying to achieve. This is based on the Jobs to Be Done methodology, popularized by Harvard Professor Clay Christensen and which constitutes today’s cutting edge in segmentation techniques. We have backed this model with unprecedented statistical rigor and hard data, from the largest-ever mobile developer survey of 6,000+ developers. Building on our earlier Developer Economics 2012 research work, we extracted hard data on thousands of developers in terms of their aspirations, motivations, challenges and plans in app development. We produced a unique model of eight developer segments – the Hobbyists, the Explorers, the Hunters, the Guns for Hire, the Product Extenders, the Digital Content Publishers, the Gold Seekers and the enterprise IT developers.] How do these eight segments and three clusters contribute to the app economy? More importantly, when do these segments interact with platforms? We find that Explorers and Hobbyists, those seeking to learn, have fun and self-improve, make up 33% of the mobile developer population but only 13% of the app economy revenues. These segments prefer – more than average – BlackBerry 10, Windows Phone as a platform, as these are more often associated with experimentation and learning. The Hunters and Guns for Hire, those seeking revenues from the app economy, make up 42% of the developer population and 48% of the app economy revenues. These segments prefer – more than average – iOS as a platform, due to the consistent revenue-generating opportunities of the platform. Product Extenders, Enterprise IT developers, Digital Content Publishers and Gold Seekers, aiming at extending a business, make up 29% of the developer population, and a whopping 39% of app economy revenues. These segments prefer – more than average – Android and HTML5 as a platform – due to the reach that these platforms offer across the entire smartphone and feature phone installed base. Our data also shows, that contrary to popular perception, money is not the only motivator for mobile app developers – in fact, far from it. Revenues – in some form or other – are the goal for only 50% of mobile developers, which challenges the assumptions of developer marketing programs that use money as the main developer incentive. The hierarchy of developer motivations on the next chart shows some surprising findings. At the base of the pyramid, the majority (53%) of mobile developers are motivated by creativity or the sense of achievement, making this the most popular among motivators. The fun of making an app, is a motivator for 40% of mobile developers – which is important to many more developer segments than just Hobbyists and Explorers. Our Developer Segmentation Q3 2013 report drills deep into each of these developer segments. We map developers in terms of their goals (“what” they are trying to achieve), their success metrics (“how” they are trying to achieve it) and more importantly the personal motivations behind their choices (the “why”). We further profile each segment across 5 dimensions: who and where they are, which markets they target, what choices they make, how they make money, what platforms they select and what challenges they face. These unique insights into developer segments can provide a strong competitive advantage for organisations for which developer outreach is a key element of their strategy. Want to know more about the Developer Segmentation 2013 report? Check out some of the key insights and contents. #developerneeds #developersegmentation

The evolution of the PC and mobile handset industry have been mirror images of each other, as both saw two distinct disruptions: a new market disruption, followed by a low-end disruption. Sameer Singh and Michael Vakulenko, VisionMobile Strategy Director explain how the shift from integrated companies to modular competitors will pressure hardware profit margins across the industry, leading to the emergence of a new business model, i.e. hardware-as-distribution The mobile handset industry has already seen two waves of disruption: A “new market disruption”, led by Apple, and a “low-cost disruption”, driven by Google and its Android platform. Each wave created distinctly different business models that completely realigned competitive dynamics in the industry. Where do we go from here? We believe that the coming, third wave of disruption will again reshuffle the deck for all industry players. We will see growth in a new class of business models, where handset hardware is no longer seen as a source of profits, but is treated as a distribution channel for digital products and services. Let us explain why this is the next natural step in the evolution of the mobile handset industry. Dual Disruption Patterns in Computing As industry observers are keenly aware, Android and iOS currently dominate the smartphone landscape in terms of shipments as well as developer mindshare. This duopoly is a result of two major disruptions that the mobile industry saw in rapid succession. The first was a “new market disruption”, caused by the iPhone, which introduced the paradigm of mobile computing. The second was a low-end disruption, caused by the Android operating system, which reduced barriers to entry to the smartphone market and caused deep commoditization. Clay Christensen defined a “new market disruption” as one that changes the basis of competition in the marketplace and initially competes against non-consumption. In the mobile industry, the iPhone brought the concept of mobile computing to the mainstream market and initially did not have much of an impact on incumbents. Over time, performance improvement enabled a wider range of tasks to be performed on the iPhone, which pulled in customers from competing legacy mobile platforms (such as Symbian, Blackberry, Windows Mobile, etc.) and personal computing platforms as well. In contrast with this dynamic, a “low-end disruption” takes root in low-end segments of an existing market which may be overserved. Improved technology enables new business models to emerge that are based on lower cost structures. Low-end disruptors with extendable business models then move up-market by offering “good enough” products at lower price points. The Android operating system was a classic “low-end disruption”, as it introduced a modular platform and ecosystem that allowed less experienced handset makers to build compelling products without major investment in software. Source: Jeremy Reimer, Arstechnica Curiously, this dual disruption pattern was also seen during the early days of the PC industry. Apple Computer caused the first “new market disruption” by introducing the personal computing paradigm, while the second, low-end disruption was caused by clones of the IBM PC, running Microsoft operating systems and productivity applications (for example, Compaq, Gateway, Olivetti, Dell, HP and later numerous Asian OEMs). Of course, the time frame between these disruptions and the resulting evolution was much longer in the PC industry. This was because mobile adoption was driven by the consumer market (“bottom-up” diffusion or “grass roots” adoption). In the PC industry, high acquisition costs ensured that adoption was driven by the enterprise market followed by smaller customers as costs reduced (“top-down” diffusion or “trickle down” adoption). Mark Andreessen explains the idea here. There are some very interesting patterns that emerge when we compare the evolution of business models in these two industries. The first disruption was created by a product that offered integrated hardware & software, while the second was caused by the introduction of a platform that removed entry barriers for OEMs and hence, increased competitive intensity and reduced margins on hardware. Let’s take a look at the evolution of computing business models from the perspective of value chains. Impact of Value Chain Integration on Business Model Evolution The chart above compares the evolution of business models and value chains in the personal computing and mobile computing industries. Underserved sections of the value chain need proprietary architectures or vertical integration to maximize performance, while modular architectures can provide more cost-effective solutions in overserved sections of the value chain. “New market disruptions” created product categories that faced early technological challenges, especially at the hardware & OS layers. In the PC days, Apple became the dominant (and most profitable) player in both industries, as it was integrated at those underserved layers. This was followed by the entry of modular players, led by Microsoft in PC and Google in mobile. The initial modular competitors were inferior to Apple’s integrated approach, but were relatively less expensive and were aimed at less demanding customers. As hardware performance improved, the industry began to get more crowded with the entry of IBM PC clones and low-cost smartphone vendors like Huawei, ZTE, etc. At this point, the focus began shifting to the next point in the value chain that was underserved, i.e. the applications/services layer. The reason that Microsoft was extremely successful is that it was vertically integrated across the operating system and applications layers. Similarly in mobile, Google has successfully integrated across the operating system (Android), browser (Chrome) and services layers. The clear pattern that emerges here is that profits should accrue to those companies that offer proprietary solutions at the layers of the value chain that are still underserved. Once the segment is overserved, price competition from inferior, modular competition proceeds to destroy margins. The impact of value chain evolution on profitability was very clear in the personal computing industry. According to McKinsey’s estimates, the share of industry profits captured by integrated computing companies dropped from 80% in 1986 to just 20% in 1991. During the same time frame, the suppliers of components, software & services increased their share of profits from 20% to 31%. The remaining 49% of value generated by the industry evaporated in the form of consumer savings. This “profit share” structure mirrors the current state of the mobile industry, where Apple and Samsung (the two most integrated hardware companies by most measures) have captured nearly all of the industry’s operating profits. Apple’s products are integrated from the software to the retail interface, whereas Samsung’s products are integrated across components and hardware. The industry balance will continue to change as the present-day leaders will see growing competition from companies with lower cost structures. Vendors like Huawei, Lenovo and various regional OEMs are already very strong in ”less demanding” markets (like India, China, Africa) and are highly motivated to move upmarket. The Third Disruption: Hardware as a Distribution Channel As there will be fewer profits left in the handset industry, a third wave of disruption is a certainty. In the PC industry, once the dominance of modular architectures led to deep commoditization, hardware just became a distribution channel for software (the operating system and applications). The evolution of the mobile handset industry works out slightly differently. Google essentially destroyed the software licensing business model by giving the Android operating system away for free. Consequently, the cost of owning a proprietary operating system became unviable for most players (like Motorola, Sony Ericsson or Nokia) because hardware margins became severely pressured. This ensured that industry focus and profitability would accrue to the next layer of the value chain that was underserved, i.e. Google’s core business – online services. In the PC industry, OEMs like Dell and Sony used the “hardware as distribution” approach to charge software vendors to pre-install applications on their devices and boost margins. In the mobile industry, we have seen already numerous companies follow this model to create a competitive advantage by leveraging established ecosystems. Many service companies like Baidu, Dropbox, Opera, Facebook and Whatsapp have attempted this strategy by partnering with OEMs to pre-install or use their services by default. Another variation of this strategy, followed by services and content companies, is selling relatively high-end hardware at cost, in order to enable deeper penetration of the company’s core services. Companies like Amazon and Xiaomi compete asymmetrically with true hardware vendors in order to expand their consumer base. Both strategies have been quite successful – Amazon has expanded Kindle Fire availability to numerous countries based on strong sales and Xiaomi expects to double its handset sales to 15 million this year. Many more services companies like Evernote and Spotify are contemplating the low-cost, “hardware as distribution” strategy in the future. We have already seen a smartphone called SmartNamo dedicated to an Indian politician, Narendra Modi. Will we see a “Justin Bieber phone”, “Shah Rukh Khan phone” or even a “Real Madrid phone”? Rapid commoditization will only make it easier for companies to convert hardware into a distribution channel. The tablet industry has seen more price competition than the smartphone market in the absence of carrier-driven price distortions. As a result, commoditization has been much more rapid and the “hardware as distribution” model has come to the forefront in a very narrow time frame. Low-cost tablet hardware has allowed companies like Newscorp to enter the industry with preloaded, education-focused content. We have seen similar models emerge in South Africa, India, China and many more countries. As price competition increases, commoditization pressure in the smartphone industry, variations of “hardware as distribution”, could become one of the primary drivers of profitability. The expected shift in handset business models will reshuffle the deck once again. Companies that catch the trend early will find plenty of opportunities to create competitive advantages and thrive in the new environment. Those who miss it will be destined to fight the losing battle of “competition to the best”, which Prof. Porter calls “the granddaddy of all strategy mistakes”. #mobilebusinessmodels #google #Apple #marketdisruption #handsetmarket

The term “web app” has been around for the past years – we’ve all heard it and used it more times than we care to remember. Yet there remains a debate on where “web sites” end, and “web apps” begin. Guest author Ciprian Borodescu presents the opinions of several prominent figures in the web technology domain and discusses the ‘app-ification’ of the web. Definitions of web sites vs. apps Web sites are so deeply embedded into our daily culture that it is impossible to imagine life without them. Even as a developer, I find it hard to remember the times from my childhood when my chubby little hands didn’t yet know how to type. In the last two decades, the Internet has grown, expanded, exploded and became impossible to ignore, making any keyboard without an Internet connection pretty much useless. In the last few years, the web brought with it a new term that can be exciting and confusing at the same time: “web app”. But what is a “web app”, how does it differentiate from a “web site” and why does it matter? Understanding this difference ultimately makes us better users or developers? Is a business going to blossom just by marketing its online presence as a “web app” instead of a “web site”? To figure out the boundaries between websites and web apps, I interviewed several prominent figures in the web technology domain who contributed with their experience and professionalism to help guide the debate: Dominique Hazael-Massieux (Mobile Web Initiative Activity Lead at World Wide Web Consortium), James Pearce (Head of Developer Advocacy at Facebook), Michael Mullany (CEO at Sencha), Christian Heilmann (Principal Developer Evangelist – HTML5/Open Web – at Mozilla Corporation) and Stephen Pinches (Head of Learning Technologies – ELT at Pearson plc and Group Product Manager – Mobile & Emerging Platforms at Financial Times). In this article I pieced together their expert input to help answer the web site vs web app debate. The difference between Web sites and Web apps In the pre app store era, the word “applications” had been applied to Web sites that provided advanced user interactions and capabilities previously available only through installable software. Early examples of web applications include Webmail, Google Maps and Google Docs. Compared to the classic web, i.e. blogs and news sites, web apps provided a richer user experience and access to advanced browser capabilities. Today single-page web sites might still be referred to as web apps, but it’s more about the task focus than the technology itself. From this perspective, as Christian Heilmann explains, “The use case of an application is always to DO something with it”. The task centricity of web apps is easier to understand if you think of smartphones or tablets: an app’s purpose is to achieve a specific task, like making a call, checking your email or finding a taxi nearby. Some may argue that we can simply classify Web sites as being read-only and Web apps as being read-write. That certainly seems simple enough: Web sites are for consumption what Web apps are for creation. Does it sound right? For developers, it is easier to draw the line between web sites and web apps if we think of the technical distinctions. Web apps have some defining attributes that bring them closer to their native counterparts: self-contained rich/interactive user interface, possibly mimicking the native UI of the device using advanced device capabilities – like geolocation, camera integration, or other technologies that the W3C Device APIs and Policy Working Group is developing action-oriented rather than information oriented not relying heavily on (or hiding when possible) the browser chrome (back button, reload button, address bar) working off-line, for example using HTML5 ApplicationCache, localStorage, or indexed database Mozilla’s Christian Heilmann argues that the offline attribute is not a technical necessity in terms of definition, but rather a crucial usability distinction: “Seeing how flaky our connections are – I am writing this on a plane – our apps should make people as effective as possible and this means we shouldn’t be dependent on a connection. The interface should be usable whilst we are off the grid and sync as soon as we go online”. But how can we explain the difference to non-technical users? And, do we need to? According to Dominique Hazael-Massieux, a Web site can be presented as a Web app as long as users consume it in a similar way they do a native app. If it’s exposed as an iconified app and used for a specific task, it shouldn’t matter whether it’s contained in the browser or installed via an app store. Facebook’s James Pearce outlined a few possible vectors that need to be considered when differentiating between Web sites and Web apps. I‘ve summed up his arguments: Creation versus Consumption. Pearce asserts that read-only interaction should be classified as a site, but this criteria is not sufficient to distinguish between web sites and web apps. We still have cases like Flipboard (clearly oriented towards consumption) or Twitter and Facebook (with entirely user-generated content) that do not fit in any box. Linkability. Since both web sites and web apps can be launched by entering a URL into a browser or from a home-screen icon, this is clearly “not a reliable way to distinguish between web apps and web sites” according to Pearce. User Experience. Visual pizzazz is an important argument, one that users might particularly relate to, but is also a fuzzy boundary. What if my site displays a fixed toolbar, but no back button? What if my list appears as hyperlinks instead of ‘tappable’ items? What if I use plain scrolling instead of smooth fancy bars? Architecture. In the case of single page webapps, is SEO the price to pay when choosing to give the browser far more autonomy and responsibility and take advantage of its HTML5 APIs like storage? Do Web sites have SEO capabilities while Web apps don’t? We are back to explaining the differences between the two by using technical terms. Should you be building web apps or web sites? This question might be regarded as a technicality with a pinch of marketing to spice it up. This reminds me of the “HTML5 is ready” contest by Sencha that was announced a few months back, encouraging developers to draw inspiration from native apps and create similar web apps that show off the capabilities of HTML5. The creators of the competition correctly argued that “the mobile web is the most fertile ground for leading edge web development because it doesn’t have the legacy of the older internet explorers that the desktop does. You can start your development with the assumption that your app or your content will be used in a fairly recent browser, so you can take advantage of a whole host of features like Canvas, inline SVG, HTML5 video, CSS3 styling etc. that bring the experience alive for the user”, as Sencha’s Michael Mullany explains. Would it be safe to argue in favor of building web apps instead of web sites especially on mobile? Mobile users perform specific tasks on their devices, so a web app that offers the same experience as a specialized native app might gain more interest compared to a regular website. Long term the distinction should not matter. According to FT’s Stephen Pinches, it really doesn’t make any sense, on the long term, to speak about the future of the mobile web: “there shouldn’t be “mobile” and “desktop” but simply good, user-centered design, which adapts and responds to the screen size and features of the device upon which it is displayed. However, on short to medium term, there is a need to differentiate and ensure the user experience is as good as possible on a given device.” The ‘app-ification’ of the Web Whatever your preference may be, there is an increasing number of mobile developers targeting web apps. Based on VisionMobile’s latest Developer Economics survey of 6,000+ developers, already 23% of HTML5 mobile developers develop web apps, compared to 38% who develop mobile websites. With browsers increasing support for device APIs, and with a growing number of developers going direct to native with PhoneGap, Icenium or Appcelerator, or even with the recently launched Firefox OS, the web world is clearly moving in the direction of apps. As Sir Tim Berners-Lee said in 2012, “the solution is in your hands: develop web apps!” Interested in finding out how you compare to other software developers in your country/region? Take the Developer Economics survey and get your personalised developer scorecard. #apps #web

What can BREW OS teach us about ecosystems? Qualcomm’s Steve Sprigg takes us on a trip down memory lane and gives us an insider view of the history of BREW OS and the lessons learned for Qualcomm. Imagine creating an operating system used on a billion devices and an app store serving millions of apps every day and then consciously making a decision to back away from driving the product. Sound far-fetched? That’s exactly what Qualcomm did when we made the decision to step back from aggressively pushing our BREW OS and app download business in favor of other emerging smartphone and tablet platforms. To understand why we did that and why it was the right decision a bit of history is in order. [tweetable]Unlike many legends, the story of how BREW OS was created is true[/tweetable]. The idea came during an informal whiteboard session with Dr. Paul Jacobs back in the late 1990s. Back then, Qualcomm was in the handset market as a means to jumpstart an ecosystem of devices using CDMA. But as we pushed wireless Internet access and new multimedia features, we found ourselves limited by the lack of a robust, efficient and secure operating system. I was also whining about the demise of the retail software industry. Our discussion brought both issues together and Paul mapped out a two phased strategy with an OS and SDK for app developers to get apps on our phones and subsequently drive an application download business. The picture Paul drew quickly evolved into the now familiar “virtuous circle” with an ecosystem of partners including handset OEMs, wireless operators, application developers and Qualcomm. After a quick weekend trip to our small R&D lab in Scotts Valley, a lot of coffee and very little sleep, I returned to San Diego with a prototype of the OS. Over the next year we recruited some really smart folks, refined the platform and eventually downloaded our first application in December of 2000. A decade later BREW had been integrated into about a billion devices and helped to jumpstart an industry of developers leveraging a lot of cool new features exposed by our chipsets. Under the leadership of Paul and Peggy Johnson, we also assembled one of the finest, most driven and enthusiastic software teams in history. It’s also true that the name BREW came from a brainstorming session where we backed into “Binary Runtime Environment for Wireless” which was certainly more appropriate than some other combinations we threw out there. So with all that success why did we make the tough decision to scale back? The answer lies in reminding ourselves of the original objectives behind the endeavor. Qualcomm is a big believer in ecosystems. We believe that win-win scenarios produce the best opportunities and products. As we had done in the handset business, the purpose behind BREW was to link users to technology by creating an ecosystem of partners who all stood to benefit. But with the emergence of other smartphone operating systems, the need for us to drive our own OS ran counter to that philosophy. Could we have won an OS war? From the perspective of an unabashedly biased leader on that team I believe so. Stretching back to our roots battling those who claimed CDMA defied the laws of physics, Qualcomm tends to attract people who just refuse to accept that things cannot be done. But we also continually reminded ourselves of the objective of driving ecosystems. Even as we developed BREW we put tremendous resource on facilitating the innovation of other operating systems. We actually had larger engineering teams working on those platforms than we did on BREW. As those platforms evolved we saw an even bigger ecosystem emerging and an opportunity to do even more than we could with our own OS. In the end, the decision was not as tough as you might think. BREW OS had accomplished its goals. It had blazed the trail in creating an ecosystem linking the desktop application and wireless worlds. Now other platforms have emerged and Qualcomm is driving the most powerful and efficient chipsets across a broad ecosystem of carriers, device manufacturers, OS providers and app developers. The lesson from BREW is one we routinely leverage at Qualcomm. When we achieve an objective we declare victory and ask our folks to go solve the next problem by defying the laws of physics… #brew #mobileplatform

The global app economy was worth $ 53Bn in 2012, and expected to rise to $ 143Bn in 2016. As part of our new Developer Economics: App Economy Forecasts 2013-2016 report, Senior Analyst, Andreas Pappas, examines developer population, platforms, revenues, and revenue models and shows how app store sales are just a small part of the app economy. In the past few years the mobile industry has experienced a powerful upheaval sparked by the launch of the first iPhone and the creation of the first, true app ecosystem. This event brought about a gradual restructuring of the mobile value chain and a steady shift in value from the traditional pillars of the mobile economy, telco services and mobile handsets into app ecosystems. This emerging component of the value chain is what we call the “mobile app economy” and it represents the fastest growing area in the mobile value chain today and will continue to do so in the foreseeable future. The value migration is profound as can be seen in the following graph. In 2012, the global app economy accounted for 18% of the combined app services & handset market. We estimate that by 2016 the contribution of the app market will rise to 33% of the combined market, equivalent to half of the handset market. While several sources have estimated revenues generated via app-stores and advertising, these estimates are missing the largest part of the app economy. The contribution of app store sales to the total size of the app economy is less than 20%, while the combined app store sales and advertising market accounts for just over a quarter of revenues generated via apps. VisionMobile has developed a model for sizing the direct app economy, that uses the large-scale, fine-grained dataset obtained via Developer Economics surveys. This model incorporates not just revenues generated directly through apps but economic activity generated via commissioned app development, mobile app e-commerce as an app monetisation model (i.e. not including e-commerce as core business), VC funding, services for app developers and several other income sources directly related to mobile apps. The global app economy was worth $ 53Bn in 2012, and expected to rise to $ 68Bn in 2013. It is growing at a 28% CAGR between 2012 and 2016, reaching $143 Bn in 2016. The bulk of this growth will come from APAC and LatAm, the fastest growing markets in terms of smartphone penetration. We estimate the global mobile developer population in 2013 will reach 2.3M individuals with each organisation that is directly involved in the app economy employing 4.5 developers on average, although this figure varies significantly by region. The mobile segment corresponds to 12.6% of the global developer population. In other words, 1 in 8 software developers is involved in mobile development in 2013. VisionMobile’s App Economy Forecast 2013 – 2016 model combines results from our Q3 2013 Developer Economics survey (free download) and a large set of industry figures and indicators to deliver both bottom-up and top-down approaches in sizing the app economy. The VisionMobile App Economy Forecasts 2013-2016 report report provides a unique set of data points on the current state and growth of the app economy including: Forecasts (2013 – 2016) for revenues across regions (North America, Europe, Asia-Pacific, Latin America, Middle East & Africa) Forecasts (2013 – 2016) for revenues across platforms (Android, iOS, HTML5, Windows Phone) Forecasts (2013 – 2016) for revenues across revenue sources (App stores, In-app advertising, mobile e-Commerce, outsourced development, other) Forecasts (2013 – 2016) for the Mobile Developer population globally Mobile developer population by region, platform and revenue source for 2013 Thoughts? Comments? Get in touch with us! – Andreas @PappasAndreas #ios #marketforecasts #mobiledeveloper #Android #appeconomy

We’re proud to present our latest Developer Economics report – the 5th in our highly acclaimed developer research series! The full report is [vm_form_download link_text=’available for download’ product_id=’4062′] on PDF – but you can also visit our newly-launched Developer Economics portal for more data and insights! State of the Developer Nation is the 5th in the series of Developer Economics reports, based on the largest, most global developer survey (over 6,000 respondents from 115 countries). This report tracks the state of mobile ecosystems, developer mindshare, monetisation trends, revenue models and developer tools.

VisionMobile’s Web Technology Lead, Dimitris Michalakos, is presenting at an HTML-themed webinar by FierceWireless. The topic of the webinar is “The Pros and Cons of HTML5 vs. Native” and Dimitris is presenting some of the key HTML-related highlights from our new Developer Economics report.

We’re happy to announce the launch of our new Developer Economics report, based on the largest, most global developer survey (6,000+ respondents from 115+ countries). You can [vm_form_download link_text=’download a free copy’ product_id=’4062′] of this latest report, that tracks the state of mobile ecosystems, developer mindshare, monetisation trends, revenue models and developer tools. The full report is available for [vm_form_download link_text=’free download’ product_id=’4062′] – but you can also view the web version, in our newly-launched Developer Economics website and comment on specific sections of the report! In this article we’ll just present some of the key insights – but stay tuned for more Developer Economics articles, based on data from our latest survey! Developer Mindshare Q3 2013 The Mobile Developer Mindshare Q3 2013 shows Android leading at 71% of developers using the platform, followed by iOS at 56%. HTML5 has entrenched itself as a mobile development technology of choice, with 52% of the developer population using HTML5 technologies for developing mobile apps. Once we double click on that 52% of HTML5 mobile mindshare, a kaleidoscope of colour and options appears. The largest share (38%) of HTML5 developers develop mobile websites with another 23% developing mobile apps, i.e. incorporating offline functionality and deeper browser integration. Hybrid apps, such as those produced by PhoneGap account for 27% of HTML5 mobile developers. A minority of 7% of HTML5 mobile developers use platforms exposing native APIs via JavaScript, such as Firefox OS and BlackBerry 10. Last but not least, 5% of HTML5 mobile developers use a Javascript-to-native converter tool like Appcelerator. Up-and-coming platforms BlackBerry has been successful in transitioning BB legacy developers over to its new BB10 platform, with the new platform having almost the same mindshare as the legacy BlackBerry 5/6/7 had just before the release of BB10 six months ago. The strong interest in Windows Phone observed in past surveys is still there (35% of developers planning to adopt WP) but has subsided by 12 percentage points since Q1 2013. Mobile developers now have a wide gamut of options with challenger platforms competing for their attention. Windows 8 is at 40% of Mobile Developer Intentshare, followed by BlackBerry 10 (28%) and Firefox OS (capturing 27% of all developers planning to adopt a platform). Platform selection and consolidation There is no one-size fits all in mobile platforms. Our research shows that iOS is selected more frequently than average by developers that value revenue potential (+12%), graphics (+7%), app discovery (+8%) and user reach (+10%). Developers tend to use HTML5 more frequently as their primary platform when they value porting (+9%) and speed & cost of development (+4%). BlackBerry 10 is used more frequently than average as a primary platform by developers valuing developer community programmes (+16%). And Windows Phone is most popular for developers looking for the right development environment (+3%) and documentation (+2%). Whether hobbyists or IT managers of Fortune-500 companies, developers use 2.9 mobile platforms concurrently, according to our recent survey of 6,000+ mobile developers. This is the first time we are observing a shift towards diversification, with our earlier 2011-2012 research pointing towards continual platform consolidation: on average mobile developers used 3.2 mobile platforms in our 2011 survey, compared to 2.7 in 2012 and 2.6 in our Q1 2013 research. Platform prioritisation At 2.9 concurrent platforms on average, today’s developer is multi-platform. In this world, not all platforms are equally important to a developer. Prioritisation has an impact on which platform are new apps and features first rolled out, as well as the focus, app quality, sales and revenue on that platform. Our data shows that 84% of mobile developers are using iOS, Android or HTML5 (mobile) as their primary platform. Our research shows a strong lead of iOS over Android with 49.4% vs 59% of platform developers preferring it as their main platform. Whereas Android has 4x times more devices shipping and a significant lead in Mobile Developer Mindshare, it lags behind iOS in terms of Android developers using it as their lead platform. Platform priorities also depend on the level of experience. Developers who are fresh to mobile have a much stronger preference towards Android, with almost twice as many new mobile developers preferring Android (40%) than iOS (21%). Revenues and revenue models At $5,200 per developer per month on average, iOS continues to be the most revenue generating platform for developers, and ahead of Android developer monthly revenues by a margin of 10%. Our research of 6,000+ mobile developers shows that there is no single revenue model that is dominant across all platforms. On Windows Phone, developers have a strong preference towards in-app advertising (43%) and pay-per download (40%). BlackBerry 10 developers have a strong preference towards pay-per download (47%). The picture is much more balanced on Android, iOS and HTML5, with no revenue model dominating to the extent observed on Windows Phone or BlackBerry 10. Developer motivations Contrary to popular perception, money is not the only motivator for mobile app developers – in fact, far from it. Revenues – in some form or other – are the goal for only 50% of mobile developers. The hierarchy of developer motivations shows some surprising findings. At the base of the pyramid, the majority (53%) of mobile developers are motivated by creativity or the sense of achievement, making this the most popular among motivators. The fun of making an app, is a motivator for 40% of mobile developers. Developer tools Our research shows that developer tools are in the must-have app development arsenal of the most sophisticated developers, and also those making most revenues. Across the tools spectrum, iOS developers are the most active and sophisticated users, with 92.5% reporting that they use at least one tool. iOS developers therefore have a clear advantage as being most advanced in tool use, and therefore having the infrastructure to innovate and differentiate. Read the [vm_form_download link_text=’full report’ product_id=’4062′] for more insights and data on the latest mobile development trends! More Developer Economics reports With the release of State of the Developer Nation, we’d also like to present two more reports, based on Developer Economics data. Developer Segmentation 2013 The definitive study of developer segments and the hierarchy of developer motivations: Extensive profiling of the 8 principle developer segments, based on desired outcomes, personal motivators and success metrics. How do the eight mobile developer segments contribute to the app economy? Which developer segments should you approach, and at which stage of your developer program? How should you approach each segment? App Economy Forecasts 2013-2016 Developer population, platforms, revenues, and revenue models sizing and forecasts 2013-2015. Sizing the app economy: developer population by region and platform, distribution of revenues, revenue models and forecasts. What is the size of the developer communities for the three key mobile platforms (Android, iOS, HTML)? Which are the most lucrative revenue models for developers? What are the relative sizes of the app economy? #ios #Android #Blackberry #mobiledevelopment #windows

[A new SDK economy has sprung up to support the needs of the 500,000+ mobile developers and the app economy. Guest author Panos Papadopoulos reviews the growth and rapid consolidation of the SDK economy and the impending rise the Mega SDK vendors] Many would argue that the mobile platform consolidation in the form of today’s Apple / Google duopoly is a good thing for developers; less choice, but two mature platforms and a billion-smartphones addressable market. Despite the platform consolidation, developers face real challenges not just in developing, but also in prototyping, designing, marketing, selling and supporting apps. The quality bar for apps is increasing; apps need to incorporate more functionality in a slicker UI, a sexier package (graphical assets and messaging), as well as through the right marketing channels and at the right price, which is usually free-to-try. App consumers are demanding, expecting utility, convenience and easy of use – all at a low or free price point with monetization shifting from paid downloads to advertising and in-app purchases. Enterprise apps have to talk to legacy systems, be an effective part of a company’s business strategy, enhance brand image, while being secure, reliable and cost efficient to develop and maintain. To support the community of 500,000+ mobile developers globally, a new “SDK economy” has emerged to cater to the needs of mobile developers. A storm of over 500 SDK startups and Enterprise IT incumbents, have emerged since 2009 to help developers in everything from app prototyping and debugging, to user analytics, planning tools, and customer support. These days developers can choose from a gazillion tools to monetize their apps, test, monitor app performance, manage security, study user behaviour, cross-promote apps to attract & engage users, and manage API use and simplify use of cloud services. Today most of the supporting infrastructure for app developers resides, within 3rd party developer tools, rather than within the platform itself. This SDK economy has become the critical infrastructure underneath the app economy. Growth and consolidation in the SDK economy The SDK economy has seen an impressive amount of growth and consolidation in the last 4 years. It’s also an economy that’s intensely suffering in terms of monetisation. The very first SDKs or tools for mobile developers were App store analytics (tracking sales & downloads) from the likes of Distimo and App Annie. Then came ad networks (mobile-centric like AdMob, acquired by Google), later followed by web ad networks expanding to in-app advertising, with ad networks and servers now in abundant supply. Cross platform tools followed soon after, helping develop apps for more platforms, from a single code base. Led by PhoneGap and Appcelerator, the supply of CPTs has exceeded 50 vendors, practically making this area of the tools economy a red ocean. Looking for investment opportunities, VCs began investing in the companies that support Enterprise and Consumer mobile app development. The VC capital created value but it also changed developer perceptions of value, by forcing tool vendors to offer base products for free. It also led to a string of acquisitions (see below), as covered in VisionMobile’s Developer Economics Q1 2013 report. Table: Mergers and Acquisitions in Mobile Developer ToolsCompanyProduct & typeAcquired byDateAptanaDevelopment environmentAppceleratorJan-11MetismoBedrock Java-to-native source code translatorSoftware AGMay-11TapJSGame hosting platform and APIAppMobiJun-11TapLynxApp factoryPush IOJun-11RhoMobileRhodes enterprise apps frameworkMotorola SolutionsJul-11Particle CodeHTML development toolsAppceleratorOct-11NitobiMakers of PhoneGapAdobeOct-11StrobeWeb app framework and app management platformFacebookNov-11UsergridBackend-as-a-ServiceApigeeJan-12CocoafishPost-download app servicesAppceleratorFeb-12WorklightEnterprise app platformIBMFeb-12ChompApp store search and discoveryAppleFeb-12TestFlightBeta testingBurstlyMar-12TrestleBack-end-as-a-serviceFlurryJul-12AppstaticsApp performance trackingserviceAppsfireJul-12InstaopsUser analyticsApigeeAug-12CabanaA tool to turn Facebook pages to mobile appsTwitterOct-12NodeableBig data processingAppceleratorNov-12CrashlyticsMobile crash reportingTwitterJan-13WaviiNatural Language ProcessingGoogleApril-13ParseMobile Backend as a ServiceFacebookApril-13Handmark/ OneLouderApp Store & Mobile app advertising platformSprint NextelMay-13Proxomo SoftwareMobile backend technologyLucent MobileMay-13AppshedCross platform tool & App FactoryIDG GroupMay-13IrisCouchMobile Backend as a ServiceNodejitsuMay-13AeponaAPI exposure and monetization platformIntelMay-13MasheryAPI management and monetizationIntelMay-13StaqGame management platformPlayHavenMay-13 There are three reasons behind the consolidation of the SDK economy: 1. Capital changing the perception of value. VC capital allowed tool vendors to offer developer products for free to accelerate user acquisition. 2. The need to subsidise developer onboarding. Developers are always the side of a mobile platform that Apple, Google, Microsoft or BlackBerry will need to subsidise. As a result platform-provided tools will be usually free and 3rd party tools will be prime acquisition targets for platforms themselves. 3. Catering to adjacent developer needs. There are substantial benefits to developers by integrating functionality across tools (e.g. ad networks with user analytics or crash reporting with performance management), which inevitably leads to acquisitions on tools that are adjacent in the developer journey. Catering to adjacent developer needs also helps tool vendors attract and, most importantly, retain their user base. Who stands to survive and win in this ongoing consolidation of the SDK economy? As is already evident from the earlier M&A list, consolidation will become clustered around where developer money is flowing into: App Marketing Services & Enterprise Mobile Services. App Marketing Services Mobile Advertising is expected to be a 20B market by 2015. Traditional ad networks have already ported their existing products – banner advertising – over to mobile in the form of in-app advertising. This model doesn’t work well yet in mobile and is a factor in why traditional ad networks are not yet profitable. One VC backed company, Flurry, followed a completely different path to capture app marketing revenue. Flurry recognized developers would first worry about the challenges of developing their app(s) and then worry about monetization. Flurry offered developers a host of tools (many of them free) to develop and track their app usage, built a relationship of trust with their developers, emerged as a leader in the mobile services market, and then launched a range of products that will help developers monetize their apps. Flurry considered the developer journey and built a spectrum of solutions to engage developers from the beginning to the end of that journey: – Analytics: a free service to measure actual use of the application – AppCloud (free): a back-end as a service – AppSpot: helping developers monetise, once an app has achieved traction – AppCircle: where developers can re-engage, promote and reach out to more users Flurry is capturing the lucrative app monetization dollars because VC funding gave them a head start. With strategic acquisitions like TrestleApp (a backend service startup that helps developers minimise backend coding) and giving away their analytics for free, Flurry is building the first true mobile, data driven (Big Data) ad network. Other companies are understanding this formula and making a play for App Marketing Services. Burst.ly acquired TestFlight earlier this year in a bid to become the vertical solution that covers all developers’ needs. Similarly, Facebook wanted to reinforce its relationship with developers and did so by acquiring Parse, a BaaS service. This acquisition reflects a growing trend where non-mobile companies see developers as platforms rather than customers, and developer tools as routes for customer acquisition, rather than feature enhancement. Enterprise Mobile Services Enterprise IT needs are different from consumer app needs. In enterprise apps, companies are less concerned with advertising or virtual good purchases and care more about security, stability, predictability and scaling down costs of mobile development and maintenance. Enterprise apps take performance, security and systems integration much more seriously than virality, direct monetization and high engagement. So which mobile tools do enterprises need? User analytics, app performance analytics, crash reporting, integration with existing business logic (connectors with SAP, Oracle, IBM), identity management, data security, and own app store distribution, to name a few. In enterprise IT, the incumbent back-end systems players like SAP, IBM and Oracle have been in the space for years and are very well positioned to ride the enterprise mobility wave. They stand as a formidable wall, deterring smaller vendors from entering the enterprise mobility market because they “own” the back-end and related ecosystems (including solution providers and integrators) within the largest companies. Mobilising those “owned” back-ends by 3rd parties is expensive because of the licensing schemes imposed by the incumbent back-end vendors. At the same time, a wave of smaller, more nimble vendors is making a play at enterprise mobility. Appcelerator, after failing to effectively monetize their cross-platform tools, is now making a vertical stack play, much like Amazon AWS, for mobile. They help developers of any platform access traditional services, such as user management, object persistence, push notifications and analytics via API calls to their cloud services or on-premise installations of their suite. Apigee announced a new product aiming at Mobile, offering user analytics, performance management, crash reporting and network analytics. All of these players clearly want to offer much more than a product that focuses on a tiny vertical or niche market. On the server side, there are tools like Splunk, which give insights into how an app is performing, identify bottlenecks and discover patterns. These tools don’t exist yet in Mobile, and big players, like New Relic, just entered this space. At the same time, the back-end incumbents are strengthening their mobile play. IBM has laid out a mobile strategy that wants to bring in Mobile as part of a more traditional IT strategy. The recent acquisition of Tealeaf aims at helping traditional business better understand and analyze their mobile audiences. Consolidation is already playing out within enterprise mobile services. “As the mobile market heats up, we agree that consolidation will likely result, as larger vendors look to shore up their mobile service offerings. Operational tools, especially those that deliver critical capabilities for monitoring the performance of mobile platforms and the web infrastructures upon which they rely, will become a strategic area of focus in this process. At the end of the day, any vendor who wishes to emerge as a key player in this arena must effectively monitor the whole application environment – transactions, mobile devices, network response, real user experiences, application servers, database connections and more.” –Jim Gochee, SVP Products, New Relic Tool vendors who stick to single functionality – be it prototyping or internationalisation or customer support – will become either niche players with a small but profitable market segment or zombie companies, surviving with minimal profitability and, given the Series A crunch, they will drive consolidation to new heights in 2013. The rise of the Mega SDKs The consolidation of the SDK economy will continue to accelerate leading to the rise of the Mega SDKs, along the two clusters: App Marketing Services: Winners will be those who build developer trust with end-to-end app development support, monetizing all channels that can maximise revenues or reach (e.g. ad networks, cross-promo networks, user analytics) Enterprise Mobile Services: Winners will be those helping developers write across more screens, manage more users, and better understand users (e.g. cross-platform tools, BaaS, app performance management, API management) Competition in the marketing tools will force companies to offer more and more for free, making it difficult for smaller startups to compete with the breadth of tools and the scale of companies like Flurry and Facebook. In the enterprise IT world, we should expect new titans to emerge or incumbents like IBM to enter and become the Amazon Web Services of mobile. Who do you think will be the first Mega SDK to emerge? #developertools #flurry #sdkeconomy

[Facebook is competing for eyeballs on Google’s own turf: Android. Guest author Francisco Kattan explains why Facebook’s Home strategy takes us back to the days of the 2005 home screen turf war and how Google, Yahoo and Samsung are impacted] By now most of you have heard of Facebook Home. Some of you might have even tried it. If you have been hiding under a rock for the past month, there is a good summary here: Facebook Home “replaces your standard Android’s homescreen with an immersive Facebook experience featuring full-screen photos, status updates, and notifications. Facebook also announced that a special version of Home will come pre-installed on the new HTC First phone on AT&T.” Facebook Home is Facebook’s attempt at taking over the user experience and app discovery of most phones without having to build a phone itself (which would result in a meager market share at best). Although execution by Facebook has been poor (see review here), the strategy behind it is brilliant. Moreover, this move represents such a significant threat to other players in the ecosystem that it will spark a second battle for control of the home screen and app discovery. To emphasize the importance of the home screen to ecosystem players, I borrow heavily from VisionMobile’s own report on this topic, published in 2009: “The active idle-screen (aka home screen or phone top) is the synonym of zero-click distance. It is the most premium real-estate on the handset for service delivery and promotion.” “The ownership of the idle screen will become as elementary as customer ownership; as ubiquitous as handset branding; and as important a monetisation tool as handset accessories.” More than a Home Screen But Facebook Home is not just a home screen – it is a very deep application itself, with its own contacts, its own messaging, its own photo sharing, its own video sharing, and more (see illustration above). Facebook is not just providing a launchpad or discovery portal for other apps on the phone, it is virtually replacing many of them by pushing them down, deeper into the phone, where they are harder to discover. If you have an app that competes with Facebook, this is not cool. And as Facebook introduces new services, other parts of the ecosystem should be worried. Quoting again from the 2009 VisionMobile report: “The home screen is the starting point for all user journeys; it is therefore natural for the home screen to provide shortcuts into functionality that is used most frequently, such as search – whether it is for contacts, voicemail summaries, free minutes remaining, where’s-my-nearest, what’s my Facebook status and many more creative search scenarios. We believe that the home screen is ideally placed to aggregate all such information from third party sources in the Internet cloud, the network and the device” Disrupting ecosystem players, one at a time Facebook unnerves many ecosystem players with its Home move. Google can’t allow Facebook to take over the user experience of its Android operating system. The idea was for the user experience to be owned by Google and extended by its Android licensees, not a competitor. Many of Google’s own services are threatened by Facebook Home, especially Gmail, Talk, Hangouts, Contacts, and of course Google+. Even Google Maps would be threatened should Facebook launch its own mapping service as has been rumored (It has been widely reported that Facebook bid for Waze before its recent acquisition by Google). Samsung can’t allow Facebook (or even Google for that matter) to commoditize its devices. Facebook Home reduces the ability of handset makers to differentiate and promote their own services. With Facebook Home, Samsung devices will look and behave a lot like HTC devices. Messaging service providers like Whatsapp, Google (Gmail), Yahoo (Mail) or the new and cool Just Me can’t allow Facebook to become the default messaging service on consumers’ phones. If you are on Facebook Home, it is much easier to send a Facebook message than dig deeper to find other messaging apps or even the phone’s native SMS client. Yahoo has bigger problems, but if Marissa Mayer has any hope of fixing the company, it will need to figure out how to have a prominent mobile presence. This is not possible if consumers choose Facebook Home. With Facebook Home, Yahoo’s Mail, Messenger, Flickr, and even Yahoo’s cool new Tumblr service would be pushed down and become a second-class citizens on the phone. AT&T, Verizon, Telefonica, Vodafone, and mobile operators in general who are still fighting to become relevant in the ecosystem lose even more control of service discovery. Operators today still exert some influence over some handset makers, especially in postpaid markets where they control handset distribution, subsidies and marketing spend. But as control for the user experience moves from handset makers to over –the-top providers like Facebook, the carrier’s influence over the ecosystem is crushed even more. Back to the Future – The first battle for the home screen Once upon a time in the not-too-distant past (early 2000s) device makers differentiated primarily on the basis of hardware. What’s the form factor? Clam shell or candy bar? Is there a full Qwerty keyboard? Bluetooth? 2G or 3G? How long is the battery life? But as the hardware became commoditized, device makers turned to differentiation on the basis of the software, and in particular the home screen and overall user interface of the phone. When I was at Adobe I saw this play out first hand. Device makers were turning to Adobe Flash as the platform for customizing their user interfaces and deliver more engaging home screens. A couple of good examples are the LG Chocolate and the Samsung D900. They both had beautiful home screens, powered by Adobe Flash. The LG Prada took this concept quite a bit further when it launched with a big splash in 2006. A beautiful, fashionable device with cool looking apps running on the home screen, powered by Flash. It was the first phone with a capacitive touch screen. Take a look and you’ll see a resemblance to some of today’s smartphone interfaces. Keep in mind this was before the iPhone. The operators want their piece of the action. Given the influence large carriers enjoyed over device makers at the time, there was an opportunity for them to take over the home screen to expose their own services. To enable such operators Adobe launched Flash Home in 2008 (launched by my team at the time, coincidentally). See the news here. “Adobe Flash Home, an over-the-air, customizable UI, enabling consumers to personalize the look and feel of their handsets and discover new content and services via home screens and data-enabled wallpapers” It sounds a lot like Facebook Home – except that rather than surfacing Facebook services to the home screen, it was about surfacing the operator’s walled gardened services. Too little too late. Unfortunately for operators, before their efforts to take over the home screen had a chance to succeed, iOS and Android devices began to sell in large volumes, upsetting the whole ecosystem and limiting operator influence even more. Operators diverted their focus to acquiring more data users with smartphones rather than promoting their own data services on feature phones. How should the ecosystem players react to Facebook Home? Google. Google could launch its own “Google Home” of course, but a more wise strategy for Google is to block third party app developers from messing with the home screen. This could be done by closing the relevant APIs or more easily by changing the terms of its agreement with developers. Google’s strategy is of course to generate advertising revenues from its services, and this requires Google to “crush down anything that stands between consumer eyeballs and Google inventory” (quoted from a good VisionMobile post on Google strategy: “Flatten, Expand, and Mine”). If any app can bury all Google services behind a proprietary app launcher like Facebook Home can, that app could limit Google’s mobile ad revenues significantly. The way things stand, if Facebook Home were to gain user traction, it is not hard to see that advertising dollars would shift from Google to Facebook. This is not a desirable outcome for Google, and one that, if not blocked by Google, would ignite a battle for control of the Android home screen. Yahoo. For as long as Google is allowing apps to take over the home screen, Yahoo should copy Facebook’s strategy and develop “Yahoo! Home” to surface all its services to the top of the phone. Flickr pictures, Tumblr posts, Yahoo messaging, Yahoo News, Yahoo Weather, and all other Yahoo services would be discovered much more easily, boosting Yahoo’s advertising revenues. To improve the likelihood that consumers will actually turn on Yahoo Home, Yahoo should learn from Facebook’s execution mistakes and do a better job of integrating with the rest of the operating system and apps. Facebook messed up with this integration and buried even critical OS functions like notifications, battery life, and even the time of day behind Facebook pictures. Yahoo (or anyone else attempting a home screen app) should also do a better job surfacing the user’s favorite apps. In other words, the home screen should expose not only Yahoo’s own apps, but also other favorite apps selected by the user to ensure a higher level of adoption. Samsung. Samsung should fork Android and launch its own Android version in much the same way Amazon did with Kindle. Samsung is now powerful enough to maintain its own platform, using its own Galaxy brand, its own home screen, an off-the-shelf store (Amazon or Yandex store) and a white label maps solution (like Nokia Maps) – in other words, all the ingredients needed to circumvent Google’s control points. In fact, even without the threat from Facebook Home, Samsung is already investing in a vertical, Apple-like strategy strategy with the Tizen platform. Whether Tizen succeeds or not, Samsung has all the ingredients to fork Android and tighten its control over the operating system. What are your thoughts? Do you think Facebook Home will spark a new battle for the home screen? Do you think Google should block such apps from taking over Android? What should Samsung, Yahoo, and the other big boys do? – Francisco (@FranciscoKattan) #activeidlescreen #Android #facebook #facebookhome