Monday, June 15, 2009


Fragmentation Stifles Innovation in Mobile and It's Here to Stay

Kenan Wang


There's a concept that we at Ondeego call the Mobility Barrier. The Mobility Barrier is our name for all the issues that prevent companies or individual developers from creating mobile applications. It is the reason that innovation in mobile hasn't hit the point of inflection, where growth becomes exponential. Right now innovation in mobile has largely been linear (with the notable exception of the iPhone). Up until a couple years ago a select group of people from the carriers or the handset manufacturers provided almost all the innovation (primarily in the form of new devices and features) in the mobile space up. "Apple has fundamentally changed the industry from a focus on hardware to a focus on software and content," says Ken Dulaney, an analyst at consultancy Gartner (IT). In response the major players in the mobile industry - the carriers, platform vendors, and handset manufacturers - are showing a willingness to work with outside groups particularly ISVs (check out the 100 Million Club http://www.visionmobile.com/research.php#The-100-million-club) to drive innovation through software and content. However, the Mobile Barrier still prevents the everyday developer from contributing much to the mobile space outside of the iPhone app store. What will change things is when the economics change so that the everyday developer can contribute to innovation too.

One lesson that Mobile can learn from the recent Web movement is that innovation is largely a product of economics. When making websites became easy and cheap enough to make, so that businesses and everyday people could contribute- that's when the web took off.

The potential of HTML to create graphically attractive web-sites and the ease with which these sites could be accessed through the new generations of web-browsers opened the Web to whole new groups. Until now, the Web had served two main communities - the scientific community (accessing on-line documentation) and a wider 'netizens' (net citizens) community (accessing e-mail and news-group facilities). Now commercial web-sites began their proliferation, followed at a short distance by local school/club/family sites. These developments were accelerated by the appearance of ever-more powerful (and cheap) personal computers (which increased both the number of netizens and the potential market for businesses) and by the increase in capacity of the communications infrastructure. The Web now exploded.

Griffiths, R. T. "Internet for Historians, History of the Internet: The Development of the Internet."


What we see is that the Mobility Barrier is preventing the supply of mobile apps from meeting the latent demand for mobile apps - there is a gap in innovation. In a study by IBM, “89 percent said they would like a higher level of personalization through the ability to pick and mix applications, services and other characteristics of the handset such as form factors and designs. Moreover, 81 percent would switch to a provider that offered greater choice for customization.”
http://www.telecommagazine.com/international/article.asp?HH_ID=AR_4564

Furthermore, a detailed look at the behavior of app phone users and non-app phone users shows promising signs of the potential for mobile innovation. http://www.gravitytank.com/apps/#

There are three main layers to the Mobility Barrier. One layer is technical issues. The second layer is business issues. The third layer is the lack of understanding of the mobile space. All of these layers are interconnected and affect each other; however, it's possible to take one area as the focus of our discussion to drive our analysis of the problem. Today we will talk about the technical issues blocking mobile innovation, particularly fragmentation.

Damith C. Rajapakse, from the National University of Singapore, School of Computing, has a superb article discussing Device Fragmentation. Rajapakse describes fragmentation as "the inability to 'write once and run anywhere'." He breaks down the reasons for fragmentation as

-"Hardware diversity, such as differences in screen parameters (size, color depth, orientation, aspect ratio), memory size (heap, persistent), processing power, input mode (keyboard, touch screen, etc.), presence of additional hardware (camera, voice recorder), and connectivity options (bluetooth, IR, GPRS, etc.).

Software diversity:
-Platform diversity, such as differences in platform/OS (Symbian, Nokia OS, RIM OS, Apple OS X, PalmOS, Mobile Linux, Android, BREW,etc.), API standards (MIDP 1.0, MIDP 2.0, etc.), optional APIs, proprietary APIs, variations in access to hardware (e.g., fullscreen support, access to local storage), and differences in multimedia support (e.g., codecs), maximum binary size allowed, etc.

-Implementation diversity, such as quirks of implementing standards (different interpretations of the standards, bugs, etc.). Incideentally, fragmentation resulting from implementation bugs/quirks is one of the most tiresome type of fragmentations, according to practitioners.

-Feature variations, such as light version vs full version

User-preference diversity, in aspects such as in language, style, etc., or accessibility requirements

Environmental diversity, such as diversity in the deployment infrastructure (e.g., branding by carrier, compatibility requirements of the carrier backend APIs, gateway characteristics, opened ports, restrictions on access to outside the network etc.), locale, local standards."


Each of these separate issues don't just add to the problem, they multiply it. We as application developers have thousands and thousands of possible variations (Rajapakse calls them Operating Contexts or OCs) to worry about. The problem is big.

Rajapakse further classifies these issues into two types of diversity:

"Essential diversity: This is the diversity that differentiates a product/service in some useful manner. This kind of diversity is intentional and often unavoidable. For example, users will continue to differ in their preferred size for a device, and the device manufacturers will continue to differentiate the devices in terms of size.

Accidental diversity: This is the diversity that - does not serve any useful purpose, is often introduced unintentionally, and is often avoidable. For example, diversity due to API implementation bugs/quirks is unintentional, avoidable, and does not serve any useful purpose"


He states that essential diversity is here to stay and will only get worse as the additional features and capabilities are added to different devices. This seems like a fairly reasonable assumption. Because each person treats and uses their mobile device so differently no hardware or feature standardization, like what has happened with PCs, is likely. Two factors contributing to increased essential diversity are:

" Desktop-class mobile applications: As devices become more capable, there is more potential for feature-rich, mission-critical (and consequently larger, and more complex) applications to move to the mobile platform. This is likely to exacerbate the fragmentation problem. Specifically, it will increase the effort required to fit one application to multiple OCs.

Growing number of new device models: Even released applications will continues to fragment, as more and more new OCs need to be supported. This fragmentation may be hard to predict, or plan for. It also becomes necessary to identify OCs no longer cost-effective to support."


Accidental diversity can be addressed, he says. Better standards would go a long way to help. However he accurately points out that the major mobile players - Carriers, Device Manufacturers, and Platform vendors play a critical role.

I believe even accidental diversity has little chance of getting better in the near future. Some efforts exist toward promoting standards and consolidating the number of platforms. Things like the Open Handset Alliance, or efforts by Sun may help in the long run. However, with such a proliferation of platforms in the market, more platforms entering every day, and no pressing need for the major players to reduce fragmentation, fragmentation will only get worse in the near future, and will be slow to get better.
http://disruptivewireless.blogspot.com/2008/03/handset-os-fragmentation-is-here-to.html

Rajapakse also discusses at length the various ways of dealing with fragmentation. http://www.comp.nus.edu.sg/~damithch/df/dfApproches.htm

We use what Rajapakse calls the All-In-One, Self Adapt approach to dealing with fragmentation.

Labels: , , , , , , , , , , ,

Monday, June 8, 2009


4 Keys to a Great Developer Ecosystem

The Pre's biggest disadvantage is its app store, the App Catalog. At launch, it has only about a dozen apps, compared with over 40,000 for the iPhone, and thousands each for the G1 and the modern BlackBerry models. Even worse, the Pre App Catalog isn't finished. It's immature, it's labeled a beta, and Palm has yet to release the tools for making Pre apps available to more than a small group of developers.

- Walt Mossberg, Wall Street Journal, June 4, 2008

With the rise of new app stores, attracting developers to a platform or app store is important to drive revenue and stay relevant. Today’s consumers know that “there’s an app for that,” and they want that app on their phones. If today’s carriers or handset manufacturers can’t offer those cool and useful apps, consumers will switch to another platform, carrier, or app store to get them.

Today’s carrier or handset manufacturer is now serving more masters than ever before – in addition to their stockholders and consumers, they must now attract developers to their offering. App stores and great developer programs are a way for carriers to be more than “dumb pipes,” and maintain relevance in the rapidly growing mobile content ecosystem.

The good news is developers will flock to these new platforms and create applications. They will sell them in app stores, which will drive app store revenue, and drive consumers to these platforms. A good vibrant developer program can increase revenue, drive new consumers to devices, and add new services to devices without effort on the part of the manufacturer/carrier. (For example, see the iPhone.)

The bad news is that developer programs can go off the rails – see Palm’s struggles with their Pre development community. As you can see from the Palm testimony, when developers get mad, they use the internet to show their disapproval – like here , here and here – and thoughts spread virally amongst developers really, really easily. (A lot of developers are bloggers, active forum contributors, and avid social media users. Some of them are even SEO/SEM experts. It is one thing to be hated on the internet, but it’s quite another to be hated by the people who can get to the top of Google page.) Palm’s poor launch is a wake-up call to take a look at what makes developer programs succeed or fail.


Today’s app developers are not traditional ISVs (independent software vendors) – they are college kids in dorm rooms, experienced programmers coding after hours, and small shops run out of garages – think the early days of the internet. While larger ISVs are important and part of a vibrant ecosystem , their needs are different than those of small developers. Because of this difference in motivation, it makes sense to give ISVs a separate track, with a business development manager contact. Smaller developers, by contrast, need a contact who understands them – someone who is a developer and understands the technical and logistical problems associated with creating applications for your platform.


The keys to attracting small developers to a particular platform are simple yet often missed: give them tools, share revenue with them, communicate with them, and be transparent with your rules.


Give Them Tools

Today’s mobile application developers are looking for the most effective way to create and bring to market their mobile service. Because it is impossible (or at least very difficult) to predict what will be a runaway success in an app store combined with fragmentation issues, creating an app is a substantial upfront cost to a developer not just in cash outlays but in time costs as well. One way you can lower the barrier-to-entry for new developers to your platform is to give them great, easy-to-use tools and lower their time costs so they can spend more time developing and less time learning how to use your tools.


Apple’s iPhone SDK is a great example of this – they created tools that made it easy for developers to create visually attractive applications. Fragmentation is still a huge problem and appears to be getting worse. If you operate a mobile application store on multiple handset platforms, you must give developers tools to allow them to tackle the fragmentation issues. By contrast, Palm refuses to distribute their SDK publicly, and has about a dozen apps.


Sharing is Caring

Sharing revenue with developers is very important to attracting them to your platform. While the standard is becoming 30% with Apple App Store, other stores are picking different revenue splits. Windows Mobile went with the same split, while BlackBerry opted to give their developers a little more with an 80/20 split. T-Mobile has taken a different tack with their announced app store – it will cover all T-Mobile handsets and have a revenue share based on bandwidth use. Now that there are carrier app stores and independent app stores, it is very possible that a consumer will have more than one app store on his or her phone – even one from a carrier, one from a handset OEM, and an independent one. With that in mind, developers will sell their applications in the stores with the largest reach and the most generous revenue share. Some app stores, like China Mobile, have announced revenue splits as high as 50-50 between developers and the carrier. If your app store is not the only option, developers will seek other venues to distribute their apps.


Have a Dialog with Your Developers

Communicating with people who are developing software for your platform at their own expense is important. Forums, wikis, and blogs are the best ways to do this – developers, by their nature, will first Google a problem they encounter. Have a developer relations staffer monitor these forums, and answer questions. BlackBerry has done a great job of this – all of the developers I know comment on how responsive their developer relations staff is on forums.


Not communicating with your developers is a grave mistake. Complaints in the blogosphere are rampant about trying to get
answers to questions from Apple. Then, there is the mother of all PR/Developer Relations disasters, Palm’s actions with their PreDevCamp group. It seems that the organizers of these events signed an NDA with Palm, tweeted to their community that they signed such an agreement, and were then informed that they violated the NDA by tweeting about it. Developers will use social media to communicate with each other about your product – join the conversation or let it happen. Trying to muzzle it will lead to a disaster – such as one of the organizers of your dev community writing an article in Businessweek airing their grievances and predicting your failure. Hell hath no fury like a developer scorned.


Transparency

Developers, particularly small developers, will follow the rules of your app store. However, if you have rules regarding submissions, it is important that they be applied evenly across the community and across applications. When you don’t do this, you have the PR storm that Apple had around approvals – the process itself, approving the baby shaking application, and the Trent Reznor/NIN debacle. Whether you decide to approve everything or follow content standards, you must consistently follow this policy.


Conclusion

Today’s consumers expect mobile apps on their devices. (See the Walt Mossberg quote at the top of the article.) A thriving developer ecosystem is a great thing for a platform and an app store, and will drive revenue if properly managed. Transparency, dialog, sharing revenue, and provision of tools are keys to growing a developer community.

(Disclosure: Ondeego is a BlackBerry Partner.)

Questions? Comments? Want to discuss developer relations strategies? Reach Matt at Matt (at) ondeego (dot) com, or leave a comment.

Labels: , , , , , ,

Wednesday, June 3, 2009


Ken Singer Talks About Ondeego on Mobile Presence

Last week, Ondeego CEO Ken Singer was interviewed for the Mobile Presence podcast. Ken talks about how carriers and handset makers can empower developers and drive revenue in their app stores.

Labels: , ,

Monday, June 1, 2009


Flurry: Analytics for Mobile Apps

Flurry: Mobile Analytics Provider

I was recommended Flurry (http://www.flurry.com) by one of our friends at Trend Mobility (http://www.trendmobility.com). Flurry is a really cool mobile analytics service that works across almost all platforms (just like Ondeego's applications). With just one snippet of code, you get close to real-time analytics and insights about your app and how it gets used. It's like Google Analytics for mobile – you even get pretty graphs in flash on your analytics page. Cool product, responsive team – a good thing, all in all. If you’re a mobile app developer looking for insights into consumer behavior, or a brand seeking to understand who actually uses your app, it might be the piece you need.

(Disclosure: We use Flurry to track some of our applications. )

Labels: , , ,