Month: December 2014

Categories
Business Community

Can the app stores sustain 5.5 million developers?

5.5 million developers

In our latest report, App Economy Forecasts 2015 – 2017, we estimate the number of mobile ecosystem in 2014 at 5.5 million developers. Demand for mobile development skills has never been higher and yet revenue from app store sales cannot possibly pay their salaries. Luckily they don’t have to as developers aren’t all building apps full time and there are several other revenue sources in the app economy, some of them comparable with or even significantly larger than the app stores.

Βlueprint of the app economy preview 4

Estimating the developer population

Counting mobile developers is hard. A lot of software developers look into mobile platforms and a lot of people are curious enough about how they’d make an app for their phones that they’ll try to find out. We can’t meaningfully count all of these as mobile developers. However, we also know from our Developer Economics surveys that a huge percentage of developers creating the apps that fill the app stores are not full-time professionals. Popular programming Q&A site StackOverflow has around 35 million unique visitors and it is only an English speaking community. That probably includes a lot of students trying to get help with their coursework. Meanwhile bottom up estimates for the global professional developer population based on job classification data from multiple sources are just under 20 million. This is highly error-prone due to the way developers are classified along with other IT professionals in many places around the world. How many of those are really building mobile apps anyway? Apple has over 9 million developers registered on their developer portal. Some of those are for Mac and Safari but the majority are iOS developers. Then again, the number of developer accounts with any apps published on the App Store for iOS is only around 350,000. Google Play has fewer active publishers than iOS. The truth must lie somewhere between these extremes.

For the purposes of our estimate we decided to count developers who are actively building, or planning to build in the very near future, publishable apps for a mobile platform. Students building toy apps to learn and hobbyists who only build things for themselves aren’t taken into account. Those people could join the ranks of mobile developers in the near future but they aren’t doing anything to satisfy mobile app demand yet. 5.5 million is the number of developers required to maintain all of the published apps that have been updated in the last 12 months, plus build all of the new ones released in the same period. In our report we also forecast the number of new and updated apps going forward and the number of developers required to sustain that app growth through 2017.

Keeping the pizza and coffee flowing

Developers are in high demand and as employees in the US they will typically earn upwards of $100k per year with relatively little experience. Proven talent in Silicon Valley can easily earn 50-100% more. Salaries in Western Europe are not quite as eye-catching but not that far behind either. In countries where the cost of living is much lower, developer salaries are obviously more modest but actually often a greater multiple of the national average wage.

Why would anyone with such earning potential build and sell apps that are likely to produce a poor return on their time. There are several answers:

  • Some apps make fantastic returns and some developers believe, or at least hope, they could emulate those and use their skills to make a small fortune
  • Other developers are trying to build small but sustainable businesses on the app stores, targeting niches and working as artists and entrepreneurs
  • Some developers build their own apps as proof of their abilities in order to sell their skills for a higher rate on contract development work
  • Many developers just love to code and already earn a full time salary in their day job, they build apps as side projects or for a hobby, either for fun, a little extra income or to sharpen their skills for their next career move
  • Some developers are purely learning and having fun, usually either at the beginning of their careers and in some cases after they’ve retired.

Note that only the first two of these are depending on the apps for income. Of course not all developers are trying to make a return from apps via paid downloads or in-app purchases. Advertising is also a big source of revenue in the app economy, although most of it goes to a few giant corporations. The typical developer monetising through ads does much worse than those using in-app purchases, so that’s not the answer. However, there are other models where developers have better odds of making money. Subscriptions are the fastest growing revenue opportunity according to our forecasts, although for pure Software as a Service rather than content subscriptions that will mostly be selling to enterprises. The biggest revenue opportunity of all in app economy over the next few years is definitely not in pure software businesses. Indeed, it’s the rather old-fashioned business of selling real physical things! Find out just how big it is by purchasing our latest report.

Categories
APIs

4 + 2 tools for a happy multi-cloud developer

It is exciting to be a developer these days. You’re the talk of the town and everyone looks for ways to make you happy, competing to create new tools or new services just for you. Developing a great app in such a mesh of services shouldn’t be an issue. Still, this often proves to be a daunting task. Just like the last time you wished to deploy in the cloud and there were 15+ various different services you had to consider.

sdks-de

– OK, so what is the problem? Having many alternatives is good … Right?

Well, that depends…. Here’s an example…
Let’s take the app we just talked about. To develop an app for cloud “X” you will need to download the SDK or Toolkit of that cloud and start writing code to use it. But what happens if you wish to switch to another provider? In case you want to change to cloud “Y”, you will need to download the toolkit for the new cloud. Cloud “Y”’s toolkit in turn has its own structure, syntax and design.

What can you do?
1. Stay on the same cloud…
2. Switch to another cloud. That is: Remove the old cloud code; download the toolkit of the new cloud; understand how it works; learn its particulars and re-design your app around it. Quite complicated, isn’t it?

It is clear that switching to another cloud provider is becoming difficult. Should you stay or should you go? This problem can be solved by two ways: standardization or 3rd party tools.

There are currently two organizations competing to come up with a standard for all cloud providers. These two standards are the CIMI / Cloud Infrastructure Management Interface and the OCCI / Open Cloud Computing Interface. The problem is that neither CIMI or OCCI are very widely used – instead of standardising, providers are increasingly coming up with their own APIs. Which leads to the 3rd party tools solution.

Cloud providers offer REST APIs for their services, but these often differ at the details. Cloud libraries or multi-cloud toolkits try to fix this by offering an abstraction layer over these services, allowing interaction with various cloud providers. They hide away their differences, provide one view and a unified API and eventually make moving between cloud providers easier. With their help, you can avoid getting stuck with one vendor. You only have to download the toolkit and write the code to use its API, which in turn will communicate with the cloud services. To switch to another cloud, you will not need to download another SDK or toolkit. You simply need to write some code (which is what you do anyway) to “talk” to both clouds.

What is out there?
There are several open-source, multi-cloud toolkits that you can use in your projects. Which to select largely depends on your coding language, cloud provider and service you need to work with. There are 4 main types of services supported by these toolkits:

  1. Compute nodes (Start / Stop instances or configure)
  2. Data Volumes (Creating / Attaching / Delete volumes, snapshots etc.)
  3. Load Balancers
  4. DNS

Note that not all providers are supported or willing to hand you over all the above four functionalities. To choose therefore the tool that best fits your needs, you need to do some homework.

To understand why you need to do any homework, let’s consider an example.

Assume you want to deploy and integrate your application and you only have to select between Amazon AWS and Microsoft Azure. Which are the best tools for you?

Apache Libcloud – Python

In 2009, Cloudkick created a SaaS cloud monitoring and management platform as a means of “talking” to many different providers. That early version of Cloudkick was later released as an open source Apache project and was finally acquired by Rackspace and replaced by Rackspace Cloud Monitoring.

Libcloud is a library that abstracts the differences between cloud providers. It allows you to manage different cloud resources through a unified and easy API. It is an open source project with a single Python interface of 35+ cloud providers and their services. Below is a list of the features and supported providers:

SERVICE AWS Azure
Compute 40+ YES
Block Storage 17+ YES
Cloud Object Storage 8+ YES YES
CDN 6+
Load Balancers as a Service 7+ YES
DNS 6+ YES

Libcloud is the de facto choice for devs into Python and is supported by a great community. The documentation on their website is pretty good.

Let’s see some community stats:

  • Stackoverflow questions: 160
  • Github repositories 176
  • Most Github Stars (on single project) 518
  • Github Code results 2.2M
  • Google search (name + “libcloud”) 80K

Notice that Libcloud does not fully support Azure. For the time being it only supports Azure Blob Storages plus many of the AWS methods.

More about Libcloud at:

Note 1: If you exclusively work with AWS you may want to check Boto < https://github.com/boto/boto>. It is a Python library for interacting with AWS APIs which allows you to build tools in Python, change and manage your AWS resources.
The project is led by an Amazon Engineer.

Note 2: If you feel adventurous, take a look at Libcloud REST, a Google Summer of Code 2012project which exposes most of the Libcloud functionality over HTTP.

Apache Jclouds – Java, Clojure

Jclouds, now one of the most popular solutions, started off as a project from Adrian Cole who later joined the Apache incubator. Adrian Cole is considered an active community leader in the cloud interoperability, REST and DevOps space. His current title is “cloud guy” at Twitter. Jclouds is an open source library that allows you to use portable abstractions or cloud-specific features and supports Java and Clojure.

Let’s see what kind of cloud resources Jclouds can manage:

SERVICE AWS Azure
Compute 17+ YES
Block Storage 7+ YES YES
Cloud Object Storage
CDN
Load Balancers as a Service 2+ YES
DNS

Jclouds, being a Java toolkit, naturally relies on a great community to support it. They also have excellent documentation on their website.

Here are the community statistics:

  • Stackoverflow questions 26
  • Github repositories 52
  • Most Github Stars (on single project) 531
  • Github Code results 7K
  • Google search (name + “jclouds”) 33K

While Jclouds supports some of the AWS services, it does very little on the Microsoft Azure side. In fact, it does not go beyond Azure Blob.

Note: There seem to be some early Azure implementations in the Jclouds labs. If interested, take a look or even contribute to their project.

More about Jclouds at:

Fog – Ruby

Wesley Beary, currently working at Heroku, is a great Rubist and the creator of Fog back when he was at Engine Yard. Fog is a cloud provider agnostic toolkit, therefore it supports a variety of cloud providers. The Fog gem is the most popular cloud SDK in the Ruby world and it is heavily used with over 4M downloads and a large and active community contributing to its development. It is an MIT-licensed open-source community project and is also used as basis for other Ruby gems like Chef.

SERVICE AWS Azure
Compute 25+ YES
Block Storage 9+ YES
Cloud Object Storage
CDN
Load Balancers as a Service 2+ YES
DNS 10+ YES

You can find many tutorials about Fog and its implementation online and adequate documentation on their website.

  • Stackoverflow questions 279
  • Github repositories 188
  • Most Github Stars (on single project) 3230
  • Github Code results 305K
  • Google search (name + “fog”) 565K

While currently Fog supports some of the major AWS services, it supports nothing on Azure! There are various discussions around the net about whether Fog will eventually go that way but, for the time being, no ongoing relative efforts exist other than some sparse GitHub repositories. Thus, if you are a Rubist and Azure user, the official SDK is a one-way option.

More about Fog at:

Apache deltacloud

RedHat wanted to develop an open cloud, vendor neutral so they started Deltacloud in 2009 and later joined the Apache incubator. For all you Rubists outhere, Deltacloud was written in Sinatra.

While Deltacloud is not the only open source project to offer cloud abstraction, it has a remarkable difference: Libcloud and Python, Jclouds and Java, Fog and Ruby are programming language-specific libraries. Deltacloud on the other hand is independent of the programming language and can also be used as web service. It provides three different APIs for interacting with Cloud service providers (a RESTful API, a CIMI-compliant API and a proprietary API) and is backward compatible across different versions of support cloud platforms.
Let’s see what kind of cloud resources and providers it supports:

SERVICE AWS Azure
Compute 15+ YES
Block Storage 15+ YES YES
Cloud Object Storage
CDN
Load Balancers as a Service
DNS

Apache Deltacloud has an active community of programmers who constantly update it. You may find adequate info both in their website and online to get you started.

  • Stackoverflow questions 10
  • Github repositories 37
  • Most Github Stars (on single project) 80
  • Github Code results 34K
  • Google search (name + “deltacloud”) 23K

More about Deltacloud at:

…and 2 bonus tools

1) Do you like to play with node.js? Check pkgcloud! It is a standard library for node.js that abstracts away the differences among multiple cloud providers. It supports the usual Cloud resources and providers. Interestingly, it supports Azure Compute resources which is not the case in any of the above toolkits.

2) If you are the Erlang type of dev take a look at elibloud. An Erlang wrapper around Libcloud.

Community Statistics Comparison

Below you will find two charts: a comparison of the number of cloud providers supported by each of the above toolkits and some community statistics.

cloud-providers
community-statistics-comparison

Conclusion

Since 2006 the number of cloud providers has been steadily growing, bringing more services in the game. This is good news for developers, as more options become available to choose from. Using tools that provide a single interface to work with all these services can prove of great value to you, facilitating a potential transition from one provider to another. Still, good research prior to choosing a toolkit is essential. In our example, it becomes clear that Azure support from the toolkits presented is problematic, which is not the case for AWS (there could be many reasons for that, some originating in the very nature and definition of the Azure API). It seems that the development of toolkits is still a work in progress and things will soon start moving. Support of all major cloud providers is only a matter of time – and a game changer!

Do you use any kind of multi-cloud toolkits?

Categories
Business

Are Freemium Apps Killing Game Developers?

The rise of freemium games has been ferociously quick and it continues to accelerate at an incredible pace. It’s estimated that adults now spend, on average, 5 hours and 46 minutes online and on their mobile devices. Time spent online has now surpassed time spend watching TV.

Blog002_Final

With more consumers than ever playing games on their mobile devices, developers have had to “evolve” to find the most efficient ways to monetise their potential customers and, from a revenue perspective, [tweetable]the ‘freemium’ model has almost completely killed ‘paid-for’ games[/tweetable].

Putting morals and ethics aside, the freemium route is absolutely genius. Freemium, especially on mobile, can generate vast amounts of profit for developers who manage to create popular applications.

When we ask the question, “are freemium apps killing game developers?”, it always generates an interesting debate. Let’s understand why.

What are freemium apps?

The term freemium can be defined as:

“A business model that provides a game to players free of charge, but charges a premium fee for special features, powers, or content.”

Take a look at the App Store whilst reading this post and you will see the overwhelming majority of top grossing applications are free to download.

freemium-business-model-3

To developers, these applications would be classed as “freemium” apps, but the majority of users who download these type of applications believe the developer is making it as difficult as possible to progress within the application in order for you to purchase ‘upgrades’, ‘coins’ or ‘power-ups’ that allow you to progress within the application.

freemium-business-model

Freemium applications started as an experiment, but very quickly became mainstream. In fact, it was reported last year that 76% of all iPhone app revenue came from in-app purchases.

From a developer’s perspective, freemium games are the preferred route. It’s where the majority of download volume exists and the highest earning revenue streams can be found. Most importantly, their prospective customers’ mindset has shifted. If you are not a ‘free’ game or application, you will have a much harder time selling yourself.

When you speak to independent game developers, they will tell you that more and more revenue could be generated from a free-to-download application. Take an example of a subscription-based game which might charge $20 a month to play. Only a few people might ever be willing to spend that – but far more would be willing to spend 10% of that on a freemium type game. The reality is, when you look at the metrics, there is little to no comparison. Free apps with in-app purchases are potentially much more lucrative.

On the other hand, there may be customers who, even if they were spending $20 a month on a game, would be willing to spend even more if they had the opportunity to. Legacy games never offered that type of flexibility, but things have changed and the top games developers are reaping the rewards.

The thought of ‘what if?’ really did start a new line of thinking. A line of thinking that eventually took the freemium model mainstream.

Why is Freemium seen as bad?

When you look at games from a hardcore gamers point of view, with the above scenarios in mind, you soon realise that the freemium trend is a real negative for them and their style of playing.

[tweetable]The core underlying aspect of freemium games is that you have to pay to continue playing[/tweetable]. Rather than pay a one off fee for a game which would take even the most dedicated gamer a while to complete, there are now deliberate parts of a game or application that force you to spend money in order to overcome a problem.

Roadblocks deliberately placed by a developer force a gamer to spend if they want to continue progressing. It’s this understanding, which has led to many negative reviews of freemium games and the mobile gaming industry in general.

When it comes to developing, freemium games are, arguably, easier for much larger game publishers to make, because these types of games require much more iteration than a traditional paid-for game might demand.

This means that the true independents have a higher barrier to entry than they did before. People expect a lot for free, and if you are not monitoring your audience with a deep level of detail, it’s very difficult to understand when the best time to monetise might be.

Example of the freemium model

Examples of the freemium model taking place inside a game can be found in many different scenarios:

Energy bars are everywhere. The new ‘World of Warriors’ game and ‘Clash of Clans’ from Supercell are good examples of energy meters. In both games, you have ‘food’ and various other ‘elixirs’ which are essentially energy meters. If you have ‘0’ food, you can’t play until it recharges. Regardless of what shape these roadblocks come in, they all serve an identical function: to slow down a player’s progress.

Mobile games would also appear to be getting easier and easier. The majority of these games would not work if a gamer could engage with them and play them for an hour at a time.

Energy meters and time constraints mean that you can only really play an app in small chunks. Unless you pay.

Naturally, a percentage of all users don’t want to wait for their timers to be refilled, so they will pay to get passed what was intended to be a roadblock.

In older, more traditional games, if the player was stuck at a specific part of the game, they would work hard to try and find a solution to the problem they face. However, now if you run into a problem, no matter the quality of the gamer, to get past what might once have been a complex problem – you can pay.

Another very common freemium model is charging for virtual items.

It’s difficult for game developers to understand what is a fair price to charge for various virtual items, but developers are now moving towards simpler monetisation tactics. For example, skipping a level or buying a considerable item which gets them past what was supposed to be a difficult level.

The problem with this is that items like ‘level skipping’ could be free, because it doesn’t actually cost the developer anything to offer hints.

If you compare this with a game we all know, Call Of Duty, giving a player the opportunity to buy new weapons or customise a character has cost the game developer/designer time and money.

Are freemium games killing developers?

Whilst consumers have obviously voted with their wallets that freemium games and applications are what they want to buy, some of us at Tapdaq believe that this has squeezed independent developers into a corner they might not necessarily have wanted to end up in.

There is no doubt about it, I think it’s harder to devote time into creating a game which is long and complex simply because of the natural shift to more casual gaming.

As with all markets, there are two sides to it. In this particular market, you have developers and you have players. If game players are so anti freemium games, then they need to do their bit. They need to start spending money on items which actually cost the developer resources to make, as opposed to buying hints and level-skipping upgrades which defeat the object of playing the game in the first place. They need to value the mobile gaming experience.

New freemium games come out every week in today’s quickly evolving mobile gaming market. This is a business model that, for the foreseeable future, will impact the games we all play. Therefore, game players need to go out and support games that are fair as well as fun to play. Players passionate about game sustainability must vote with their wallets as well as their words.

Looking at the graph below, freemium is proving to be great for developers, but it might have adverse effects, and who knows when we might start to see diminishing returns.

Freemium still has a large share of the market, but it’s unlikely to make you rich.Freemium still has a large share of the market, but it’s unlikely to make you rich.

I think we’ll continue to see larger game developers dominate the top grossing in various app stores for the foreseeable future, and I don’t think freemium as a business model for games gives a fair platform for genuine independent studios to thrive. However, individuals and small studios who create games are usually far more dynamic and should adapt to evolution faster than larger corporations.

So, is freemium killing developers? The answer is, we can’t be sure yet. One thing is certain, though,the industry will continue to be driven by its customers and customer perceptions of “free” games. Recent events have shown that there is a split between those who are happy to pay for games and additional content within them, and those who expect the game or updates to be free.

A winner for preferred business model has not yet emerged on the mobile platforms, and it is very possible that mobile gaming will evolve in a similar vein to its desktop/console brethren – with games adopting different monetisation methods based on their audience, content and personal preferences.

Let me know what you think in the comments below.