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

Nike, Adidas and Under Armour have digitally opened up their fitness and athletics products. McCormick Foods and Campbells Soup have released flavor profile data. Walgreens digitized their photo printing and prescription filling order services. Philips released programmable lightbulbs. Edmunds transformed from a car classifieds site to a digital sales inventory and vehicle information service. Most recently banks like Capital One and BBVA are encouraging developers to build new products based off banking data. All of these companies are growing because they saw new opportunities in helping third party innovators extend their products by creating new software. To succeed today, businesses are transforming into platforms on which others can build new software. Competitive, forward-thinking businesses of all kinds — startups, medium-sized companies and enterprise — are all beginning to release their data and services in a programmable form in order to encourage new business partnerships. Developers are at the center of those partnerships, as they will be the ones who enable a business to extend its reach, create new products using the company’s assets and services, and open up new revenue-sharing opportunities. John Musser, VP of Tech at Basho (one of the world’s largest application database providers), serial entrepreneur and founder of ProgrammableWeb, says one of the most misunderstood terms in business today is ‘developer’. “There is such a gross generalization as to what a developer actually means,” he says. Musser stresses that for any effective business model, knowing your customer segments is vital. “Without thinking about which type of developer, where they go for information, what they do, the companies they work with, the languages they use, their skill-sets, their pain points… many a business model has floundered or failed because of inadequate developer segmentation. You are not going to go after any market without first defining some type of segmentation.” Developers are a key business customer and partner segment, as they are the external business partners who can speed up an enterprise’s digital offerings — for example, by creating mobile and wearable apps — as well as help connect an enterprise to fast rising stars like the current generation of tech platforms including Uber and Slack, and support business units to operate more efficiently by connecting processes and data internally. Musser says when a company is thinking about how to reach different developer audiences and engage with them as business partners and growth generators, it is also worth recognizing that internal developers working behind the firewall are a segment that can be approached and engaged. These developers have their own motivations and can play a major part in encouraging consistent tech design internally. They are also responsible for building automated operational processes that create time and cost efficiencies. Preparing developer personas is a methodology that aims to document the characteristics of key developer segments that are expected to be using a business’ APIs, data, or microservices to build applications or to integrate tech solutions. VisionMobile regularly conducts global surveys — now having reached over 20,000 developers — to build and validate the world’s most comprehensive developer segmentation model across mobile, cloud, desktop and IoT platforms. This data is used to produce detailed reports, such as the recent Cloud Developer Segmentation, that focus on segments working within a specific sphere, and These State of the Developer Nation Reports are global deep-dive resources that can be used by business to segment and understand developer motivations and characteristics. A business can then craft more customized segments for each category based on their own use cases that match their specific business’ growth plans. “Segmentation used to be about which technology the developer uses, or what platform they were targeting, but now we’re more concerned with what they are trying to achieve – what does the developer get out of it?” as VisionMobile’s senior analyst Bill Ray puts it. VisionMobile’s developer segmentation model helps businesses divide their developer customers/partners into groupings not based on their skill-set — such as which platform they develop on — but on their motivations and goals as a way to organize developers into key audience groupings. This can help frame how those developers are incentivized and what resources they are provided with. While there is a return on investment for development engagement activities, a business can only pursue so many market segments at any given time. Developer segmentation helps a business identify how to prioritize developer engagement resources to create a constant wave of S-curves. Depending on the business/tech cycle stage, this may first involve supporting developer Explorers and Scouts who are looking at the horizon and will be creating the next generation of products a business can market. Then, new revenue opportunities are created by harnessing Guns for Hire and Hunter devs who are building third party apps. A third wave of dev engagement then focuses on Enterprise IT and Product extenders who will use software to improve efficiency or engage customers more effectively. Kristen Womack is a consultant who works on digital strategies, and has helped several businesses document their developer personas. She gave a talk about approaches to documenting developer personas at the API Strategy and Practice conference last year. “I gravitate more to understanding the sentiment and the feeling the developer is having,” says Womack. “For example, for a lot of developers what really wows them is when something works smoothly and is a little bit clever. I try to focus on the feeling because the skills are irrelevant as more developers move between platforms,” she says. By focusing on the motivations that drive a developer, Womack says, a business has a much higher success rate of engaging effectively. Jérôme Louvel, CEO of Restlet, one of the world’s largest open source IDE platforms, says creating developer personas is a user research activity that must be carried out “like for any other agile IT project”. He suggests creating developer personas and then generating user stories around how they engage with the various resources the business provides to help them achieve their goals. Understanding their motivations is crucial for documenting user stories. But beyond that initial interaction, Louvel says that developer personas can be used to keep a developer community engaged with the business. “We see an increasing awareness of the importance of the overall developer experience, which encompasses not only initial application development, but also the operations and engagement activities on an IT project, as a whole,” says Louvel. “The key here is to personify, categorize and prioritize correctly the developers that will use your APIs, your app backend, your microservice or your integration process so that it becomes more natural to think about the experience that those developers — depending on their goals and skills — will have at various level of interaction with your solution.” Womack says that for developer personas to drive revenue and build out a successful ecosystem, the personas must be used as regularly referenced business tools. “I see most people create them and they just sit there,” Womack warns. “What I recommend is an ‘information radiators’ approach: if you put up the information you want people to absorb, there is more likelihood they will be referred to and used regularly.” Womack says she has seen developer personas posted on lab walls, given a specific spot in standup meetings, and even had slackbots created so that a dev persona can chime in on a feature channel discussion, for example. “It is a bit like that quote about Jeff Bezos always having a chair set aside in meetings to represent the customer, it is about making room and space for the developer persona.” Womack also recommends assigning a team member to maintain the persona, to perhaps ask at standup meetings on a regular basis, “Is there anything we learnt about Amy, one of our developer personas, yesterday?” Louvel is heartened by how the current interest in developer personas he is seeing in the enterprise: “I see a growing trend that puts the developer persona at the center of the API creation process, especially for private APIs,” Louvel says. “The developer who will consume a business’ API needs to have tighter and tighter control over the defined API. If the developer is involved too late in the creation process, then they won’t be able to build the proper solution such as a mobile or web app UI.” Increasingly, all businesses — whether they be Nike, McCormick Foods, Walgreens, Philips, or Capital One — across all sectors are becoming tech businesses. As part of this shift, businesses are opening up their data and services as components that can be integrated into applications and processes by third party partners. In this economy, developers become crucial to enabling revenue growth and can help extend market reach by helping a business create new digital products, or integrate into other digital platforms. Business models and business plans must better target developer segments in order to leverage new growth. Developer personas are a key tool to successfully build these new partner relationships. The Cloud Developer Segmentation Report by VisionMobile, is based on the 10th edition of the Developer Economics survey that reached over 21,000 respondents from 150 countries and provides detailed data on thousands of cloud developers. The  report looks in detail at the cloud developer segments, seeing how motivations map to tools and business models, providing an insight into what applications they are creating and how they are creating them. Consequently it divides developers into eight segments, based on what they want to achieve rather than the tools they use to achieve it. #appdevelopers #cloudsegmentation #developer #personas

[UPDATE: The survey is now closed -Enjoy the infographic] Have you ever asked yourselves what would the world be like if there were only 100 developers in it? Well even if you haven’t, we are sure we have just made you think about it. Based on our Developer Economics survey that reaches 30,000+ devs per year, across mobile, IoT, cloud, desktop, AR/VR, machine learning , we designed a very interesting Infographic illustrating this scenario. Check it out and find interesting insights about the Developer World : How many men and women would this world include ? Which continent would be the most populated ? How many would be Pros and how many Hobbyists ? How experienced are developers  in this world? What is the most popular coding language? Embed #appdevelopers #pros #hobbyists #software #developerpopulation

These days everyone and their uncle is talking about chatbots as the next thing after apps. But ‘Chatbot’ is a rather poor name for explaining the changes taking hold in mobile. ‘Chatbots’ are a mental model suited to developers. The term means very little to users. Besides, ‘chatbots’ represent only a small part of what is happening in the messaging space. The tech media and blogosphere usually focus on one of three things when talking about ‘chatbots’: the merits of the conversational UI the promise and reality of AI-based natural language processing, and messaging platforms as an alternative to app store distribution. In reality these three things are quite independent and sometimes the discussion in the media reminds me of the famous Indian proverb about an elephant and the blind men. The elephant is really about billions of people relying on messaging as their main person-to-person communication tool and in the process getting used to what Dan Grover, WeChat Product Manager, calls the thread-centric UI. It’s no stretch to see WeChat and its ilk not as SMS replacements but as nascent visions of a mobile OS whose UI paradigm is, rather than rigidly app-centric, thread-centric (and not, strictly speaking, conversation-centric). The next natural step is to apply the same thread-centric paradigm to communicating with businesses on mobile. It works brilliantly. It works in China, where WeChat/Weixin is on the way to becoming an alternative to the mobile Internet itself. It works in Brazil, where WhatsApp has become a one-stop solution for everyone, from small businesses to government agencies, to manage everything, from transactions to recipes and relationships. The messaging quadrant There are thousands of business to consumer chat services already, from early-stage startups like ChatandBook and AndChill, to large corporations like KLM, Disney and NBCUnversal. To compare and contrast all the different approaches we consider two independent axes: Apps vs. no apps, and AI vs no AI. The “apps vs no apps” axis is about whether the service is delivered as a standalone iOS or Android app, or whether the service ‘lives” inside horizontal messaging platforms (Messenger, Slack, Skype, Telegram, Kik, as well as SMS). The “AI vs no AI” axis is about whether the chat service is powered entirely by human operators or uses AI-based natural language processing to automate all or parts of conversations. These 2 axes give us what we call “the messaging quadrant”. Apps without AI: There are iOS or Android apps that connect users with human operators through a chat-based interface. For example, HotelTonight offers a human concierge service called Aces inside its mobile app. Snapdeal, Indian e-commerce service, provides chat-based support to its users by connecting them with human operators, again within the Snapdeal app. Yup (formerly MathCrunch) connects students with tutors over a chat-based app. Wellness specialist Vida connects users of its app with human coaches. Pana connects you with a real travel agent, and on and on. Apps with AI: In this quadrant we find standalone chat apps that use AI to automate all or parts of the interaction with users. For example, GoButler uses AI to help you with travel planning. Ozlo helps you to pick a restaurant or a coffee shop, Lola Travel reinvents personal travel by combining of AI with human travel agents, and so on. The mobile app approach makes most sense for companies that already have a significant user base (like Snapdeal or HotelTonight). They don’t have to rely on the broken app store distribution to attract users. For everyone else, I believe a native iOS or Android app is just a stop gap. The high cost of making, distributing and supporting native apps combined with the distribution power of messaging platforms will push the majority of companies to skip mobile apps completely and deliver their services directly inside messaging platforms. Let’s look at some examples. Operator, a US-based shopping assistant that connects users with shopping experts initially started as an iOS mobile app, but recently started offering its services over Facebook Messenger. No apps, no AI: In this quadrant we find services connecting users with human operators inside popular messaging apps or SMS. For example, Rogers, a Canadian telecom operator offer access to its support operators through Facebook Messenger. Examples are numerous. If this sounds boring, consider the business potential of replacing millions of 1-800 customer support numbers with 21st century technology and user experience. Just replacing clunky IVR with simple messaging plus custom buttons and asynchronous communication with the agents are huge steps forward. (I hope you’re not listening to some boring hold music over the telephone while reading this post.) There is also a growing number of services connecting users with human operators and providers over messaging platforms. For example, HealthTap makes its network of U.S. physicians available to Messenger users worldwide. AI without apps: This area generates most excitement with entrepreneurs. It allows access to users without the costs and headaches of native mobile apps, while promising to be much more scalable than services dependent on human operators. AI can have enormous impact without reaching full automation. Consider that in customer support recognising and automatically responding to the top 10 simple queries, while routing everything else to a human operator might allow a big corporation to cut lots of call centre jobs. Facebook itself is experimenting with M on Messenger, where it uses humans to train AI and create a fully automated personal assistant. Assist uses natural language processing to connect users with a host of on-demand services over SMS, Messenger, Slack, Telegram and Kik. Meekan automates meeting scheduling for Slack teams and on the way helps you to find the flight. Databot allows you to “speak with your database” simply in a Slack chat. The list of automated chat services grows every hour. One critically important question remains unanswered: How users will discover thousands and potentially millions of 3rd party services available inside messaging platforms? Slack Bot Directory, for example, adopts an approach similar to mobile app stores. Users can browse selection of Slack bots organized by categories or popularity. Facebook and Microsoft seem ready to take a different approach: Facebook M virtual assistant will be able to recommend chat services based on the current conversation and requests. Microsoft demonstrated how the company’s Cortana virtual assistant automatically summons and dismisses 3rd party chat services in a conversation. A post-app ecosystem in the making Stan Chudnovsky, Head of Product, Facebook Messenger said at TechCrunch Disrupt that “tens of thousands” of developers are making messaging bots for the Facebook Messenger platform. Already tens of companies are building tools for bot developers – From giants like Facebook and Microsoft, to startups like Smooch, Kasisto, Reply, Meya, and Init. It’s clearly the beginning of a post-app wave and the hottest opportunity for developers disillusioned by mobile apps. We cannot wait to share the results of our 12th Developer Economics survey, which includes questions on bot development. #aichatbots #artificialinteligence #chatbots #chatbox