5+1 ways to attract Internet of Things developers

With so much buzz around the Internet of Things, many are wondering what will be the platform on which the IoT ecosystem will be built. Stijn Schuermans reviews several interesting developments in IoT hardware modules that make getting ‘Things’ done a breeze, and adds some question marks with the widespread focus on devices.

Blog003-01_web copy

Five years ago, at the onset of the smartphone revolution, no-one predicted a significant latent demand for apps such as flashlights or “Draw Something”. And who would have thought that a game like Angry Birds could create billions of dollars in value; not just for the publisher, Rovio, but also for Apple as the platform owner?
Continue reading 5+1 ways to attract Internet of Things developers

[Infographic] Developer Economics 2013: Dev tools are the foundation of the app economy

We’d like to present our latest infographic, based on the latest Developer Economics report – themed around developer tools. This infographic presents some of the key findings from the published report (which is available for download here).

  • 72% of developers use Android, 56% use iOS – HTML is the third most popular choice among mobile developers, 50% of whom use the HTML-based set of technologies as a deployment or development platform
  • 67% of developers are below the “app poverty line” of $500 per app per month –  BlackBerry and Windows Phone lagging behind in terms of monetisation, but leading platforms also have issues. 61% of iOS and 68% of Android developers are below the poverty line
  • 74% of developers use two or more platforms concurrently – Multi-platform offers much better monetisation potential, as developers who use more than one platform have higher revenues than those who just use one
  • Advertising is the most popular revenue model, used by 38% of developers – but subscriptions pay more
  •  Ad services are reaching mass adoption for developers – 34% are using at least one ad-service tool – 90% of developers use at least one third-party tool or service, with an average of 1.47 tools used concurrently

Want to be part of the next Developer Economics? Our online survey is still live (closes May 6 2013) – have your say and claim one of our great prizes!


(like our infographic? feel free to embed it – see codes below the post)
Developer Economics 2013 Infographic - Dev Tools: The foundations of the app economy

Monetising apps: Lessons from the music industry

[VisionMobile analyst Stijn Schuermans muses about the similarities between the app economy and other businesses like FMCGs and music. What can app makers learn from other industries and how can these lessons help developers monetising apps?]

In a recent post on our newly launched Developer Economics portal with facts and insights for app developers – build.developereconomics.com – colleague Mark Wilcox likened the app economy to a retail business:
In the early days of relatively empty app stores, simply launching a good product was often sufficient to get noticed and soar up the store charts. However, as with any fast-moving consumer goods (FMCG) business, the value within apps has shifted from the contents (the functionality) to the packaging (the user experience) and marketing. Continue reading Monetising apps: Lessons from the music industry

[Infographic] The Mobile Platform Race – How do mobile platforms stack up?

We’re proud to present our latest infographic, The Mobile Platform Race, showcasing some of the most important findings and insights from our Developer Economics 2011 report (free download here).

Developer Economics is the definitive report on mobile developers, apps and brands going mobile. Developer Economics was created by VisionMobile and sponsored by BlueVia. We hope you enjoy the infographic – and feel free to embed it in your own website. Comments welcome, as always.

Feel free to copy the infographic and embed it in your website.

Developer Economics 2011
600 pixels wide version

760 pixels wide version

1000 pixels wide version

[sociable_code]

The Guide to Building Developer Communities

[Developers are currently the hottest property in the mobile industry. Tens of developer programs have sprung up, aiming to woo developers.  However, besides Apple, Google and perhaps Microsoft, other developer programs have had at best a lukewarm response. Guest author Gyanee Dewnarain investigates what makes developers tick and the faux-pas to avoid.]

The Guide to Building Developer Communities

Have you been ramping up your developer marketing efforts lately with a view to attracting more developers to your programme? How are your efforts faring? Let’s have a look at what works and what does not.

First and foremost – who to target?

Before you set out on your quest, it is important to know who you are targeting. We have all come across the perennial cliché of a developer as being the unshaven geeky guy with long hair and sandals. This image is outdated: developers nowadays are a rapidly expanding community that includes software engineers (architects, implementers, discoverers, thinkers, inventors) within small, medium and large enterprises, hobbyists or indie developers (working on open source or proprietary software), high school kids aspiring to go to MIT, commissioned developers, brands developing  B2C apps, system integrators targeting B2B apps, investors funding mobile development and 100s of start-ups.

Each developer segment has varying goals and incentives and the ways of engaging with them vary too. It pays to do your research first and understand who you are targeting and how to do so. However, irrespective of the segment you are targeting, there are a few key ingredients (so-called hygiene factors) that need to be in place in your developer program for the greatest chances of success. These hygiene factors are covered extensively in VisionMobile’s Developer Economics 2010 and 2011 reports. This post focuses more on developer marketing strategies and tactics.

First Impressions Matter

The first step in a developer marketing program is to create a solid first impression. Developers expect you to invest considerable effort in the way you present your tools, APIs and documentation to them as well as the way you present their applications to your customers. This is a competitive marketplace and if you want to stand any chance of getting noticed, your offering needs to stand out from the other developer programs which are vying for developers’ attention.

It is equally very important that your messaging and your branding are consistent across all your digital assets – website, blog, storefront etc. If your branding and messaging is confused, developers’ confidence in your developer program will erode rapidly.

Developers also have an aversion to long, convoluted, legal terminologies; don’t make them read and sign long T&C’s before they can access any of the exciting stuff (code, APIs, tools and documentation). Second opportunities come seldom in this market.

The “coolness” factor

Developers like cool companies (think slide, smoothie bar, collectable pins) and cool brands and if you appear stuck-up, they will run a mile. If you want to engage with them, you have to think about the image you and your company project – you have to speak their language and dress like them. The language on your website should be simple and straightforward (cut back the marketing blurb).

While more technically inclined, developers still like devices which have mass market appeal (both from the perspective of personal interest and also from the perspective of user reach and revenue generation). Engage with other brands and channels to increase the desirability of your device, your storefront or your cloud platform.

In addition, make sure that your products are able to get developers excited (from the development tools, emulators and documentation through the storefront to the actual devices that you are selling in the market).

Encourage openness and interaction

Do not bind your developers into contracts and NDAs that forbid them from sharing useful hints and tips. Even Apple realised the mistake it was making by preventing discussions amongst its developers and had to retract its NDA three months after the launch of its iPhone developer program. You should encourage your developers to share their experiences, best practices and code snippets by creating places and opportunities for them to meet and interact with each other.

Online forums, blogs, mailing lists (both on your own website and on popular 3rd party fan websites) are must-haves. Such communication amongst developers helps build a sense of community.   Developer events are equally de rigueur in any developer program. Your events should ideally favour hands-on code oriented tutorials and workshops as opposed to marketing presentations.

Learn the art of listening

Building communities means extending bridges. The mantra is – communicate, communicate, communicate; whether it’s through one to one e-mails, social media, developer forums or third party developer events. Keep in touch with your most loyal developers, as much as you can, and in a personalised manner. Formulate your message in such a way that you make them feel important; the focus should not be on your company but on them.

The worst thing you can do is have a big developer bash and disappear off the radar for a while. That might have worked a few years back but in the current market, with everyone competing for your developers’ attention, if you do not constantly keep in touch, someone else will snatch your developers away in the blink of an eye.

Honesty is the best policy

Changes to existing APIs and introduction of new APIs are a natural part of software development. However, be as transparent as you can with your developer community. Inform them about the changes that you have made to your APIs and try to have a sensible upgrade path so that there are no rude awakenings. Ensure compatibility with previous versions; this would show that you are respectful of the time and effort that developers are committing to your program.  Despite facing a lot of criticism with regards to fragmentation risks across its multiple releases, Google has gone to great lengths to explain API updates to new Android releases.

Share your vision of the future

Sharing your vision for the future is a critical part of engaging with developers. It is therefore essential that you communicate the rationale behind your business strategies, technology decisions (e.g. moving from native to web) and the future direction of your program very clearly to your developer following.  Endeavour to provide your developers with the opportunity to provide their feedback, comments and suggestions. Arguably, developer programs such as BONDI and JIL failed due to their inability to communicate any tangible vision to developers. Unfortunately, WAC seems to be following a similar path.

Favour substance over style

If your platform does not ship; if your tools look good but do not deliver;  if your code samples are too difficult to learn and use, your developers will churn to greener pastures. This means:

  • If you are going down the route of having your own platform, then you have to ensure that the tools that you provide are easy to learn and your programming paradigms enable quick coding and prototyping.
  • Provide APIs that are rich and that offer developers the opportunity to go the extra mile in creating truly innovative applications. These could include select hardware APIs (that are normally hidden) and in some cases network APIs such as billing, location, user profile etc.
  • Provide debuggers and emulators that are fast and provide accurate target device mirroring.
  • Make sure that your development environment includes an app porting framework and solid emulator integration.
  • Choice is good – provide options for advanced use cases for example both a basic command line text editor and a web based IDE.

Moreover, if you get lethargic and do not constantly look at ways of evolving your tools, being innovative with your business models, and seeking newer markets, boredom is likely to set in and your developers may start looking at other alternatives. Therefore, continuously check how your program is faring against competition. Several operators dismissed Apple and Google for more than 2 years until it was too late to figure out a positioning strategy.

Bridges to developers need constant maintenance

You’ll need to set aside a significant budget to finance various types of seed programs as well as developer competitions. Seed programs include many incentives for developing such as:

  • Releasing early builds of your platform/ SDK version to developers, both to get feedback about bugs and other issues as well as to give developers lead time to test software or experiment with adding new features.
  • Commissioning developers to develop apps specifically for your platform or port existing apps from other platforms.
  • Fast tracking the certification of apps for a select group of your target developers (especially useful when you need to get an app ported from a competitive platform to your own)
  • Distribution of free reference hardware or commercial devices to your installed base of developers in order to build loyalty.

Show me the money

Many of the developers that you want onboard (especially those with a commercial role) want to see a return on their investment. From the outset, it should be clear in your own mind how your developers are going to make money from their apps and you should communicate this in a very clear manner to them – what are the devices that you support, how many people are using those devices, how do they get their apps on those devices, how do customers find, download and pay for the apps and how, when and how much do developers get paid.

The other thing to note is that developers are smart and discerning consumers who will fact-check you before they can trust you – make sure you have the figures to back your marketing assertions.

One of the critical issues facing developers currently is “discovery” of their apps by customers. The developer programs which come up with the most original ideas to improve discovery and present new business models for increased monetisation are likely to gain traction with the largest number of developers.

Casual settings work better

When socialising with your developers, small informal events work much better than large formal conferences. Make sure that the developers and software engineers from within your company get the opportunity to interact with each and every developer, answering their questions, listening to their issues, encouraging them to interact regularly and share experiences and difficulties. So far, BlueVia has been amongst the operator developer programs that have most successfully embraced this philosophy by holding small developer events in pubs around London.

Jump onto the social bandwagon – Facebook It, Tweet It

Studies show that over 60% of people within the 15-35 age group (and that includes the vast majority of your developers) spend on average 20 hours per month on social networking websites. This is where you are likely to find them and this is the medium they will use to spread the word about you if they like you enough (viral marketing). Social media is where you need to advertise your events, inform developers about the availability of the latest release of your SDK or the latest device you are planning to launch.

Locate your Evangelists

Find out who are the people who believe in your platform – the fans, the early adopters– the people who would be willing to fly the flag for you. Check the people who write favourable blog posts about you, who comment on your blog posts, tweets, participate in your forums and Facebook or LinkedIn discussion groups. Approach them and provide them further incentives to spread the good word.

Developers listen to their fellow developers – therefore, get your early adopter developers to talk about how easy it is to create apps using your APIs and SDKs and how fast it is to certify the apps and get them published.

Reward your successful developers – promote their apps in the media, ask them to come and talk about their success stories at your events; publish their success stories on your website and in your marketing collaterals; encourage them to publish stats about number of downloads and the amount of money they’ve made.

Putting it all together

In summary – decide who you want to target, make sure the hygiene factors are in place, keep your messaging and branding consistent, keep legal blurb to a minimum, be a cool brand, encourage your developers to share experiences and best practices, value feedback from your developers, be transparent about changes to APIs and code, communicate your vision and roadmap, provide high quality tools that are on par with competitive offerings,  prepare to invest, show developers the return on their investment, interact frequently with your developers preferably via small informal events and via social networks, locate and draw upon your evangelists and last but not least, reward your successful developers.  Many have tried and many have failed over the years. Sometimes, a few decisions can make or break your program. Be quick to learn both from the failures and the success stories!

Happy Community Building!

– Gyanee

[A mobile technology aficionado, Gyanee Dewnarain has 8 years’ experience working within the international telecoms business environment. Gyanee has worked for a host of companies within the mobile industry ranging from consortia (LiMo Foundation) and start-ups (Carrier IQ) to large corporations (Gemalto and Alcatel). Prior to that, Gyanee was involved with the International Telecommunications Union (ITU) and co-chaired the ITU Youth Forum in Johannesburg. Gyanee holds an MSc in Telecommunications with Distinction from University College London (UCL). She can be reached at gyanee.dewnarain (at) gmail.com]

[Report] Developer Economics 2011 – Winners and losers in the platform race

[Who is leading in the platform race – and who’s lagging behind? Marketing Manager Matos Kapetanakis examines the flow of developer mindshare and discusses how success is measured in the app era – in part 1 of our 3-part blog series on our newly released Developer Economics 2011 report.]

Developer Economics 2011 – free download here – has been created by VisionMobile and sponsored by BlueVia.

VisionMobile - Developer Economics 2011 - Platform race

Developers driving innovation


The role of mobile developers has changed dramatically over the past three years, from a lowly position as back-room engineers to the much-sought-after engine that drives mobile software innovation. Never before have developers, from big development houses to aspiring students to garage entrepreneurs, had such an enormous impact in mobile industry innovation and dynamics.

Handset manufacturers, platform vendors and even network operators (or carriers to our American readers) are competing over who’s going to build the biggest developer community, as success today is measured in terms of thousands of apps and billions of downloads. Platform and OS vendors are the most active in this game, trying to steer developer mindshare towards their platform and create a new plateau of innovative services, as well as a whole ecosystem around them.

So, which platforms lead the race and which are lagging behind?

The platform race

In the platform race for developer mindshare, there are some clear winners. According to our research, the developer mindshare is firmly flowing towards Android and iOS, with 67% of developers currently using Android and 59% using iOS.

VisionMobile - Developer Economics - Developer Mindshare

These figures show a considerable increase since last year, with the two platforms climbing nearly 10%. In contrast, the ‘old guard’ comprised of Java and Symbian are leaking developer mindshare.

However, the most surprising finding is the adoption of mobile web, i.e. the platform for apps written in HTML or JavaScript, which claimed the 3rd spot in terms of developer mindshare, being used by over 55% of the developers. We do not attribute this to the ease of learning this platform (which has a deceptively steep learning curve, as you can see in the full report), but rather the influx of non-mobile developers to the industry. Also, mobile web is fast becoming the de-facto cross-platform choice for developers, especially now that Java and Flash are waning. In addition, there is a veritable host of HTML-to-native development tools that are helping HTML/JavaScript developers target smartphone native app markets.

More on Developer Mindshare in the full report.

It’s also worthwhile to take note of the Developer Intentshare, i.e. the platforms that developers are planning to use.

VisionMobile - Developer Economics 2011 - Intentshare

Android still reigns supreme, but the surprise comes in the form of Windows Phone, which is fast becoming a developer favourite. Despite lukewarm sales in 4Q10 and 1Q11, the newly revamped Microsoft platform has managed to gain the vote of developers.

This can be attributed to a number of reasons: First and foremost, Microsoft has actually released a competitive platform with a strong toolset. Also, the platform’s future seems bright, after the now-famous Finnish Deal. Finally, Microsoft has invested a lot of time (and money) into attracting developers, tapping into the Xbox and Silverlight developer communities to divert the flow of mindshare in their favour.

The inclusion of Chrome OS in the top 5 platforms in Intentshare is more a result of curiosity for Google’s dark horse platform – how will it stack up to other platforms? MeeGo also seems to be vibrant, which goes to show that strong developer communities go a long way in this software era.

In contrast, BlackBerry has lagged behind in Intentshare, suffering from fragmentation issues (see our full report for the surprising answer to which platforms are the most fragmented), as well as minor fixes to an aging platform.

Who’s lagging behind in the platform race? Symbian and Java have suffered the biggest losses in terms of developer mindshare. Nearly 40% of developers currently using Symbian and 35% of developers currently using Java ME are planning to abandon the platforms.

VisionMobile - Developer Economics 2011 - Abandon index

No surprises there, especially in the case of Symbian, which carries an expiration date, despite Nokia’s slow transition to the WP platform. Java’s loss of mindshare is less expected, especially considering the platform’s reach as global sales are still dominated by feature phones – but developers are not sticking around for that.

Palm’s platforms are also being rapidly abandoned by developers, since Palm is all but dead and HP has still to ship its first webOS handset.

What’s in a platform?

 

How do developers make that all-important decision of which platform to select? Well, according to our research, the biggest driver in platform adoption is large market penetration – a sentiment shared by 50% of our respondents, irrespective of the platform they spend most of their time on.

VisionMobile - Developer Economics 2011 - Platform adoption

But what exactly is market penetration? A platform’s installed base is an important aspect – i.e. just how many actual handsets can run a given app – but that is not all. Penetration is also measured in terms of a platform’s ability to reach users and that is also a factor of how and where that content is available. – a centralised distribution and discovery point, such as an app store, accessible by mobile devices, tablets and PCs goes a long way towards providing developers with a direct access to their customers.

Proving that there’s more to market penetration than a large installed base, we present the case of handsets sold vs. apps. There is a large discrepancy between the number of handsets sold and the number of apps available on a given platform.

VisionMobile - Developer Economics 2011 - Apps vs. sales

In an app economy with close to 1 billion [Update: million] apps, more than half of those are concentrated on two platforms: iOS and Android. It’s easily apparent from the graph that vastly more pervasive platforms in terms of total shipments, like S40 and Java claim just a fraction of the app pie. Granted, this is a smart-centric game, but even a pervasive smartphone platform like Symbian cannot much app to the two app moguls.

Do apps mean money? Not directly, but it’s no coincidence that 2011 marks the first time Apple overtakes Microsoft in terms of revenues and Android rushes past the finally burned-out Symbian platform in terms of shipments.

-Matos

Want more Developer Economics?

Follow us on Twitter (@visionmobile) for updates and stay tuned for part 2.

And for those of you who still haven’t done so, don’t forget to download the full report!

Business model polarity: a win-win proposition for telcos and developers

[There’s 10s of telco programs targeting developers. But they all lack commercial traction. Isn’t it about time for telcos to question their approach? Guest author Jose Valles argues for a ‘polarity change’ in the telco business model and discusses the need to rethink the telcos’ relationship with developers.]

VM blog - Business model polarity

In life, we tend to take many things for granted; the Sun will rise and set every day and a compass will always point North. But we mustn’t forget that things do not, and in some cases should not, remain constant. The Earth’s magnetic poles are known to reverse their polarity every few hundred thousand years and then, the compass no longer points North, but South.

In business, we also need to question assumptions and remember that things do change. In the mobile industry, telcos (mobile network operators) have been around for over 20 years – many many generations in telco speak – but their relationship with developers has always been lukewarm at best ; telco APIs haven’t seen any significant take-up by developers.

What telcos need to do is to fundamentally question their assumptions about the software world and change their business model towards developers – in other words change the ‘polarity’ of their business model. Here’s why:

Some historical context

It is widely accepted that telcos desperately need developers; in today’s app economy, developers are a key source of innovation. If telcos want to capture value and innovation, they need to capture developer mindshare.

In the past 5 years, we have seen 10s of telco developer programs launch with different end-goals and flavours but with the same result: lack of commercial traction. Why have so many telco investments failed to see significant developer adoption? Failure is not such a bad thing, provided we can understand what went wrong and how we should fix it.

I would argue that most telco API programs have lacked two key ingredients; the lack of web mentality and a developer-centric business model.

The Web mentality

If you go to www.programmableweb.com, you can find thousands of APIs that allow developers to enhance their software and mobile apps with functionality coming from third party businesses. Functionality ranging from Google maps and eBay purchases to Tesco grocery lists, New York Times articles and pizza ordering can be accessed through cloud APIs. For a developer, this is an unprecedented source of content for their apps.

How do businesses like eBay, Tesco or NYT make it appealing to developers to use their APIs? How does the web world attract developers?

It’s the business model; in the web world APIs are often free (or freemium) so that developers don’t need to worry about upfront costs. It’s about ease-of-use; they’re also plug-and-play so that developers can experiment with functionality and see how it works. It’s also about adaptability; web businesses also adapt and change their APIs based on how developers use them.

That sounds easy. But what about telcos?

The telco mentality: the developer pays

If you go to any of the telco API programs that are out there and check their SMS API specifications, the first thing you will come across is the PRICE LIST.

Well, that may work if you have a strong developer brand or if the attractiveness of your APIs are top-notch but, honestly, that’s not the case with telcos. Developers dislike telcos – and I can say that working for a telco.

We telcos don’t have a good reputation in the developer space. And what do we telcos do?  We charge developers!

That’s not a developer proposition; it’s a wholesale mentality. And how do telcos think we are going to be able to compete in this space when much more agile voice application platforms like Twilio, Teleku, Jaduka or Vivox get fremium pricing and technology right?

The business model polarity change

 

If telcos are to grab developer attention, we need to see developers not as wholesalers – that is not a source of revenue but as the missing link between customers and telco services. When developers drive traffic or service usage we need not charge them, we need to thank them. And we need to charge not developers but end customers. We need to let developers focus on finding new ways to innovate with apps using telco capacities, not to worry about whether they have enough cash flow.

In other words, we telcos need to change our business model polarity; rather than using a “developer-pays” model, we need to move to a “customer-pays” model. If developers create apps that use telco APIs, they drive traffic or usage which benefit both the user and the telco. It’s not the developer that needs to pay – it’s the user.

VisionMobile blog - Business model polarity

Consider this; a developer builds an SMS-to-Twitter service; the user sends a new tweet by as a text to a shortcode. The reply, an SMS back to the user, is then paid by the developer. The developer is penalised for generating traffic to the network. This is the “developer pays” model and it doesn’t work.

In the “consumer pays” model, a single API allows the user to pay for both outgoing and return SMSes in one shot and the developer gets to use the API for free. The developer can focus on building a viral service and won’t have to worry about success costs.

This is a fundamental polarity change; instead of the developer paying for access to network resources, the consumer pays, and the network benefits from increased messaging revenues.

APIs like SMS or voice can also be exposed under both polarities. In this case, the developer can choose if they want to use SMS or voice APIs in a developer-pays or customer-pays polarity, depending on the nature of their app or service.

Winning with developers

We telcos need to experiment with business models. We need to learn from how developers adopt and use APIs and pivot our business model until we get to a proposition that’s truly win-win for both developers and telcos.

As the Earth’s magnetic poles shift naturally, telcos also need to question assumptions. We need to reverse the business model polarity for telco APIs in tune with the web and look for new ways to attract developer talent and new ways to satisfy customer needs. We need to fundamentally change the developer perception towards telcos if we are to succeed in helping telcos capture a share of the innovation out there.

– Jose Valles
Head of BlueVia
@josevalles49

[Jose has been working for over 10 years in different parts of Telefonica. Since 2009, Jose has been building a concept under the working name “Open Telefonica”, which ended up bringing BlueVia to life. The BlueVia business model does not just make APIs free, but it also pays the developer. “If developers use our APIs, we pay them back for the usage”. Check it out.]

[Survey] Developer Economics 2011: The evolution of app development

[Developer Economics 2011 is here! As we launch our new survey on all things developer-related, Marketing Manager Matos Kapetanakis looks back at the 2010 report and examines the major events that have shaped mobile development in the past 6 months]

VisionMobile - Developer Economics 2011

The evolution of Developer Economics
Last July we published the definitive mobile developer research report: Developer Economics 2010, dubbed by TechCruch as “one of the most profound…to date”. Our report delved into all aspects of mobile application development, across a sample of 400+ developers segmented into eight major platforms.

We’ve just launched the follow-up to this research report: Developer Economics 2011, once again made possible thanks to BlueVia, the global developer platform from Telefonica that helps developers take apps, web services and ideas to market. Our goal is to see how the dynamics of the developer world have changed since early 2010 and to provide more insights into app marketing, monetization and many other factors.

Join the survey or help spread the word! This year we ‘ve also secured a prize for each of the first 400 developers; 10 hours free testing time on DeviceAnywhere’s 2000+ handsets. UPDATE: Thanks to overwhelming support, all 400 free testing time prizes have been awarded by DeviceAnywhere. Of course, the $1,500 Amazon voucher is still up for grabs!

Major shakeups of the mobile industry for H2 2010
So, what’s changed since our 2010 research? The mobile industry is an ever-evolving landcape. In the past 6 months we have seen the Symbian Foundation close shop, with Nokia hoping that the as-yet untested MeeGo project will carry their smartphone banner. We have also seen the stellar rise of Android, zooming past Apple’s iOS and BlackBerry and becoming the no2 smartphone platform behind Symbian.

In the handset OEM arena, we have seen more shakeups in 2010 alone than in the 10 years preceding it. Apple and RIM have overtaken some of the traditional handset OEM powers (Sony Ericsson, Motorola, LG) and claimed a spot in the top 5. According to some estimates, ZTE could join them soon.

Moving forward, Developer Economics 2011 is looking at how the key metrics of mobile development have changed in the last year.

The migration of developer mindshare
One of the major findings of our 2010 report was the migration of developer mindshare away from the ‘old guard’, i.e. Symbian, BlackBerry and Java, towards the new powers of the realm – iOS and Android. According to our research, nearly 60% of the 400+ respondents had developed apps on Android. Apple’s iOS took second place, with more than 50% of respondents having a go at it, with Java ME following third.

In our Developer Economics 2011 research, we’ll be asking participants which platforms they’re currently targeting, which ones they plan on targeting and which ones they’re abandoning.

So, what’s changed since then? Well, if anything, the gap between Android and iOS and the rest of the platforms has grown even larger. The Apple App Store carries more than 300 thousand apps, while recent estimates place the number of apps in Android Market at around 130 thousand.

While Nokia has been spending considerable effort on the Ovi Store and increased its popularity with consumers and developers alike, they still have a long way to go to catch up with the two app-dispensing behemoths.

Why do developers head towards iOS and Android? Our Developer Economics 2010 analysis showed that Apple offers a platform that is relatively easy to master and using which a developer can design great UIs. They also have the largest app store and although the certification problem is an issue for some,  porting and fragmentation are not a challenge;. Android, on the other hand, has been gaining momentum across all fields, storming its competitors’ key market – the US. Of course, Android’s many fragmentation issues are often overlooked in the face of many handset OEMs’ dependency on the platform.

The disparity between handset sales and available apps

Our Developer Economics 2010 research uncovered a disparity between the number of devices sold for each platform and the number of available apps. One would expect the platforms with the highest market penetration to dominate in terms of apps, but that couldn’t be further from the truth.

Taking 3Q10 as a reference, it’s easy to see that the two platforms with the lowest penetration, iOS and Android, have the highest number of available apps.

On the opposite side of the spectrum, while Java ME and Flash Lite have the greatest market penetration by far, they can scarcely measure up to the newer platforms when it comes to app volumes.

In Q4, the contrast is even sharper. Both Android and iOS stores have grown by almost 100 thousand apps apiece. Windows Phone has shown an admirable growth, reaching 4 thousand apps in just two months, although it still has a long way to go before becoming truly a threat to incumbents.

Monetization and revenue expectations

In Developer Economics 2010, we asked developers how they felt about the revenues they’re receiving from selling their apps. Almost one in four respondents reported poor revenues, while only 5% reported revenues exceeding their expectations.

VisionMobile - Developer Economics 2010 - revenue expectations

While there has been a boom of app stores, that’s not necessarily a blessing for developers. Most developers face a discoverability issues, having their apps buried under thousands of other apps. Like one developer said in our previous research “It’s like going to a record store with 200,000 CDs. You ‘ll only look at the top-10″.

What options are there for developers? One option is to adopt a multiple storefront strategy, as well as to tailor your monetization model to specific app stores. As the CEO of Rovio, creator of the prodigious Angry Birds app, noted: “Free is the way to go with Android. Nobody has been successful selling content on Android”.

Developing apps in 2011
Care to see how the apps world has changed in the last year? Stay tuned for Developer Economics 2011, where we delve into app development, monetization, distribution, retailing, porting and fragmentation issues among many others.

Mobile developer? Join the survey and have your say.


[Infographic] The Mobile Developer Journey

The Mobile Developer Journey

A few months ago, VisionMobile published Developer Economics 2010 and Beyond, a research report that tracked the entire mobile developer journey, from app design and platform selection to market delivery and monetization. Now, we’re proud to present the entire Mobile Developer Journey on a single infographic.

The Mobile Developer Journey

Developer Economics 2010 and Beyond was created by VisionMobile and sponsored by Telefonica Developer Communities.

Did you miss the chance to participate in our research and have your say on app development? Well, you can express your views in our upcoming developer research, Developer Economics 2011, which is just a few months away. Pre-subscribe here

Feel free to copy the infographic and embed it in your website.

600 pixels wide version

760 pixels wide version

1000 pixels wide version

[sociable_code]

The Flash vs. HTML5 Endgame

[In the debate of Flash vs HTML5, has the death of Flash been over exaggerated? Guest author Guilhem Ensuque peeks through thick layers of hype and facts to predict what the future holds for the mobile web].

The Flash vs. HTML5 Endgame

The last year has seen a flurry of announcements and debate around the rise of HTML5 and the fall of Flash. Some have even gone as far as declaring a “war” between the two, and predicting the “death” of Flash as the outcome. However, as Mark Twain once famously said: “The rumor of my death is an exaggeration”. As we’ll see, the jury is still out as far as the fate of Flash and Adobe are concerned.

A brief (abridged) history of the web
“HTML5” is the new high-tech industry darling, and not just in the mobile space. It has become a catch-all phrase with little meaning when taken out of context. Before we dig into the debate, it’s worth looking at what is HTML5 and where has it come from.

“HTML5” when used as a shorthand, covers of family of web technologies currently being standardised by the W3C and at various implementation stages by browser vendors. The “5” comes from the version increment in the W3C spec number: currently most of the content you read on the web conforms to the HTML specification version 4.01.

To understand what has driven the creation of this new version of web standards, we need to look at the evolution of the web in past years.

historyofwebIn the 1990s the World-Wide-Web emerged from academia to become the ubiquitous medium to share digital documents over Internet Protocol networks. The HTML4 spec was matured in that era, and has been very much geared towards read-only, document-oriented description and hyper-linking. HTML4 mixes typographical tags with document structure description, within the bounds of static pages and has limited support for script-driven page logic and forms (does anyone remember CGI?). In that era of the web, support for multimedia content was notably absent from the web specification; leading to heterogeneous plug-ins striving to provide video delivery in web pages (remember Real Networks? or having to choose the speed of your modem?).

In the 2000s, the web evolved towards more interactivity with the advent of the “Web 2.0” (yet another buzzword) and user-generated content, especially videos uploaded and then streamed over faster ADSL connections. However, the HTML spec did not fundamentally change (apart from an attempt by the W3C to migrate to the stricter XHTML syntax which has seen mixed results in terms of adoption). To cope with HTML4‘s inefficiencies in allowing designers and developers to create interactive “experiences” (i.e. not just documents, but bi-directional “applications” living in your web browser) a number of innovations were introduced :

  • JavaScript, Dynamic HTML and XML HTTP requests (a.k.a. AJAX) as a way to have thick-client app functionality in the browser, enabling users to interact with the web in a read-write fashion (not just read-only)
  • clear separation of page structure in HTML (through heavy use of <div> tags) as well as typoraphy and style in CSS (through an arcane and verbose syntax), leading to more pleasant user experience and richer page contents
  • PHP-scripted and database-powered back-end logic bolted on top web server systems. This e.g. allowed template-driven content management systems like WordPress and Joomla to rise to prominence, fueling the blog revolution.

These innovations brought the ability to present vast amounts of data in pretty-looking dynamic web pages which mash-in RSS feeds, emails, blogs, Facebook updates, and tweets, and bringing web pages a step closer to applications.

In that era, Flash (or rather the Flash Player) rose to become a ubiquitous browser plug-in for animated graphics and video. At the same time, Flash evolved to provide an out-of-browser Rich Internet Application platform with the AIR runtime and the Flex framework, albeit at a much lower penetration level than the in-browser Flash Player.

We are now at the dawn of the 2010s, and the overhaul of the HTML4 spec is long overdue. HTML5 aims to bring back into the core spec of the web the “side” developments of the previous era and improve on them with a heavy focus on web applications. It also aims to lay the foundations enabling the delivery of web content through a new medium: mobile devices, and ultimately the “Internet of Things”. That history is yet to be written, but we can now ponder about its beginnings and the future.

So, What is HTML5 Really ?
In the context of this new era, the “HTML5” shorthand refers to a family of web standards and browser technologies that span a range of topics:

  • A modernized web markup language: the true-and-only HTMLv5 specification and matching evolution in web browser capabilities. The new syntax includes the <canvas> tag allowing bitmap manipulation through JavaScript drawing APIs, better support for vector graphics authored in SVG, the <video> tag allowing streamed media playback as simply as embedding images and the streamlining of tag usage.
  • A richer styling language: the Cascaded Style Sheets v3 specifications. CSS3 is now famous for its ability to create rounded corners, but more importantly includes so-called “transforms” allowing graphical effects like moves, rotations, gradients, etc. as well as 3D graphical objects manipulations. Much effort as been put by browser vendor to support hardware acceleration for CSS3 rendering. However, the standard is not yet mature and today requires using prefixes specific to each browser.
  • Application-oriented advancements in the browser, as well as matching JavaScript APIs: the Web Workers offering background and concurrent execution capabilities; a Web Storage allowing simple local data storage and manipulation in XML; and a Web SQL Database  providing the capability to perform SQL queries on large amounts of data stored locally and replicated from a server.
  • Mobile-oriented advancements (not yet finalised in the specs) including JavaScript APIs for Geolocation, Device and File APIs
  • Miscellaneous additions catering for the Semantic Web (microdata), security (cross-domain HTTP requests), and more.

To the above set of technologies standardised by the W3C we should add a domain that has sprung out of both proprietary or open-source efforts: high-performance JavaScript runtimes within browsers and JavaScript Application Frameworks. The latter extend the capabilities of the web, turning it into a full-blown client-side application platform much in the same way that UI and application frameworks like Qt or Gtk extend the “bare” Linux OS framebuffer. Such application frameworks include complementary JavaScript APIs, and rely on CSS3 to provide extensive sets of UI controls. Some mobile-specific frameworks (like Phonegap or BONDI, an offspring of the mobile operator community) go as far as providing additional device APIs for smartphone features like messaging or camera, while others provide a rich set of UI controls mimicking the native platform look & feel (more on this later).

Why the clash with Flash ?
There’s no denying that the capabilities brought forward by the emergence of the HTML5 “family” bring browser runtimes on a par with core capabilities of the Flash Player, which if adopted widely could make Flash redundant.

In the eyes of most mobile industry observers, the delays in bringing out a fully-featured Flash Player with acceptable performance on smartphones have played in favour of HTML5. Remember that, as of today, Flash Player v10.1 is only available for high-end smartphones that run the Android version 2.2 operating system. I would estimate that these represent only 1% of the overall smartphone shipments in Q2. This is a far shot from Adobe’s self proclaimed goal of having Flash shipping on 50% of smartphones by 2012 (see my previous article on this topic).
smartphoneos_share_q2_2010

Figure: Smartphone Operating Systems – Q2 2010 Shipments share (source: Gartner, Google)

Company Browser / OS HTML5 compliance
Nokia Symbian S60 5th Ed. 7%
RIM Blackberry v5 0%
RIM Blackberry v6 (Torch)* 69%
Google Android v2.1* 50%
Google Android v2.2* 59%
Apple Safari for iPhone (iOS 4.0)* 62%
Microsoft IE Mobile (Winmob 6.5) 0%
Opera Opera Mini (on iPhone) 9%

Figure: HTML5 compliance of mobile browsers
[some notes on the methodology: HTML5 compliance was carried out using html5test.com. (*) denotes a WebKit-based browser. The Nokia Symbian S60 browser, albeit based on an old version of WebKit, scores poorly in HTML5 compliance tests. I could not test Mozilla Fennec, Palm’s WebOS browser, nor Opera Mobile.Opera Mini is a special case due to server-side rendering.]

Making things worse, Apple has stayed firm on its policy to not allow the Flash Player browser plugin on its iOS devices (iPhone, iPad and iPod Touch), preferring to rely on its in-house video streaming capabilities developed within its HTML5-capable WebKit browser core and QuickTime player. And to make things even more complicated, Steve Jobs’ “Thoughts on Flash” have played a key role in fanning the flames of the “Flash is dead, long live HTML5” fire.

Moreover, Google’s Android, Palm’s WebOS and, more recently, RIM’s Blackberry also embed web browsers based on WebKit that score very high in terms of HTML5 compliance, as can be seen in the table above.

Thanks to WebKit, half of the smartphones being shipped are poised to have the Flash-like capabilities brought by “HTML5” built into their browsers. However, let’s not rush in declaring Flash “dead” and Adobe a company in decline as a result.

Does HTML5 matter to Adobe ?
HTML5 is actually good for Adobe’s business. Indeed most of Adobe’s revenues do not come from Flash as can be seen by breaking down the Flash product portfolio::

  • The Flash Professional tool, is the authoring software for creating Flash content. It ships standalone or within the Creative Suite bundle. This is where Adobe makes its money as can be seen from the “Creative Solutions” BU share of the chart on the side (courtesy of Business Insider’s “Chart of the Day” series). Creative Suite also includes the massively popular Dreamweaver web design tool, and Illustrator, a vector graphics design tool, both of which which are now starting to incorporate HTML5/CSS3 design capabilities. Adobe has also hinted that Dreamweaver will be able to convert Flash timeline animations to Javascript/CSS3 code to render those animations in “HTML5” compliant browsers. This means that “HTML5” will not be a threat to Adobe’s main source of revenue. On the contrary, since there are few good commercial web design tools, the rise of “HTML5” will spur demand for Adobe products.
  • The Flash Player: the plug-in is free and is therefore represents  an R&D cost for Adobe. No impact there. One might argue that, if HTML5 were to totally eliminate the need for the Flash Player, it would the positively impact Adobe’s bottom line in the unlikely event the company were to lay off the entire Flash Player team 🙂
  • The Flash “Platform”: “auxiliary” products that rely on the Flash Player include the Flash Media Server and Flash Access product ranges, licensed to organisations that use Flash to deliver streamed video content (e.g. Hulu, Influxis, Brightcove). The “Platform” also includes the commercial Flash Builder IDE allowing the development of Rich Internet Applications (and the associated free and open-source Flex framework). As can be seen in the chart, these represent a minute proportion of Adobe’s revenue. As we will see further down, these products are not going to disappear overnight due to the emergence of HTML5.

However, HTML5 does put competitive pressure on the product management and engineering teams responsible for the Flash Player to out-innovate the evolutions in browser technology. Adobe points out that this is “business as usual for them” as –they say- it was never their intention to fully replace the browser altogether, but rather complement its capabilities with innovative features, and harmonise areas in which standards have been implemented in an inconsistent fashion across browser runtimes.

As an engineering-driven company, Adobe aims for Flash to stay one step ahead of HTML5 technology implementations, as it already is today in numerous areas. Indeed, an agile R&D division within a single corporate entity will always be faster than a “snail driven by a committee” as the W3C HTML5 spec bodies have been dubbed by some.

Some areas where Adobe is pushing the envelope for the Flash Player include 3D rendering with hardware acceleration, concurrency support, IP TVs and peer-to-peer media delivery. The latter is an interesting transposition of the file-sharing P2P concept; imagine tens of millions of users watching the same live video coverage of the opening ceremony of the 2012 Olympics in London. No server farm or CDN today is capable of sustaining such a peak demand. By allowing instances of the Flash Player across millions of peers to share chunks of the video stream at the edge of the network could be the answer to the problem.

Beyond innovation, another aspect to factor in is that HTML5 is still in its early stages of implementation across browsers, with Microsoft’s uber-popular Internet Explorer browser today lacking any form of HTML5 support whilst representing close to 60% of the web user base (see chart below). Even with the IE9 beta improving HTML5 support and other browsers consistently gaining market share it will still take some years before HTML5-capable desktop browsers dominate the installed base. This will justify the existence of Flash in the desktop browser space for years to come and give some leeway to Adobe’s engineering teams in designing more innovative capabilities.

Desktop browser market share

Company Browser HTML5 compliance
Microsoft Internet Explorer 9 beta 32%
Microsoft Internet Explorer 8 9%
Microsoft Internet Explorer 7 4%
Microsoft Internet Explorer 6 0%
Mozilla Firefox 4 beta 5 68%
Mozilla Firefox 3.6 46%
Mozilla Firefox 3.5 42%
Google Chrome v6 72%
Apple Safari v5 69%
Opera Opera browser v10 53%

Figure: Desktop web browsers users share and level of HTML5 compliance
(sources: wikipedia and test conducted with https://www.html5test.com)

Reality check: comparing Flash and HTML5 in key areas
So how is Flash vs HTML5 faring today? For review purposes we can single-out a few key areas of Flash and HTML5 competition, specifically display advertising, video delivery, games and application development.

Display Advertising: a slight advantage for Flash
One of the main use cases for Flash (and big source of annoyance to web users) is display advertising. “Display” adverts are animated banners that appear at the top, side or overlaid in front of the web content you. As annoying as they may be, display ads are a necessary evil for the online world since they represent 40% of the revenues that the digital content and e-commerce ecosystems live on. Even Google uses Flash in its DoubleClick Studio rich advert SDK for advertisers.

Some have said that because HTML5 will kill Flash, those annoying ads will disappear. I would rather think that they may be replaced by equivalents designed in HTML5/CSS3, with the caveat that they may look crappier in most of today’s browsers than their Flash counterparts, as can be seen from these examples.

Indeed a point often overlooked is that today’s HTML5 graphical rendering capabilities are at the level of what Flash capabilities were some years ago and CSS3 transforms allowing to design good “eye-candy” are inconsistently supported across browsers. Therefore I would argue that advertisers will hold back from using “HTML5” for display ad creation in the medium term. The lack of proper HTML5/CSS design tools will also delay this technology adoption by design agencies and creative professionals especially within  industry circles where Flash is deeply entrenched.

On mobile devices, the situation will be no different. The blue legos now seen on iPad and iPhones may soon be replaced by HTML5 counterparts; or even by iAds. However, as of today, Apple is the only company creating iAds (in the process levying a hefty ad tax) and is reported to be struggling with the demands of advertisers with its in-house HTML5-based ad creation tools and technologies.

Video Delivery: advantage for Flash
Another area in which “HTML5” has been touted a “Flash killer” is online video delivery. Let’s have a look. As far as basic video playback is concerned, Flash and HTML5’s <video> tag provide the same capabilities, so why not ditch Flash and avoid to end users the (relatively minimal) hassle of installing a plugin?

The situation is not as simple as it sounds as the various browser vendors do not yet all support the same video codecs. On one side, Apple and Microsoft are proponents of H.264; Google is pushing its opensource WebM codec (formerly the proprietary VP8 codec that it inherited through the acquisition of On2/Sorenson); and Mozilla and Opera by default supporting the free and opensource Ogg Theora.

This poses a challenge to online video publishers like YouTube since they then have to re-encode their content multiple times to support each codec.

To end users, this means that videos may not be available in the format supported by their browser. Flash on the other hand, even though it requires videos to be packaged in the FLV container format (not to be confused with encodings like H.264), is available across all desktop browsers and is used as a reliable fallback by “HTML5” web developers i.e. for the 50% or so of IE end-users whose browser can’t render the <video> tag.

Furthermore, the Flash Player supports advanced capabilities required by online publishers such as DRM protection (crucial for pay-per-view business models) and picture-in-picture overlay of multiple video sources with alpha-blending (e.g. for e-learning or overlay of contextual adverts). These capabilities may not be offered for years with the <video> tag in HTML5 browsers.

Casual Games and Visualizations
Flash is the technology that powers some massively popular “casual games” (such as Zynga‘s Farmville or Mafia Wars) played by millions of Facebook users worldwide. It also powers numerous other Facebook applications. There was earlier this year a rumor that Zynga was converting its titles to HTML5 to be able to run on the iPhone and iPad. This turned out not to be true, as it announced at Apple’s WWDC that it had ported Farmville to the iPhone as a native app; which may be interpreted as a sign that “HTML5” was not up to the task.

farmville.320x480-75 Another area in which today Flash is massively popular is that of visualizations and generative art. There is a large and enthusiastic community that has turned Flash animation into a true art form. Artists like Erik Natzke or Yugo Nakamura (of the Tha agency) are prominent examples of this community. To date, I have not seen any such artistic usage of “HTML5” technologies.

Other “HTML5” demos that have received a lot of media attention are Google’s “bubbles” doodle earlier this month, its experiment with Arcade Fire or a port of Quake to JavaScript using GWT. However, I do not yet see casual games developers or visualization artists migrating “en masse” away from Flash. This may be explained by the fact that those experiments in “HTML5” remain CPU-intensive and RAM-hungry (more than Flash in most cases), while designer-grade tools are lacking, and the fragmentation between browsers makes Flash a lot more dependable.

Applications Development: a draw
Web app development is another technology domain where the HTML5 family of technologies has been contending with Flash.

We have seen earlier that “HTML5” provides most core capabilities needed to run local applications, including code execution, storage and access to the screen. These core capabilities are now complemented by a flurry of web application frameworks that rely on JavaScript / CSS: DoJo, JQuery, MooTools and Sproutcore, to name a few. Google’s Web Toolkit (GWT) represents a particular case since it is a framework + tools package that allows to code a web application in Java and convert it to JavaScript for execution in the browsers (note how Gmail, Buzzz and other Google apps are built with GWT).

More recently, these frameworks have been forked into mobile variants: JQuery Mobile, Sproutcore Touch and Sencha Touch. Sendra is actually a case in point: the developer company raised $14 million in venture capital, a testament to the significant size of the business opportunity, and has jokingly proclaimed “The End Of Native” (see photo).

This abundance of JavaScript frameworks may be encouraging, but also represents a dizzying array of choices for the developer. This diversity limits the degree of industry-wide code reusability and fragments the pool of Javascript app developers into vertical niches.

This diversity further plays in favour of Adobe’s own web applications platform AIR (a sibling to the Flash Player) and the associated Flex framework, which uses the Actionscript programming language and allows XML-driven UI design through its MXML language.

In my own experience, seasoned developers find ActionScript and MXML a much better programming paradigm than Javascript frameworks in most developer aspects; code reuse, team productivity, tools support, debugging and ease of UI design.

In conclusion, the momentum behind web applications thanks to “HTML5”’s core capabilities and associated frameworks may seem unstopable, especially as it is driven by technology behemoths like Google and a large enthusiastic community. However this optimism is mitigated by the lack of developer productivity and the rising popularity of Adobe’s application development technologies.

What of the Future ?
Based on the earlier analysis, Flash is far from dead today. There are many cases in which Flash will continue to offer a better alternative (worst case a very useful fallback) to “HTML5” technologies due to the fragmentation in new web standards browser support.

To the question : “will HTML5 kill Flash?” there is no single answer. It all depends on which use case is considered and in what timescale.

On the desktop front, it is the lack of HTML5 capabilities in IE8/9 and their immaturity in all other browsers, that will secure the future of Flash in the medium term. At the same time, Adobe is under pressure from Microsoft, Google and Apple who are betting huge R&D budgets in the development of HTML5-capable browsers and who should be able to out-innovate Adobe in the longer term.

On mobile, the Flash Player is still in its infancy, while WebKit-based browsers are sharply rising towards ubiquity (250 million and counting as of end 2009). This gives the “HTML5 camp” an edge today, especially in the area of basic video playback and mobile web applications for which numerous JavaScript/CSS3 mobile frameworks are available. Looking forward however, Flash may still better HTML5 on mobile for use cases like casual games and animated graphics given its greater dependability and its widespread usage today in those communities.

Where would you place *your* bet?

– Guilhem

[Guilhem Ensuque is Director of Product Marketing at OpenPlug. He has more than twelve years of experience in the areas of mobile software and mobile telecoms. Guilhem was a speaker at last year’s Adobe MAX conference. His favorite pastimes (beyond mobile software strategy!) include making his baby daughter smile and sailing his Hobie Cat with his girlfriend. You should follow Guilhem on twitter @gensuque_op]