Android's Lessons for New Mobile Operating Systems: Community

While Android and iOS presently have the smartphone market largely sewn up, other mobile operating systems are in the works or will arise over time. For example, Mozilla is creating Firefox Mobile OS as their entrant into this space.

In this blog post series, I will explore some lessons that I think we can learn from Android’s successes and failures that can help new mobile OSes as they try to break into this space. Today, I’d like to focus on community.

There are several ways to go after an established market with large incumbents.

One involves a head-on assault, using marketing dollars and related forms of clout to try to get market attention. This is how Microsoft is going after the smartphone market with Windows Phone.

Another involves taking a flanking position first, to try go gain credibility in some slice of the market and expanding from there. Amazon’s second-generation Kindle Fire represents a head-on assault on tablets, but their $50/year 4G mobile data plan on the top-end Fire serves as a flanking position for the smartphone market, should they attempt to go after that in the future.

The third is a guerrilla approach, trying to win from the grassroots up. This is the most likely avenue of tactical success for new entrants, such as Firefox Mobile OS, as both expectations and costs are manageable.

With that in mind, what can we learn from Android that can apply to new entrants in the mobile OS arena?

Force Multipliers

We like to toss around terms like “ecosystem” and “community” to refer to the entire set of groups and individuals with a vested interest in the success of certain products. From the standpoint of the mobile OS vendor, though, you might want to think of the ecosystem as being force multipliers, to steal a term from the military. The developers, bloggers, and other early adopters can help you push your OS, but only to the extent that you help them to do so. What you get out is what you put in.

In some cases, “what you put in” can seem lightweight but carry significant impact. One of the most insightful moves that Google made with Android was to make the bugdroid mascot available under a Creative Commons license. It is unclear whether they truly envisioned the impact that the lil’ green guy would have, but bugdroid puts a face to the Android name, even if that face is merely artwork. Today, bugdroid is used in everything from television commercials to blog banners, helping to tie together an otherwise disparate ecosystem.

This does not mean that having a cute readily-licensed bit of mascot is some sort of magic bullet, one that will make a mobile OS succeed on its own. But it is one way of helping those who want to help you do just that, in a way that, over time, will help build brand momentum.

Apps: Numbers and Names

Hardware specs — like mono speakers versus stereo speakers on a tablet — are something that help buyers choose between substitutes within a market. All else being equal, they will go with the stereo speakers… except that all else is usually not equal.

However, such specs only matter when you are perceived as a viable substitute. Right now, smartphones are perceived as a substitute if they successfully answer the question: “can I get what I want?”. And, to a large extent, “what I want” comes in the form of apps, or content powered by apps.

Buyers will have questions about apps with your mobile OS:

• “Can it run XYZ app?”, for apps they have used elsewhere, or apps that came strongly recommended from friends, etc.
• “Can I do XZY on the device?”, for things they know they want in general but may not have particular apps in mind (“can I watch videos?” “can I connect to my office VPN?” and the like)
• “How many apps are there?”, as a general guide for determining whether or not they are likely to find a solution for a need they do not presently know that they have

This is where trying to enter the mobile OS space will be troublesome. Having an OS is one thing; having an OS and apps is quite another. Amazon, for example, has to defend their AppStore for Android’s size, being a shadow of what the Play Store has… and Amazon has 50,000 apps at present. It will take a new entrant quite some time to get to 50,000.

Your Developers Are Key Early Adopters

That’s why courting developers early on and convincing them that there is a reason to pay attention to you is important. Back when Android hit the scene, developers and users took to Android in part because Apple limited iPhone’s availability, and markets, like nature, abhor a vacuum. But now that Androids (and iOS devices to a lesser degree) are available in most countries for most carriers, the vacuum is gone. Maintaining multiple ports of apps is a pain, and porting to an unproven platform will not make sense to many a developer.

Hence, you need to go out of your way to make sure that getting apps on your platform is as easy as humanly possible. That includes things like:

• Hardware seeding programs, whether through device giveaways, loaner programs, or bulletproof ways to get your mobile OS onto other existing devices

• A clear path to volume (e.g., Firefox Mobile OS playing up the Web aspects, showing developers how to create apps that work well on their OS and regular Web browsers, and perhaps even on other mobile platforms the developers have not yet targeted)

• Copious support, from documentation to clear ways to get authoritative answers — if a new entrant tries Google’s “volunteer only” approach towards answering developer questions, the new entrant is unlikely to fare well

Reuse Makes the World Go ‘Round

Another key element for getting developers on board is a clear model for reuse. You need to make it dirt simple for developers to get apps onto your platform. Some of that may come from you directly, but you really need the force multiplier effect of other developers if you are “coming from behind” within a market. Having an easy way for developers to contribute components — from UI widgets to utility libraries to app “bootplates” — will be important as you try to woo the next generation of developers to contribute apps to your platform.

Once again, Android was able to skip this part, because it was able to fill a gap in the market offerings, though it is suffering today due to the lack of a reuse model and go-to component bazaar.

Have Humility

If you visit the Android Developer site, it would be easy to think that there is no Android developer community. Outside of links to some Google-established Google Groups, there is no sign whatsoever that third party developers exist, other than the fact that apps magically appear on the Play Store. There are no links to key third-party libraries, or a blogroll of useful developer blogs, or even a link to StackOverflow (while there used to be one that had existed for a year or so, it was removed in the site revamp in early 2012). While as individuals, Google engineers are generally awesome, as an organization, Google’s general behavior toward third-party developers as a group can be best described as “benign neglect”. You get your SDK and tools, you upload to the Play Store, and for anything outside of those aspects, you’re on your own.

You are not more important than your developers.

Yes, in a military analogy, you are the generals and the developers are the “grunts”. This means that you will be more visible and will be able to “call the shots” more often than not. But wars are only infrequently won based purely on the genius of the generals; more often, it is the grit and guile of the grunts that plays a major part. That is even more important for platforms “playing catch-up”, because “underneath each helmet is a head, and heads can think”. Developers have left Android in the past due to the benign neglect, and others will likely do so in the future. That is one thing when you have tens of thousands of developers; it is a somewhat larger issue when you have tens of dozens of developers.