Fragmentation Stifles Innovation in Mobile and It's Here to Stay
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: app developers, carriers, developers, fragmentation, handset fragmentation, handset makers, hardware diversity, mobile marketing, mobile platform, mobility barrier, porting, transcoding