Uncategorized Archives - SlashData Blog

Developer Relations vs Developer Marketing Which Side are You On?

Have you ever wondered what the difference is between developer marketing and developer relations? And what is the difference between an advocate and evangelist? Just who is behind those developer portals you use for the developer documentation and who answers your queries on official forums? Read on to find out!

In this blog post, I’ll set out to disambiguate the roles within a company’s developer outreach team and explain what each person does and where they focus their attention.

If you are a developer, you have likely visited a number of portals and joined communities over the years, some successful and some less so. You’ll find it interesting to know the inside story on how they are put together and what happens behind the scenes.

If you work with developers, or are planning to, you’ll also find this post useful, particularly if you are considering building a developer community, or funding one. It’s also likely to be something that you need to consider if you already have a nascent community running already but want to push into the next level of the developer community maturity model.

Here at /Data, our Developer Program Benchmarking reports track how developers perceive individual developer programs. Twice per year, we measure developer adoption, engagement, and satisfaction across the industry, reaching over 40,000 developers in more than 165 countries. Our data shows that developers visit the top developer portals at least once per week and, on average, developers report to be involved with 3.1 different developer communities. These days, development uptake revolves around community, and your outreach team is likely to have a huge bearing on your success. So, without further digression, let’s dive in to the structure of a typical developer outreach team.

Developer product engineering

What is a company’s developer product? Well, it could be a Github repo that you clone, or an installable tool. it could be a zip file that you download, maybe it’s an API, maybe it’s a library or a package. It’s something you use if you are a developer — and somebody made it. That person, or group of people, sit in the developer product team.

The developer product team can range from a handful of developers to hundreds of people in big organisations. This team is responsible for setting out their product strategy & roadmap, for developing the product and its supporting documentation & sample code, plus tooling, and libraries and IDE integration where relevant. They will be the know how behind the technical support provided when you need it.

Their goal is to develop the best product for you, the audience, in terms of its usability and relevance. They will want to know how to improve their offering to you, and also want to be able to demonstrate to their company that they are worthy of what has been invested in them.

Many product teams would agree that the marketing metrics of “who read our blog?” or “ how many twitter followers do we have?” don’t really apply to them. In our recent book, Developer Marketing: The Essential Guide, Pablo & Rex of Arm’s developer ecosystem team, made the point that their goal is to help developers’ code run better on Arm products, and their efforts in this direction is what they need to measure. Their approach is to educate themselves on their developer audience so well that they find a unique way to serve them and make their lives better, thus raising their awareness of the company. In the book, they describe how they spent time meeting developers and listening to woes about a particular development workflow. They set out to build a tool to smooth out the experience for developers, and set themselves a target for the installation process to get a developer up and running in under 5 minutes.

Developer relations

Now we’ve seen into the team building the developer product, let’s turn to the main interface between that team and developers using their output: those working in developer relations. Their goal is to build credibility, trust and influence with developers for the company they represent.

Many people struggle with working out exactly how to pin down the role of developer relations, and those working in it may alternatively be labelled community manager, developer evangelists or advocate. The role incorporates some marketing, but it also fits alongside the product group and within engineering. We’ve described previously that developers don’t trust always marketing, so developer relations is often seen as the bridge or connector between the two. Developer relations is about field work: working with developers to help them understand how to use the developer product. Some of the activities you may find developer relations working on include:

– public speaking

– attending hackathons and contests

– writing sample code and running demos

– social media (including technical blogging)

– attending events and meetups

– hosting office hours

A role in two parts

The developer relations team has two distinct ways of working. Part of their responsibility is evangelism: to communicate the company’s message to external developers. They may find themselves explaining which features are available and which are not, yet.

Conversely, the other part of their job is advocacy: to convey the developers’ views back to the product team. Developer relations practitioners are familiar with saying “I’m getting very strong feedback from people who use X that we should actually include feature Y and not Z”, and defend specific feature requests to the product team.

It’s a very important role, advocating on behalf of the developers to the company and evangelising the company to the developers. It’s also something of a balancing act at times. In our recent podcast with Mary Thengvall, author of a recent book about developer relations and well-established community builder, she said:

“… you’re constantly going back to the company with feedback from the community or turning around and explaining to the community why a product roadmap looks the way that it does and why those are the decisions you’ve made. You find that you’re explaining why we’ve made decisions or what best practices we have decided to follow. There’s a lot of storytelling in there, fitting your knowledge to the perspective of the person that you are talking to. Taking the feedback from the developer audience and the technical audience and communicating that in a way that the product team and the stakeholders and the company are going to understand and vice versa, taking the business speak from your stakeholders and communicating that back out into the community in a way that they understand…”.

Developer relations people are responsible for building connections, then stepping back and letting other people do their jobs. For example, they make an introduction between a community member and a recruiter, or they connect an active community member to someone at the marketing team, to write a blog post. The developer relations team are not responsible for hiring the person or publishing the blog, and it may or may not happen. But the connection was made and it can bring value to the company, ultimately, so that’s the job. It isn’t measurable in terms of sales numbers or marketing numbers or traditional business metrics.

Developer marketing

Working in developer marketing, the focus is to encourage developers to learn about, try out, adopt, use and contribute to a software product. This is the team that defines the target audience by building a model of developer segmentation and personas. They also create the developer marketing strategy and product go-to-market plans, and work on outreach channels of social media, content marketing, email campaigns and blogs. Some developer marketeers will be in teams that establish developer rewards programs and early access programs for software or hardware; other, smaller teams, will be focussed on growing an audience via sponsored events and meetups.

There’s a great chapter in Developer Marketing: The Essential Guide, by Ana and Christine of Qualcomm, who talk about building a developer community around hardware. They describe the process of narrowing down the target audience for the community around their Snapdragon 410E processor. It was

‘…to let a thousand flowers bloom: to make it as easy as possible to use, to build up a broad community and channel, then see where biggest leads came from and tune the business approach along the way. That’s a difficult place for developer marketing to work.

“Who is our target audience?” we asked.

“Lots of people,” the product team told us.

“What will they make with the board?”

“Lots of things. You know, for the Internet of Things.”

“Can you identify a few key vertical segments to focus on for our initial campaigns?”

“Why would we do that? We need to position the product as broadly as possible.”…’

As they say in the book, it wasn’t exactly a well-defined target audience and clear direction, but that is as succinct a description of the place that a developer marketing team finds itself as I’ve ever seen!

And finally…

The following table illustrates the subdivision between roles as I’ve described them above. Please let me know in the comments if you think I missed anything about the roles, or if you have good (or bad!) examples of how they work together to allow the developer outreach team to engage with its community.

Future Developer Summit 2017: behind the scenes

We live in a platform world; But we ‘re still unlocking its secrets; how to design for, market to, and engage developers. In this nascent industry, we need to learn from each other. This is what we designed our Future Developer Summit 2017 to do, an invite-only conference where thought leaders and practitioners discuss the future of developer relations and marketing.

Our second Future Developer Summit was held earlier in October. We hand-picked 35 Director-level executives from 35 top technology platforms who came together for one day to learn from each other. All were leaders responsible for developer product, relations or marketing.

Attendees came from the top platform companies (Facebook, Google, Amazon, Microsoft, Mozilla), hardware companies (ARM, Intel), enterprise companies (Oracle, SAP, Salesforce, VMWare, Adobe, Cisco, Atlassian, Slack, Mobile Iron), game companies (Unity, Epic Games), cloud software companies (MongoDB, RedHat, Heroku, Digital Ocean), car makers (Ford), handset makers (Sony), emerging platforms (Roblox, Twitch), finance companies (Stripe, Intuit), open source foundations (Linux Foundation), and recruiting companies (StackOverflow).

The small audience was instrumental in keeping the Summit a trusted environment where information and experiences could be shared openly, under Chatham House rules. Having only one representative per company, allowed us to maximise the diversity of views and experiences that are shared, while keeping the audience small and tightly knit.

The venue was beautiful – perched on Menlo Park’s Sand Hill road, surrounded with trees, drenched in light and decorated with modern art paintings. The food was top-end and plentiful – with my highlight being the mash potato bar! The wine and beer were award-winning. And the jazz band for the networking drinks & buffet was one of the best in the area.

We also took the opportunity to launch the first developer satisfaction awards at the event. Nine organisations from the software industry were unveiled as leaders for developer satisfaction. The Developer Satisfaction Awards recognise the software products and brands that developers are most satisfied with. Results are based on the independent and unbiased opinions of over 40,000 developers surveyed annually, from around the globe, combined with SlashData’s rigid research methodology.

We also run a survey on Return on Developer Investment with the Summit attendees representing 28 diverse companies. The survey revealed some unique patterns on spend, team size and priorities for the developer relations industry- the first time dev relations trends data has been collected at this scale. We found that almost half of responding companies have 10-50 FTE staff in their dev relations, marketing or product activities, while just over a quarter have 10 people or under. Yet 40% of developer programs have a similar budget of $1M-$5M for developer marketing / relations / product investments. And how do do developer programs measure RoI? the indicator used by most programs is monthly active users, followed by unique visitors and SDK downloads.

Thank you to the team that helped put together the event – Chris, Moschoula, Virve, Sofia, Christos, Christina and Mark – we clearly exceeded our expectations, as well as to the entire company that contributed with data and insights.

Until the next Future Developer Summit – watch this space. If you want to be involved in the next event drop us a line.

Andreas

Developer Program Metrics: How Intel Measures Developer Satisfaction.

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.

Return on Developer Investment

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

Cloud PaaS tools: this is how developers use them.

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.

Chatbots: From hype to “figuring it out”

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?

Whatever happened to Operator Billing?

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.

Android First is the New Normal

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

Why are mobile developers so obsessed with advertising?

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.