Search Results

Many modern competitive battles have been won by attracting developers – whether it’s Apple in the case of mobile platforms, Amazon in cloud, or Salesforce in CRM platforms. Companies are now investing 10s of millions of dollars in attracting and engaging developers to build extensions, products and partnerships around their platform. As these developer platforms and programs are becoming commonplace, we wanted to investigate their best practices; what makes them tick. Scott Apeland oversees developer relations at Intel and has recently launched a whole new developer program aimed at encouraging developers to build new products with their artificial intelligence and machine learning tools. We spoke to Scott about how he identified which developers to target and how he is tracking the effectiveness of their developer program. Intel hosts one of the largest developer programs in the world, with over 20 million active developers visiting their platform and making use of their APIs in projects and products. With a central focus on developers as customers, Intel has been able to introduce more commonly understood metrics to measure customer satisfaction. One of these metrics is the Net Promoter Score (NPS), which asks: “How likely is it that you would recommend Intel Developer Zone to a friend or colleague?” Intel survey their developers every three months and aggregate the responses. Developers rate their likelihood to recommend out of 10 Intel conducts the NPS surveys via monthly emails, anonymous feedback, through their Innovators and Managers Programs, and at roadshows and workshops. In the first half of 2016, Intel received over 2,500 responses and 2,600 comments on developers experience with Intel. Measuring their results by business unit and overall, Intel has recorded a jump from an average NPS score of 19.5 in 2015 to 27 in 2016. The Internet of Things and Robotics developer tools jumped the greatest in terms of improvements in developer satisfaction during this time, while other developer programs such as mobile app development and 3D cameras also increased levels of developer satisfaction. VisionMobile: How do you first identify which developers need to be targeted in a developer program? Scott Apeland: Because Intel’s developer program is one of the most diverse and broadest, it is growing quickly. We had 16 million developers in 2015, and now we have reached 20 million in the Intel Developer Zone. This means we have to be really good at understanding different types of developer needs. So we profile the developers in each audience segment and then create developer personas. We also use VisionMobile’s developer segmentation model to understand the different motivations of each segment and that’s very helpful for us too. For example, in our data center developer program, we are working with HPC (High Performance Computing) developers with advanced C++ skills. They are really proficient at optimizing software to get the most out of the hardware. These developers are trying to get the most performance they can through techniques such as parallelization and vectorization. We help them by providing have the tools, training and support at the right level for these advanced developers who have years of experience. But also in the data center program, we have developers who are trying to take advantage of brand new tech like network function virtualization. These developers need a different set of tools, and have different partners in the ecosystem and skillsets to deal with. That’s just in the data center world. In the laptop space, we have a game developer program where we are helping devs take advantage of the latest platforms and create new experiences with 3D graphics, virtual reality, and 3D video. This is a whole different type of developer. And in the IoT space, you are often dealing with a “maker” looking at what problems they can solve using a combination of h/w and software together in a new innovative way. They are more likely to be individuals innovating by themselves but value sharing their knowledge and expertise in a community. VM: How do you align building a developer program with overall business goals? SA: Each business unit comes to us with their objective. For example, in the data center business unit, they have an objective to accelerate the growth of artificial intelligence (AI) and machine  learning technology. To achieve this we must have the developer community on board and partner with them on delivering open source frameworks and tools. So we just rolled out our AI developer program on November 17. The program was front and center in Intel’s announcement and is focused on upstreaming tools, technology and training, making them available to all types of developers. We’ve been working with the developer community for many years but each time we put together a new initiative we start by interviewing real developers and software experts both inside and outside of Intel. Internally we spoke with developers optimizing the AI frameworks and creating the software tools. Externally we spoke with the top developers in our black belt program. We have a close relationship with them and can discuss what’s important to them and how to make them successful. They provided us with valuable insight to refine the program and focus it squarely on real developer needs. At AI day we rolled out a new AI Developer Zone with frameworks, tools, tutorials, videos, sample code, a partnership with Coursera, a contest with Kaggle to solve early detection of cancer, and a brand new student developer program. Academia plays an important role in advancing AI, so we put a strong focus on that as well. All of those elements came together and culminated in our entrance to the market. VM: How do you measure the success of your developer program? SA: We use a number of metrics, including the number of developers using our technology and the impact their applications have in the market. But one of the most important success metrics is developer satisfaction because without that we can not maintain developer mindshare and support long term.  To measure satisfaction we use the Net Promoter Score (NPS). It gives us a top level benchmark: would developers recommend us to their colleagues? It is an indicator that management can use to assess how we are doing in general. In addition to this score, what is even more valuable is the comments we get back from the survey. We get thousands of comments back (2,656 last quarter) around how we can improve things and that’s where we hear about the need for more additional tutorials and code samples, for example, or how the forums are tough to use online. We get continued feedback so we can really make this work for the developer side. What I do is I make the NPS a top level goal in our division. The goal is to improve our score year over year, and every quarter, my staff will review our NPS results. Everyone will read all the comments and then we get together and decide on common themes that are emerging. For example, we may notice the need for more tutorials in Chinese or that a particular developer tool is difficult to use, and we take that feedback and we form an action team. That team is empowered to dive in and address the issue. The team includes a dev evangelist, a content author, a community manager, a web experience expert and a geo-rep for global input. They go and look at each comment in greater detail and put together a plan to improve that area. Then the team reports back every couple of weeks on their progress. Since we’ve started this approach we’ve been able to move the needle on NPS with a jump from 1.6 two year ago when we started to 27 today – you don’t see that kind of jump in the NPS world. NPS has really helped us in driving a customer-centric culture in our organization.. For any business opening up APIs to external developers, it is possible to measure the number of visits to the developer portal page or the number of developers requesting an API key. But in the same way that ‘likes’ in social media are often just a vanity metric, developer portal visits and API signups tell you very little about whether a developer program is successful or not. Intel have found that by using the Net Promoter Score, they can engage regularly with their developers as first-class customers and support them to become champions of Intel’s products. It is not just a satisfaction metric that Intel have introduced, it is a key customer engagement strategy. They use the NPS and associated feedback as a continuous improvement mechanism to identify what developer resources they can next create and how to respond to new developer needs. The proof is in the results: each year, more and more developers are comfortable with recommending Intel to their colleagues. Do you have best practices you ‘d like to share from your developer program? Drop us a line here: hello@visionmobile.com. Disclaimer: Intel is a customer of VisionMobile, but there was no financial motivation behind this article.

When devs create apps, it feels like that is the project. But once an app is built and released on an app store, it becomes obvious: creating the app was just the start of the journey. Developers are makers. They solve pains, entertain, enlighten, and enhance productivity. Building an app can be an exhilarating experience and the joys of shipping can linger for… about ten seconds. Then comes the question, “I’ve built an app, now what?” Now comes the really exciting (and scary) stuff: getting that app in front of users who will find it useful, and making sure they keep coming back to your app on a regular basis. Building strategies for user acquisition and retention are the two major tasks for dev teams after they have built an app. Acquisition  is really about marketing (app store optimisation, paid & organic acquisition) and user retention is about marketing and the product working together (user experience, re-engagement and performance). Analytics helps understand exactly what is happening and how to keep building traction. From there, new possibilities can emerge that will help you grow your user community even stronger and help you identify novel ideas that may offer you a winning edge. Check out this  infographic based on on VisionMobile’s series of articles by Mark Boyd on:  User Acquisition , User Retention and Growth Analytics. #mobileapps #acquisition #engagement #retention #userexperience #analytics #churn #performance

My most fun job ever was as a C++ developer. Ok, I don’t have much grey hair yet, but I fondly remember the late 90s and the challenges of writing a background synchronisation application on a Compaq iPaq. And reverse engineering Mozilla’s Navigator into an XSLT parser. My second most fun job ever has been building a company that helps the world understand developers, with research. We’ve come a long way – and a few pivots – from surveying the pulse of 400 developers in 2009 to 30,000 developers annually in 2016. That’s a lot of data – in fact more than our analyst team can chew. It’s a privilege to be working with some of the biggest names in tech – I ‘ve learned a lot the past 2 years. Earlier this month, Amazon, Microsoft, Facebook, Adobe, Intel, Oracle and many more joined our first Future Developer Summit, and shared some of their best practices in how they work with developers. I ‘d like to share some the learnings here. Return on Developer Investment. You would think that with billions of dollars spent every year on building tools for developers, running hackathons, loyalty programs, tutorials and how-tos, evangelist and MVP programs – the platform leaders would have figured it all out. Yet, with so much money being spent on developer tools and marketing there is no standard for measuring the Return on Developer Investment. Most companies represented at the Future Developer Summit shared how they measure success. At their inception, developer-facing orgs measure success by number of developers touched – but that’s a meaningless metric, a dinosaur from the age of print marketing. Some platforms are using NPS (net promoter score), polling their active developers once a year for how likely they are to recommend the platform. Many are informing product decisions based on developer comments (“will you ever fix that”?) – you’ll be surprised how many decisions are taken based on “the devs that I spoke to said..”. Other developer relations teams are measuring success through the number of apps in the store, and the number of apps using signature APIs. In the case of open source projects, a popular metric is GitHub stars, forks and commits over time. The more sophisticated platforms track the Return on Developer Investment funnel from SDK downloads to app download and use. But there isn’t a consistent way to measure how the investments in hackathons, tutorials, how-tos, loaner devices, evangelism programs and some many more developer-facing activities are paying off for the likes of Google, Amazon and Facebook. Quality of apps, not quantity. Another theme of the Future Developer Summit was the need for quality, not quantity of applications at the start of an ecosystem. B2B ecosystems like Slack and Intuit prioritise quality; Poorly written messaging apps can damage not just the perception of Slack, but also the perception of chatbots in general. Similarly, a poorly written app for the QuickBooks platform can wreak havoc to sensitive financial data for thousands of small businesses. As a result both Slack and Intuit have very stringent app review processes, including weeks of testing, usability and security reviews. To improve quality for bots, Slack has pioneered a “Botness” program, bringing together bot platforms and leading bot developers; the aim is to “make bots suck less” i.e. improve the bot user experience and avert a long-term damage to the reputation of chat bots. There are already 250 members signed up and the next event is on November 4 in NYC . The next Future Developer Summit will focus on best practices for developer relations. If you ‘d like to be part of the invite-only audience of platform leaders, register your interest at www.futuredeveloper.io #amazon #oracle #chatbots #developerprograms #developerresearch #slack #intel #facebook #quickbooks #Adobe #microsoft #intuit

Platform as a Service (PaaS) tools are an important part of the modern developer’s arsenal. They provide a complete environment for building and delivering applications: taking care of both the underlying infrastructure (like hosting servers, compute and storage engines, and security) and the development tools, databases, frameworks needed to build mobile, web and enterprise apps. In the 11th edition of the Developer Economics survey (for Q3 2016), cloud developers across the globe were asked which cloud platforms they use, and to rate the importance of features like ease and speed of development, security, flexibility, learning curve, and support/documentation. Based on these responses, Developer Economics calculated an overall satisfaction score per solution that truly reflects which cloud providers are delivering the services that developers care about, and which are focusing their efforts in the wrong place. This has now been compiled into the Cloud PaaS Developer Satisfaction Tracker. The survey covered the major Public Cloud PaaS options: AWS Elastic BeanStalk Google App Engine Heroku IBM Cloud Platform MS Azure App Services Oracle Cloud Platform Red Hat OpenShift. Which Developer Segments are Using PaaS? Developer segments making use of PaaS tools include: Explorers experimenting with new ideas who want to quickly build proof of concept applications, Product Extenders looking at better managing their product range while reducing their overheads on infrastructure management, and Corporate Guns for Hire and Hunter developers who are using Cloud PaaS to work with enterprise clients and build commercial apps to enter new markets quickly. How each developer segment uses PaaS, and their thoughts on the direction PaaS tools must take, varies according to their goals and objectives. We spoke with three developers: an explorer, a product extender and a gun-for-hire about how they use PaaS tools. Developer Explorers using PaaS By day, Jack Skinner works as API Evangelist with the MYOB software company where he supports over 4,000 developer partners to build integrated solutions. On weekends, he attends hackathon and maker events. So he often needs to quickly create proof of concept ideas from scratch and uses PaaS tools as a complete creation and pilot deployment environment. “When I look at PaaS vendors, I’m looking at the simplest possible solution to launching an app,” said Skinner. “This lets me focus on building the next greatest API demo or side project rather than focus on the underlying infrastructure management.” Skinner said that there is still some difficulty in choosing which PaaS to use, as there is rarely a feature list that compares the different options side-by-side. “I have more experience working with Heroku,” he said. “I find the tutorials documentation really smooth and their social response has been really great: I have tweeted questions and gotten immediate replies, and that for me is definitely one of the deciding factors: Can I experiment and get feedback quickly?” Skinner offered some advice to developers starting in Cloud PaaS environments. He recommended that developers follow the 12-factor app mindset for building apps. Eventually, if an app is successful, it will grow to a point where developers need to scale components of their app and might choose to take them off the PaaS and into their own infrastructure environment. By using the 12- factor process, apps will be built from the outset in a more composable form that lends itself to having some components taken out and moved around without destroying the data flow or services. Skinner also suggests developers alter sample code to reduce vendor lock-in. “To a certain extent, with any level of tech, there is always some level of vendor buy-in: the language framework, the toolkits or the underlying services. But you can create environment-independent code. For example, in naming conventions around environmental variables, you could use app_n rather than heroku_n so that your dependencies are not hardcoded.” To sum up, Skinner suggested: “When building for PaaS, I’m generally looking to: Isolate dependencies so that there’s minimal vendor lock in Detect features rather than hard coded dependencies, and Automate, visualise and have pipelines for deployments.” Skinner admitted that any developer on a growth trajectory will at some point need to accept that they may need to pick up their app and move it into a different  PaaS environment, or into their own infrastructure. “To have the vision that you will be able to pick up your app and move it is a bit idealistic. There will always be work to do to change your infrastructure, your libraries, there is always some kind of overhead,” he confirmed. Product Extenders using PaaS Alex MacCaw, CEO of Clearbit, a software service that offers market intelligence based on contact emails and business domains, says that the PaaS market is quickly maturing so some of Jack Skinner’s limitations around using PaaS are already changing. “Traditionally that has been the case that PaaS is best for proof of concept and experimentation,” confirmed MacCaw. “But there are some very interesting developments happening that will let you have a production-grade PaaS and host it yourself.” One of Skinner’s concerns is that as an app grows beyond the initial prototype, and starts to gain users, PaaS has difficulties scaling up which is when devs need to take certain app components out of the PaaS environment and into their own infrastructure. MacCaw says that PaaS gives developers the freedom to focus on their app without worrying about the infrastructure and DevOps management, and as they grow, newer PaaS tools are becoming flexible enough to allow a deeper dive into the DevOps working of their apps. He pointed to the open source project Deis as the type of new generation Cloud PaaS that is most promising. MacCaw says when looking for a PaaS, it is important to choose one that can work with the top three hosting environments: Google, Amazon and Microsoft. He encourages devs to consider PaaS not just for prototyping but for running their apps and websites in production: “You will ultimately need a sysadmin but hopefully this means you can put it off for longer and will need less in the long term,” he said. Guns for Hire and Hunters Using PaaS Saul Caganoff is Principal of Platform Engineering at Deloitte Consulting where he works with enterprise clients to implement technology platforms, including helping them make use of Cloud PaaS solutions. “Many organizations are looking to become their own platforms. They recognise the benefits that a platform can give in terms of rapid iteration and innovation, plus reduced costs through shared infrastructure. But developing the platform requires significant up-front planning and design. We use a PaaS approach in delivering these capabilities since those technologies provide high levels of automation and take care of many of the challenges of distributed systems,” said Caganoff. He clarified that for many corporate clients, they are looking for private PaaS solutions rather than the public offerings like Heroku and Google AppEngine, as enterprise often want to make use of the data in their legacy systems, which means running PaaS behind the firewall. He does recognise the benefits of Cloud PaaS: “The great thing about using Heroku, for example, is you write just the code for your app and you get all the autoscaling and availability out of the box. The problem with public cloud PaaS is that they can be very isolated. For developers working in an enterprise innovation lab, you can do the app in Heroku but most people want to leverage off their existing assets. For example, in a bank you want to create apps that use banking transaction data and core banking services. They need to be able to get the velocity that comes with PaaS but leverage their existing assets. That requires either an on-premise PaaS, or some standard AWS-type infrastructure.” Caganoff suggests that smaller developer teams, who may be looking to build for enterprise clients in future, look to use a PaaS that offers both public cloud and private on-premise editions (like RedHat’s OpenShift). This will let the developers become proficient on the public PaaS solution while also building their enterprise skill-set. What PaaS Are Developers Choosing? Given the diversity of reasons why developers are using PaaS, the best solution is rarely obvious. Overall, technical support, ease-of-use and availability of developer tools were often more important than price for developers choosing a PaaS solution, but the logic behind the decisions isn’t always so easily identified. For a comprehensive look at what developers care about, and where that is taking them, see our Cloud PaaS Developer Satisfaction Tracker. What is the Developer Satisfaction Tracker? The Developer Satisfaction Tracker is a research service exploring when and why developers choose competitor products over yours – and how to fix that. Our data proves you are the leader or helps you become one. We survey 30,000+ developers annually, including your competitors’ developers, to analyze and measure their experience across competitive products. This is not just an analyst assessment of software products, it’s the real developer experience. The Tracker helps SDK, API and platform vendors to better understand when and why developers choose competitor products or services over theirs – and how to fix that.Our research service tracks the developer experience across 10s of developer products, and measures 8 key quantitative and qualitative indicators of that experience. #clouddevelopers #paas #tools #cloud #cloudsolutions #paastools

The Map of the Developer Universe charts developer usage of and satisfaction with leading platforms and tools. This is not just an assessment of software products. It is the real developer experience based on hard data from 30,000+ developers surveyed annually. Check out how developers’ perception of products place them on the market map and improve your product positioning against competition. The Map addresses the following questions: Which solutions in each sector are developers most satisfied with? Which solutions in each sector  are the most and which the least popular among developers? Which are the upcoming solutions in each sector challenging the leading ones? At a high-level, what are the key reasons behind the shown mapping of solutions? #iaas #paas #tools #platforms #softwaresolutios #cloudsolutions

Chatbots and conversational UI are among the most hyped technologies of 2016. Chatbots are computer programs that can maintain automated text conversations with users through use of artificial intelligence and natural language processing. Early excitement about chatbots has given way to the realization that many challenges remain in both technology and understanding of what users are looking for when chatting with computers. In the words of Fred Wilson, a prominent venture capitalist who invested in Kik, a popular messaging platform: “New user behaviors take time to develop and sometimes require a breakthrough app to get things started. That’s where we are with chatbots. The hype phase is over and we are now into the figuring it out phase. That’s usually when interesting stuff starts to happen.” According to Comscore, smartphone apps now account for half the time Americans spend online. At the same time, the mobile app market has become saturated. It is extremely difficult and expensive right now to succeed with a consumer focused mobile app. The mobile app gold rush is over for all but large deep-pocket publishers. Mobile app developers are looking for the next big thing. While many challenges remain, chatbots promise to create a new channel for reaching mobile users alongside mobile apps. That’s why there is no shortage of entrepreneurs and developers taking their shots at “figuring it out” with chatbots. All popular messaging services, including Facebook Messenger, WhatsApp, Skype, Telegram, Slack and Kik, are opening their platforms to innovation by 3rd party developers. In July 2016 Microsoft announced that 30,000 developers have signed up for the Microsoft Bot Framework. In the same month Facebook reported that developers created 11,000 bots for its Facebook Messenger platform. In August 2016 Kik, a smaller messaging app popular with teens in North America, reported that more than 20,000 bots have been built for Kik, and Kik users have exchanged almost 2 billion messages with chatbots since the company has opened its app to developers. The chatbot group on Facebook has close to 13,000 members, and a new chatbot is being announced almost every day. The outcomes of the “figuring it out” phase in chatbots will be decided by developers. This is why we included questions about chatbot development in our 11th Developer Economics survey. 8,464 developers answered questions about chatbots and we published full results in the Chatbot Developer Landscape 2016 report. The data shows that the efforts of Facebook, Microsoft and Slack to promote chatbot development achieved early results. An absolute majority of developers worldwide are aware of the opportunities in chatbots. At the same time, the chatbot ecosystem is still in its early stages and lots of work remains to attract masses of developers to the chatbot idea. Less than quarter of developers who are aware of chatbots are convinced of the chatbot appeal. It’s notable that Apple and Google, the undisputed leaders of the mobile app world, fell far behind Facebook, Microsoft, and even smaller messaging apps in seizing the chatbot opportunity. Facebook is the undisputed global leader in developer mindshare with over 40% of developers interested in developing for the Facebook Messenger platform. If you’d like to know more about what developers think about chatbots, take a look at our Chatbot Developer Landscape 2016 report, which answers the following questions: What does the chatbot landscape look like? How popular is the idea of chatbots with developers? How mature is the chatbot developer ecosystem? Which developers are more attracted to the chatbot promise? Which messaging platforms are popular with chatbot developers? #aichatbots #artificialintelligence #chatbots

More than half of mobile developers are living in “app poverty”: making less than $500 a month from their apps. We’ve produced an infographic which looks at insights such as this from The Evolving State of Mobile Commerce, a report published by VisionMobile in collaboration with Braintree. Here are some more of the insights that are featured in the infographic: Half of M-commerce developers are using the App store Operators are still bankers in the Middle East and Africa Bitcoin is bigger in the Americas This is just a small sample of the insights contained in the report, if you’d like to know more, then take a look at The Evolving State of Mobile Commerce report. #mobileapps #mobilepayments #mobiledeveloper #mcommerce #mobilecommerce

In 2003 Europe’s mobile operators launched Simpay, promising to let us buy flowers and concert tickets across Europe, with the price added to our mobile phone bill. By 2005 that had morphed into PayForIt, for UK operators only but with similar aspirations, and a similar lack of success. A decade later, mobile network operators are still being cut out of the payment loop, but not for lack of trying. Operator billing should be the perfect m-commerce platform: Mobile operators store prepaid credit for 77% of their customers, according to the GSMA, and have credit agreements with the other 23%. They have experience dealing with critical systems, and real-time credit checking systems built to take huge loading, so they should be the obvious winners in the m-commerce business. As then-CEO of Vodafone Arun Sarin told the FT in 2007: “The simple fact that we have the customer and billing relationship is a hugely powerful thing that nobody can take away from us … Whoever comes into the marketplace is going to have to work through us.” Only they didn’t, and they don’t, and these days operator billing is a minority pastime everywhere – except Africa and the Middle East. The data comes from the VisionMobile Developer Economics survey, which reached more than 11,000 mobile developers at the start of 2016. Almost 2,000 of those developers are involved in m-commerce, but only 16% of those have integrated operator billing into their applications. In Europe, where operators have perhaps tried the hardest to become the wallet of the future, that number drops to 12%, and in North America only 8% of m-commerce developers have bothered to work with the operator to handle billing. In 2010 Verizon launched its own payment service, based on the BilltoMobile platform, but BilltoMobile has been losing money ever since, and in May this year was purchased by UK payment processor Bango. The argument against operator billing has always been that of interoperability – developers integrating with one mobile operator’s billing system would have to port their code to support another. That was the problem that Simpay, and PayforIt, were designed to solve, and they are far from alone in solving that. The GSMA’a OneAPI started out as platform for interfacing with SMS Centres and network call management, but quickly focused into a cross-operator billing system to attract operators who proved reluctant to spend money implementing the whole standard. Even GSMA’s decision to host a OneAPI proxy (making it much easier for operators to integrate) wasn’t enough for the operators, and the standard now languishes as a vertical API within a handful of network operators. In May 2016 yet another attempt was made, with nine of the largest mobile operators joining up to endorse the “Open API” from the TM Forum (an industry body with a decent history of setting architectural standards in infrastructure). This latest set of APIs covers a very wide remit, but includes much that the OneAPI set out to achieve including the resolution of billing events. Other cross-operator alternatives, such as Telefónica’s BlueVia, have achieved some level of success, but it is probably too late for mobile operators to become the default billing platform they imagined that they would be. Only in the Middle East and Africa is mobile operator billing being used by a significant proportion of m-commerce developers; everywhere else that role is being filled by other players. Just as Apple and Google provided operator-independent app stores, those companies provide the perfect alternative for developers looking to collect money. Billing through the app store itself, or via the electronic wallets run by Apple and Google, is increasingly popular – and both companies have extended the functionality in recent months. Credit cards also remain popular. Most credit card processing is done via third-party companies, such as Braintree and Stripe, who compete to provide the best APIs and value-added services. Meanwhile various banking consortia are jumping into the frame, and Visa and MasterCard are funding various competitions intended to raise the profile of their own developer programs, and demonstrate their utility beyond basic transaction processing. With such strong competition in place the opportunity for operators to step in and take the market is long gone, and developers won’t be easily wooed away from third-party providers. With a coordinated approach the operators certainly could have grabbed the market, but arrogance, lethargy – and the fear of creating an illegal cartel – prevented that future from happening. The world of mobile commerce is evolving fast, and is only going to become more important as it grows and changes so rapidly, but mobile network operators will struggle to be more than a big player in it. If you’d like to know more about which m-commerce platforms are gaining ground, or what developers are looking for in an m-commerce platform, then take a look at The evolving state of mobile commerce, a report published by VisionMobile in collaboration with Braintree. #mobileapps #mobilepayments #mcommerce #mobiledeveloper #mobilecommerce

The mobile platform landscape was fairly stable for more than two years. Having both won the platform wars, Android and iOS seemed quite settled into their market positions. Android selling the most units in every market, but with iOS taking a dominant share of the lucrative high-end. Similarly, Android’s greater developer mindshare was always counterbalanced by iOS developers making the most revenue, and iOS being the primary platform for more full-time professionals. In the last six months we’ve seen a very significant shift on that last point. Apple will now have to work extremely hard in the next few years to avoid giving up further ground. Why developers are prioritising Android Towards the end of 2013, Steve Cheney wrote a very widely-read post on Why Android First is a Myth. We wrote a response at the time highlighting the strong silicon valley bias that made the conclusions doubtful, but also confirming with our data that, at least, professional developers were quite heavily prioritising iOS. In 2014 we heard that Android first was a fallacy – the user base might be there but fragmentation, plus inferior documentation and tooling, would make it a poor trade-off for many. In 2015 debate on the topic continued while our data showed Android gradually winning the priority of professional developers from other platforms, but not iOS. We entered 2016 with Android marginally ahead: 40% of professional developers globally prioritised the platform versus 39% for iOS. That seems to have been a tipping point, with our latest survey showing a large shift from iOS to Android. A massive 47% of mobile developers now tell us they consider Android most important, while preference for iOS has slipped to 31%. The reasons for this shift are many but related. The fastest growing regions in terms of mobile developers are those dominated by Android already. New mobile developers are increasingly choosing Android first in all regions. Existing developers are shifting their priority to Android because the types of app they build are changing. We’ve been highlighting for some time that the app economy is shifting away from direct monetisation of apps, to using apps as a channel for some other business. Mobile commerce is by far the largest and fastest growing (at least in terms of total revenues) part of the app economy. Demographics still matter – users of iOS spend more on real-world goods and services through each device than Android users. However, unlike with downloads and in-app purchases, the difference is nowhere near enough to make up for Android’s larger user base. Leveling of the playing field For startups trying to find product-market fit, and enterprises needing to deploy across multiple platforms, a key reason to build on iOS first has been the ability to get to market faster. Android had more relaxed deployment policies and much faster publishing cycles, but it was was easier to develop higher quality apps for iOS. The most critical area in this regard has been the UI. Historically iOS had a few fixed resolutions and higher quality APIs for UI development. Android had a vast array of screen resolutions and aspect ratios, and fairly basic abstractions for dealing with that complexity. However, with the launch of the iPhone 6 and 6 plus in 2014, along with split screen mode for iPads in 2015, Apple has forced iOS developers down a scalable UI path as well. Once the UI of an app has to adapt to multiple resolutions dynamically, the complexity isn’t significantly increased by having to work with many more resolutions (maybe in testing but not in development). So iOS development has become harder, whilst Android has had time to mature their UI APIs, providing support libraries to reduce fragmentation across operating system versions. The other area where a major Apple advantage has been eroded is in the design of app interfaces. Both Apple and Google moved towards a flatter and more minimalist style, which shifts the emphasis towards animation as the way to both give an interface personality and help users to understand it. Apple’s approach has been to show rather than tell, and leave artists to create, while Google has provided extensive guidance to developers on how to implement their Material Design. The latter has been favoured by many developers that don’t want completely custom UIs deciding to design for Android and adapt that for iOS, where the reverse was previously the case. Apple isn’t doomed just yet It’s important to note that mindshare for iOS is still within the range it has occupied for the last few years at 52%. Developers are not abandoning the platform. Shifting developer priorities towards Android are quite a long-leading indicator for device sales, and Apple are already making big moves to counter this trend. Swift is a boost to iOS developer productivity. Cutting app review times increases iteration speed. Apple Pay on the web gives iOS a greater advantage in the booming mobile commerce market. The danger for Apple is if Android first becomes firmly established as the new normal. If some of the best apps and services come out on Android first then some of the early adopters will start to migrate. Where the early adopter user base goes, other users and the cool startups will follow. Without an app ecosystem advantage, Apple would become almost entirely dependent on hardware differentiation to maintain a price premium. This battle is far from over but Apple will be working a lot harder to keep developers focused on iOS than they have in the past. The tip of the iceberg We’ve just taken a deep dive into one interesting trend in the mobile developer ecosystem, there’s more going on with the mobile browser and Windows 10 too. We also have the latest trends from desktop, cloud and IoT, as well as new insights into augmented and virtual reality, plus data science and machine learning. Our State of the Developer Nation Q3 2016 report is filled with interesting trends as seen by 16,500+ developers across 145 countries. Get it here #Android #appdevelopers #developer #developereconomics

Advertising is used as a revenue stream by 38% of mobile app developers, far higher than any other source, but the majority of developers chasing the advertising dollar aren’t making much money, so what kind of developer persists in embedding adverts when the real money is elsewhere? At VisionMobile we ask developers about every aspect of their work, the tools they use, the languages they work with, and (most importantly) what they hope to achieve by developing mobile applications. That last question is used to divide the developer community into eight segments, reflecting the motivation behind their efforts. We know that across the mobile community 38% of developers are using advertising, compared to 21% who are still making money from downloads and 19% who are looking for subscription revenue. That 38% has remained pretty static over the last few years – at the start of 2015 it was 36% (see State of the Developer Nation Q1 2015) despite the lack of revenue generated (see State of the Developer Nation Q1 2016 for more details). The simplicity and scalability of advertising is irresistible to cash-strapped developers. But when we break down the numbers by developer segment some more interesting patterns emerge. More than half of Hunters, for example, are using advertising as a revenue stream, the largest of any segment. Hunters are making money from their applications, but are always on the lookout for new opportunities or sources of revenue. As a result, they are the largest users of pay-per-download and in-app purchasing, as well as advertising. Almost a third of Hunters are using each of those business models, and more than 20% are using subscriptions too. Hunters are clearly prepared to make money any way they can, and have harnessed multiple business models to make their product viable, but the segment also reflects an industry trend towards harnessing more than one revenue stream. The first wave of mobile applications were largely pay to download – users were asked for a few dollars which was collected by the application store. That resulted in race to the bottom, as cheaper applications supplanted higher-quality rivals, and the cost of developing a mobile app quickly become untenable. The solution was advertising, embedded in the app as it ran or sponsoring content within the app, to cover the cost of development. That worked for a while, but as the industry grew in size the advertising revenue was spread more thinly. In-app purchasing is another alternative, and now a foundation of most games and many other mobile applications too. Freemium models, where a basic version of an app is free, but users pay to remove adverts or add features (or both) have become increasing popular. Developers aren’t pinning their hopes on one revenue model any more, they are taking money however they can. Digital Content Publishers are almost as polyamorous as Hunters in their exploitation of different revenue streams; subscriptions are obviously very important to them, 27% citing subscriptions as a revenue stream, but Advertising is even more significant with 34% mentioning it. There are really two groups of developers who use advertising as a revenue source – those looking for simplicity and scalability as they dream of being the next big thing, and those who have added advertising as an additional revenue stream to top up their income. The developer of Flappy Bird didn’t expect to make much more than pocket money when he released his childishly-simple (but challenging) game into the app stores, but (almost a year later) an unexpected surge in popularity was generating $50,000 a day for the developer. The scalability and simplicity makes advertising attractive, but very few developers manage to emulate that level of success. For the second group, advertising is more viable – the only risk is a possible alienation of users, but that can be alleviated by offering a “premium” version for those who choose to pay. For many developers the income from advertising can form part of a revenue mix which combines to form a sustainable business. Advertising isn’t the fairy dust it once was – giving up 10% of a mobile screen isn’t the route to riches – but neither can it be ignored as part of the mobile revenue mix, as it has become for many developers. To gain more insights into how mobile developers can be understood through segmentation take a look at Mobile Developer Segmentation 2016, available from VisionMobile. #developersegmentation #mobileapp #mobiledeveloper #segmentation

Despite all the hype around the death of the PC and the enormous amount of media attention focused on mobile, cloud and IoT, the humble desktop is still the biggest part of the developer economy. There are more professional developers working on desktop applications than any other sector. There’s also more revenue in desktop development. It’s understandable that the media focuses on the exciting growth areas and no-one is arguing that the desktop is likely to make a major comeback. However, while there are still significant quantities of both users and revenue on the desktop there will be developers creating new software for it. While those developers are still adding enough value for the users, the users will stick around. Will those developers still building for the desktop stay loyal to their platforms, or be tempted away into exciting new growth areas? The answer will depend on individual developers’ goals and motivations. There being enough money to pay developer salaries, in any area, is obviously a very important factor. Even in gaming, where mobile revenue has grown at an astonishing rate in recent years, the desktop still accounts for more than a quarter of revenues. In the enterprise software market, which dwarfs gaming at well over $300 billion annually, desktops still account for the majority of the revenue, with cloud-based software and services gaining fast. Then we have e-Commerce, which in total is likely to approach $2 trillion this year. Mobile devices are rapidly eating into and expanding this market but they’re still only just over 30% of transactions and closer to 20% of revenue. However, although this looks healthy for the desktop currently, the growth trajectories will encourage a lot of developers to move towards mobile or cloud services development in medium term. Even so, our research says that money is not the most important thing for desktop developers. Individual developer goals, motivations, and success metrics vary significantly and some do put revenues first. Many more developers measure their success by the knowledge gained, or users reached, ahead of revenue or cost savings. Opportunities to learn and reach users should remain plentiful on the desktop for some time. Steve Jobs made a great analogy as he predicted the beginning of the post-PC era: “I’m trying to think of a good analogy. When we were an agrarian nation, all cars were trucks. But as people moved more towards urban centers, people started to get into cars. I think PCs are going to be like trucks. Less people will need them.” The desktop PC isn’t going away any time soon and the enormous developer economy based around it isn’t either. Although there are far more cars than trucks today, the trucking industry is still worth hundreds of billions of dollars. Also, new technologies may reach serious commercial scale on trucks before cars. Autonomous trucks platooning are likely to be widely deployed long before consumer transport in autonomous cars. The economics of electric vehicles also makes even more sense for trucks than it does for cars. Similarly, although Virtual Reality (VR) will probably go truly mass market via mobile devices, the early market is likely to be dominated by PC-based VR systems. Developers wanting to push forward the latest cloud technologies in the enterprise will find their audiences demand desktop (at least web) clients on the front-end, with mobile currently more of a bonus than an absolute must-have feature in many cases. Anyone interested in the ongoing survival and health of the desktop platform needs to understand the developers that are building for it and why they do so. Those that want to tempt developers away from the largest ecosystem to exciting new ones also need to understand what motivates those developers. VisionMobile’s latest Desktop Developer Segmentation 2016 report applies our proven segmentation model to the world’s largest developer talent pool. The report is based on data from our 10th edition Developer Economics survey, which ran in October-­November 2015 and reached more than 17,000 desktop developers in over 150 countries, of which over 2,500 answered detailed questions on their desktop development work. We use this data to generate a wealth of insights about desktop developers: What drives them? What else are they working on? What languages, platforms, and tools do they use? What categories of application do they build and how much money do they make? #desktop #segmentation #developer #developermarketing #developertargeting #developersegmentation

Not all developers are the same, and their needs vary wildly, so any attempt to effectively address them all with a single messaging and outreach strategy is doomed to fail. At the same time it would be impractical to have one strategy per developer, so a more intelligent approach is needed. What if you could identify a handful of developer personas, or segments, each with a very distinct set of needs and interests? What if on top of that set of developer personas you also had some guidance as to how to address each one of them, what to include in your outreach campaigns targeted at them in order to make them more effective? Our new IoT Segmentation report provides exactly that. Building on our proven segmentation model it sheds light to the IoT developer personas, their needs, and the message most suited for them. As such, it presents you with a valuable developer marketing tool of proven effectiveness. Taking a deep-dive into the segmentation model the report is an indispensable tool for those who wish to: Optimize the value proposition of their developer product Identify the type of developer they are best positioned to be targeting Fine-tune their messaging and outreach strategy, so that it resonates with the developer segments of interest. We know, from the data presented in the report , that 63% of IoT developers are fun-loving Hobbyists or Explorers, but they aren’t the only segment more interested in gaining knowledge and experience than making money, and reaching out to that audience requires a specialist approach. To further illustrate our segmentation model we have prepared a very detailed infographic presenting the 8 different IoT segments that are formed based on the goals that determine developer choices , namely : Self-improvement, Direct Revenues and Improving an existing business.

But today, I want to talk not so much about Alexa’s merits as such, but use it as a metaphor for the IoT developer community. IoT developers, too, are in the process of gaining a proverbial 1,000 skills, and are growing fast to become the centerpiece of the IoT economy. Like Alexa, the IoT developer community is seeing impressive early traction. The number of IoT developers is clocking in at over 5 million, and growing at almost a million developers per year. This said, both Alexa and the IoT community are still in the early stages, searching for their place in the world. In Alexa’s case, most recent reviews of the device still focus on: “what can I do with this thing?” Is it a speaker? Is it another Siri? The Skills store is still in its infancy, with little curation or discoverability. IoT developers, on their end, are still discovering what they can do with this flood of new IoT technology coming their way. VisionMobile’s IoT developer segmentation model groups developers in eight segments based on their key motivations to do IoT. A whopping 63% of IoT developers are either Hobbyists, developing for fun, or Explorers, learning the technology to put themselves in a good position to capture future opportunities. That percentage is much higher in IoT than in other sectors, like mobile or cloud. By the way, Alexa has competition, too, in the form of Google Home, a device similar to Echo and powered by Google Now that the company announced in May, and Apple’s Siri, which it opened to developers at its WWDC event in June. The competition of such major platform players creates uncertainty about the future. The lack of clear leaders in the market is a key part of why developers are exploring – developers don’t want to commit to a platform just yet. Back to Alexa, whose Skills are exploding – there is a 7x increase in Skills supply since January. IoT developers are also working hard at improving their skill set. The most important measure of success for IoT developers is how much knowledge and experience they have gained. Learning is the main goal for Explorers, representing almost a third of the developer population. But it goes far beyond that In a sense, all segments of IoT developers – not just Explorers – are still exploring opportunities and figuring out what their personal position in this space will be. Amazon first goal is not to be a consumer electronics company. The e-commerce giant is in the habit of selling its devices at a price close to the cost of production. It gains instead from being on the first row – right in front of you – at the moment you decide you want to buy something. Likewise, most IoT developers are not in a rush to make bucketloads of money. They don’t prioritise making revenues straight away. As we said, learning is more important for a sense of success than how much money is made, how many users are reached, or how many costs are saved. On a personal level, culture and emotion play a huge role in the lives of developers; more so than business objectives. Most IoT developers are Hobbyists and Explorers, learning is a key motivator, and business success is not (yet). If you run an IoT platform, developer tool, or API, or you’re marketing to IoT developers for any other reason, these insights might be counter-intuitive for you. If you want your product and messaging to resonate with IoT developers, it must match their current state of mind. In our new IoT Developer Segmentation report, we dive much deeper into our data from 4,400 IoT developers to provide you with an effective marketing tool that describes the causal motivators that drive developer decisions. Check it out!

At this year’s Google I/O conference the search giant announced Instant Apps – Android applications dynamically downloaded, installed, and executed, with a single click. Slick functionality, certainly, but functionality which comes at the price of undermining the openness of Android as a platform. Instant Apps will be part of Google Play Services, not Android, and so alternative distributions will be left in the cold. 20 years ago Microsoft tried something very similar, and with the same justification. Microsoft failed, so it’s worth taking a moment to see why Google will probably succeed. It was 1996 when Microsoft broke out of the browser sandbox with ActiveX, a technology providing the same functionality as Instant Apps. Just like Google, Microsoft’s primary motivation was extending its control over the platform, but Google will likely succeed where Microsoft didn’t, so what’s altered since ActiveX failed to change the world? ActiveX was designed to compete with Java Applets – a technology from Sun which solved the same problem using Java. Java Applets run within a slightly-larger sandbox, designed to prevent the applet doing any damage, while permitting more functionality than a web page alone. ActiveX didn’t come with a sandbox: downloaded code runs native with all the performance, and capabilities, that implies. These days an ActiveX download requires user approval before running, but at launch the only protection was the digital signature from Microsoft. Which wasn’t enough. The public overwhelming recoiled from the idea of letting downloaded applications automatically run without a sandbox, while the Java Applet sandbox proved woefully insecure. Modern browsers (Chrome and Edge) don’t support either type of downloaded content by default, forcing companies still reliant on ActiveX to use IE or install extensions. But the concept was valid, and sandboxed content is more popular than ever. JavaScript is part of almost all web sites, and executes in a sandbox in much the same way as a Java Applet. Native applications, meanwhile, are getting more restricted as mobile platforms pioneered the idea of applications that could be trusted a bit, but not entirely. Android and iOS provide granular security, a sandbox-with-extensions. An application can ask for permission to access the camera, but won’t be allowed to make phone calls if it didn’t request the right. At first glance Instant Apps look very much like ActiveX. Digitally-signed applications will be downloaded and executed without user interaction, and will be able to access device resources which would normally sit outside the sandbox (such as the camera and NFC chip). These applications will be signed by Google, but the user will not be given a list of requested permissions, and will not have the option of rejecting them either. While it might seem that Instant Apps inherent all the downsides of ActiveX, it’s been a long time since ActiveX failed as a web technology, and much has changed. ActiveX suffered from having to support multiple operating systems, and slow download times, but Instant Apps are only on Android and when a single web page already averages more than 2MB* the additional load of a small app isn’t significant. Which brings us back to security, and why Google will do a much better job than Microsoft ever could. The fact is that Android, and other modern operating systems, are compartmentalised into sandboxes at every level, making the sandbox the default operating environment rather than an exception to the rule. Once it had been approved, and digitally signed, an ActiveX application could do anything – write to arbitrary memory addresses, interfere with data stored by other applications, rewrite the OS to act as a reproduction engine (the latter being why we call them “viruses”), enjoying a level of freedom denied to any approved application running on Android, no matter who approves it. The architecture of Android means that Instant Apps won’t rely on the certification process of Google Play. They will still run within the sandbox which surrounds all Android applications. Even more importantly – all the Instant Apps will be delivered from Google’s servers. That means a misbehaving app can be instantly removed from circulation, and Google will curate the applications to ensure none make use of permissions they don’t need. The paternal management is new. A company like Google can keep a careful eye on how Instant Apps develop, and tweak their capabilities as they go along. The permanent beta has become Agile development, and the company managing the platform has become a guiding hand which won’t let go. Instant Apps will have security issues, the Android compartmentalism isn’t perfect and there will be a few well-reported breaches, but Google will move swiftly to patch and secure the system. Alternative distribution stores, tolerated on Android, will likely be excluded from Instant Apps, and users won’t be permitted to opt out of Google’s control. Competing distributions of Android will struggle to provide similar functionality, and even if they do it won’t be compatible, bringing Android more under Google’s control. Instant Apps will provide useful functionality, just as Google has been demonstrating at its developer conference, but at the cost of locking out the competition. Instant Apps will succeed where ActiveX failed. Better compartmentalisation and centralised management will secure it, and users will appreciate it, but the real winner will be Google who squashes alternative app stores and outmanoeuvres alternative Android distributions, all in the interest of providing greater web-site functionality. * http://www.httparchive.org/interesting.php?a=All&l=Apr%201%202016 #activex #google #instantapps