The Pennsylvania State University
The Graduate School
College of Information Sciences and Technology
THE IMPACT OF PLATFORM CERTIFICATION
ON A PLATFORM-BASED PRODUCT MARKET:
THE CASE OF MOBILE APPLICATIONS
A Dissertation in
Information Sciences and Technology
by
Ankur Tarnacha
Submitted in Partial Fulfillment of the Requirements for the Degree of
Doctor of Philosophy
May 2008
The dissertation of Ankur Tarnacha was reviewed and approved* by the following:
Carleen F. Maitland Assistant Professor of Information Sciences and Technology Dissertation Advisor Chair of Committee
Steven B. Sawyer Associate Professor of Information Sciences and Technology
Irene J. Petrick Professor of Practice of Information Sciences and Technology
Thomas F. LaPorta Distinguished Professor of Computer Sciences and Engineering
John Yen Associate Dean for Research and Graduate Programs Head of the Department of Information Sciences and Technology
*Signatures are on file in the Graduate School
iii ABSTRACT
Complex Information and Communication technology (ICT) systems operating in diverse environments rely on technology platforms to ensure scalable product development and compatibility across the components that make up these systems.
Recent times have witnessed an increasing use of certification programs that seek to evaluate the reliability and compatibility of platform-based products. While various studies have focused on the phenomenon of certification, the evolution and diffusion of platforms, and the influence of certification and platforms on industry structure per se; to date little is known about platform certification programs and their implications for firms that supply platform-based products.
To address these gaps, this study examines platform certification by conceptualizing it as a market regulatory mechanism that is expected to influence the dynamics of the platform-based product market. In particular, the study investigates certification programs for mobile computing platforms and evaluates their implications for the mobile applications/software market. The study employs a multiple-case study design to explore three platform certification programs – Symbian Signed, Java Verified, and True BREW – and qualitatively assess their influences on the firms in the mobile applications market. The cases are analyzed using a conceptual framework that relates key attributes of platform certification systems, namely certification authority structure, imposed certification constraints, and perceived certification benefits, to their implications for vertical product compatibility and market entry barriers.
The study finds that platform certification systems can influence their platform- based product market through at least two mechanisms. First, the research suggests that the ways in which a certification program is managed (control structure), increases
iv vertical product compatibility. Second, the degree to which certifications are a pre- requisite to market participation (coerciveness) and the level of accommodations made by the certification program to application developer needs (flexibility), influence the level of market entry barriers.
The study extends the literature on certification by providing a conceptual framework for understanding platform certifications and assessing their impact on market development, structure, and competition. In addition, the study contributes to practice by highlighting various technical and business barriers, issues, and recommendations for effective development, deployment, and distribution of mobile applications that can potentially assist software vendors in supplying innovative and cost-effective mobile applications.
v TABLE OF CONTENTS
LIST OF FIGURES ...... x
LIST OF TABLES ...... xi
ACKNOWLEDGEMENTS ...... xii
Chapter 1 Introduction ...... 1
1.1 Research Objectives, Questions, and Scope ...... 4 1.2 Research Merit ...... 7
Chapter 2 Mobile Computing Industry and Platform Certification ...... 10
2.1 The Mobile Industry ...... 10 2.2 The Emergence of Mobile Computing ...... 12 2.2.1 Key Actors in the Mobile Computing Industry ...... 13 2.2.2 Value in the Mobile Computing Industry ...... 15 2.3 Mobile Computing Platforms and their Ecosystems ...... 18 2.3.1 Symbian-OS ...... 22 2.3.1.1 The Symbian Signed Certification Program ...... 24 2.3.2 Java ME ...... 25 2.3.2.1 The Java Verified Certification Program ...... 27 2.3.3 BREW ...... 28 2.3.3.1 The TRUE BREW Certification Program ...... 30
Chapter 3 Literature Review ...... 32
3.1 Technology Architectures and Platforms ...... 32 3.1.1 Product Platforms ...... 34 3.1.2 Computing Platforms ...... 35 3.1.3 Platforms and Business Ecosystems ...... 37 3.2 Certification: A Market Regulatory Mechanism ...... 40 3.2.1 Certification in a Supply Chain ...... 41 3.2.2 Third-Party Certifications ...... 42 3.2.2.1 Process and Product Certification ...... 44 3.2.2.2 Standards and Software Certification ...... 45 3.2.3 Certification Systems ...... 46 3.3 Summary ...... 48
Chapter 4 Conceptual Framework ...... 50
4.1 Investigating a Platform Certification System ...... 51 4.1.1 Certification Authority Structure ...... 53 4.1.2 Certification Constraints ...... 55 4.1.3 Certification Benefits ...... 57 4.2 Market Effects of Platform Certification System ...... 60
vi
4.2.1 Vertical Product Compatibility ...... 61 4.2.2 Market Entry Barriers ...... 64
Chapter 5 Research Methods ...... 68
5.1 Research Approach ...... 68 5.2 Research Procedure and Data Collection ...... 72 5.2.1 Data Sources and Sampling ...... 73 5.2.1.1 Primary Sources: Key Experts ...... 73 5.2.1.2 Primary Sources: Key Informants ...... 75 5.2.1.3 Secondary Sources: Developer Forums and Trade Press Archives ...... 76 5.2.2 Research Participants ...... 78 5.2.2.1 Key Experts ...... 78 5.2.2.2 Key Informants: Mobile Application Developers...... 79 5.3 Data Analysis ...... 82 5.3.1 Construct Operationalization ...... 83 5.3.2 Levels of Analysis ...... 86
Chapter 6 The Symbian Signed Program ...... 87
6.1 Symbian-OS ...... 88 6.1.1 Symbian-OS Architecture for Application Development and Deployment ...... 89 6.2 The Symbian Signed Certification Program ...... 92 6.2.1 Certification Options ...... 93 6.2.2 The Symbian Signing Process ...... 96 6.2.2.1 Symbian Signing Prerequisites ...... 97 6.2.2.2 Pre-Submission Testing and Developer Certificates...... 98 6.2.2.3 Symbian Signed Submission ...... 98 6.2.2.4 Symbian Signed Waivers ...... 100 6.2.3 The Symbian Signed Testing Criteria ...... 100 6.3 The Symbian Signed Certification System ...... 103 6.3.1 Authority Structure ...... 103 6.3.2 Constraints ...... 105 6.3.2.1 Symbian Signing Costs ...... 106 6.3.2.2 Administrative Costs ...... 108 6.3.3 Benefits ...... 111 6.3.3.1 Applications Security and Quality ...... 112 6.3.3.2 Marketing and Distribution ...... 113 6.4 Market Effects of Symbian Signed: A Discussion ...... 114 6.4.1 Deployment Compatibility ...... 114 6.4.2 Implications for Application Developers ...... 116 6.4.2.1 Market Entry Barriers ...... 117 6.4.2.2 Market Consolidation ...... 118
Chapter 7 The Java Verified Program ...... 120
vii
7.1 Java ME ...... 121 7.1.1 Java ME Architecture for Application Development and Deployment ...... 123 7.2 The Java Verified Certification Program ...... 126 7.2.1 The Java Verified Process ...... 128 7.2.2 The Java Verified Unified Testing Criteria ...... 131 7.3 The Java Verified Certification System ...... 134 7.3.1 Authority Structure ...... 135 7.3.2 Constraints ...... 137 7.3.2.1 Java Verified Costs ...... 138 7.3.2.2 Administrative Costs ...... 141 7.3.3 Benefits ...... 144 7.3.3.1 Unified Application Testing ...... 144 7.3.3.2 Application Quality and Security ...... 145 7.3.3.3 Application Distribution and Marketing ...... 147 7.4 Market Effects of Java Verified: A Discussion ...... 148 7.4.1 Deployment Compatibility ...... 148 7.4.2 Implications for Application Developers ...... 150
Chapter 8 The True BREW Program ...... 152
8.1 The BREW Technology ...... 153 8.2 The True BREW Certification Program ...... 157 8.2.1 Certification Process ...... 159 8.2.1.1 BREW Developer Registration ...... 160 8.2.1.2 Application Submission ...... 162 8.2.1.3 Application Testing ...... 163 8.2.1.4 Application Pricing and Deployment ...... 163 8.2.2 True BREW Testing Criteria ...... 164 8.2.3 True BREW Certification Options ...... 167 8.2.3.1 Partial-Testing Certification ...... 167 8.2.3.2 Self-Testing Certification ...... 168 8.3 The True BREW Certification System ...... 169 8.3.1 Authority Structure ...... 169 8.3.2 Constraints ...... 173 8.3.2.1 Development Investments ...... 174 8.3.2.2 True BREW Testing Costs ...... 175 8.3.3 Benefits ...... 177 8.4 Market Effects of True BREW: A Discussion ...... 179 8.4.1 Deployment Compatibility ...... 180 8.4.2 Implications for Application developers ...... 182
Chapter 9 Cross Case Comparison ...... 186
9.1 Similarities across Cases ...... 187 9.2 Differences across Cases: Authority Structure Re-Conceptualized ...... 189 9.2.1 Certification Control Structure ...... 191
viii 9.2.1.1 Certification Control Structure: A comparison across platforms ...... 192 9.2.2 Certification Coerciveness ...... 194 9.2.2.1 Certification Coerciveness: A comparison across platforms ..... 196 9.2.3 Certification Flexibility ...... 198 9.2.3.1 Certification Flexibility: A comparison across platforms ...... 199 9.3 Market Effects of Platform Certification ...... 201 9.3.1 Effects on Platform-Based Products ...... 202 9.3.2 Effects on Platform-Based Product Market ...... 206
Chapter 10 Discussion ...... 214
10.1 Conceptually Framing Platform Certifications ...... 214 10.1.1 Platform Certification and Product Certifications ...... 215 10.1.2 Platform Certification as Supplier Certifications ...... 218 10.1.3 The Role of Platform Promulgator ...... 221 10.2 Markets with Platform Certification ...... 223 10.2.1 Implications for Platform Promulgators and Powerful Actors ...... 227 10.2.2 Implications for Intermediaries ...... 229 10.2.3 Implications for Platform-Based Product Developers ...... 231
Chapter 11 Conclusions ...... 234
11.1 Research Findings and Implications for Theory and Practice ...... 235 11.2 Generalizability and Limitations ...... 238 11.3 Future Research ...... 241
Bibliography ...... 245
Appendix A Dissertation Keywords ...... 257
Appendix B Interview Instruments ...... 260
B.1 Representatives of Certification Program Offices & Certification Program Supporters...... 260 B.2 Representatives of Authorized Certification Labs ...... 265 B.3 Representatives of Mobile Application Developers ...... 270
Appendix C Research Participant Recruitment Emails ...... 276
C.1 Mailing the Certification Program Offices & Certification Program Supporters...... 276 C.2 Mailing the Authorized Certification Labs ...... 277 C.3 Mailing on Developers‘ Generic Email Addresses ...... 278 C.4 Mailing a Rolling Developer Contact Directly ...... 280
Appendix D List of Supporting Documents ...... 282
Appendix E A Primer on Network Markets ...... 287
ix
E.1 Network Effects and its Sources ...... 287 E.2 Characteristics of Network Markets ...... 291 E.3 Conduct and Performance in Network Markets ...... 293 E.3.1 Importance of Technology Standards ...... 293 E.3.2 Product Compatibility ...... 294 E.3.3 Systems Competition and Complementarity ...... 296
Appendix F A Primer on Public Key Infrastructure ...... 298
F.1 Public Key Cryptography ...... 298 F.2 Digital Certificates ...... 300 F.3 Certification Authority ...... 300 F.4 Certificate Verification and Revocation ...... 301
Appendix G Platforms‘ Secure API-Function Mapping ...... 303
G.1 Symbian-OS API-Capability Matrix ...... 303 G.2 Java ME API Function Groups ...... 304 G.3 BREW API Privilege Levels ...... 306
x LIST OF FIGURES
Figure 2:1: A Simplified Mobile Industry Value-Chain ...... 12
Figure 2:2: The Mobile Computing Value Chain ...... 16
Figure 2:3: Mobile Computing Value Web/Network ...... 17
Figure 2:4: A Simplified Mobile Computing Ecosystem ...... 22
Figure 4:1: Platform Certification System: Conceptual Constructs ...... 60
Figure 4:2: Market Effects of Platform Certification: Conceptual Expectations ...... 61
Figure 4:3: Effects of Platform Certification: Platform-Based Product‘s Vertical Compatibility ...... 64
Figure 4:4: Effects of Platform Certification: Platform-Based Market Entry Barriers ...... 66
Figure 6:1: Symbian-OS Architecture ...... 90
Figure 6:2: Symbian Signed Application Marketing Logo ...... 113
Figure 7:1: JTWI defined Java ME architecture ...... 124
Figure 7:2: Overview of the Java Verified testing process ...... 129
Figure 7:3: Java Verified Application Marketing Logo ...... 147
Figure 8:1: The BREW Platform Architecture ...... 154
Figure 8:2: The BREW Delivery System ...... 155
Figure 8:3: The True BREW Submission and Testing Process ...... 160
Figure 9:1: Platform Certification Effects on Vertical Compatibility in Mobile Applications Market ...... 204
Figure 9:2: Platform Certification Effects on Market Entry Barriers in Mobile Applications Market ...... 209
Figure 9:3: Revised Framework for the Market Effects of Platform Certification in Mobile Applications Market ...... 213
xi LIST OF TABLES
Table 5-1: Developer Forums: A Source of Research Participant Sampling and Secondary Data ...... 77
Table 5-2: Key Experts: Stakeholder Representatives...... 79
Table 5-3: Key Informants: Mobile Application Developers ...... 80
Table 5-4: Key Informants: Expertise Breakdown of Developers ...... 81
Table 5-5: Key Informants: Functional Breakdown of the Interviewees ...... 81
Table 5-6: Construct Operationalization and Validity ...... 84
Table 7-1: UTC Evolution ...... 132
Table 8-1: True BREW Testing Fee Structure ...... 176
Table 9-1: Relative Assessment of Certification Control Structure across Platforms ...... 194
Table 9-2: Relative Assessment of Certification Coerciveness across Platforms ..... 198
Table 9-3: Relative Assessment of Certification Flexibility across Platforms ...... 201
Table 9-4: Platform Certification Program Pricing ...... 207
Table G-1: API-Capability Matrix for Symbian-OS ...... 303
Table G-2: Java ME MIDP 2.0 Function Groups and their Descriptions ...... 305
Table G-3: AEE Privilege Level Flags for BREW 3.1 ...... 307
xii ACKNOWLEDGEMENTS
First off, I want to extend a heartfelt thanks to my advisor, Carleen Maitland. If there was a distinction for ―The most painful PhD student‖, I‘d probably clinch it without competition. I can‘t even begin to imagine, how much painstaking effort, encouragement, and patience from Carleen has come my way. She has been an instrumental force in everything I have done as a PhD student, from the days I was looking to enroll in the
PhD program to the ―congratulations‖ on my PhD defense. I would never have even imagined it without her.
I am grateful to my dissertation committee members – Steve, Irene, and Tom.
Their insightful comments, guidance, and enthusiasm have greatly strengthened this dissertation. I am truly indebted to Fred Fonseca and Ben Kleindorfer for introducing me to Philosophy of Science. The class of spring 2004, with just four students, has by far been the most exhilarating intellectual experience in my life. It was the best scholarly foundation anyone can ask for.
The highlight of four years in the PhD program has been the company of bright students from around the globe. In particular, I would like to thank Annemijn, Nick, Dave,
Julio, Edgar, Haiyan, Allison, Jeria, Karthik, Sharoda, and Andrey. Their company made my IST days truly special and exciting. Thanks to all my friends at Penn State – Batra,
Pasa, Vani, Samsi, Sai, Sachin, Aparna, Rama, Lav, and Angshuman. They were like my family in State College. Special thanks to Umer, for those amazing moments of competitive squash. They truly rejuvenated me.
I would also like to thank Lynn Yecina for her warm smiles and tight hugs. I would consider my life a success, if I can emulate a fraction of her inspiring attitude and zest for life.
xiii To my parents back home – Thanks for your enduring love and confidence in my abilities. Your constant struggles and efforts to provide the best for your kids have put me here. Thank you for everything you have given and continue to give me.
Last but not least – Thanks to my wife Angela. I can‘t even begin to thank her without feeling a rush of emotions. I could not have written this dissertation without her unwavering love, support, and patience. Thanks so much for always being by my side.
DEDICATED TO MY FATHER – RAM SARUP TARNACHA
Chapter 1
Introduction
Over time, the evolution of the ICT industry has been increasingly influenced by the emergence of standardized technology architectures or ‗platforms‘ that allow modular design and development of complementary products/components such as software and peripheral hardware (Gandal, 1995; Greenstein, 1998; Meyer & Seliger,
1998). The initial platforms in the ICT industry were proprietary, meaning that a system‘s manufacturer designed and controlled the platform to develop complementary hardware and software products. Historically, the industry was dominated by a few vertically integrated firms that owned and controlled platforms (Bresnahan & Greenstein, 1999).
For instance, IBM had tight control over its proprietary technology embedded in the early system 360/370 platforms that allowed it to develop and sell complementary hardware and software products (Greenstein, 1998).
Today, with the increasing complexity of ICT platforms, most platforms have been ―opened‖ to third-party product vendors to enable development of complementary platform-based products. While proprietary platforms still exist, control over platforms has become increasingly decentralized and shared among several firms through industry consortia. A classic example is the so-called ―Wintel‖ platform (Windows and Intel). The
Wintel platform has several stakeholders, which include thousands of software developer firms, peripheral equipment and card manufacturers, and a few hardware and software architecture firms (such as Intel, Microsoft, IBM, and AMD). The Wintel platform greatly altered the computing industry structure increasing inter-firm coordination and strategic dependence (Bresnahan & Greenstein, 1999).
2 While these multilateral initiatives have their advantages, firms with a technological stake in the design of platforms often attempt to exercise control over such distributed platforms for competitive advantage. Such control has also often raised anti- trust concerns, where a single dominant firm controlling a platform can alter and even stifle competition in platform-based product markets (Dobson, 2006; Levinson, Romaine,
& Salop, 2001). Microsoft‘s battle with Netscape in the Internet browser market is a classic example of such anti-trust concerns (Windrum, 2004).
In recent times, firms with a stake in the design of platforms have started regulating the design, deployment, and distribution of platform-based products by third- party firms. In particular, certification of platform-based products is gaining prominence.
Prime examples in ICT industries include Microsoft‘s ―Windows Logo‖ programs, which test and verify PC hardware components for compatibility with the Windows operating system1; Sun‘s ―Solaris Ready Logo‖ program, which certifies third-party hardware vendor products for compatibility with the Solaris operating system2; and GSM
Association‘s ―GSM Certification Forum‖ program, which provides the verification of
GSM phones against GSM Association‘s requirements3. These platform certification programs test the adherence of third-party platform-based products to the platform‘s technology architecture to achieve product compatibility.
More recently, this phenomenon of platform certification has gained prevalence in the emerging mobile software industry. Several mobile computing platforms have associated certification programs for third-party platform-based mobile applications
1 For details see the Windows Logo program‘s website http://www.microsoft.com/whdc/winlogo/default.mspx, Accessed Feb 2008. 2 For details see the Solaris Ready Logo program‘s website http://www.sun.com/solarisready/index.html, Accessed Feb 2008 3 For details see GSM Associations Document TSGS#5(99)405, 11-13 October, 1999, http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_05/Docs/PDF/SP-99405.pdf, Accessed Feb 2008
3 (software). Prime examples of such certification programs include Symbian Operating
System‘s ―Symbian Signed‖4, Windows Mobile‘s ―Mobile2Market‖5, Java ME‘s ―Java
Verified‖6, and BREW‘s ―True BREW‖7.
These third-party platform-based product certification programs are becoming commonplace in the ICT industries. However, literature on the implications of such programs on the evolution of the industry and its stakeholder firms has been relatively scant. Although various studies have focused on the phenomenon of certification
(Albano & Lizzeri, 2001; Lingenfelter, 1988; Vertinsky & Zhou, 2000), the evolution and diffusion of platforms (Steensma & Fairbank, 1999; Weitzel, Beimborn, & Konig, 2006;
West & Dedrick, 2006), and the influence of certification or platforms on industry structure per say (Bresnahan & Greenstein, 1999; Lane & Papathanasis, 1983;
Terziovski, Power, & Sohal, 2003; West & Dedrick, 2000), limited studies have assessed the implications of platform certifications for the competitive landscape of an industry and its constituent firms.
In this study, I address this gap by conceptually investigating platform certification and empirically assessing its role in shaping a platform-based product market. Certification systems, in general, have been viewed as a market regulatory mechanism in the literature (Dawson & Lewelling, 1991; Egyedi & Joode, 2004; Jahn,
Schramm, & Spiller, 2005). Drawing on such suggestions, I expect platform certifications to have structural ramifications for the platform-based market and hence economic implications for actors in the platform-based product market.
4 For details see https://www.symbiansigned.com/app/page 5 For details see http://msdn2.microsoft.com/en-us/windowsmobile/bb327790.aspx 6 For details see http://javaverified.com/ 7 For details see http://brew.qualcomm.com/brew/en/developer/commercialization/application_testing.html
4 I specifically focus on the mobile computing industry, evaluating the implications of mobile computing platform certification programs on the platform-based mobile applications/software market. As the mobile applications market has several competing mobile computing platforms with associated application certification programs, it presents an ideal context to investigate the role of platform certifications in shaping a platform-based product market.
1.1 Research Objectives, Questions, and Scope
This study examines the influence of platform certification on a platform-based product market. In order to investigate the role of platform certification in influencing a market, the study specifically examines the implications of platform certification on firms in the mobile applications ecosystem8 . The study is hence guided by the following overarching research question –
RQ0: How do Mobile Computing Platforms‘ Certification Programs Influence
Firms in the Mobile Applications Ecosystem?
The overarching research question is broken down into four specific questions –
RQ1: What are the Characteristics of a Mobile Computing Platform?
RQ2: What are the Characteristics of a Mobile Computing Platform‘s Certification
Program?
RQ3: What are the Implications of these Platform Certification Programs for
Platform-Based Application Developers?
8 A market ecosystem, in this context, refers to a collection of firms including buyers, sellers, and intermediaries that are directly or indirectly involved in the design, development, distribution, and support of products and services that are transacted in a particular market.
5
RQ4: What are the implications of Platform Certification Programs for other firms
in the Mobile Value Ecosystem?
The first research question examines the technological architecture of mobile computing platforms. It specifically addresses a set of related questions – How do we conceptually understand a mobile computing platform? What are its technological underpinnings, features, and business models that support application development and distribution? How do different mobile computing platforms vary, if at all? This provides a rich understanding of the scope of a mobile computing platform. Given this understanding, the second research question examines the purpose and scope of the certification programs associated with these mobile computing platforms. It addresses a set of related research questions – How do we conceptually understand platform certifications in the context of mobile computing platforms? What are the platform certification program‘s key attributes? How do different platform certification programs vary, if at all?
Finally, the last two research questions examine the effects of platform certification programs in the platform-based mobile applications market. RQ3 specifically examines the implications of platform certifications for what are arguably the most important set of firms in the mobile application ecosystem – the developers and suppliers of mobile applications. RQ4, on the other hand, focuses on the firms that directly or indirectly transact with or support the developers and suppliers of the platform-based mobile applications. These firms primarily include dominant actors in the mobile application ecosystem such as the platform promulgators that design, own, and manage the dissemination of the mobile computing platforms; mobile device manufacturers that implement/embed mobile computing platforms in their mobile
6 devices; and mobile network operators that often deploy/deliver mobile applications to mobile devices9.
In order to address these research questions, the study investigates the characteristics of three mobile computing platforms – Symbian OS, Java ME (Java Micro
Edition), and Qualcomm BREW (Binary Runtime Environment for Wireless); and their respective certification programs – ―Symbian Signed‖, ―Java Verified‖, and ―True
BREW‖10. Investigating the characteristics of the three certification programs provides the necessary background to examine the role of platform certification in shaping the competitive landscape of the mobile applications market. The study then examines the implications of the three platform certification programs for various actors in the mobile application ecosystem. It should be noted that although different types of mobile devices are available today, for reasons of analytical clarity the proposed study specifically focuses on mobile applications developed for cellular devices11. This reduces the scope of the study without forgoing the research objective of investigating the role of platform certification on the mobile applications ecosystem.
9 For details about different actors in the mobile ecosystem see the following chapter (Chapter 2). 10 See Chapter 5 on Research Methods for an explanation of selecting the three mobile computing platforms and their certification programs. 11 For the purpose of the study, Cellular Devices are defined as mobile devices that – 1) can wirelessly connect and exchange information over a cellular network such as GSM and CDMA; and 2) are computationally capable of executing mobile applications/software. This excludes mobile devices that – 1) are not capable of wireless connection to exchange information (such as portable media players) and/or executing mobile applications/ software. Further, mobile devices that can wirelessly connect and exchange information using non-cellular networks (such as WiFi) are also excluded. In this document, ‗Cellular Devices‘, ‗Cellular Phones‘, ‗Mobile Devices‘, ‗Mobile Phones‘, and ‗Handsets‘ are used interchangeably to refer to ‗Cellular Devices‘.
7 1.2 Research Merit
The study contributes to the literature on the role of certification in the diffusion of platforms, its implications for various platform certification stakeholders, and its impact on the development of platform-based product market. The study provides theoretical insights at various levels. Firstly, it provides a conceptual framework for understanding and assessing platform certifications, which is becoming increasingly prevalent desktop and mobile software markets. Secondly, the study evaluates the influence of platforms and their certification programs on the suppliers, buyers, and intermediaries across the value chain of an emerging market. Thirdly, the study informs the network markets literature by evaluating specific structural constructs to assess specific effects of platforms and their certification programs on the platform-based product markets. In doing so, the study provides specific theoretical insights in understanding the role of technology architectures in industrial coordination and competition.
In addition, the study provides empirical insights into the development of the global mobile applications market, a market that has rapidly emerged in the last decade or so and has received relatively limited attention in the industrial organization and strategy literature. The study uses an integrative theoretical approach to provide a holistic account of the development of mobile application markets, which provides a richer understanding of the development of the mobile applications market for future studies. The findings from the study can also be extended and applied to understand the role of platform certifications in other similar markets that supply platform-based products.
Further on a practical level, the study has implications for strategic planners and managers in the mobile applications market. The study will enable them to make
8 informed strategic decisions so they can better leverage the dynamics of an emerging market. The study also contributes to practice by highlighting various technical and business barriers, issues, and recommendations for the effective development, deployment, and distribution of mobile applications. These findings will particularly assist new firms in establishing an effective business plan in supplying improved and diverse mobile applications.
The findings from the study will be of particular interest to the information sciences and telecommunications research communities. Drawing on the mobile applications market, the study attempts to illustrate the patterns of industrial innovation and development through an increasingly complex interaction of technology, people, and the market-driven regulation of information products. In particular, this research provides nuanced insights into the administration of certification programs for the development of vibrant information product-markets, which are shaping the development of an increasingly global information society at large.
The presentation of this research is structured as follows. The next chapter presents the research context, which includes a brief overview of the mobile communication industry, the mobile applications market, and application development platforms. This background is followed by a review of relevant extant literature on technology architectures, and certification. The next chapter presents an initial analytic conceptual framework to guide the evaluation of platform certification and its effects on the mobile applications market. The following chapter then describes the methods employed for the study. The next three chapters then present the findings from three separate case studies of platform certification in the mobile applications market. A cross case analysis of the three cases is presented in the following chapter to evaluate,
9 corroborate, and modify the initial conceptual framework. Finally, the theoretical and practical implications of the findings are discussed, which is followed by conclusions and recommendations for future research.
Chapter 2
Mobile Computing Industry and Platform Certification
Mobile computing is an emerging segment of the growing global mobile telecommunications industry with a plethora of interrelated technological architectures, designs, and standards. To investigate the implications of platforms and their certification programs for the mobile computing ecosystem, this chapter provides the contextual background of the mobile industry. This chapter presents a brief overview of the structural organization of the mobile industry, its key actors and technological architectures. In particular, I focus on the mobile computing industry segment discussing different computing platforms and the key stakeholders in emerging computing ecosystems. Further, I discuss the three major computing platforms of interest to this study that offer certification programs for mobile applications.
2.1 The Mobile Industry
The mobile telecommunications industry is a highly dynamic technology-based industry. The dynamism, in part, has been attributed to rapid technological advances in the wireless realm (Menneceke & Strader, 2003; Varshney & Vetter, 2002). It has been argued that the ―confluence of technological leaps in devices, networks, and applications is setting the stage for wireless to change our lives the way personal computers (PCs) did in the 1980s and Internet in the late 1990s.‖ (Sabat, 2002)(p. 505). Researchers have presented the dynamics of the mobile industry running along several technological dimensions of mobile network infrastructure, protocols, equipment, and devices (Funk,
11 2004a, 2004b). Rapid technological advances in these interrelated dimensions have been supported by increasingly complex technological architectures and standards
(Gandal, Salant, & Waverman, 2003). Some of the technological architectures are integrative and inclusive, while others directly or indirectly compete with each other for wide-spread adoption creating challenges for modular interoperability and compatibility.
The mobile industry, hence, provides an ideal context to study technological architectures, platforms and standards, and examine the implications of platform certification for various stakeholders in a growing industry.
Various empirical studies have documented the complex ecology of the mobile industry. Funk (2004), for instance, used an evolutionary lens to identify key technological trajectories, dominant designs and product life cycles in the mobile industry (Funk, 2004b, 2004c). Tilson and Lyytinen (2006), document the transitions through generations of mobile infrastructures in the US, while Steinbock (2003) discusses the globalization of the entire mobile value system (Steinbock, 2003; Tilson &
Lyytinen, 2006).
At a conceptual level, researchers have also outlined various frameworks and analogies to describe and study the mobile industry. Michael Porter‘s, value chain framework has been one of the most widely accepted frameworks in understanding the structural organization of industries (Porter, 1985). A value chain is a map of the entire set of competencies required to produce, deliver, maintain and reap the proceeds from a product or service. This framework has also been applied to the mobile industry to formulate a basic understanding of its structural organization (Rülke, Iyer, & Chiasson,
2003). A high level value chain for the mobile industry is shown in Figure 2:1.
12
Mobile Mobile Mobile Mobile Network Service Device Network End-Users Equipment Providers Manufacturers Operators Manufacturers
Figure 2:1: A Simplified Mobile Industry Value-Chain
2.2 The Emergence of Mobile Computing
The mobile industry has traditionally provided communication services to the mobile user. In the last decade or so the mobile industry has leveraged digital technologies to evolve into a data-centric industry. Today, advanced mobile networks can transmit greater volumes of data, while mobile devices have increased processing power. Such advances have facilitated the provision of an increasing number of applications and services for the mobile user in addition to mobile communications.
Mobile users can wirelessly access emails, chat, download music, and search for information. Such applications and services have been more commonly referred to as mobile computing.
With the emergence of mobile computing and the digital revolution, the mobile industry like many other industries has witnessed convergence and blurring of industry boundaries (Greenstein, 1997). From an ecological point of view, the mobile computing industry is a converging amalgamation of firms from diverse interrelated industries such as telecommunications, entertainment, computing hardware, software, and consumer electronics (Barnes, 2002). The result is a complex industry structure, where firms with different competencies, business models, and embedded relations collaborate and compete to provide value.
13 2.2.1 Key Actors in the Mobile Computing Industry
In order to understand this complex ecology of firms, researchers have attempted to generate categories of similar actors in the emerging mobile computing industry
(Karvonen & Warsta, 2004; Li & Whalley, 2002). On a broader level, the actors in the mobile industry include the – 1) mobile content providers that include the creators, aggregators, and distributors of passive mobile content such as videos, pictures, and music; 2) mobile application developers and publishers that develop software that packages the content, as well as, provide computational functions such as email/chat clients, word/spreadsheet processing, and mobile games; 3) mobile device manufacturers that produce the mobile client devices; 4) network equipment manufacturers that provide the hardware for mobile telecommunication networks; and 5) network operators that setup and manage the mobile network to provide access and other services.
Each of these actors adds value at different stages of design, development, deployment, and distribution of various mobile applications and services. Network equipment manufacturers design and manufacture the physical equipment needed for mobile communications such as radio base stations, base station controllers, receivers, mobile switching centers and the various interfaces that enable connections between cellular end-users and the public switched telephone network. Their typical business models include hardware sales/leases to network operators. Some key actors are
Ericsson, Motorola, and Alcatel-Lucent. The device manufacturers are actors that provide cellular devices for end-users that can access a cellular network. These devices typically include mobile cell-phones and wireless PDAs. The typical business model for
14 device manufacturers is based on device sale to end-users or the network operators.
Some key actors are Nokia, Motorola, and Sony-Ericsson.
The network operators buy/lease, setup and manage the mobile telecommunication network in order to provide access service to the end-users. Network operators also license the wireless spectrum for communications either from a regulating agency or an open spectrum market. Typical business models for network operators include charging the end-user for speed and volume of data or voice access and usage.
Some key actors are AT&T, Verizon Wireless, Vodafone, Orange, and Sprint-Nextel. It should be noted that network operators play a central role in mobile value chain as they own the conduit for all firms in the value chain to reach the end-user. Due to their centrality, network operators often act as gatekeepers and exercise their preferences over upstream actors.
The content providers essentially either create or aggregate/package/distribute content such as images, videos, and music to the end-users. Typically, the content providers come from different industries such as entertainment, finance, and video games. They also typically provide information via other channels like the Internet or television, and wish to use the mobile industry as a complementary channel for distributing their content. The typical business model is based on advertising, subscription, download and revenue sharing with network operators. Some key actors are Yahoo, ESPN, and Disney. A specialized group of actors in this segment are mobile portals that are either web driven (WAP) or managed by a network operator. Mobile portals provide a subset of available content targeted toward the preferences of the end- users. They usually include personal information management tools, mobile games and location-based information. Examples of mobile portal companies include MSN mobile and AOL mobile.
15 The mobile application developers are a segment of the actors that design and develop software that executes on mobile devices and the network hardware.
Applications are often necessary to deliver and display content on the mobile devices.
The applications developed are either end-user centric that include, but are not limited to, mobile games, email/chat clients, word/spreadsheet processing, and GPS software, or enterprise centric such as integrated mobile corporate email and mobile sales force management. The typical business model is based on software licenses, number of transactions and subscription fees. Another closely related set of actors are the mobile application publishers that aggregate various types of mobile applications from different application developers. They essentially interface directly with mobile network operators and manage the relations with them so as to be able to distribute applications through them in bulk. The revenues generated are passed on to the mobile application developers. Examples of application publishers include EA Mobile, Gameloft, and
Hands-On mobile.
2.2.2 Value in the Mobile Computing Industry
With the emergence of mobile computing, the structure of the mobile industry has become increasingly complex. Firms from related computing, communications, and entertainment industries have assumed specialized roles to add value in the mobile industry. The resulting value propositions are more complex as firms with differing competencies collaborate and partner in providing innovative mobile applications and services. The value-chain of the mobile computing industry now incorporates the roles played by these new actors. Although the level of interaction between these groups of actors depends on the kind of product or service being offered to the end-user, the
16 value-flow interactions can be captured, at least to an extent, by the value-chain metaphor as shown in Figure 2:2. The value is now driven by the mobile content, applications, and service developers, providers, and aggregators. Often, with regards to their position in this value chain, such actors are referred to as the upstream actors and the others are referred to as the downstream actors. The actors in the upstream provide a base for mobile content, application and service delivery, which typically depend on the reliability, functionality and features provided by the downstream actors. The downstream actors are often credited for the value push to the end-user in the emerging mobile computing industry (Funk, 2004b; MacInnes, Moneta, & Caraballo, 2002).
Content Source Mobile Content Enablement Mobile Network and Devices User-Access
- Content Aggregation - Network Infrastructure Providers - Content Delivery - Wireless Transcievers - Mobile Portals & Browsers - Wireless Routers & Servers - Content Management Systems - Wireless Protocols & Standards Content Providers End-Users - Application Developers - Network Operators - Application Service Providers - Wireless Service Provision - Mobile Computing Platforms - Service Rating & Billing
- Systems Integrators - Device Manufacturers - Service Providers - Wireless Chipsets & Components - Device Architectures
Upstream Downstream
Figure 2:2: The Mobile Computing Value Chain12
However, the value-chain is a simplistic representational model. The order of value flow in a value chain is often ambiguous. Different actors typically add value with no particular flow order. This has been especially observed in the evolving mobile industry, where the end product or services are a result of value input from several inter- dependent systems of firms (Barnes, 2002; Fransman, 2002; Rülke et al., 2003;
12 Adapted from (Sabat, 2002)
17 Tarasewich, 2003). Researchers often prefer a ―web‖ or network model to represent these complex interactions and value flow (Andrews & Hahn, 1998; Li & Whalley, 2002).
The web model overcomes the restrictions of a chain analogy to provide a better visual understanding for the interaction/value flow. Although suppliers and buyers of products and services are easily identified using the value chain metaphor, identifying the buyers and suppliers of applications and services in the mobile computing industry is inherently complex and requires an understanding of the technological and business components of a specific application or service. A high-level value-web, shown in Figure 2:3, attempts to capture some of these nuances in the core mobile content, application and services provisioning segment of the mobile computing industry.
Mobile Device Manufacturers Network Mobile Equipment Network Manufacturers Operators
Standard Development Organizations Value End-Users Computing Platform Promulgators
Mobile Mobile Content Application Providers Developers Content and Application Publishers
Figure 2:3: Mobile Computing Value Web/Network
18 2.3 Mobile Computing Platforms and their Ecosystems
The complexity of transactions between firms with specialized competencies is further exacerbated by a plethora of communication, application development, and service delivery technologies that have to be incorporated for successful mobile application and service provisioning. From the perspective of upstream actors (mobile content, application, and service developers), an application or service is dependent upon a standardized mechanism of interaction between various technological layers of mobile infrastructure, equipment, and devices. This is especially true for mobile applications that leverage the computational capabilities of the underlying devices and network to provide specific functionalities13. Although mobile applications typically execute on mobile devices, they often interact with network transceivers, routers and servers for wireless access and connectivity. This complex interaction is achieved by the use of ―design interfaces‖ that provides access to the layer-specific features required by the application. These design interfaces are commonly referred to ―Application
Programming Interfaces‖ or APIs that facilitate application development. Depending on its functionality, an application might interact with many interfaces across these different layers. For instance, a location-based multimedia application might require and use the mobile network‘s location APIs for mapping; the mobile device‘s camera-controlling APIs for collecting visual imagery; and the device‘s operating system‘s file-system APIs for data storage. It should be noted that while these APIs enhance interoperability, they also limit applications to the particular devices and networks that provide those specific APIs.
If an application is designed using an API that is not available on the device/network it is
13 For instance a mobile chat application relies on both device and network functionalities to package and exchange messages between devices.
19 deployed/installed on, the application can ―crash‖ or is unable to perform its intended functions. In that sense a mobile application is dependent on the availability of APIs on the device and/or network on which it is deployed.
In order to circumvent the complex dependency of mobile applications across multiple layers, various computing platforms have been developed. These platforms essentially package available APIs at different layers and provide a standardized mechanism to access various layer-specific features. The traditional approach to address the technological dependency for application development has been the use of a standardized operating system. In the desktop realm, operating systems like Microsoft
Windows, Macintosh OS and Linux are commonly known to software developers and end-users. Applications are typically designed to execute using an operating system‘s standardized API‘s. Although this makes the applications operating-system-dependent, it provides an integrating mechanism for many hardware-specific API‘s such as the keyboard, mouse, and the monitor. In the mobile realm as well, operating systems provide this integrating mechanism. Symbian-OS, Windows Mobile, and Palm-OS and mobile versions of Linux are primary examples of such operating systems. Of these
Symbian-OS enjoys about two thirds market share, while Windows Mobile, Symbian-
OS‘s chief competitor, has about one sixth market share of the global mobile operating system market. In addition to mobile operating systems, an application can also be designed for what are commonly referred to as ―middleware computing platforms‖.
These middleware platforms provide API packages that are operating-system- independent. They are deployed on top of and across multiple operating systems so as to provide an integrated and simplified mechanism for application development and deployment across different operating systems. Sun‘s Java ME and Qualcomm‘s BREW are prominent examples of such middleware platforms.
20 These computing platforms have simplified application development by leveraging capabilities across various technological layers of the mobile computing industry and their impact on the mobile computing industry has been profound. Today multiple computing platforms – be it operating systems or middleware solutions – compete for industry dominance and wide-spread adoption by mobile application developers. Various firms and stakeholders in the mobile industry have invested considerable time and money in the development of these platforms. Further, it has also been argued that the growth potential of the entire mobile computing industry is contingent upon the evolution and proliferation of these platforms (Karvonen & Warsta,
2004). From a structural point of view, the mobile computing industry is evolving around these computing platforms that are increasingly simplifying application development and empowering upstream actors to develop and deploy innovative applications for eventual end-user consumption. As such, the evolution of the mobile computing industry has more aptly been characterized as platform-centric ecosystems of interdependent specialized firms (Mannermaa, 2005).
With the emergence of these competing computing platforms, an influential set of actors have emerged in the mobile value web – the mobile platform promulgators. These platform promulgators are the organizations that are responsible for creating, enhancing, and implementing their respective platforms on different mobile devices. Some of the platform promulgators are independent firms that license their platforms for a profit, while others are alliance-driven for-profit or open-source-driven non-profit standardization initiatives. In essence, platform promulgators market and promulgate a platform for wide- spread adoption by various stakeholders such as device manufacturers, network operators, and application developers.
21 As platform promulgators have a vested interest in the industry-wide acceptance of their respective platforms, they not only continuously enhance platform capabilities, but also provide opportunities to raise the quality of platform-based applications to attract more potential platform licensees. One of the more common mechanisms employed to ensure quality applications is that of application certification14, wherein platform promulgators test and approve applications against security, quality, and compatibility standards. The platform promulgators play a critical role in shaping the mobile computing ecosystems by providing platforms as well as their certification programs for the development and distribution of certified applications. The platform promulgators also typically outsource the administration of certification to third-party testing labs that serve as certification agents. Hence, a typical mobile computing ecosystem includes the platform promulgator and actors such as the platform-based application developers, certification testing labs, and primary application distribution channels such as device manufacturers and network operators. A simplified mobile computing ecosystem is shown in Figure 2:4.
14 In this study I refer to such application certification programs as platform application certifications or platform certifications. Throughout the document the terms ―application certifications‖ and ―platform certifications‖ are used interchangeably, unless further clarified.
22
Authorize Certification Testing Labs
Platform Promulgator Test Device Manufacturers
n o Provides on i uti t trib u is b D i r t s i D Application To End Use Platform Applications Developers Develop Certification Users D i s t r i Di b str u ib t ut i ion o n Network Operators
Figure 2:4: A Simplified Mobile Computing Ecosystem
In the following sub-sections I provide a brief overview of three of the more widely-implemented platforms – Symbian-OS, Java ME, and BREW – their promulgators, certification programs, and ecosystems.
2.3.1 Symbian-OS
Symbian-OS is a proprietary mobile operating system that is licensed to various mobile device manufacturers for implementation on various mobile devices. Symbian–
OS is structured like many desktop operating systems with multitasking and memory protection, and provides APIs for integrated access to mobile device hardware as well as network functionality and features. Symbian-OS has its roots in Psion PLC‘s EPOC mobile operating system, which from release 5 onwards was labeled Symbian-OS v5.
23 Symbian-OS v9.5, the latest revision, was released for implementation on mobile devices in March 2007.
Symbian-OS commands a majority market share for Smartphone implementation15. As of early 2007 Symbian-OS had more than 66% market share worldwide, while Windows Mobile, BlackBerry-OS, Linux, Palm-Os and others share the remaining one third of the global market share16. Symbian-OS is owned Symbian
Software Ltd. (Symbian), which is a joint venture of several mobile device manufacturers. Symbian-OS in that sense is an alliance-driven platform standardization initiative.
Symbian was founded in June, 1998 when a mobile computer software developer, Psion PLC, merged with Ericsson, Nokia and Motorola. At the time of joint venture Psion PLC owned majority of the Symbian shares. The ownership of Symbian has changed since 1998 and different device manufacturers joined and left the venture subsequently. Psion later sold its stake in Symbian to Nokia in February, 2004 and made
Nokia the majority shareholder. As of June, 2007 Symbian is owned by six device manufacturers – Nokia (47.9%), Ericsson (15.6), Sony-Ericsson (13.1%), Panasonic
(10.5%), Siemens 8.4%), and Samsung (4.5%)17. Further, as of June 2007, Symbian-OS licensees include Arima, BenQ, Fujitsu, Panasonic, Lenovo, LG Electronics, Mitsubishi
Electric Corp, Motorola, Nokia, Samsung, Sharp, Siemens, and Sony Ericsson18.
15 See http://www.symbian.com/about/fastfacts/fastfacts.html. Accessed June 2007 16 See – 1) Cellular-News (Aug 24, 2006), New Symbian Smartphone Model Ships Every Week in Q2, http://www.cellular-news.com/story/18973.php; 2) IDC (2006), IDC Mobile Device Operating System Report Confirms Symbian's Lead in the Converged Mobile Device Market, Followed by Microsoft and Linux, http://www.idc.com/getdoc.jsp?containerId=prUS00202205; and 3) Canalys (2006), 64 million smart phones shipped worldwide in 200, http://www.canalys.com/pr/2007/r2007024.htm, Accessed June 2007 17 See http://www.symbian.com/about/fastfacts/fastfacts.html, Accessed June, 2007 18 See http://www.symbian.com/about/overview/licensees/licensees.html, Accessed June 2007
24 In 2002, Symbian opened Symbian-OS‘s source-code to third-party application developers for developing Symbian applications. According to Symbian, as of Early
2007, about 400 independent application developers had developed more than 7000 applications for Symbian-OS19. Out of these 7000, about 1100 applications were developed for Symbian-OS‘s latest release series (v9.x). In addition to application developers, application publishers are an integral part of the Symbian ecosystem. These publishers aggregate applications for sale to mobile operators, portals and other distribution channels for eventual end-user consumption. In that sense, Symbian-OS licensing device manufacturers, Symbian-OS application developers, publishers, and global strategic partnerships with mobile operators20 form the core Symbian-OS ecosystem. Symbian provides a subscription-based partnership program to manage their growing ecosystem, wherein Symbian-OS developers, publishers, mobile operators and licensing device manufacturers can access information including the Symbian source-code, Software Development Kits (SDKs), technical and marketing support, and training material.
2.3.1.1 The Symbian Signed Certification Program
In May 2004, Symbian launched an application certification program called
Symbian Signed. According to Symbian, the Symbian Signed program was established to test Symbian applications against industry-agreed quality and security requirements of
19 See http://www.symbian.com/about/fastfacts/fastfacts.html, Accessed June 2007 20 Examples include - NTTDoCoMo, Vodafone, Orange, and Cingular
25 various mobile operators and device manufacturers. Symbian Signed seeks to promote best practice in designing applications to run on Symbian-OS based devices21.
The Symbian Signed program is managed by Symbian, where a dedicated
Symbian staff provides operational management and administration of the program22.
Symbian is responsible for documenting and updating the Symbian Signed processes and test criteria, facilitating certification support, and promoting the Symbian Signed program. Symbian Signed is endorsed by many mobile operators, device manufacturers and other distribution channels.
2.3.2 Java ME
Java ME (Java Micro Edition) is an operating-system-independent modular
―middleware‖ platform that can be used to develop Java applications for various Java- enabled devices across different mobile operating systems. Java ME is one of the most widely deployed computing platforms for mobile devices. Most, if not all, mobile devices including low-end cellular phones and high-end Smartphones have implemented selective modules of the Java ME platform23.
Architecturally, Java ME is a subset of the Java platform for desktops, with modular API packages designed to access different features of mobile devices. Using
Java‘s core virtual machine technology and a modular packaging of various API specifications, Java ME provides a virtualized environment for Java ME applications to
21 See Symbian (2004), Symbian Signed drives mobile applications market, http://www.symbian.com/news/pr/2004/pr20043052.html, Accessed June 2007 22 The Symbian Signed dedicated Staff is referred in this document as the Symbian Signed Program Office 23 See (Sun 2007), Java ME: the Most Ubiquitous Application Platform for Mobile Devices, http://java.sun.com/javame/index.jsp, Accessed June 2007
26 execute independent of the underlying operating system. As a middleware platform it is implemented to run on top of a variety of operating systems and hardware.
Java ME is considered an open platform standardization initiative that is managed by Sun Microsystems Inc. It is designed through a community-driven process known as the Java Community Process (JCP) 24, wherein experts from various mobile device manufacturers, mobile operators, and developers collaboratively design and approve various API modules for implementation. The platform is considered open in the sense that it accepts industry-wide participation in its design and publicly shares the approved API specifications. Initially, Java was developed and owned by Sun. However,
Sun later opened the Java ME source-code under the GNU General Public License
(GPL) 25&26. As of July 2007, all Java ME modules (also known as JSRs) were available for free under the GPL27. In that sense, it is often considered a non-proprietary platform that can be implemented freely under the GPL agreement by device manufacturers.
As a GPL licensed platform, the Java ME ecosystem includes a community of stakeholders that influences, at least to some extent, the continuous improvement of the platform through the JCP. In the mobile industry the stakeholders include the Java application developers, the mobile device manufacturers, and the mobile operators. As
24 The Java Community Process (JCP), established by Sun in 1998, is an open and participative process to develop and revise the Java technology specifications. The process is initiated by a Java Specification Request (JSR) submitted by a JCP member, which is reviewed by the community. Once the JSR is accepted an expert group is formed through nomination, which is responsible for further specification development, and community and public reviews to finalize the specification (See the Java Community Process website http://jcp.org/en/home/index for details). 25 For details of the GNU public license see - http://en.wikipedia.org/wiki/GNU_General_Public_License, Accessed July 2007 26 See http://www.sun.com/smi/Press/sunflash/2006-11/sunflash.20061113.1.xml, Accessed July 2007 27 The Source code was released to the public on December, 2006 under the PhoneME project. For details see the project website - https://phoneme.dev.java.net/, Accessed July 2007
27 of July 2007, 38 mobile device manufacturers and component OEMs had licensed and implemented the Java ME platform28.
2.3.2.1 The Java Verified Certification Program
As mentioned above, Java ME is a modular platform wherein device manufacturers can selectively implement various API modules. Further, implementations are often not consistent across various device models. This selective and varying implementation of various Java ME API specifications creates an inconsistent application deployment environment, which results in inconsistent behavior of Java ME applications across different mobile devices. Java ME applications were hence considered low quality applications. In order to assure development of consistent quality applications, various device manufacturers in partnership with Sun created the Unified
Testing Initiative (UTI) in 2003. As of July 2007, LG Electronics, Motorola, Nokia,
Orange/FranceTelecom, Samsung, Sun Microsystems, Sony Ericsson and Vodafone were members of the UTI. UTI was established to raise the Java ME application quality by testing applications against an industry-accepted criterion called the Unified Testing
Criteria (UTC). Based on the UTC, the UTI members launched an application testing and certification program called the Java Verified certification program in early 2004.
According to Sun, since the launch of Java Verified, over 13,000 applications developed
28 See http://java.sun.com/javame/licensees/index.jsp, Accessed, July 2007
28 by more than 3,100 developers have been tested on more than 400 Java ME compliant devices through the Java Verified program29.
The Java Verified program is managed by the UTI members, where a dedicated
Java Verified staff provides operational management and administration of the program30. The UTI members are responsible for documenting and updating the Java
Verified processes and test criteria, facilitating certification support, and promoting the
Java Verified program. Java Verified is endorsed by all UTI members and is accepted by many non-UTI mobile operators and device manufacturers31.
2.3.3 BREW
BREW (Binary Runtime Environment for Wireless), is another operating-system- independent ―middleware‖ platform that is used to develop BREW applications for
BREW-enabled mobile devices. BREW, like Java ME, operates on top of the device operating system and provides a set of APIs for BREW applications. However, unlike
Java ME, BREW provides a more integrated encapsulation of APIs, wherein BREW is implemented on mobile devices as a complete package. Other than providing APIs for application development BREW incorporates an application distribution system called the BREW Delivery System (BDS) that provides the framework for network operators and the end users‘ to shop, purchase, download, and install software over the operators‘
29 From Sun Press Release, May 10, 2007, ―Sun Announces Broad Release of UTI Digital Certificate Through Java Verified Program to Help Drive Worldwide Mobile Application Security‖, http://www.sun.com/aboutsun/pr/2007-05/sunflash.20070510.2.xml, Accessed July 2007 30 The Java Verified dedicated staff is referred in this document as the Java Verified Program Office 31 Sun Press Release, May 10, 2007, ―Sun Announces Broad Release of UTI Digital Certificate Through Java Verified Program to Help Drive Worldwide Mobile Application Security‖, http://www.sun.com/aboutsun/pr/2007-05/sunflash.20070510.2.xml, Accessed July 2007
29 network. In that sense, BREW provides vertically integrated distribution control to the network operator32.
The BREW platform is solely owned by Qualcomm Inc., and hence is considered a proprietary platform standard that competes with other computing platforms for de- facto market dominance. BREW is specifically designed for the network operators and licensed to device manufacturers for devices supported by BREW network operators.
BREW has a presence in various regions around the globe, especially in the Americas. It has a significant market share on CDMA mobile devices and with CDMA mobile operators. As of July 2007, about 50 different device manufacturers had implemented
BREW on their devices; more than 30 mobile operators had deployed the BREW infrastructure33.
In addition to the mobile operators and device manufacturers, BREW application developers and publishers form the core actors of the BREW ecosystem. Qualcomm actively seeks promotes the BREW technology through various Developer conferences, technical support, and marketing tools to encourage BREW application development.
Since BREW‘s launch, Qualcomm has promoted and managed the BREW application developers through a ―BREW Alliance‖ program, which is a subscription-based partnership program that aids BREW developers in application design, deployment as well as commercialization on mobile operator networks34. The program provides various services including technical resources & support, product development guidance,
32 BDS handles the over the air transactions and billing for such distribution and Qualcomm retains a share of the transaction. BREW developers can get their product to market following a formalized process laid out by Qualcomm. The process streamlines the testing, and delivery of applications to the network operator, who eventually deliver the applications to the end-users (See (Qualcomm, 2007) for details). 33 See http://brew.qualcomm.com/brew/en/manufacturer/manufacturer_directory.html, Accessed July 2007 34 See the BREW Alliance Program website- http://brew.qualcomm.com/brew/en/developer/getting_started/alliance.html, Accessed July 2007
30 business development and operations support, and application promotional opportunities. As of July 2007, about 750 developers and publishers world-wide had registered for BREW application development35. According to Qualcomm in early 2007, the BREW ecosystem was ―vibrant‖ with more than 170 Million BREW-Enabled devices shipped in 200636; and BREW developers had generated more than $1 billion in application revenues37.
2.3.3.1 The TRUE BREW Certification Program
When Qualcomm released the BREW platform in 2001, it also launched the
BREW application testing and certification program called TRUE BREW. According to
Qualcomm, the program was part of the BREW vision since its commercial launch in
2001. The TRUE BREW program was designed to evaluate BREW applications against
―the established levels of stability, quality, and compliance with standard platform requirements that Qualcomm‘s carrier partners demand‖38. The level of stability, quality and compliance were established by Qualcomm so as to be able to promote the BREW package to their prime customers – the mobile operators.
Qualcomm, as the proprietary owner of the BREW technology, mandated TRUE
BREW certification for all BREW applications that were deployed by BREW mobile operators. As all BREW applications are distributed through the BDS over the mobile
35 See http://brew.qualcomm.com/brew/en/developer/directory.html, Accessed July 2007 36 See http://brew.qualcomm.com/bnry_brew/pdf/white_papers/brew_personalizing_information.pdf, Accessed July 2007 37 See http://brew.qualcomm.com/jsp/brew/en/press_room/press_releases/2007/03_05_07.html, Accessed July 2007 38 From BREW Newsletter, 2001, http://brew.qualcomm.com/brew/en/developer/newsletter/2001/september_2001.html, Accessed July 2001
31 operator‘s network, all commercially available BREW applications have to be TRUE
BREW certified.
In summary, the mobile computing industry is an emerging industry that is increasingly being influenced by these three mobile computing platforms. Given the existence of multiple platforms, their evolving ecosystems, the use of platform certification by major platform promulgators, and a vast population of mobile application developers, the mobile computing industry presents an ideal context to explore the implications of platform certification on a platform-based product market. In this study, I examine three of the more widely-implemented platforms – Symbian-OS, Java ME, and
BREW – to investigate the implications of their platform certification programs on the mobile applications market. In the following chapter, I survey the academic literature and identify the theoretical gaps that the study attempts to address.
Chapter 3
Literature Review
In this chapter, academic literature is surveyed to elaborate on existing knowledge base, identify core theoretical insights and concepts, and highlight under- researched gaps that the study addresses. The chapter is organized as follows.
I first review the academic literature concerning the role of technology architectures and platforms in technology-based industries. I focus on product platforms and their role in influencing the market dynamics and competition in today‘s converging industries, with a specific emphasis on computing platforms and research in the broader context of ICT industries. I then survey the industrial organization and strategy literature on various forms of certifications. In particular, I review theoretical and empirical research on various forms of supplier, product, process, and standards certification systems. Finally, the chapter ends with a summary of the reviewed literature and identifies the gaps that the study addresses.
It should be noted that this review draws several concepts from the vast literature on network markets. A review of the literature on network markets is presented in the
Appendix (Primer on Network Markets) and references to it are made whenever required.
3.1 Technology Architectures and Platforms
Academic literature on technology-based industries is vast. In investigating technology-based industries, researchers have given particular attention to so-called
33 ―technology architectures‖ or ―platforms‖ that form the basis of production for derivative products. Platforms essentially provide a common design structure with a standardized set of interface specifications that a derivative product can use to access the platform‘s capabilities. In essence, they provide a standardized mechanism for producing derivative products.
Technology architectures have been observed in several industries. They have also been known to play a significant role in influencing industry structure and evolution.
Evolutionary theorists, in particular, have conceptually elaborated the role of technology architectures in shaping industry evolution. Clark (1985), in a seminal paper, described a conceptual framework to understand the interaction between technology and industry evolution. He conceptualized technology as ―design hierarchies‖ that incrementally co- evolve with industry structure (Clark, 1985). Tushman and Anderson (1986), using longitudinal data from the minicomputer, cement, and airline industries, empirically highlighted the patterns of technological change and impact of technological design breakthroughs on industrial growth (Tushman & Anderson, 1986). They suggested that technology evolves through periods of incremental change, punctuated by technological design breakthroughs that either enhance or destroy the competence of firms in an industry. The key concept introduced was ―dominant designs‖, which form the basis of production in technology-based industries (Anderson & Tushman, 1990)39.
In the organizational context of firms, technology designs have been referred to as ―product architectures‖ (Baldwin & Clark, 1997; Henderson & Clark, 1990; Sanchez,
1996; Sanchez & Mahoney, 1996; Ulrich, 1995). A product architecture is defined as an
39 Technological breakthroughs or dominant designs in an industry have also been referred to as ―disruptive technologies‖ as they disrupt the established value structure and competitive landscape in an industry (Christensen & Rosenbloom, 1995).
34 ―interactive pattern of functional modules in a product system‖ that act as a guideline for a firm to design and develop products from modular components (Chen & Liu, 2005;
Sanchez & Mahoney, 1996; Ulrich, 1995). Using product architectures firms can introduce new products into the market with limited effort, shorter lead times, and lower costs (Meyer & Utterback, 1993). Further, product architectures have also been shown to accelerate product innovation (Henderson & Clark, 1990; Meyer & Utterback, 1993).
3.1.1 Product Platforms
Product architectures are typically proprietary. They are used by organizations to create cost-effective innovative products to gain competitive advantage in a market
(Sanchez, 2002), and hence are not shared with competitors or complementary product manufacturers. In network markets, product architectures are often shared and licensed to third-party complementary product developers. The objective is to establish industry- wide dominance of the product architecture so as to reap positive network externality benefits in supplying architecture-based products (for the definition of network markets and a detailed review of network markets, externalities, and effects see the ‗Primer on
Network Markets‘ in the Appendix). Such product architectures have also been called
―product platforms‖ (Meyer & Dalal, 2002; Meyer & Zack, 1996), which form the basis of production outside the organization that developed the platform.
Product platforms are defined as ―a set of subsystems and interfaces that form a common structure from which a stream of derivative products can be efficiently developed and produced‖ (Meyer & Seliger, 1998). Platforms provide interfaces to their core functional modules and capabilities that allow a firm to rapidly and efficiently derive complementary ―follow-on‖ products (Chen & Liu, 2005; West & Dedrick, 2000).
35 Essentially, the architecture of any single product has the potential of becoming a platform if it serves as the foundation for others to create derivative products (Meyer &
Seliger, 1998). Platforms provide leverage in the sense that each new derivative product can be developed at a relatively small incremental cost compared to the development of the initial product platform.
The use of product platforms has been observed across many industries.
Wheelwright and Clark (1992), for instance, observed the use of platform in the design of derivative products for vacuum cleaners; Meyer and Utterback (1993) gave examples from electronic imaging systems and peripherals; as did Sanderson and Uzumeri (1995) in studying the evolution of Sony Walkman, and Meyer and Lehnerd (1997) in the development and renewal of HP‘s ink jet printers (Meyer & Lehnerd, 1997; Meyer &
Utterback, 1993; Sanderson & Uzumeri, 1995; Wheelwright & Clark, 1992).
3.1.2 Computing Platforms
A rich stream of literature has also examined the role of computing platforms in shaping the evolution of ICT industries. Computing platforms have been conceptualized as a cluster of technically standardized components called ―Application Programming
Interfaces‖‘ or APIs that define the interaction of complementary software applications or products designed for a particular computing platform (Greenstein, 1998). These APIs provide the necessary information for developers to design applications compatible with the given platform. In that sense, computing platforms have been viewed as a critical
―compatibility standard‖ that mediate software compatibility (David & Greenstein, 1990;
West & Dedrick, 2000).
36 Various studies have investigated the uses and implications of such computing platforms for the rapid growth and convergence in ICT industries (Bresnahan &
Greenstein, 1999; Bresnahan & Malerba, 1997; Greenstein, 1999; Özsomer & Cavusgil,
2000). Examining the case of a software firm, Meyer and Lopez (1995) underscore the importance of computing platforms and their continuous renewal in efficiently developing a range of software products (Meyer & Lopez, 1995). Meyer and Zack (1996) further elaborated how firms can leverage platforms to enhance design and development of information products and create sustainable competitive advantage (Meyer & Zack,
1996). Bresnahan and Greenstein (1999) provide evidence of the criticality of technological competition between computer platforms, as opposed to individual firms, in a thirty year longitudinal investigation of the computing industry (Bresnahan &
Greenstein, 1999). Further several studies have documented the emergence and control of computing platforms in shaping industry structure attributes including entry barriers, concentration, and vertical integration (Gandal, Greenstein, & Salant, 1999; Greenstein,
1998; West & Dedrick, 2000). Studies have also documented the strategic implications of developing, managing, and adopting platforms for firms in the ICT industries (Garud &
Kumaraswamy, 1993; West & Dedrick, 2006; Windrum, 2004).
More recent studies have focused on the emerging mobile computing industry.
McMullan and Richardson (1996) argue that mobile phones have rapidly emerged as a new computing medium. They are more than just a telephone and hence must be considered as an ―emergent entertainment media interface‖ (McMullan & Richardson,
2006). Several empirical studies have examined the importance of these emerging mobile computing platforms. For instance, Iversen and Tee (2006) have documented the case of the Symbian mobile computing platform to analyze the impact of institutional changes in technology standardization on industrial organization in the mobile sector. In
37 particular, they observed that the development of the Symbian platform has significantly altered the level of industry coordination (Iversen & Tee, 2006). Further, Karvonen and
Warsta (2004) studied several mobile software companies to underscore the significance of mobile platforms in influencing the value propositions of mobile multimedia services. They suggested that the core capabilities of mobile platforms not only influence the business models in the mobile services sector, but also alters the value chain of the broader mobile computing industry (Karvonen & Warsta, 2004).
Furthermore, Methlie & Gressgård (2006) discussed the strategic implications of developing service platforms for mobile data service providers to conceptualize their impact on market structure, firm conduct, and performance. They found that service platforms create greater complementarities, firm differentiation, and business model diversity, thereby enhancing the innovativeness in the mobile services sector (Methlie &
Gressgård, 2006).
While these studies have begun to shed light on the role of platforms in the development of the market they all take compliance with the platform as a given and thereby pay little attention to certification. Further, they especially focus on the downstream participants such as platform promulgators, standardization bodies, network operators, and device manufacturers, as compared to the upstream application developers considered in this study.
3.1.3 Platforms and Business Ecosystems
Recently a related stream of literature has applied concepts of ecological ecosystems to understand market dynamics and competition in today‘s converging industries (Gundlach, 2006; Iansiti & Levien, 2004b; Moore, 1993, 1995, 2006). This
38 stream of literature conceptually describes the competitive environment as shaped by
―business ecosystems‖. A business ecosystem is defined as ―an economic community supported by a foundation of interacting organizations and individuals – the organisms of the business world‖ (Moore, 1997)(pg 26). These organizations include component suppliers, complementary producers, trade associations, and standardization bodies that often span many related industries and create a sustainable cooperative network that succeeds collaboratively.
This view is different from the traditional formulation of business or value networks in three crucial aspects (Gossain & Kandiah, 1998). First, business ecosystems are not limited to an industry but span multiple related industries. The level of analysis in the business ecosystem framework is the dynamics within the ecosystem‘s roles and actors as opposed to traditional industry sector specific assessments. Second, the business ecosystem literature underscores the importance of leadership for the business community to prosper as a whole. The entire community values and benefits from leadership by a few central firms that enables them to move towards a shared vision and out-compete members of competing ecosystems. In the traditional view, on the other hand, leadership or monopoly is expected to stifle market growth (Dobson,
2006; Gundlach, 2006; Moore, 2006). Third, the business ecosystems view recognizes technology architectures, platforms, and standards as a fundamental fabric that connects the community of actors (Iansiti & Levien, 2004b). Design, dissemination and control over technology platforms, define leadership and the overall health of the ecosystem as a whole (Iansiti & Levien, 2004a).
From a strategic point of view, firms in an ecosystem can act as ―hubs‖ and pursue leadership, or position themselves to pursue specialized or ―niche‖ strategies
(Iansiti & Levien, 2004a). Drawing insights from the growth of ecosystems led by firms
39 such as Microsoft, Walmart, eBay, AT&T, and IBM, researchers have highlighted how firms strategically co-align their strategies for sustainable competitive advantage (Iansiti
& Levien, 2004a; Moore, 1997). The view suggests that leaders as ―keystones‖, ―must manage the health of their ecosystems as a key business priority‖ (Iansiti & Levien,
2004a, pg. 220), where the ―health‖ is determined by the productivity, robustness, and diversity of the niche members of the business ecosystem. Such a management of firms requires leaders to incentivize community membership, while controlling the interdependence of firms in the ecosystem by carefully crafting and sharing technology platforms (Iansiti & Levien, 2004a, pg. 158). Firms, that do not control such platforms risk disintegrating the ecosystem that results in diminished profits for the keystones as well as the entire business community.
Utilizing the business ecosystem framework, researchers have also highlighted structure, health and performance of software and IT ecosystems. Iansiti and Richards
(2006), for instance, describe the IT ecosystems as a ―network of organizations, technologies, products, and consumers‖. They provide a historical evaluation of the IT ecosystem to highlight the role of IT platforms such as operating systems, web servers, browsers, multimedia, and mobile devices in shaping the productivity, robustness, and diversity in the community of niche software vendors (Iansiti & Richards, 2006). Further,
Nguyen (2006) draws on e-business challenges to underscore the efficacy of business-
IT integration platforms in driving the ecological growth of the software ecosystem
(Nguyen, 2002). Furthermore, in the context of mobile and wireless domains, researchers have also stressed the importance of developing a productive, robust, and diverse mobile application ecosystem (Mannermaa, 2005; Rülke et al., 2003). However, these studies have not examined the implications of certification per se, for the emerging mobile application ecosystem.
40 3.2 Certification: A Market Regulatory Mechanism
In addition to the insights on the role of platforms in shaping the broader industry ecosystems, a related stream of literature has focused on the issues of technological coordination among firms, which can potentially create a competitive advantage for a business ecosystem over another. The technology coordination literature further underscores the importance of technology architectures, designs, or platforms in shaping the competitive system of interdependent firms. The underlying idea in this stream of literature is that if a firm is able to control and leverage technological architectures, they will be in a better position to manage an ecosystem of firms and generate a form of monopoly rent (Dobson, 2006).
An essential mechanism discussed to achieving this technological coordination is that of certification. Conceptually, certification can be defined as a formalized mechanism through which an organization provides a seal of approval to firms, their products, or organizational processes, for conformance to certain guidelines and requirements. Such organizations range from individual buyers (firms) with higher market bargaining power to industry-recognized trade associations, standardization bodies, and government agencies that develop and enforce conformance to standards so as to foster broader socio-economic welfare. I first review the literature on certification by individual firms and then survey the literature on various forms of certification schemes provided by independent (third-party) economic and regulatory agencies.
41 3.2.1 Certification in a Supply Chain
One of the more common forms of certification schemes discussed in the literature is the one sponsored and managed by individual firms in a value chain. Such certification schemes are established by a firm that transact and manage relations with several suppliers in the value chain. They are often referred to as ―supplier certifications‖. Supplier certifications have been discussed in the literature in the context of logistics management primarily drawing insights from manufacturing sectors. Supplier certification programs are characterized as formalized mechanisms employed by manufacturers or aggregators to assess and benchmark the quality of their material and component suppliers (Willis & Huston, 1992). It typically involves a thorough examination of all aspects of a supplier‘s performance (Lockhart & Ettkin, 1993), and often includes elements of a supplier‘s conformance to manufacturer specified process and product quality standards (Inman & Hubler, 1992).
Literature suggests that the primary objective of supplier certification is to enhance the level of trust and communication and strengthen the supplier-manufacturer relationship (Gould, 2003; Grieco, 1989). Several studies have found that supplier certifications facilitate material flows and reduce production costs (Gibson, Mundy, &
Sink, 1995; Larson & Kulchitsky, 1998; Lockhart & Ettkin, 1993). A supplier certification program also aids buyers and distributors in streamlining the identification, selection, and negotiation with suppliers. Certification not only provides an effective way to build relationships and reduce transactions costs, but also enhances end-product quality and saves time in bringing products to market (Larson & Kulchitsky, 1998; Maass, 1988). It should be noted that the literature almost unequivocally highlights the benefits of
42 supplier certifications with limited focus on potential issues and drawbacks. Further, the studies especially focus on certifiers with limited attention to certifiee issues.
3.2.2 Third-Party Certifications
In addition to supplier certifications, literature has also explored the certifications schemes sponsored and managed by various third-parties such as governmental regulatory institutions, international standards organizations and industrial consortia, for the broader societal welfare (Examples of such organizations include FCC40, UL41, and standards development organization such as ISO, ANSI, and IEC42). Such certifications have been commonly referred to as third-party certifications43 (Lingenfelter, 1988), wherein an independent44 third-party acts as a certification intermediary to facilitate buyer-supplier interactions (Biglaiser & Friedman, 1994; Lizzeri, 1999; Marette & Crespi,
2003).
40 The FCC or Federal Communications Commission is the US federal government‘s regulatory body responsible for regulating the telecommunications industry in the US at large. For more information see http://www.fcc.gov/. 41 The UL or Underwriters Laboratories Inc. is a US-based, privately-owned, non-profit product safety testing and certification organization that develops standards and test procedures for safety of a range of products, materials, assemblies, equipments, and tools. UL is one of the main labs authorized by the federal US government‘s Occupational Safety and Health Administration (OSHA). For more information see http://www.ul.com/. 42 The IEC or International Electrotechnical Commission is an international, non-profit, standards organization that develops and publishes International standards for a wide variety of electrical, electronic and related technologies for home appliances, office equipment, semiconductors, fiber optics, batteries, etc. IEC publishes standards in collaboration with other international standards development organizations such as IEEE, ISO, and ITU. The IEC also manages conformity assessment schemes to certify equipment, systems or components conformance to International standards. For more information see http://www.iec.ch/. 43 In a consistent classification system, third-party certification schemes differ from "first party" schemes, wherein suppliers conduct an internal assessment of the product or practices themselves; and "second party" schemes, where endorsements are made by individual buyers or buyer associations with a vested financial interest in the suppliers‘ products. 44 Independence typically refers to the notion that an organization neither directly facilitates nor influences the buyer-suppler transactions. See (Boegh, 2006) for details.
43 Studies have found that third-party certification adds value in markets where verification by buyers is expensive, possibility of unobservable quality difference is high, or suppliers are numerous and hence may lack sufficient market reputation to credibly disclose quality (Choi, 1998; Rubinstein & Wolinsky, 1987). Further, third-parties act as intermediating gatekeepers, who can lower pricing inefficiencies, reduce search costs, and increase trust in a market (Biglaiser & Friedman, 1994; Resnick, Zeckhauser, &
Avery, 1994; Sarkar, Butler, & Steinfield, 1995).
Literature has also examined the effects of third-party certification intermediaries on an industry‘s economic performance and structure (Albano & Lizzeri, 2001; Dewally &
Ederington, 2006; Lane & Papathanasis, 1983; Marette & Crespi, 2003). Lane and
Papathanasis (1983), for instance, show that third-party product certification can significantly increase firm concentration in manufacturing industries; Marette and Crespi
(2003), examine different cost structures for third-party certification to show that a stable industry cartel of firms providing information about product quality can improve overall welfare even in the presence of supplier collusion; and Albano and Lizzeri (2001), show that certification intermediaries can enhance market efficiency where severe quality information asymmetry exists between buyers and suppliers (Albano & Lizzeri, 2001;
Lane & Papathanasis, 1983; Marette & Crespi, 2003). Further, studies have also discussed the effects of competing certification intermediaries on quality transparency and revelation for reducing buyer-supplier transaction costs (Biglaiser & Friedman, 1994;
Lizzeri, 1999).
44 3.2.2.1 Process and Product Certification
Most third-party certification schemes focus on a specific aspects of a firm‘s performance such as the quality of a firm‘s production processes and the safety of their end-products (Inman & Hubler, 1992; Lingenfelter, 1988; Raynor, 1993). In regards to quality and safety, government and international standards organizations have been particularly proactive in providing process and product certifications (Dawson &
Lewelling, 1991). A classic example is the ISO 9000 certifications, which assesses the conformance of a firm‘s quality assurance processes to the internationally accepted guidelines provided by ISO. Focusing on procedures, controls, and documentation, the
ISO certification is designed to assist firms in identifying mistakes and streamlining their operations in order to guarantee a consistent level of end-product quality (Raynor, 1993;
Stevenson & Barnes, 2002). Such process certifications not only raise the end-product quality but also play a significant role in enhancing customer satisfaction and the firm‘s productivity, performance, and profitability (Kartha, 2007; Terziovski et al., 2003).
Further, literature has also examined the importance of certification at the product-level. While firm-level certifications assess a wide variety of quality attributes of a firm such as product development processes and quality assurance practices, product certifications are more specialized in their purpose. Product certifications primarily focus on the conformance of a product to minimal quality and safety standards for greater social welfare (Dawson & Lewelling, 1991; Jahn et al., 2005; Lingenfelter, 1988).
45 3.2.2.2 Standards and Software Certification
In the context of ICT industry, studies have primarily focused on technology standards certification by various regulatory as well as international standardization third-parties (Costlow, 2004; Dawson & Lewelling, 1991). Rada (1996), for instance, surveys various IT standards conformity assessment bodies to highlight the importance of certification in tackling software safety and welfare challenges (Rada, 1996).
Backhouse (2002), underscoring the criticality of security in e-commerce assesses the role of different standards certification authorities (Backhouse, 2002). Further, research has also focused on how certification can be used by standardization bodies to effectively implement standards for increased product compatibility (Söderström, 2002).
Of particular importance are the studies by Tineke M. Egyedi (Egyedi, 2001; Egyedi &
Dahanayake, 2003; Egyedi & Joode, 2003). Discussing various forms of standardization initiatives she provides a coordination framework through which standardization initiatives can address compatibility (Egyedi, 2001). One such coordination mechanism is that of standards certification by standardization bodies or promulgators (Egyedi &
Hudson, 2005). Discussing the case of Linux standardization, she discusses the importance of standards certification by third-party ―gatekeepers‖ of standards developing organization to ensure correct implementation (Egyedi & Joode, 2004)(see
Box 1).
In addition to standards certification, studies have also highlighted the benefits of software safety certification at large. Rodrigue-Dapena (1999) positions software safety certification as a multi-domain problem that spans across software application domains with great safety concerns such as defense systems and health care equipment
(Rodriguez-Dapena, 1999). Software certifications are hence critical in ensuring safety of
46 the systems that the software is applied to (Karasik, 1985; Voas, 1999). Studies have also grappled with the complexity of software systems and provided various mechanisms to execute software testing and certification (Voas, 2001; Voas & Payne,
2000; Wohlin & Runeson, 1994). Boegh (2006), for instance, suggest that third-party certification of software components can better guarantee total software quality (Boegh,
2006). Further, Voas and Payne (2000), raise concerns for software testing and certification due to the inaccessibility of source code of proprietary software components.
Acknowledging such intellectual property concerns they propose a ―test quality rating‖ metric for a component's dependability and demonstrate its effectiveness when used by an independent third-party certification agency (Voas & Payne, 2000). While these studies examine software certification programs acknowledging issues of certification for certifiees, their focus is on creating optimal certification program designs as opposed to understanding the broader effects of the certification.
3.2.3 Certification Systems
As discussed above, literature on certification in general is quite broad.
Certification has been explored in various contexts with focus on – 1) domains such as processes, products, and standards; 2) criteria such as quality, safety, and performance; and 3) sponsors such as buyers, suppliers, and independent third-party agencies.
Although broad in its focus and context, recent literature has attempted to theoretically outline the conceptual underpinnings of a certification system.
Of particular note is the study by Vertinsky and Zhou (2000). Discussing certification in the forestry industry they provide a framework to understand, describe, and evaluate different types of certification systems. They identify six key attributes of
47 any certification system – 1) the structure of control, which essentially describes the nature of the entity providing certification (the certifier); 2) the degree of coercive power, which refers to the level of coercion exercised by a certifier on certifiees; 3) the threshold standard, which refers to the openness or inclusiveness of a certification system to certifiees; 4) the scope of certification, which refers to the domain of certification (a process, product, or professionals); 5) the geographical scope, which refers to the jurisdiction of the certification system; and 6) the way certification is conveyed, which refers to the way certification can be leveraged by certifiees for marketing a certified object (Vertinsky & Zhou, 2000).
More recently, Jahn et al (2005) developed a framework for assessing the economics of certifications based on the prevalence of third-party certifications in the food products industry. They conceptualize certification as a ―consumer policy tool‖ and outline the structure of a certification system identifying key roles for market actors.
These roles include - 1) a standards owner that establishes the minimal certification threshold and monitors the certification activity; 2) an accreditation body that grants recognition and authority to a standards owner to certify; 3) a certification body that executes certification testing; and 4) a group of suppliers and consumers of certifiable goods. They suggest that the reliability of a certification system depends on various actors credibly assuming these roles (Jahn et al., 2005).
These key attributes and roles can be used to describe a given certification system. As theoretical constructs, they provide a helpful template in systematically assessing the efficacy, and exploring the influences of specific certification systems on the market for certified products.
48 3.3 Summary
Research on technology platforms, industrial organization, and strategy has come a long way in theoretically describing and empirically observing the implications of platforms on the coordination and competition between firms. However, research has been limited is three essential aspects.
Firstly, although certification has been observed as market coordination, control, and regulatory mechanism that has been employed by individual firms, third-party economic and governmental entities alike, its application to technology platforms has been considerably under-researched. This is especially surprising as the literature suggests that the design, development and management of platforms is essential in determining the competitive advantage of individual firms as well as the growth of an industry as a whole. Research on platform certification is particularly warranted in network markets where firms heavily rely on the quantity and quality of platform-based products, especially as certifications cannot presume to be cost-free (Jahn et al., 2005).
Secondly, limited studies address the implications of certification for different stakeholders. Although studies have shown that certification can shape competition in a market, they do not sufficiently address the strategic implications for specific stakeholders such as platform promulgators, powerful buyers, and suppliers of certifiable goods.
Thirdly, research that seeks to generate formalized frameworks to analyze certification systems as market institutions is limited. Only a few studies have attempted to conceptualize a certification system and established the validity of constructs in the context of specific markets (examples include (Jahn et al., 2005; Vertinsky & Zhou,
2000))
49 This study addresses these gaps by developing a framework based on theoretical constructs adapted from the extant literature on certification to examine and evaluate platform certification systems. In particular, this study critically examines compliance irregularities, costs, and benefits to highlight the implications of platform certifications for various stakeholders in the mobile applications ecosystem. The following chapter draws on concepts from the reviewed literature to present an initial analytic framework to analyze mobile platform certification programs and their implications for the mobile applications market.
Chapter 4
Conceptual Framework
In this chapter, I draw from and build on the diverse interdisciplinary literature on network markets, technology platforms, standards, certification, and industrial organization to describe a conceptual framework. The conceptual framework is used as an analytic template for examining platform certification systems and their effects on complementary platform-based product markets in the context of mobile computing industry. The conceptual framework outlines the key attributes of a certification system and proposes some expected effects on the platform-based product market drawing on theoretical insights from the literature discussed in the previous chapter.
The chapter is organized in two sections. The first section highlights some of the key attributes of a typical certification system. These attributes are adapted to examine and assess platform certification systems. In particular, ―observation points‖45 to examine each key attribute are discussed. The following section applies the identified attributes of a platform certification system to explore their potential effects on the platform-based product market. In doing so the section presents theoretically guided propositions on the market implications of platform certification. More specifically, the propositions address the expected effects of platform certification on vertical compatibility of platform-based products and entry barriers in the platform-based product market.
45 Observation points are investigative ―sensitizing concepts‖ that help in systematic research data collection and analysis. For details see the next chapter on Research Methods.
51 4.1 Investigating a Platform Certification System
In order to investigate the overarching research question of how platform certification programs influence the firms in the mobile applications ecosystem, it is essential to first examine platform certification systems. I begin by identifying the key attributes of a typical certification system.
As discussed in the previous chapter, the literature on certification is quite broad.
Certification has been explored in various contexts with focus on domains such as processes, products, and standards; involving certification criteria that include quality, safety, or performance; and sponsored by various market stakeholders including buyers, suppliers, or independent third-party agencies. However, Vertinsky and Zhou (2000), provide a useful template to conceptually understand a typical certification system.
Drawing on the forest product and manufacturing process certification programs, they identify six key attributes of a certification system. The six attributes include the structure of control, the degree of coercive power exerted, the threshold of standards, the scope of certification, its geographical scope, and the way certification is conveyed to the market (Vertinsky & Zhou, 2000).
The structure of control emphasizes the certifier‘s control over the certification procedures, policies, and criteria. The structure of control underscores a certifier‘s role in the certification system and addresses a few key questions. Who provides the certification? (Is it a for-profit or a non-profit agency?) What is the underlying objective of the certifier? And, how do they manage the certification program? The degree of coercive power exerted, emphasizes the costs of not certifying for a potential certifiee46.
Is the certification program mandatory or voluntary? And what are the costs of not
46 The entity attempting to get an object (product, process, or personnel) certified
52 certifying (for a potential certifiee)? The threshold of standards, underscores the certification scheme or criteria that differentiates the certified from the uncertified. This attribute addresses questions about the rigor of the certification scheme. Is it easily conformable (and hence inclusive) or rigorous (and hence exclusive)? The scope of certification emphasizes the domain of certification. What is being certified? a process, product, or professionals. The geographic scope specifies the jurisdiction of certification.
Is it regional, national, global or applies to specific markets? And finally, the way certification is conveyed refers how certification can be leveraged by certifiees for marketing a certified object (Vertinsky & Zhou, 2000).
These attributes can be applied to all certification systems. I draw on these key attributes to specifically assess platform certification systems in the context of the mobile computing ecosystem. As this study examines both the characteristics and the effects of mobile computing platform certification systems, I adapted the Vertinsky and Zhou
(2000) certification system typology to develop a simplified effects-oriented framework.
In this adapted framework the three key certification attributes I seek to explore are – the certification authority structure, the certification constraints, and the certification benefits.
In this adapted typology, the certification authority structure describes the role of a
―certifier‖ that designs and manages the certification system. In Vertinsky and Zhou‘s terms, the ―structure of control‖ and the ―degree of coercive power‖ imposed by the certifier are an integral part of determining the certification authority structure. Further, taking the potential ―certifiee‖ perspective, I view certification as a regulatory mechanism, wherein the certification system provides a set of constraints and benefits for potential certifiees. These certification constraints and benefits for a certifiee can provide insights in assessing the effects of certification on the market of potential certifiees. In Vertinsky and Zhou‘s terms, the certification constraints and benefits cut across the ―threshold of
53 standards‖ and ―the way certification is conveyed‖ attributes. In summary, the three certification attributes – authority structure, constraints, and benefits – describe the way a certification system is designed and managed by a certifier, in addition to the constraint and benefits it provides to potential certifiees. I elaborate on these three attributes of the certification system in the following sub-sections.
4.1.1 Certification Authority Structure
Certification is often viewed as a regulatory mechanism that requires establishing a control or authority structure (Dawson & Lewelling, 1991; Egyedi & Joode, 2004). An authority or authority structure has to be formally or informally designated so as to manage a certification system or program.
In the case of platform certifications, typically the agency responsible for promulgating the platform acts as the certification authority47. I refer to such an authority as the ―platform promulgator‖. The platform promulgator(s) might derive its authority through formally recognized regulatory entities (examples ITU, ANSI, ETSI) or informally though its reputation and recognition by industry consortia or stakeholders. A platform promulgator might not have the requisite influence or dominance in an industry that is essential for industry-wide acceptance of a certification program. In such situations, the platform promulgator, in an attempt to legitimize the certification program, can acquire authority from firms with higher bargaining power in an industry (powerful actors). Such
―powerful actors‖ often derive their bargaining power from either their position in the industry value chain or superior market share (Porter, 1985). The success of the
47 Also sometimes referred to as a certification sponsor
54 certification program depends on how a platform promulgator interacts with the powerful actors so as to gain recognition and acceptance for the certification program. The platform promulgator can acquire the requisite influence from powerful actors by either cooperatively offering the certification program with one or multiple powerful actors, or negotiate certification program endorsements with power actor(s) after the launch of the certification program.
Further, a platform promulgator also provides a platform for designing complementary products. The success of a platform in terms of its adoption critically depends on the complementary product developers due to indirect network externalities
(Bresnahan & Greenstein, 1999; Clements, 2004). Hence, for platform certification, the platform promulgator also has to gain sufficient support from the complementary product developers. The success of the platform and its certification program depends on how the platform promulgator interacts with the ecosystem of complementary product developers and leverages their support.
The certification authority structure in platform certification can hence be investigated by examining three essential dimensions – 1) the platform promulgators control over and management of the platform certification program; 2) the recognition and support of the actors with higher bargaining power in the industry, and sufficient acceptance of the complementary product developer community; and 3) the interaction of platform promulgator with the powerful actors and the complementary platform-based product developer community. Hence, in order to investigate platform certifications, the study should address the following observation points –
Observation Point 1. Platform promulgator‘s control over the certification
program – in terms of the program‘s design, procedural management, and
relegation of certification control
55 Observation Point 2. The bargaining power of actors that endorse and support
the certification program in the industry – in terms of their market share and value
chain position
Observation Point 3. The inclusion of certification in typical distribution and
revenue models in the platform-based product developer community
Observation Point 4. The nature of relations between the platform promulgator,
the powerful actors, and their platform-based product developers – in terms of
the recognition, support, and acceptance of the certification program
These observation points help describe the influence exerted by the certification authority structure on potential certifiees. For analytical purposes the influence of certification authority structure can be described as ‗strong‘ or ‗weak‘. A weak certification authority structure can be attributed to observations of low level of recognition of platform promulgator, low combined market share of supporting powerful actors, and low level of cooperation with powerful actors48.
4.1.2 Certification Constraints
A certification system imposes a set of constraints so as to differentiate the certified object (product, process, or personnel) from the uncertified. Certification constraints are the tools or mechanisms that can be used for regulating various aspects of the object of certification. A certification program can vary in their type and degree of
48 See the next chapter on Research Methods for detailed construct operationalization
56 imposed constraints. This variation can determine, at least in part, the implications of the certification system.
Broadly, the constraints of a certification system can be broken into three categories – a) the certification criteria, i.e. the conditions for approval; b) the certification process, i.e. the procedure to gain approval; and c) the certification cost, i.e. the cost of gaining approval. The certification criteria are the most important form of constraint that are often explicitly stated and documented. It can range from extensive/comprehensive/detailed to limited/cursory/narrow. The certification criteria influence the inclusiveness or exclusiveness of the certification system and hence determine the degree of differentiation a certified object can achieve. Certification process, on the other hand, is an indirect form of constraint, wherein the process can additionally constrain the certifiee. The certification process can range from cumbersome/confusing/lengthy to compact/clear/short. It should be noted that even though the certification process is an indirect constraint, it can be intentionally used to influence the inclusiveness or exclusiveness of the certification system. Finally, the certification cost is another form of indirect certification constraint that can exclude the entity attempting to certify. Although the certification cost is often unavoidable as resources required to certify such as test equipment and management, have associated costs, the price of certification can be altered to influence the inclusiveness or exclusiveness of the certification system. In a certification system where certification authority is leveraged from the economic entities in the market, the cost of certification presents an important observable constraint.
The constraints of platform certification can then be investigated by examining the certification criteria, process, and cost. In order to investigate platform certifications, the study should hence address the following observation points –
57 Observation Point 5. The scope of certification criteria – in terms of its
comprehensiveness and rigor
Observation Point 6. The process of certification – in terms of clarity and the
time it takes to certify
Observation Point 7. The cost of certification – in terms of certification fees,
investments, and the cost of not certifying49 for a potential certifiee
These observation points help describe the basic constraints imposed by platform certification. From the perspective of the entity applying for certification these observation highlight the evaluative points for accepting the certification program. For analytical purposes certification constraints can be described as ‗high‘ or ‗low‘, where low certification constraints can be attributed to observations of cursory certification criteria; clear and compact certification process, and low or no cost for certification50.
4.1.3 Certification Benefits
In addition to the authority structure and the constraints levied, it is essential to describe the advantages offered by the certification system. A certification system will have no utility if it does not provide any benefits or if the constraints outweigh the benefits. As benefits is a perceived dimension it has to be explored along the dimensions of its importance in the industry, the way it is conveyed or advertised, and qualitatively perceived by potential certifiees. The success of the certification system
49 The cost of not certifying the object of certification is also referred to as ―opportunity cost‖ in economics 50 See the next chapter on Research Methods for detailed construct operationalization
58 then depends on the importance of benefits provided, as well as the way they are conveyed, advertised, and perceived, which directly influences the strategic conduct of potential certifiees in the market.
In a platform certification system, the benefits can be provided through multiple mechanisms. Two benefits can be broadly identified as production and distribution facilitation. Platforms are viewed as design or technology architectures that form the basis of production for complementary products (Chen & Liu, 2005; Halman, Hofer, &
Vuuren, 2003; Hobday, 1998; Meyer & Lehnerd, 1997). It is expected that a platform certification system should, at least to some extent, facilitate the production and distribution of complementary products. In other words, benefits of a platform certification system can be observed along the dimensions of production and distribution support provided by the certification system to the potential certifiees. Production support can include provision of design guidelines, assurance of vertical compatibility, availability and access to specialized development tools and training. In addition, the distribution support can include exclusive access to or establishment of distribution channels and marketing partnerships to distribute certified products.
It is expected that the platform promulgators, as certifiers, will actively facilitate both production and distribution of complementary certified products. However, the existence of production and distribution support by certifiers does not necessarily guarantee their usefulness, which can vary greatly in terms of their ease of use, reliability, and quality of information provided. The certification benefits can hence be better observed through the exclusivity, quality, and ease of access to the production and distribution support as perceived by the certifiees. Therefore, the benefits of platform certification can be investigated by examining the level and perceptions of both
59 production and distribution support. Therefore, the study should examine the following observation points –
Observation Point 8. Production support – in terms of its breadth, variety and
perceived exclusivity, easy access, and quality
Observation Point 9. Distribution support – in terms of variety and perceived
exclusivity and reduced distribution transaction costs
These observation points help describe the exclusive benefits provided by a platform certification system. From the perspective of the entity applying for certification these observation highlight the evaluative points for adopting the certification program.
For analytical purposes certification benefits can be described as ‗high‘ or ‗low‘, where low certification benefits can be attributed to observations of low or no production support, ineffectual or nonexistent distribution support51.
From a structural perspective, a platform certification system has three critical constructs – Authority Structure, Imposed Constraints, and Perceived Benefits. A platform promulgator establishes the certification authority structure that is then leveraged to impose certification constrains and provides certification benefits to the certifiees. Together, these conceptual constructs can be examined to characterize platform certification systems and evaluate their effects on the platform-based product markets. Figure 4:1 summarizes the conceptual characterization of a platform certification system.
51 See the next chapter on Research Methods for detailed construct operationalization
60
Authority Structure
Control and Management Powerful Actor Support Developer Acceptance
Imposed Constraints Perceived Benefits
Criteria Production Support Process Distribution Support Cost
Figure 4:1: Platform Certification System: Conceptual Constructs
4.2 Market Effects of Platform Certification System
A certification system has often been viewed as a market regulatory mechanism in the literature (Dawson & Lewelling, 1991; Egyedi & Joode, 2004). Jahn et al (2005) conceptualized a certification system as a consumer policy tool, wherein the competitive economics of a market are shaped by certification (Jahn et al., 2005). Platform certification in a platform-based market hence is bound to have economic implications for various market actors. In this section I present theoretically guided propositions on the expected market effects of platform certifications. I specifically focus on the certification implications for the suppliers of certifiable goods – the developers of platform-based products. The market effect expectation of platform certification is shown in Figure 4:2.
61
Platform Platform-Based Certification Influences Product-Market System
Figure 4:2: Market Effects of Platform Certification: Conceptual Expectations
In order to examine the market effects of platform certification, I explore two conceptual dimensions that describe the supply of platform-based products – the deployability52 of products, and the market conditions for producers/suppliers. In exploring deployability of platform-based products, I specifically examine vertical compatibility of products with the implementations of their platforms. Further, I examine the classical entry barriers to describe the basic market conditions for producers. In the following subsections, I first discuss the expected effects of platform certification on the vertical compatibility of certifiable products. I then highlight the expected effects of platform certification on the market entry conditions for the producers.
4.2.1 Vertical Product Compatibility
Extant literature on platforms suggests that platform-based product markets exhibit characteristics of network markets. Platforms, as design architectures, form the basis of production for many complementary products that in turn enhance the adoption of the platform (Chen & Liu, 2005; Meyer & Lehnerd, 1997). The success of a platform hence critically depends on the availability of complementary products (Church &
52 Deployability can be defined as the ease with which products can be produced and delivered for eventual end-user consumption
62 Gandal, 1993, 1996). Therefore, ensuring the availability of complementary platform- based products is a primary concern for platform promulgators.
Various researchers have recognized vertical compatibility of complementary products as one of the core challenges for platform promulgators in ensuring the availability of complementary products (David & Greenstein, 1990; Nicholas
Economides, 1996; Egyedi, 2001; Farrell & Saloner, 1992; Katz & Shapiro, 1985). This is especially the case in ICT industries, where technology architectures are inherently complex as they define and combine multiple technical components, their specifications and document the rules and guidelines of their interactions (Egyedi & Dahanayake,
2003; Greenstein, 1998, 2006). This complexity can lead to ambiguous architecture specifications and varying implementations (Egyedi & Joode, 2003). Hence, the vertical compatibility of products designed for a platform can suffer.
Platform certification systems can potentially address the issues of vertical product compatibility for a platform promulgator. As a regulatory instrument, platform certification systems can potentially assess vertical compatibility of platform-based products and enhance vertical compatibility of certified products. The overall effect of a platform certification system can hence be to enhance the vertical compatibility of complementary products available in the market.
A platform certification system can enhance vertical compatibility through two key mechanisms. The primary driving force in addressing vertical compatibility is the imposed certification constraint, in particular, the certification criterion. The certification criterion can potentially specify the basic tests for product compatibility with the specified platform. The resulting certified product would hence, at least to an extent, conform to the basic compatibility guidelines of the platform promulgators. Further, the more rigorous and comprehensive the certification criteria, the less room it leaves for
63 incompatibility. This leads to a higher degree of compatibility of certified products with the underlying platform. Other forms of constraints such as the process and cost of certification have no direct effect on ensuring compatibility and hence are irrelevant in enhancing vertical compatibility. Therefore the proposition –
Proposition 1: A positive relationship exists between the level of certification
constraints, specifically certification criteria, and the level of vertical compatibility
in the platform-based product market.
In addition to the certification criteria, the level of vertical compatibility also depends on the certification authority structure. Broadly speaking, the stronger the certification authority structure, the higher will be the incentives for the platform-based product developers to attempt certification. For instance, a platform certification system that is supported, endorsed, or mandated by actors with higher bargaining power, will force greater number of platform-based product developers to certify their product. Given that the certification constraints address issues of compatibility, a stronger authority structure will encourage certification and hence enhance vertical compatibility of platform-based products available in the market. Therefore the proposition –
Proposition 2: Given a higher level of certification constraints, a strong authority
structure will further enhance vertical compatibility in the platform-based product
market.
In summary, the effect of platform certification on the vertical compatibility of platform-based products will be a collectively determined by the nature of certification constraints (in particular certification criteria) and the authority structure of the certification. The propositions for the effects of platform certification on deployment fragmentation are summarized in Figure 4:3.
64
Certification Authority Structure
+ P2
Certification Vertical + Constraints P1 Compatibility
Figure 4:3: Effects of Platform Certification: Platform-Based Product‘s Vertical Compatibility
4.2.2 Market Entry Barriers
Entry barriers are a critical determinant of the competitive landscape and innovative potential of a market (Formaini, 2001). An entry barrier in economic terms is defined as the cost that must be incurred by a new entrant (firm or entrepreneur) that incumbents do not incur (McAfee, Mialon, & Williams, 2004). Entry barriers include the required sunk investments and advertising before an entrant can make the first sale. In platform-based markets, additional entry barriers might stem from technological uncertainty and network externalities (Tarnacha & Maitland, 2008a, 2008b). In this section I explore the possibility of platform certification raising barriers for candidate entrants in the platform-based product market.
As certification systems are mechanisms to segregate the certified from the uncertified, they can also erect structural barriers that can indirectly stifle market entry by new firms. For instance, Lane and Papathanasis (1983), examining data from the
Federal Trade Commission showed that entry barriers are raised by existence of product quality certification programs (Lane & Papathanasis, 1983). Similarly platform
65 certification can potentially increase entry barriers in the platform-based product market.
Essentially, platform certification erects operational barriers for developing platform- based products. These operational barriers can potentially deter entry for new entrants in the market that were not faced by incumbents before the certification program was established.
These entry barriers will be created primarily due to the certification constraints imposed by the certification program. Higher certification constraints, in terms of the certification criteria, process, and cost, will deter entry in the platform-based product market. In other words, the higher the certification constraints, the higher the entry barriers in the platform-based product market. Therefore the proposition –
Proposition 3: A positive relationship exists between the level of certification
constraints and the level of entry barriers in the platform-based product market.
However, entrants can potentially have an advantage over incumbents in the market. As the certification program provides certain benefits that were not available before the certification program to the incumbents, the entry will be encouraged by the certification program. The benefits include centralized access to technical and marketing information important to develop a platform-based product and make the first sale.
Hence, the certification program can reduce entry barriers depending on the perceived importance of certification benefits. Therefore the proposition –
Proposition 4: A negative relationship exists between the level of perceived
benefits and the level of entry barriers in the platform-based product market.
Furthermore, the effects of imposed certification constraints and perceived certification benefits are contingent upon the certification authority structure. A platform certification system that is supported or mandated by actors with higher bargaining power, will force greater number of platform-based product developers to certify their
66 product to make a sale. Based on the level of support for the certification system, on one extreme, certification can become a de-facto market requirement for all developers, enhancing the effects of certification constraints and benefits on market entry barriers.
While on the other hand, if the certification system has weak support, developers can avoid certification altogether, thereby annulling the expected affects of certification constraints and benefits on market entry barriers. Therefore the proposition –
Proposition 5: The effects of certification constraints and benefits on entry
barriers in the platform-based market will be positively moderated by the
certification authority structure.
In summary, the effect of certification program on entry barrier will be collectively determined by the certification authority structure, constraints and benefits. The propositions for the effects of platform certification on market entry barriers in the platform-based product market are summarized in Figure 4:4.
Certification Authority Structure
+ + P5
Certification + Constraints P3 Market Entry Barriers Certification - Benefits P4
Figure 4:4: Effects of Platform Certification: Platform-Based Market Entry Barriers
67 In conclusion, the chapter outlined a conceptual framework for investigating characteristics of platform certification and some of the potential effects on the platform- based product market. In the framework I outline three conceptual constructs of a platform certification system – Certification Authority Structure, Imposed Certification
Constraints, and Perceived Certification Benefits. Further, I outlined nine observation points to describe and assess a platform certification system. Furthermore, five propositions were presented to highlight some of the market implications of platform certifications on the platform-based product market. In the following section I present the research design employed for investigating the research questions in the context of the mobile applications market.
Chapter 5
Research Methods
This chapter discusses the research design employed for investigating the research questions in the context of the mobile applications market. The chapter first outlines the research approach. The outline discusses the ontological and epistemological lenses applied, its suitability for addressing the research questions, and the research methods employed. The following section describes the procedures followed for data collection, wherein data sources and sampling strategy is presented. A descriptive summary of the research participants is also presented. This is followed by the section on data analysis approach, which details the construct operationalization and addresses construct validity and triangulation. Further, levels of analyses and issues of analytic closure are discussed to highlight the process for data analysis.
5.1 Research Approach
In order to investigate how platform certification programs affect firms in the mobile applications ecosystem, the study employs the case study method. The study in particular uses the multiple-case design (Yin, 1994), wherein three platform certification programs in the mobile application value chain – Symbian Signed, Java Verified, and
TRUE BREW are investigated as separate cases. The conceptual model developed in the previous chapter is used to investigate each case individually, where similar constructs were observed and evidence was sought to corroborate the propositions.
69 The three certification programs were primarily selected due to the wide deployment and the differences in the standardization approach of their underlying platforms on various mobile devices.
Firstly, Symbian-OS, Java ME, and BREW are few of the most widely deployed platforms on mobile devices. On one hand, Symbian-OS has steadily gained its market share in the Smartphone Device market share (RCRWireless, 2004, 2005). By 2006,
Symbian-OS had more than 66% of the Smartphone market share (Canalys, 2006;
RCRWireless, 2006). On the other hand, according to EDC, an independent application developer survey agency Java ME was one of the most widely deployed middleware platforms on all types of mobile devices, while BREW was widely deployed on a majority of CDMA-based cellular devices (Butters, 2005). The widespread deployment increases the availability and accessibility of the suppliers of the platform-based products, as well as the trade press coverage, which are used as data sources for the study. The availability of multiple data sources to inform each case enhances the robustness and the validity of the cases (Yin, 1994, pg. 103).
Secondly, as the literature on platform certification is limited, the observations that corroborate the propositions can also be attributed to constructs that are not taken into account in the study. For instance, platform standardization approach used by a platform promulgator can potentially influence the design and management (authority structure) of its certification program. Hence, the certification programs of BREW (a proprietary platform standardization approach), Java ME (an open stakeholder- participatory standardization approach), and Symbian (an alliance-driven standardization approach) were selected to take into account the variations attributed to the standardization approach of the platform promulgator. The three cases allow for what is referred to as theoretical replication, so that data from the three cases can be analyzed
70 across cases (Yin, 1994). Theoretical replication of cases creates the possibility of observing variations across cases for comparative assessment that can aid in corroborating/refuting the expected effects of platform certification on the firms in the mobile applications ecosystem.
On an ontological level the research approach is interpretive in nature that builds on the fundamental view that social processes and interactions (and hence economic and market interactions) can be understood through the involved actors and their discourse (Walsham, 1995). The subjective account and assessment of the actors involved or influenced by the socio-economic phenomenon can be interpreted to build, refine and support the findings on the nature and effects of the platform certification (a socio-economic phenomenon). The case study design, in particular, is chosen as the proposed study focuses on a complex phenomenon in the real-world context, where the researcher cannot control either the behavior of the actors involved or the unfolding of events (Yin, 1994)(See 53 for further discussion). Further, the case study design is beneficial in exploring the variations in the real-world context that cannot be taken into
53 As the study focuses on the establishment of a socio-economic system (certification) at a particular time, the proposed study can also be designed using a positivistic approach. The positivistic approach would entail conducting the research by observing the context before and after the system was established, by using observation controls. However, such an approach can not only be practically tricky, but also be misleading. First, it is practically difficult as it assumes the availability of data on the operational attributes of the market before and after the establishment of the system in the market. In the mobile application market, most of the application vendors are still not publicly traded, ruling out the possibility of SEC data on the mobile application markets. Further, no prior studies have been conducted observing the structural attributes of the mobile application market prior to establishment of platform certification that can be leveraged. Second, and more importantly, even if such data was available, the approach can be misleading due to the nascent state of the market. In emerging markets, it is often impossible to predict, identify, and control exogenous factors that can influence the evolution of markets. Examples of exogenous uncertainty can stem from unpredictable demand, technological breakthroughs, and level of investment. This inability to control these exogenous factors can lead to inflated or deflated attribution of the endogenous factors on the structural attributes of the market. This is particularly true for the emerging mobile applications market, which has high demand uncertainty (Kleijnen, Ruyter, & Wetzels, 2003) and rapid technological advances (Funk, 2004a).
71 account at the onset of the study leading to rich and in-depth analysis of the phenomenon at hand.
The interpretive approach affords multiple research methods, through which data can be collected such as interviews, observations, and documents (Patton, 2001). This research study used interviews with key certification stakeholders and published documents as the primary methods for data collection (more details in the following section). In that sense the approach is a multi-method approach that incorporates – 1) interviews with involved actors about their industry experiences and anecdotal observations; and 2) document collection and analysis to support as well as highlight the context of the industry in which they operate. A multi-method synthesis illuminates the context from different sources, providing richer understanding (Sawyer, 2001) as well as methodological triangulation (Patton, 2001, pg. 247) to establish the robustness of the findings.
Further, the study collected data from multiple sources of interview subjects and documents. The interview subjects were categorized into two broad categories – the key experts and the key informants. In particular, the key experts are the representatives of the firms involved in the development and administration of the platform certification programs, which include the representatives of the platform promulgators‘ certification program offices, the authorized certification labs, and the official certification program supporting stakeholders (more details to follow). The interviews with key experts were open-ended in nature, which provides a descriptive account of the nature and intended rationale of the certification programs. On the other hand, the key informants are the representatives of various suppliers of platform-based products (mobile applications) who were active before and after the establishment of the certification program. These key informants provided key anecdotal insights in to the effects of platform certification
72 programs on the mobile application developers. The interviews with key informants were semi-structured and guided by the analytic framework outlined in the previous chapter.
The open-ended component of the interviews with the key informants allows room to reflect on the structural conditions of the market, as well as, provide a descriptive account of the nature and intended rationale of the certification programs, leading to data triangulation from multiple sources of evidence (Yin, 1994)(Patton, 2001, pg. 247).
Finally, the study also used archived and current documents to illuminate the context of the study. The documents used for the study included industry reports, technological magazines, trade-press articles, publicly accessible developer forum web-logs and secondary publicly available survey research. Again, collecting data from multiple sources aids data triangulation (Patton, 2001, pg. 247).
5.2 Research Procedure and Data Collection
As the study examines the role of platform certification programs in influencing the firms in the mobile application ecosystem, the focal points of investigation were two- prong. First, I examined the design and management of the platform certification programs – its institutional policies, key stakeholders, and their roles. Second, I evaluated the effects of design and management of platform certification on the firms in the mobile application ecosystem and the resulting structure of the market. As a primary source of information for examining the design and management of the platform certification programs, I recruited key experts, who were knowledgeable about the rationale and administration of the certification programs. Further, as a primary source of information for evaluating the market effects of platform certification programs, I recruited key informants, who shared their experiences in the mobile application
73 market54. The following sub-sections discuss the data sources, their sampling strategies, and then present a summary of the recruited research participants.
5.2.1 Data Sources and Sampling
As mentioned above, data was collected from two primary sources and two secondary sources. The primary sources included the interviews with the key experts and key informants, wherein key experts were identified and interviewed to provide the contextual knowledge-base for evaluating data from the key informants. The secondary sources included documents and discourse on various developer forums and trade press articles, which were used to support and triangulate data from the key experts and informants.
5.2.1.1 Primary Sources: Key Experts
In order to examine and assess the certification programs, key experts were identified as the official representatives from the certification program office, the representatives from the authorized certification lab, and the representatives from the official certification program supporting stakeholders. The key experts were sampled based on their direct experience with and expertise in the initial design and eventual administration of the platform certification program.
54 It should be noted that although the key experts and key informants act as primary source of information for the certification program and its effects on the mobile applications market, respectively, they are also used to support and corroborate each other‘s information. For instance, the key experts were also asked to share their views on the impact of certification program on the mobile application market, while experienced key informants were also asked about the administration and management of the certification programs. This leads to what is often referred to as data source triangulation ((Patton, 2001), pg. 247).
74 Firstly, the key experts from the certification program offices were directly contacted through the publicly available contact information on the certification program‘s website. The details and scope of the study was emailed with the recruitment email. Secondly, representatives from the authorized certification labs were also sought through email using contact information listed on the websites of the certification programs. Finally, representatives from the official supporters of the three certification programs were identified using developer forums and trade press articles. The official supporters of interest to the study primarily included the network operators and device manufacturers as they have been identified in the literature as the actors with higher bargaining power in the value chain (Barnes, 2002; Rülke et al., 2003; Sabat, 2002). As all major network operators and device manufacturers host and administer developer forums, the forum coordinators were contacted to identify and recruit representatives of the official supporters of the certification program.
Once the initial key experts were interviewed, the sample was expanded based on their recommendations. References and suggestions from initially sampled key experts were used to recruit additional key experts 55&56. Key experts were continually recruited and interviewed till all the stakeholder categories were covered and a consensus on diverse expert information was reached.
55 This snowball sampling strategy was particularly effective for identifying and contacting key experts in the official certification program supporters 56 The author had the opportunity of working at National Software Testing Labs (NSTL), a key authorized certification lab for all the three certification programs, in the summer of 2006. They provided crucial contact information and references of various key experts in certification program offices as well as official program supporting stakeholders such as mobile operators and device manufacturers.
75 5.2.1.2 Primary Sources: Key Informants
In addition to key experts of the certification programs, key informants served as source for evaluating the market effects of platform certification programs. These key informants included the senior representatives of mobile applications developer firms, which had been active in the mobile application market before the inception of the certification programs57. Recruiting representatives of developers active before the inception of the certification program allows for a more credible and accurate evaluation of the market effects of the certification programs.
Mobile application developers were mostly identified from developer forums hosted by platform promulgators, network operators, and device manufacturers. In order to inform individual cases I classified developers in to three categories – 1) BREW
Developers; 2) Java ME Developers; and 3) Symbian Developers, based on their preferred choice of application development platform. In cases where a sampled developer developed applications for more than one platform, their experiences on all the platforms and their certification programs were used to analyze data across cases.
Application developers were continually recruited and interviewed till a consensus on major developer issues was reached.
57 It is important to note that as the Symbian Signed program was established in mid 2004, only Symbian application developers who had been operational since at least 2003 were recruited. Further, as the Java Verified program was established in mid 2003, only Java ME application developers who had been operational since at least 2002 were recruited. Finally, as the TRUE BREW program was launched simultaneously with the BREW platform in 2001, only the BREW developers established in 2001 and currently active were recruited.
76 5.2.1.3 Secondary Sources: Developer Forums and Trade Press Archives
The insights from interviews with the key experts and informants were triangulated from two secondary sources – developer forums and trade press archives.
As mentioned above, most major network operators and device manufacturers, in addition to platform promulgators host and manage developer forums. These developer forums are essentially an online business and technical community of mobile application developers. Such forums provide a wealth of information, resources, and tools for developers to develop and distribute applications on particular platforms, networks, and devices. Data from these developer forums were used, whenever necessary, to corroborate or refute the insights provided by the key experts and informants. A list of developer forums used for the study is shown in Table 5-1 .
77
Table 5-1: Developer Forums: A Source of Research Participant Sampling and Secondary Data Developer Forums Website Platform Promulgators BREW Developer http://brew.qualcomm.com/brew/en/developer/overview.html Program Symbian Developer http://developer.symbian.com/ Network Sun Developer http://developers.sun.com/ Network Network Operators Cingular http://developer.cingular.com/developer/index.jsp?page=commu devCentral nity Verizon Wireless http://www.vzwdevelopers.com/aims/ Zon Sprint Application http://developer.sprint.com/ Developer Program Orange Partner http://www.orangepartner.com/ Device Manufacturers Forum Nokia http://www.forum.nokia.com/ Motorola Developer http://developer.motorola.com/ Network Sony Ericsson http://developer.sonyericsson.com/ Developer World BlackBerry http://na.blackberry.com/eng/developers/community.jsp Community
In addition to developer forums, trade press archives were also used to inform and support the study. The trade press archives were sampled based on a pilot study that was conducted by the author on the mobile application industry in the fall of 2005.
The study had conducted open-ended interviews with various actors in the mobile application value chain, wherein the interviewees identified key sources of mobile industry information and news. These sources included Cellular News58, RCR News
58 Website: http://www.cellular-news.com
78 Directory59, Fierce Wireless News60, and Mobile Content News61. These archives were particularly used to search for articles to support data from primary sources.
A list of supporting documents used for the study is provided in the Appendix.
5.2.2 Research Participants
The data for the study was collected from late 2006 to mid 2007, primarily over the phone. A total of 46 interviews with over 32 hours of engagement were conducted with different research participants. The interviews ranged from 18 to 75 minutes with an average of about 42 minutes per interview.
5.2.2.1 Key Experts
A total of 20 key experts were recruited from the three certification program offices, their authorized testing labs, and key certification program supporters including device manufacturers and network operators. All the key experts were, at least, senior managers responsible for test planning, operations, and developer engagement programs62. Table 5-2 provides the number of interviews conducted for each stakeholder organization.
59 Website: http://www.rcrnewsdirectory.com/ 60 Website: http://www.fiercewireless.com/ 61 Website: http://www.moconews.net/ 62 In the interest of anonymity promised to the recruited interviewees, the name of the interviewees‘ organization and their position is not disclosed.
79
Table 5-2: Key Experts: Stakeholder Representatives Stakeholders Number of Interviewees Certification Program Offices 7 Authorized Certification Testing Labs 7 Certification Program Device Manufacturers 3 Supporters Mobile Network Operators 3
5.2.2.2 Key Informants: Mobile Application Developers
In addition to key experts, senior representatives from a total of 26 developer firms were interviewed. Most of these developers had operations across the Americas and Europe. Some of the developers (10 out of 26) had development expertise and operations across the three platforms. The details of the developer firms are presented in Table 5-3. A summary of the developer firms‘ expertise on platforms is presented in
Table 5-4. Further, Table 5-5 shows the functional breakdown of the interviewed developer firm representatives63.
63 Again, in the interest of anonymity promised to the recruited interviewees, the name of the interviewees‘ organization and their position is not disclosed.
80
Table 5-3: Key Informants: Mobile Application Developers Developer Number of Avg. Number Major Development Platform(s) Employees of Regional Applications/ Operations Year 1 3 <5 Americas BREW 2 <50 >25 Americas BREW; Java ME; Symbian 3 <25 <5 Europe Java ME 4 1 <5 Americas BREW 5 1 <5 Europe BREW 6 <10 <5 Europe Symbian 7 2 <5 Asia Java ME 8 <50 >25 Europe Java ME; Symbian 9 <10 <5 Americas Java ME; Symbian 10 5 <5 Europe Symbian 11 <25 <5 Americas BREW; Java ME; Symbian 12 3 <5 Europe Java ME 13 <15 <10 Europe Java ME 14 <10 <5 Europe BREW 15 5 <5 Asia Java ME 16 <10 <10 Americas BREW 17 5 <5 Americas BREW 18 1 <5 Europe Java ME 19 <10 <5 Americas BREW; Java ME 20 2 <5 Europe Java ME 21 <50 >25 Europe Java ME; Symbian 22 <10 <5 Americas BREW; Java ME 23 <100 >25 Europe BREW; Java ME; Symbian 24 <25 <5 Americas BREW; Java ME 25 <150 >25 Americas BREW; Java ME; Symbian 26 1 <5 Europe Symbian
81
Table 5-4: Key Informants: Expertise Breakdown of Developers Developers Number of Developers64 BREW Developers65 13 Java ME Developers66 17 Symbian Developers67 10 Developers for more than one platform 10
Table 5-5: Key Informants: Functional Breakdown of the Interviewees Function Number of Interviewees Top-Management 13 Technical Operations, Quality Assurance and Testing 7 Business Development and Sales 6
Among the developers interviewed, most (21 out of 26) were ―low-volume‖ application developers who reported an average of less than 10 different deployed applications per year, while the rest were (5 out of 26) were ―high-volume‖ application developers who reported an average of more than 25 different deployed applications per year. For analytic consistency, I refer to low-volume application developers, who develop an average of less than 10 applications a year, as ―Small Developers‖; and high-volume developers, who develop an average of more than 25 applications a year, as ―Large
Developers‖68.
64 The number of developers in the table will not match the total number of developers interviewed (26), as some developers had expertise on more than one application platform market. 65 Active in BREW application development since 2001 66 Active in Java ME application development at least since 2002 67 Active in Symbian application development at least since 2003 68 In distinguishing between ―Small‖ and ―Large‖ developer firms, I used ―average number of application per year‖ over the ―number of employees‖ because I was primarily interested in an
82 Estimated population of developers for a particular platform ranges from hundreds to a few thousands. The population of developers for a particular platform was estimated from the number of registered firms on the certification program offices website, as well as the statistics reported by platform promulgators about the strength of their respective ecosystems. BREW application developer population in 2007 ranged between 750-1000. Symbian in 2006 reported about 450 active registered developers, while Sun claims that Java ME developers are in at least a few thousand.
5.3 Data Analysis
As discussed above, the study used an interpretive multiple case design to examine and evaluate platform certification programs, as well as observe the market implications of platform certification programs on the mobile application ecosystem.
Given this research design, the primary more of analysis was narrative interpretation and document analysis (Patton, 2001). The interviews with the key experts were recorded, transcribed, and coded along the observation points (outlined in the conceptual model) to examine and evaluate the three platform certification programs. Further, documents from the developer forums and the trade press archives were also collected and coded along these observation points to triangulate and supplement the interviews with key experts. These observation points acted as ―sensitizing concepts‖ (see (Patton, 2001),
Chapter 6 and 8 for details) that aided in the exploration as well as theoretical conceptualization of the design and management of the certification programs.
estimate of the production capacity of the developer firm. The number of applications provides a more accurate picture than the traditional operationalization of size – the number of employees.
83 In addition interviews with key experts and document analysis along the observation points, the interviews with key informants were recorded, transcribed, and coded based on the constructs of the initial analytic framework. Although the initial coding of key informant interviews was driven by the constructs outlined in the analytic framework, the coding was continuously adjusted along the course of the investigation in order to capture concepts and events that were not taken into account at the onset of the study. Outlying observations were treated as critical junctures where an attempt was made to adjust the coding template to develop a more rich and logical explanation of market effects (Ereaut, 2002). Further, interviews, coding and analysis were simultaneously done across the three cases until data consistency and analytic closure was satisfactorily reached across the three cases (Ereaut, 2002).
5.3.1 Construct Operationalization
In order to systematically collect data for individual cases and asses it across cases, the constructs identified in the conceptual model were operationalized for consistent measurement. Construct operationalization aids in a constructs measurement, wherein it describes the different dimensions of observable measures that collectively inform the construct. Further, construct operationalization helps in ensuring that the observations are consistent, convincing, and legitimate (Babbie, 2004, pg. 112). In addition to construct operationalization, identification of sources informing the operationalized construct can reduce measurement bias and increase the robustness and validity of the measurements (Ereaut, 2002, pg. 143). For this purpose, multiple sources of data are used wherever possible to observe the construct operationalizations. Table 5-6 lists the core constructs for the study and their prime
84 operational measures. The sources of assessing the operational measures are included in parenthesis.
Table 5-6: Construct Operationalization and Validity
Construct Operationalization Certification Platform Promulgator‘s (PP) Control over the Certification Program Authority Investment in and Ownership of platform certification Structure program (Trade press articles, Authorized Certification Labs, Certification Program Office) Degree of Certification Support for Developers (Trade press articles, Developers, Certification Program Office) Relegation of Certification Authority (Trade press articles, Authorized Certification Labs, Certification Program Office) Certification Program‘s Recognition and Reputation in the market (Trade press articles, Developers, Network Operators, Device Manufacturers) Platform Certification Supporting Actors‘ (SA) Bargaining Power Their value chain bargaining power (Trade press articles) Their market share in the segment of the value chain (Trade press articles) Relationship between PP and SA Administrative Sponsorship of the certification program through investments (Trade press articles, Authorized Certification Labs, Certification program office) SA‘s official Endorsement of the certification program (Trade press articles) SA adapting the certification criteria (Trade press articles, Developers, Certification Program Office) Relationship between PP and Developers PP‘s role in encouraging and incentivizing certification by Developers (Developers) PP‘s role in Supporting Developers (Certification Program Office, Developers) Imposed Certification Criteria Certification The Comprehensiveness and Rigor of the certification test Constraints cases (Trade press articles, Publicly available Official Certification Documentation, Authorized Certification Labs) The Failure rate of the submitted applications (Trade press articles, Authorized Certification Labs) The Ease of executing the test cases before certification submission (Developers, Authorized Certification Labs) Certification Process The Clarity and Easy availability of certification criteria documents (Publicly available Official Certification Documentation, Developers)
85
The Transparency in certification usage agreements and clauses (Publicly available Official Certification Documentation) The Time it takes to certify vs. Time to execute the certification criteria (Authorized Certification Labs, Developers) Certification Cost Direct cost to certify one application (Trade press articles, Authorized Certification Labs, Developers) Revenue loss if not certified (Trade press articles, Developers) Perceived Production Support Certification Availability of a variety of technical support tools (objective) Benefits (Trade press articles, Publicly available Official Certification Documentation) Perceived exclusivity, easy access, and quality of technical support tools (subjective) (Developers, Trade press articles) Marketing Support Availability of a variety of distribution channels and buyers (objective) (Publicly available Official Certification Documentation, Trade press articles) Perceived Exclusivity of available distribution channels (subjective) (Developers) Reduction in application distribution costs (Objective and Subjective) (Developers, Certification Program Office, Trade press articles) Market Entry Cost and Availability of required certification equipment Barriers (Authorized Certification Labs, Developers, Trade press articles, Online Search) Cost and Availability of qualified certification test engineers (Trade press articles, Authorized Certification Labs) Certification Discounts for incumbents (Authorized Certification Labs, Developers) Reduced Pricing of applications for incumbents (Trade press articles, Developers) Vertical Ease of Application Deployability across devices Compatibility implementing the same platform (Developers, Trade press articles) Level of cross-platform application porting services used (Trade press articles, Developers) Backward compatibility of applications across devices using a previous platform version (Developers, Trade press articles)
86 5.3.2 Levels of Analysis
The data collected in the research was analyzed along two levels – the intra-case and inter-case. The intra-case analysis consisted of observing the design and management of a particular platform certification program and its immediate implications for application developers in isolation. The case-specific data for the three cases was collected and analyzed simultaneously to highlight case-specific observations and issues. This intra-case analysis provided important nuanced particularities of individual platform certification programs and their effects on application developers.
As the individual cases in themselves cannot completely inform the research questions on assessing platform certification and their implications on developers, the cases were then compared along the constructs outlined in the conceptual framework.
This comparative inter-case analysis helped in addressing some of the generic effects of platform certification in the mobile applications ecosystem. During the cross-case analysis, evidence was sought to corroborate the propositions. Further, reservations on generalizability were made wherever necessary due to the differences across the three platforms and their market-specific peculiarities.
Chapter 6
The Symbian Signed Program
In order to investigate the overarching research question of how platform application certification programs affect firms in the mobile applications ecosystem, I first examine the Symbian Signed program for the Symbian-OS platform. I examine the
Symbian case first as Symbian-OS, as a mobile device operating system provides integrated access to and control over the entire set of mobile device functions and capabilities. In that sense, it is one of the more direct forms of mobile application development platforms.
In this chapter, I first provide a brief overview of the Symbian-OS platform.
Application platforms differ in terms of their technological underpinnings and business models that support application development and distribution. Hence, I discuss the
Symbian-OS features, architecture, and evolution to provide a contextual grounding of
Symbian application development and the role of Symbian Signed certification program in the Symbian ecosystem. Next I discuss the Symbian Signed program in detail. In particular, I provide some of the rationales and value propositions of the Symbian Signed program for various Symbian-OS stakeholders. Further, I outline its core certification mechanisms, processes, and application testing criteria. Following that, I discuss the authority structure of the Symbian Signed program and present some of the constraints and benefits as perceived by the Symbian application developers. Finally, I analyze and discuss some of the implications of the Symbian signed program for the application developers and other firms in the Symbian application ecosystem.
88 The data for the case was primarily gathered from interviews with representatives of the Symbian Signed program office, authorized certification labs, official program supporters, as well as the Symbian application developers. A total of 18 interviews were conducted out of which 10 were Symbian application developers. The case also draws information from various publicly available Symbian Signed documentation, developer forums of Symbian licensees (device manufactures), network operators endorsing the
Symbian Signed program, and various trade-press articles whenever necessary.
6.1 Symbian-OS
Symbian-OS is a mobile operating system that is especially designed for a class of cellular phones with greater processing power referred to as Smartphones. Symbian-
OS was first introduced as a Smartphone operating system, in early 1999. It derived its technical architecture and most of its source-code from the EPOC mobile operating system that was owned by Psion PLC prior to 1999. The first release was dubbed as
Symbian-OS version 5. Through the years its architecture and capabilities have evolved to provide a standardized framework to leverage the increasing Smartphone processing power and features. By 2007, Symbian-OS version 9.5 was available for licensing and
Smartphone implementation.
Symbian-OS is a multitasking operating system that provides a rich set of APIs for integrated access to mobile device features and cellular network functions. It provides direct access to mobile device hardware including screen, keyboard, CPU, memory and audio/video recording, playback and streaming. Further, it supports a host of mobile telephony, voice and data communication protocols including GSM, CDMA,
WAP 2.0, IrDA, Bluetooth, USB, SMS, POP, IMAP, and SMTP. In addition to providing
89 access to mobile device features and network functionality through APIs, Symbian-OS also provides a secure framework for Over-The-Air (OTA), or wireless, Symbian application download and installation. Application developers can hence leverage the underlying device and network capabilities to design and wirelessly deploy Symbian applications.
6.1.1 Symbian-OS Architecture for Application Development and Deployment
Symbian has a layered architecture that manages the mobile device hardware and provides a standardized framework for application development and deployment. A simplified overview of the Symbian-OS v9 architecture is provided in Figure 6:1.
90
Symbian OS Tools
Applications
UI Implementation Third-Party IDE
UI Framework TechView Test UI
Application Services Documentation APIs OS Services Test Tools
Hardware Adaptation Framework Ref Environment Emulation
Hardware Adapters Third-Party Complier
Hardware Including Peripherals Hardware Reference Board
Figure 6:1: Symbian-OS Architecture69
From an application design and deployment perspective, one of the more important aspects of the overall architecture is the ―Symbian Platform Security
Architecture‖. The security architecture essentially manages an application‘s access to
Symbian-OS APIs and controls the application installation, i.e. deployment, over mobile devices. This protects mobile devices, networks and the end-user by restricting an application‘s access to so called ―Sensitive APIs‖ that can be used to access private user data and virally distribute them without the user knowledge.
The security architecture manages the access to APIs by classifying them by their functionality. Most APIS (about 60%) are classified as ―Unrestricted APIs‖. The unrestricted APIs do not have any harmful security implications for the device, network,
69 Adapted from Symbian OS v9.1 Product Sheet, Symbian Ltd. http://www.symbian.com/symbianos/releases/symbianosreleases.html, Accessed Dec 2007
91 or user data integrity, and hence can be accessed by any Symbian application70. The rest of the APIs are classified as ―Restricted‖ or ―Sensitive‖ APIs. These sensitive APIs are mapped on to different ―Capabilities‖. Applications are granted access to these capabilities that determines which APIs can be accessed. Symbian-OS v9 offers a so- called ―Least Privilege‖ model, which entails giving access to the bare minimum capabilities an application requires. There are three types of capabilities based on the authority who grants them – 1) User-Grantable; 2) Symbian Signed-Grantable; and 3)
Device-Manufacturer-Grantable. The User-Granted capabilities are granted by the user at the time of application installation. Symbian-Signed-Granted capabilities are only given to applications that have been tested by a third-party against the Symbian Signed criteria (more details in the next section). Finally, the Device-Manufacturer-Grantable capabilities are only granted by the device manufacturers that implements the Symbian-
OS. The Device-Manufacturer-Grantable capabilities provide access to extremely powerful APIs that if abused can potentially lead to device failures and network overloads. Hence, these capabilities require strong business reasoning and are subject to a legal agreement with the device manufacturer. Details of the Symbian-OS API-
Capability mapping are shown in the Appendix.
In addition to managing access to APIs through controlled capability granting, the
Symbian-OS also manages how applications are installed/deployed on Symbian devices. Symbian achieves this through the use of ―Digital Certificates‖, which are secure-keys assigned to applications. This certificate-application assignment is referred to as ―Digital Signing‖, wherein an application is signed using the certificate for
70 Bruce Carney (2005), Evolving to Symbian OS v9, http://developer.symbian.com/wiki/display/papers/Evolving+to+Symbian+OS+v9, Accessed Dec 2007
92 application installation on Symbian devices. At an abstract level, digital signing assigns a level of trust to an application that it will not abuse the capabilities it accesses. The certificates are assigned to applications by trusted and authorized application developers, third-party testing labs, or Symbian-OS implementing device manufacturers depending upon the types of capabilities requested and used by the applications. At application installation time the Symbian-OS‘s certificate management module verifies the authenticity of the applications certificates using a Public Key Infrastructure (PKI) mechanism, which essentially provides the confidence that the applications being installed are from a known, reputable, and trusted application developer. For a detailed explanation of how digital signatures and PKI works, see the Appendix.
In summary, Symbian-OS‘s security architecture provides a framework for managing how Symbian applications are designed and deployed over the Symbian phones. More importantly, it can identify trusted applications through the use of digital certificates. This helps Symbian in controlling the deployment of complementary third- party applications on Symbian devices and forms the basis of its Symbian Signed application certification program. The following sections describe the Symbian Signed program, its key attributes as a certification system, and discuss its implications for the
Symbian application developers and the Symbian ecosystem at large.
6.2 The Symbian Signed Certification Program
With the emergence of mobile computing, increasing processing capabilities, and prevalence of mobile devices, various actors in the mobile value system, especially network operators and device manufacturers, had started raising concerns of the impact of poor quality and malicious applications on the growth potential of mobile computing.
93 Misbehaving or malicious applications71 could potentially lead to higher support costs and unexpected network loads for network operators, increased device failures and returns for device manufacturers, as well as compromised data privacy and unauthorized mobile service billing for end-users. To avoid and control the impact of such malicious or poor quality applications on the growing mobile computing markets,
Symbian in partnership with various device manufacturers and network operators launched the Symbian Signed application signing program in mid 2004. As an industry- endorsed program, it sought to promote best practices in Symbian-OS application development and provided a framework for building trust in the mobile application ecosystem.
The Symbian Signed program essentially tests applications against a minimum- application-quality criterion and digitally signs the application for deployment and distribution on mobile devices and mobile operator networks for eventual end-user consumption. The digitally signed application cannot be altered and in that sense guarantees the source and integrity of the application. This guarantee is provided by
Symbian and hence is often referred to as an application certification program.
In the following sub-sections, I provide a detailed overview of the Symbian
Signed certification options, process, and certification criteria.
6.2.1 Certification Options
As mentioned above, the Symbian Signed program is managed by Symbian.
However, Symbian has designed the program such that the application certification load
71 Examples of malicious applications include worms, viruses, and spyware that are specifically designed to harm the hardware or end-user.
94 can be distributed to various stakeholders in Symbian‘s ecosystem. Symbian Signed, since its inception, has provided different options, or routes for certifying applications.
Symbian has essentially authorized different stakeholders to execute Symbian Signed testing and certification. The Symbian Signed testing criteria remains the same across the available certification options, but the application testing entity and the certification process varies across the different available options. An application developer can choose between these options depending upon the requirements and business logic of the application.
Symbian initially provided four certification options for application developers –
1) Third-Party Certification: The most commonly used option is the third party
certification, wherein the application is tested and signed by a Symbian
authorized third-party testing lab. As of June 2007, there are three Authorized
Testing Labs (ATLs), National Software Testing Labs (NSTL), MphasiS, and
Sogeti HT. These ATLs test an application against the Symbian signed testing
criteria and charge the application developer a testing and signing fee. As of
June 2007, the third-party testing prices varied from $270 - $80072 per
application.
2) Publisher Certification: In addition to authorizing third-party testing agencies,
Symbian has also developed partnerships with a few applications aggregators or
publishers for application testing and signing. These publishers are recognized
and trusted by Symbian for providing testing and signing Symbian applications
they aggregate. An application developer can partner with these selected
publishers and get their applications Symbian Signed. The Publisher Certifier
72 Prices available from test house websites, Accessed June, 2007
95 tests and signs the application on behalf of the developer and assumes
responsibility of the quality and integrity of the applications. In that sense, the
publisher certifier serves as the trusted source of the application. In return, the
application developer shares the application revenues with the publisher. As of
June 2007, Handango, Flander and Cellmania were authorized publisher
certifiers for the Symbian Signed program.
3) Channel Certification: Further, Symbian also provides Symbian-OS licensees
(device manufacturers) and network operators the option to test and sign
proprietary Symbian applications they develop in-house. This certification
mechanism is referred to as channel certification and is only available to
Symbian partnering device manufacturers and network operators. Channel
certification is particularly suitable for mobile operators and device manufacturers
branded applications that are preinstalled onto mobile devices before their sale to
end-users.
4) Self Certification: Finally, Symbian has partnered with a handful of developers
who have been provided with the ―Self-Certification‖ status. These developers
have been authorized by Symbian to test, sign, and certify their applications
against the Symbian Signed criteria. Self certifiers are trusted by Symbian to test
and sign applications they have signed. They sign a legal agreement with
Symbian warranting the applications will pass the tests and pay an annual fee of
about $10,000 to become a self-certifier. Each self certifier is regularly audited
by Symbian. Before they can become self-certifiers they have their test
processes audited, have to get at least an application Symbian Signed through
the test house option. As of June 2007, there were only 30 registered self
96 certifiers including large firms such as IBM and Avaya.
In addition to the above mentioned certification options, Symbian later also provided a certification mechanism for ―freeware‖ applications. Freeware applications are defined by Symbian as software that is distributed at no charge to the user.
According to Symbian, Adware, Shareware, Crippleware73 do not qualify as freeware. As a freeware application developer does not derive any form of direct revenue for the software being used, the Symbian Signed testing is provided for free. Again, the
Symbian Signed testing criteria are the same, but testing is free. The Symbian Signing and testing costs are covered by Cellmania (a Symbian approved publisher certifier)74.
6.2.2 The Symbian Signing Process
Symbian defines the process for Symbian Signing applications. The process essentially outlines the steps for application pre-requisites, submission, testing, and signing an application. The process is similar across certification options (third-party, self, publisher, channel, and freeware) with minor deviations. The process for using a third-party is outlined below and exceptions are noted if other certification options are used.
73 For details about Adware, Shareware, and Crippleware software see http://en.wikipedia.org/wiki/Adware, http://en.wikipedia.org/wiki/Shareware, andhttp://en.wikipedia.org/wiki/Crippleware respectively 74 For details about Symbian Signing freeware see https://www.symbiansigned.com/app/page/overview/freeware
97 6.2.2.1 Symbian Signing Prerequisites
In order to Symbian Sign an application the developer is required to register their firm with Symbian on the Symbian Signed website (http://www.symbiansigned.com/). In addition, the developer has to establish their authenticity with Symbian. The developer achieves this by either applying for an ACS (Authenticated Content Signing) publisher ID from a Certificate Authority (CA), which independently verifies the developer‘s authenticity and contact information; or choosing a publisher with an ACS publisher ID and signing commercial agreements for application testing and distribution through them. The ACS Publisher ID is a unique identification number that is provided by the CA at an annual fee to an identity verified developer. All applications submitted for Symbian
Signing have to be signed by an ACS Publisher ID. For details about the role of CA see the appendix on digital signatures and public key infrastructure.
Initially, VeriSign acted as the CA for providing ACS publisher ID for $350 per year. Since May, 2007 TC Trust Center has been designated by Symbian as the new and only CA who provides ACS publisher ID for $200 per year75. According to Symbian, obtaining the ACS Publisher ID usually takes 1-4 weeks depending upon CAs ability to verify the authenticity of the developer/ISV or publisher.
In addition to obtaining and signing the application with an ACS Publisher ID, every application has to select a unique UID, which can be obtained instantly by registered developers from the Symbian Signed website. UID is a 32 bit Unique Identifier for the application, which assists in identifying and tracking misbehaving or malicious applications.
75 From Symbian Signed website, https://www.symbiansigned.com/NewCertificateAuthority.pdf, Accessed June 2007
98 6.2.2.2 Pre-Submission Testing and Developer Certificates
Since Symbian introduced the capability-based security framework to access sensitive APIs. Application accessing these sensitive APIs (Symbian-Signed-Grantable and Device-Manufacturer-Grantable APIs) cannot be installed on actual devices even for testing an application during the development phase. This creates a potential problem for developers, as before Symbian Signing the developer need to test application on a target phone to successfully pass the Symbian Signed tests. A ―Developer Certificate‖ or
DevCert solves this problem.
The developer can sign their application with a DevCert instead of an ACS
Publisher ID. The DevCert allows access to the sensitive APIs on a limited number of target devices. The developer can get DevCerts for free from the Symbian Signed website for one device without requiring an ACS Publisher ID76. Multiple DevCerts for additional devices (up to 100) require an ACS publisher ID. Further, DevCerts providing access to Device-Manufacturer-Approval and Device-Manufacturer-Grantable APIs require device manufacturer approval. A DevCert is valid for 6 months for testing on target devices.
6.2.2.3 Symbian Signed Submission
Once an application has been developed and tested in-house by the developer, they have to sign the finalized application with their ACS publisher ID. The resulting
76 Requires the IMEI of the testing device; IMEI is a globally unique identification for a particular mobile device (like a MAC address for desktops)
99 signed file is known as a SIS file, which is then submitted for Symbian Signed testing.
The submission requires the following steps –
1) Testing Lab Selection: One of three testing houses can be selected online on
the Symbian Signed website. The signed SIS file with the application usage
guide is submitted to an application submission portal of the test house. The test
house provides a quote for Symbian Signed testing.
2) Accept Testing Lab Payment or Shop: The developer can reject the testing
quote of a test house and select another test house. Once a quote has been
accepted and the payment made to the test house, the test house tests the
application against the Symbian Signed test criteria. The payment is non-
refundable even if the application fails the tests.
3) CA Signing: Once the application has successfully passed all of the tests
conducted by the testing agency, the testing agency uploads the application to
the CA. CA removes the ACS Publisher ID, stores details of the application in
their revocation database77 and then re-signs the application with the Symbian
root certificate78, and send the signed application back to the testing agency.
4) Download Symbian Signed Application: The developer can then download the
Symbian Signed application by the CA from the Symbian website.
For other certification options, the theme of signing is essentially the same except that the testing and signing is executed in-house (for self-certification), publisher
77 A Revocation database is maintained by the CA which allows them to trace the applications to the publisher and if necessary revoke application installations on mobile devices. For details see the appendix on digital signatures and public key infrastructure. 78 Symbian root certificates preinstalled in all shipped devices supporting Symbian-OS. This provides a way to control installation and capability access to Symbian Signed vs. unsigned applications.
100 (for publisher certification), or device-manufacturer/mobile operator (for channel certification). It should be noted that the Symbian Signed website is a critical resource for the entire certification submission and testing process.
6.2.2.4 Symbian Signed Waivers
All application must pass the entire Symbian Signed testing criteria for Symbian
Signing and certification. However, Symbian provides waivers for applications, if it fails a few but passes the majority of the tests. If a submitted application fails a few Symbian
Signed tests, the developer has an option of waiving the failure by demonstrating and providing proof that the application failure does not significantly impact the network and has authorized support from the relevant device manufacturer and/or the mobile operator. A waiver may only be granted by the device-manufacturers or mobile operator, against test failures on a case-by-case basis. Symbian acts as a facilitator in the process and does not make decisions on granting or rejecting a waiver. The developer requesting a waiver has to directly interface with the device manufacturer and/or mobile operator and their decision is considered final79.
6.2.3 The Symbian Signed Testing Criteria
The Symbian Signed testing criteria forms the base foundation of the Symbian
Signed program. All applications, irrespective of the chosen certification option, have to pass the entire test criteria for Symbian Signing (barring waivers). The Symbian Signed
79 From the Symbian Signed Test Criteria, version 2.11, Published November 2006 on http://www.symbiansigned.com/
101 criterion is publicly available from the Symbian Signed website and can be accede by registered developers.
As mentioned above, the Symbian Signed test criteria are aimed by Symbian to provide a Symbian partner agreed baseline for application quality, security and stability for Symbian-OS supporting mobile operators and device manufacturers. According to
Symbian, the Symbian Signed test criteria provides mobile operators a degree of assurance that the application does not harm the operation of the network to which it connects; and device manufacturers are assured that the device operates ―normally, specifically as a phone, messaging and alerting platform; before, during and after an application is installed or removed‖80. Further, the end-users are guaranteed data privacy, protection against private data loss, and that they will be notified of usage charges/communications incurred during the operation of the Symbian Signed application.
The test criteria incorporates simple black-box testing, wherein tests can be executed and verified on a standard device by providing inputs and checking outputs, in addition to some manual tests that analyze conformance to application naming and API declaration conventions. According to Symbian, the Symbian Signed test criteria do NOT cover content quality and censorship issues; language localization81; standards conformance and style guides; and business and/or commercial issues82.
80 From the Symbian Signed Test Criteria, version 2.11, Published November 2006 on http://www.symbiansigned.com/ 81 Language Localization is the process by which an application displays its content in different application supported languages such as English, French, and Spanish 82 Business issues refer to the revenue models supported by the application for its installation and usage
102 The test criteria are mapped on to the capability framework of the platform security architecture of Symbian-OS. The test cases are divided into two sets, a Generic
Set and an Extended Set –
1) Generic Set: The generic set cover the tests required for all Symbian-OS
applications that require access to to the so-called ―Basic Set‖ capabilities, which
include tests for User-Grantable APIs and the Location APIs. The generic test
cases broadly cover – 1) packaging and installation such as use of the ACS
Publisher ID, Application UID, and other manual install/uninstall/reinstall tests
that ensure that the application is installed in appropriate locations on the device;
2) manual usage tests that ensure that the application does not crash under user
stress83; 3) low memory application startup and usage; 4) device functionality
such as application handling of incoming calls and SMS; and 5) providing
appropriate end-user notifications and end-user permission requests for initiating
billable events.
2) Extended Set: The extended set test cases apply only to Symbian-OS v9+.
These test cases include the tests required to obtain access to the so-called
―Extended Set‖ capabilities, which include tests for Symbian-Signed-Grantable
APIs and Device-Manufacturer-Grantable APIs. During submission applications
requiring access to Extended Set capabilities have to provide individual API
declaration and rationale for its use. Some Symbian-Signed-Grantable APIs
require device manufacturer approval, which is acquired by the developer from
the device manufacturer before submitting the application for Symbian signing. In
addition to Symbian-Signed-Grantable APIs that require device manufacturer
83 ―Stress‖ entails using the application with other phone functionalities and applications simultaneously.
103 approval, Symbian Signed document also outlines tests for Device-
Manufacturer-Grantable APIs84, which are extremely sensitive APIs that if
required by the application, are signed only by the device manufacturers
themselves (channel certification), as opposed to any other available options
(third party, self, publisher, or freeware). Additional commercial agreements and
quality assurances have to be signed with specific device manufacturers85.
6.3 The Symbian Signed Certification System
The Symbian Signed program provides a certification framework for testing and certifying Symbian applications and in that sense is an application certification system. In this section, I present my observations and findings of the Symbian Signed program along conceptual constructs outlined in the previous chapters. I first discuss the Symbian
Signed program‘s authority structure, and then present some of the imposed constraints and perceived benefits of the program.
6.3.1 Authority Structure
Authority structure essentially describes the design and management of a certification program by a certifier. In that case of platform certification, the platform promulgator assumes the role of a certifier as it attempts to establish control and gain support and acceptance for its certification program in the market. For the Symbian
84 Device-Manufacturer-Grantable APIs are TCB and DRM 85 From the Symbian Signed Test Criteria, version 2.11, Published November 2006 on http://www.symbiansigned.com/
104 Signed program, Symbian as a platform promulgator has played an active role in establishing its authority in the Symbian applications market.
Firstly, Symbian has continuously attracted support from various Symbian-OS stakeholders in the industry. As Symbian is an alliance of major device manufacturers, the Symbian Signed initiative had the support of the majority of device manufacturers from the beginning. Other Symbian-OS licensing device manufacturers later also endorsed the program. Further, due to the claimed security and quality benefits of the program, most mobile operators have accepted and some have even mandated the
Symbian Signed program for application distribution86. Furthermore, Symbian also aggressively partnered with major application publishers worldwide to gain their support for distributing Symbian signed applications. With Symbian‘s aggressive involvement in attracting support for the program, Symbian Signed has become a de-facto certification instrument for Symbian applications.
Secondly, realizing the importance of its developer community, Symbian has actively taken input from and addressed the concerns of Symbian developers. According to developers, Symbian Signed staff has been helpful and open to their suggestions in improving the Symbian Signed program. Some of the developers also noted that their suggestions were quickly acknowledged and implemented by the Symbian Signed office.
Further, Symbian provides different certification options. According to a Symbian representative, the certification options were designed to cater for diverse developers in terms of their size and target market niche. These different options allow the developers to comply with the Symbian Signed criteria, while choosing a certification option that best
86 See Blandford, R. (2006), Operators locking handsets to Symbian Signed, August 15th, available from http://www.allaboutsymbian.com/news/item/4187_Operators_locking_handsets_Sym.php, Accessed June 2007
105 suits their needs. For instance, smaller developers, who might not have sufficient testing resources, can use the option of third-party or publisher certification. On the other hand, larger developers, who might already have an established in-house testing unit, can choose the self-certification option, allowing them to avoid testing replication. The program also provides options for developers who target different application niches.
Channel certification, for instance, provides mobile operators and device manufacturers the freedom to vertically integrate and develop applications in-house. Freeware certification, on the other hand, allows enterprise and independent application developers to provide applications that are freely distributed, but provide in-direct support for their related businesses.
Finally, Symbian has centrally managed the Symbian Signed program. Although
Symbian has relegated the certification authority to third-party testing labs, publishers, network operators and device manufacturers, it has been proactive in facilitating the certification process. First, Symbian has solely designed and expanded the Symbian
Signed‘s foundational testing criteria. According to the interviewees, Symbian takes into account the requirements of different actors in the Symbian ecosystem, but the final updates and approval is at Symbian‘s discretion. Second, Symbian also provides information and tools for application development, testing, and certification through the centralized Symbian Signed portal. Any application certification and deployment concerns and issues are directly handled by the Symbian Signed management.
6.3.2 Constraints
In order to certify applications the Symbian Signed program imposes certain constraints on the application developers. In the case of Symbian Signed program, the
106 certification constrains primarily constitute the requirements for testing, signing, and distributing a Symbian application. From a Symbian developers‘ perspective, the constraints can be grouped under two broad categories – direct financial costs of certification and indirect administrative costs.
6.3.2.1 Symbian Signing Costs
A certification system has associated costs that have to be borne by its stakeholders, broadly the certifiers and/or the certifiees. In the case of Symbian Signed, most of the costs are assumed by the certifiees – the Symbian application developers.
Financial costs associated with the Symbian Signed program is one of the most direct form of constraints that are borne by the Symbian developers. The developers have to pay for their authentication, application testing, and signing. All the key experts and informants I interviewed reported on some of the necessary financial requirements of the program.
Firstly, Symbian mandates the requirement for identifying the source of an application for Symbian Signing. This necessitates the requirement of using and often acquiring a unique ACS publisher ID for the developer. This unique ACS publisher ID is provided by the CA at an annual fee. This fee was initially $350 per year and since June,
2007 stands at $200 per year. Typically, this fee cannot be avoided by an application developer, unless they partner with an approved publisher and distribute their applications through them (publisher certification). Supplying applications using the publisher certification option is often not lucrative as one of the interviewed developer points out –
107 ―…the publisher takes a share of my revenue and makes me sign an agreement limiting my distribution options through them only…so if you think that you can avoid the [ACS publisher ID] cost, it will eventually come to you in another form…not a big deal, but I wasn‘t used to it in the desktop [software] world‖
Secondly, the developers reported that they have to pay for Symbian Signed testing of all applications they develop. The most common certification option used by developers the third-party testing by one of the three authorized testing labs (ATLs). As of June, 2007 the fee for Symbian Signed testing in these three ATLs, ranged from $270
- $800 per application.
The ATLs interviewed reported that the testing fee is determined both competitively and based on the availability of testing resources such as the target device and test engineers. In addition, the ATLs also provide bulk application testing discounts and fast-track options, the price of which is negotiated on a case-by-case basis. A
Symbian representative, talking about Symbian Signed costs for application developers in general said –
―… we have constantly tried to keep the costs down…an ACS publisher ID is almost half the price now… and the competition between test houses has lowered the testing costs to more than 75% since [Symbian Signed‘s] launch…we have also introduced a freeware signing option at no cost to the developer…‖
However, many developers stated that despite competitive pricing and discounts the testing costs can easily become burdensome. Every version of an application is treated as a new application for testing. As applications typically go through various updates and revision versions during their lifecycle, testing costs can sky-rocket. As one developer noted –
―…while the idea of allowing competition [between third-party testing labs] to drive down prices has worked, it's still very high when you consider the number of version/builds a programmer can go through for localization, bug fixes and improvements…‖
108 Although a developer can reduce such costs by becoming a self-certifier and certifying their application versions as needed, the fee to become a self-certifier is often prohibitive for most developers ($10,000 per year). As another certification option the developer can liaise with a publisher. However, according to the developers, the cost reduction isn‘t much. Either the publisher certifier charges third-party comparable testing fee per application version or negotiates with the developer to take up to 50% of the revenues generated by the application‘s sale.
6.3.2.2 Administrative Costs
In addition to the financial costs associated with Symbian Signing, the certification system imposes certain indirect constraints on the application developers.
These indirect constrains are mostly administrative in nature and impact the bottom line of application developers.
Firstly, the process of acquiring an ACS publisher ID is not always smooth. A developer‘s authenticity as a known economic entity is verified by a CA before issuing an
ACS publisher Id. Although this verification is an annual event, smaller developers reported that they faced some level of difficulty in registering with the CA. One developer reported about 4-5 weeks lag in acquiring the ACS publisher ID.
―[Obtaining ACS publisher Id] was the first major problem for me…their process for confirming that I worked for my company requires them to obtain through trusted third parties a phone number of the company, so they can call me to confirm I am who I said I was…now that was a problem as my business phone number is not listed in any of the telecom company directories….I don‘t need some directory listing pointing every telemarketer in the world to me…‖
Secondly, the Symbian signed program is centralized around its website portal that manages developer registration, DevCert issuance, testing submission, as well as,
109 distribution of testing tools and documents. This centralized nature of the portal has also created some administrative issues for the Symbian developers. For instance in July
2007, the Symbian Signed portal was down for about a week. During that time a developer I interviewed stated –
―….our application is part of a larger software package [of a client] …what am I supposed to tell my clients? I can‘t test my applications because I couldn‘t foresee the Symbian site going down?…[my client] has their own deadlines for their package release…it‘s a chain reaction and I look bad in the bargain…‖
Further, at times the testing tools provided by Symbian were also reported as inadequate and even inappropriate for pre-submission applications testing as the CTO of a developer noted –
―…some tools are very strange…the strangest of all is the tool that tests for startup memory… [it] creates an artificial low memory environment for your [application] to run under… but this is not the same environment as some [Nokia] series 60 device provide…in then end the test tool is worthless as you might fail [third-party testing] even though you tested for memory…‖
Finally and probably the most important form of administrative costs are approval requirements for accessing certain sensitive APIs. Developers reported that they were expected to develop and maintain contacts and relations with different device manufacturers and mobile operators for approving access to sensitive APIs. The
Symbian Signed testing document states that ATLs can assist in these approvals –
―[t]he Test House will then liaise with the appropriate Phone Manufacturer to review the submission and seek approval for the grant. You may also contact the Phone Manufacturer before submission and include evidence of their approval…if you have such contacts already‖ (Italics added)
However, the situation is somewhat more complex than it appears. A developer who develops applications requiring access to several sensitive APIs reported that –
―…for Sony-Ericsson and Nokia phones, the process to get approval is somewhat standardized and documented on their websites…for other
110 phones [manufacturers], I had to be able to know someone through someone to get approvals and grants worked out…‖
Further, another developer of Symbian applications for Nokia devices reported that although Nokia has a standard streamlined procedure for providing approvals, Nokia expects their applications to pass another set of test criteria.
―…this is fine by me, but if you see the Nokia test criteria for getting those grants, you will find test criteria covering ―Style Guide‖ and ―Nokia Values‖, which I‘m disappointed to say have nothing to do with ―sensitivity‖ of the APIs I‘m requesting access to…‖
Furthermore, although Symbian states that 60% of the Symbian-OS APIs can be used without requiring signatures or approvals, all developers reported that unsigned applications are hard, if not impossible, to sell. One concerned developer concisely conveys this –
―…I don‘t get the concept of an unsigned application…first of all no channel accepts unsigned applications, be it a publisher, an operator, a distributor or the phone manufacturers…second even if the a consumer somehow side-loads my unsigned app from a website, he is going to go crazy with hundreds of pop-ups (security warnings) while using my [application] …to the consumer it means my app is shitty…so boom I‘m out of the market…‖
Indeed the Head of Developer Marketing & Services at Symbian in a report stated –
―As an unsigned application has no proof of origin the user will continue to see the familiar ‗health warning‘ (security warning) to advise that the application is from an unknown source. So, even if your application does not need to access any sensitive API, you do need to consider how Symbian Signed may be beneficial for your route-to-market. Symbian Signed is increasingly being endorsed and used as the industry-wide agreed standard on what is required from an application to be distributed to mass-market devices. Already an increasing numbers of channels are
111 expecting applications to be Symbian Signed before they distribute them, in order to help boost user confidence.‖87
Another developer who had been actively developed Symbian applications for almost a decade suggested that unsigned applications will eventually be phased out by various distribution channels –
―...Software portals such as Nokia Software Market, Handango and the like are starting to get more insistent about applications being properly tested and signed…which means that in a year or so's time, software which hasn't been Symbian Signed will go absent from major download sites‖
In summary, these administrative costs of obtaining ACS publisher ID, testing tools and resources, and gaining approval to access sensitive APIs add significant issues for time-to-market Symbian applications.
6.3.3 Benefits
Although the Symbian Signed program introduces several financial and time-to- market costs for Symbian developers, it provides several compensating benefits to
Symbian developers. These benefits as perceived by the Symbian developers include enhanced application security, quality, and marketing/distribution benefits of Symbian
Signing.
87 Evolving to Symbian OS v9, By Bruce Carney, Head of Developer Marketing & Services, Symbian, Oct 2nd 2006, Accessed from http://developer.symbian.com/wiki/display/papers/Evolving+to+Symbian+OS+v9 on June 2007
112 6.3.3.1 Applications Security and Quality
One of the highly advertized benefits of the Symbian Signed program by
Symbian has been the assurance and guarantee of security and quality of Symbian
Signed applications. A quick scan of the Symbian Signed press releases by Symbian and the publicly available Symbian Signed documentation reveals the emphasis on application security and quality. A Symbian representative interviewed also attested to this observation stating that –
―…our partners and end-users have always had a strong need for secure and quality applications…what Symbian Signed provides is an industry- agreed unified approach to testing for quality…and application source verification for security‖
All developers interviewed agreed and regarded Symbian Signed as a significant milestone in increasing application quality and security of Symbian applications. Some also referred to Symbian Signed program as a ―collaborative achievement‖, wherein network operator, device manufacturer, and developer concerns have been addressed by the program. Further, they suggested that Symbian Signed, by establishing a unified industry-wide testing criterion for Symbian applications, had to some extent reduced hassles and costs of repeatedly testing applications on different operator and device manufacturer test criterion. A developer referring to pre-Symbian Signed time stated -
―…at least, what can be called, ―testing fragmentation‖, has been reduced to some extent…the expectations of operators and handset manufacturers are clearer today than they were…‖
Although the developers agree on the application security and quality is beneficial for the Symbian ecosystem as a whole, most interviewed reported that the direct benefit of Symbian Signing, especially on quality, is basic and limited. A concerned developer stated that –
113 ―…the tests are too generic…most of the usability and quality testing is actually done either by the phone [manufacturer] tests or by developers own concerns of functionality and usability…security is probably the only practical benefit…but again security is not exactly in the sense of ―application security‖ but ―application source identification‖…‖
6.3.3.2 Marketing and Distribution
Another benefit according to Symbian Signed is the marketing and distribution opportunities that are provided by Symbian and its partnering publishers, device manufacturers and network operators. Symbian and its partners provide exclusive distribution listing of Symbian Signed applications through application catalogs and download portals. These application catalogs are given increased visibility and marketing support for end-user consumption. Further, Symbian also provides a marketing logo to all Symbian Signed applications (‗for Symbian OS‘ shown in
Figure 6:2). The logo is proprietary and can only be used by Symbian Signed applications.
Figure 6:2: Symbian Signed Application Marketing Logo
However, most developers expressed their reservations on the claimed advantages of catalog listing and logos. As one developer said –
―…most distributors and carriers mandate Symbian signing…from my perspective any ―benefit‖ from that point on, is essentially useless‖
When asked about the use of logos, the developer said –
―…do you think my customers are aware of any logo? I don‘t think so…so what‘s the benefit there?‖
114 6.4 Market Effects of Symbian Signed: A Discussion
The Symbian Signed program has certainly organized the market for Symbian applications in multiple ways. As a certification system at the application level, Symbian
Signed has had profound effects on how application developers develop, test, deploy, and distribute their applications. From the viewpoint of the key experts, the Symbian
Signed program has facilitated and streamlined the development of diverse Symbian
Applications. However, from the viewpoint of interviewed informants, it seems that such benefits are limited and the program has largely contributed to unnecessary development and distribution barriers. In this section, taking a unified key expert and informant viewpoint, I first discuss the role of Symbian Signed program in developing, testing and eventual deployment of Symbian applications on the Symbian-OS implementing devices. Then I outline some of the implications of the program for
Symbian application developers and publishers.
6.4.1 Deployment Compatibility
The Symbian Signed program has influenced the compatibility between Symbian applications and the Symbian-OS platform (also referred to as vertical or deployment compatibility of Symbian applications) in a nuanced way.
The developers reported that prior to the introduction of the Symbian Signed program; Symbian applications were easily deployable and compatible with all Symbian devices. This had a lot to do with the backward compatibility that was maintained in most
Symbian-OS versions. Applications designed for one Symbian-OS versions could be deployed on devices implementing prior versions.
115 However, the introduction of Symbian Signed program necessitated a supporting framework to distinguish between signed and unsigned Symbian applications on mobile devices. This framework was introduced as the platform security architecture in
Symbian-OS version 9. The introduction of Symbian-OS version 9 broke the backward compatibility of Symbian applications. An application designed for Symbian-OS version 9 and forward is not compatible and therefore cannot be deployed on devices implementing pre-Symbian-OS-v9 platform. Further, applications designed and signed for Symbian-OS versions prior to version 9 were either incompatible version 9 implementing devices or were treated as unsigned and hence uncertified. This resulted in many developers adapting (also referred to as ―porting‖) their older signed applications for Symbian-OS version 9 and then re-signing their applications to maintain access to the required Symbian APIs. The developers incurred the costs for such porting and resigning pre-existing applications to maintain deployment compatibility with
Symbian devices.
Another issue raised by the developers on compatibility was the varying User-
Interface and Symbian-Signed-Root-Certificate implementation on different Symbian
Devices. Firstly, Symbian-OS does not provide a User Interface (UI) for its licensees.
This means that device manufacturers wishing to implement Symbian OS must either develop or license a UI implementation on their own. Symbian-OS supports three UIs –
Nokia‘ S60, Sony-Ericsson‘s UIQ, and NTT DoCoMo‘s FOMA. As applications typically rely on UI APIs in addition to Symbian-OS APIs, applications developed for UIQ, for instance, often do not execute on S60 implementing devices. Although testing for such variations was addressed in the Symbian Signed criteria, developers reported that some degree of Symbian application porting was still required across the UIs.
116 Further, the UIs typically implemented their own Symbian-Signed-Root-
Certificate, which is required to verify the deployment of a certified application on
Symbian devices. The result is that Symbian applications have to be tested and signed separately for Symbian devices implementing different UIs. This ensures a signed application‘s deployment compatibility on Symbian devices implementing different UIs, but introduces additional Symbian testing and signing costs for the developer (as the application is tested multiple times for different UI implementing devices).
In summary, the Symbian Signed program‘s unified testing initiative has had little impact on the deployment compatibility of Symbian applications. On the contrary, the introduction of the security architecture necessitated by the Symbian Signed program, has exacerbated deployment compatibility of Symbian applications, if at all.
6.4.2 Implications for Application Developers
The effects of Symbian Signed program on the Symbian applications developers have been mixed. Firstly, the market entry conditions for the Symbian application developers have changed since the launch of the program. Although the deployment and distribution of applications has become more streamlined, the interviewed developers noted that it has become more challenging for new developers to establish themselves in the Symbian applications market. Secondly, the applications market has become more consolidated. It seems that this consolidation, at least to an extent, has been facilitated by the way Symbian Signed program has been designed. I discuss both market entry and consolidation in the following sub-sections.
117 6.4.2.1 Market Entry Barriers
As discussed above, the Symbian Signed program has introduced certain additional costs for the Symbian application developers. It seems that these costs can act as entry barriers for new Symbian developers. The interviewed developers suggested a few reasons for the same.
Firstly, industry-wide support, endorsements, and mandates have made it essential for all developers to Symbian Sign their applications. Developers noted that unsigned applications have become harder, if not impossible, to sell. Most developers had not even heard of another firm that developed and distributed unsigned applications.
Further, it has become harder to freely install applications on Symbian devices with the introduction of the Symbian security architecture. Even testing applications requires
DevCerts that are distributed through the program. Essentially Symbian developers have been coerced to play by the Symbian Signed rules to be able to develop, test, deploy, and sell Symbian applications. Hence, avoiding the Symbian Signed costs today is hardly an option for market entering developers. Further, it should be noted that although the Symbian Signed program provides different certification options (third party, self, publisher, channel, and freeware), these option only assist existing developers and not a market entrant. A market entrant can only opt for the third-party or publisher certification, which typically cost the same.
Secondly, the program introduces certain investments for a market entrant that would not have been required otherwise. The Symbian Signed testing fee is one example. As discussed above, the Symbian Signed testing fee is charged for testing every application version, which in turn discourages regular application upgrades.
However, application upgrades is part of a ―trial and error‖ approach to develop quality
118 applications. This is a typical norm in application development, especially for new developers. A new developer might therefore incur a high up-front cost of signing multiple versions of an application. An established developer, highlighting this challenge for new developers said –
―…surely a new developer unaware of per version signing will get hit hard by re-testing fees, while those who understand [that every new version has to be signed], will hold back for a major revision…[with sarcasm] talk about encouraging improvements and quality…‖
Further, the administrative costs of the Symbian Signed program are also especially challenging for market entrants. For a new developer, getting an ACS
Publisher ID and device manufacturer approvals can be challenging and can take weeks. Furthermore, the signing process has an associated learning curve. All developer noted that the process would be ―confusing‖ to a new developer if they are not aware of digital signing principles. This in some cases can be discouraging for the developer in designing applications for Symbian-OS.
6.4.2.2 Market Consolidation
Another effect of the Symbian Signed program has been to indirectly encourage consolidation in the Symbian applications market. Although emerging markets typically consolidate as part of their growth pattern, the Symbian Signed program has played a role in speeding up the consolidation in the Symbian application markets.
As discussed above, the Symbian Signed program provides different options for different types of application developers. However, the self and publisher certification options are geared towards select high-volume larger application developers and publishers, which creates a competitive advantage for larger developers and publishers
119 over low-volume smaller developers. Firstly, the self-certification is a much cheaper option than using the third-party for certification. The developers that have been granted the self-certification privilege by Symbian can save a lot on certification fees. This positions the self-certifying developers to out-compete many smaller developers that are not granted this option. Secondly, the publisher certification option incentivizes publishers to develop applications in-house. From a testing and certification cost perspective, this tips the competitive balance of application development in favor of a few authorized publisher certifiers. The self and publisher certifiers are able to rapidly test and sign new and improved versions of their applications as and when they are developed, whereas other developers using third party certification are constrained by the per application version certification costs and processing times.
In that sense, Symbian Signed program has in part tipped the competitive landscape of the applications market in favor of a few Symbian-authorized self-certifiers and publisher-certifiers. The net effect is greater competitive advantage for a few larger application developers and publishers who can leverage the cost benefits of self and publisher certification, thereby encouraging market consolidation.
Chapter 7
The Java Verified Program
In this chapter I examine the case of Java Verified certification program for the
Java ME computing platform. The chapter is organized to first provide a brief overview of the Java ME platform to highlight its core technological underpinnings that facilitate Java
ME application development, testing, and deployment on Java enabled mobile devices.
Specifically I discuss Java ME‘s modular architecture and evolution to provide a contextual grounding of Java mobile application development and the role of Java
Verified certification program in the Java ME ecosystem. Next I discuss the Java Verified program in detail. In particular, I provide some of the rationales and value propositions of the Java Verified program for various Java ME stakeholders. Further, I outline the certification process and application testing criteria. Following that, I discuss the authority structure of the Java Verified program and present some of the constraints and benefits as perceived by the Java ME application developers. Finally, I analyze and discuss some of the implications of the Java Verified program for the application developers and other firms in the Java mobile application ecosystem.
The data for the case was primarily gathered from interviews with representatives of the Java Verified Program Office (JVPO), authorized certification testing labs, official program supporters, as well as the Java ME application developers. A total of 26 interviews were conducted out of which 17 were Java ME application developers. The case also draws information from various publicly available Java Verified documentation, developer forums of Java ME licensees (device manufactures), network operators
121 endorsing the Java Verified program, and various trade-press articles whenever necessary.
7.1 Java ME
Java ME (Java Micro Edition) is one of the most widely deployed mobile operating-system-independent middleware platforms and provides modular application access to various mobile device features and capabilities. As a middleware computing platform, Java ME is specifically designed for small resource-constrained mobile devices with different operating systems. It is especially suitable for cheaper, mass-market phones with limited processing powers. As a computing platform for smaller mobile devices, architecturally Java ME is considered a subset of the server and desktop versions of Java platforms – Java Enterprise Edition (Java EE) and Java Standard
Edition (Java SE) – with additional specifications to access specific capabilities of mobile devices.
Java ME is a modular platform that has continuously expanded and evolved to provide access to increasing number of device features and capabilities. Java ME comprises of multiple modular components, which can be selectively implemented by device manufacturers depending on the features and capabilities of the device models.
These modules are designed through a community-driven process known as the Java
Community Process (JCP). Established by Sun Microsystems in 1998, JCP is a formalized process that allows various industry members to define specifications and
APIs of the Java platform. The JCP involves the use of Java Specification Requests
(JSRs) that are formal documents describing proposed API specifications and changes to the evolving Java platform. Formal public reviews of a JSR are conducted, wherein
122 selected JCP members (also known as JCP Executive Committee) vote to finalize the
JSR. A finalized JSR becomes a modular component of the Java platform for implementation. The finalized JSR provides a reference implementation for appropriate implementation by its licensees and a Technology Compatibility Kit to verify correct specification implementation88. As Java ME uses the community-driven JCP approach, it is often considered a non-proprietary platform that is freely licensed under the GNU
General Public License agreement by device manufacturers.
As a platform, Java ME provides a rich set of API JSRs for access to mobile device features and cellular network functions. Examples of such features include Mobile
Media APIs (JSR 135), Mobile 3D Graphics APIs (JSR 184), Mobile Telephony APIs
(JSR 253), Wireless Messaging APIs (JSR 120), Mobile Broadcast APIs (JSR 272),
Bluetooth APIs (JSR 82), and Location APIs (JSR 179)89. In addition to providing access to mobile device features and network functionality through APIs, Java ME also provides a framework for Java ME application installation (Application Installation API, JSR 38), and Over-The-Air (OTA), or wireless, Java ME application download and installation
(Mobile Information Device Profile 2.0, JSR 118). Java ME application developers can hence leverage the underlying device and network capabilities to design and wirelessly deploy Java ME applications on Java compliant devices.
88 Details of the Java Community process can be found on the JCP website - http://jcp.org/en/procedures/jcp2, Accessed July, 2007 89 For a comprehensive list of Java ME JSRs and API packages can be found on http://jcp.org/en/jsr/all, Accessed July 2007
123 7.1.1 Java ME Architecture for Application Development and Deployment
Architecturally, Java ME is a modular platform consisting of certain core components and optional API modules. For mobile phones, the core components include the CLDC and MIDP components. The CLDC (Connected, Limited Device
Configuration) defines the way the platform interacts with the underlying mobile device hardware. Eighteen firms, mostly wireless device manufacturers, participated in the definition of CLDC using the JCP. CLDC 1.0 was finalized as JSR 30 in early 2000 and an updated CLDC 1.1 was later finalized as JSR 139 in early 2003. In addition to CLDC,
MIDP (Mobile Information Device Profile) provides the basic framework, User Interface, data storage, and networking APIs for developing Java ME applications (which are often referred to as MIDlets). MIDP 1.0 was finalized for implementation as JSR 37 in late
2000 and later updated to MIDP 2.0 as JSR 118 in late 2002 by JCP members representing about fifty different device manufacturers, operating system vendors, and network operators. Together, the CLDC and MIDP provide the basic implementation of the Java ME platform. In addition to these core modules device manufacturers can also implement optional API modules. Examples of such optional modules include Wireless
Messaging APIs (JSR 120), Bluetooth APIs (JSR 82), Mobile Media APIs (JSR 135), and Location APIs (JSR 179).
As device manufacturers implemented different versions of the core CLDC and
MIDP and optionally implemented additional JSR modules, Sun launched an umbrella specification called the Java Technology for the Wireless Industry (JTWI, JSR 18590) in
2003 to define the minimal implementation requirements of the Java ME platform for mobile phones. JTWI essentially specified the architecture of Java ME for mobile phones
90 For details of JSR 185 see http://jcp.org/en/jsr/detail?id=185, Accessed July 2007
124 and mandated certain modular component versions of Java ME that had to be implemented in all Java ME compliant mobile phones. A simplified overview of the JTWI defined Java ME architecture is shown in Figure 7:1.
s n o i t MIDlet Suites, OEM Applications s a p c A p i r l T A e p
O p e w / I
n s s A P l
S y
s t o A o
e a i 0 l r e M h M g M n a 2 M s B A n a A o P E M
1 i
s
o E k - i t e M 5 MIDP 2.0 t e a O e i c l p 3
O v R d v v i a i 1 i W t e n C - t O t S o v P a R J a i a C t S N N N J a N CLDC 1.0 (or 1.1)
Native Operating System
Wireless Device
Figure 7:1: JTWI defined Java ME architecture91
From a Java ME application development and deployment perspective, one of the more important aspects of the Java ME architecture is the MIDP. As mentioned above, the MIDP provides the basic UI, data storage, and networking APIs for developing Java ME applications (MIDlets). Additionally, it provides a framework for secure application installation or deployment over mobile devices. MIDP 2.0, a mandatory specification of Java ME, also specified a MIDlet security and signing framework, which allowed MIDlets authenticated access to certain ―Sensitive‖ APIs, in addition to enhanced specifications for application installation and Over-The-Air (OTA) application delivery.
91 Adapted from JTWI specification, 1.0, Final Release, June 26, 2003
125 The MIDP 2.0 application security model utilized digital signatures and the Public
Key Infrastructure (PKI92) to authenticate the source of MIDlets. Only the authenticated
MIDlets were allowed access to sensitive APIs. The security architecture manages the access to APIs by assigning MIDlets to so called ―Protection Domains‖. MIDP 2.0 specified four protection domains – 1) Manufacturer, which is reserved for MIDlets developed by the device manufacturer; 2) Operator, which is reserved for MIDlets developed by the mobile operator; 3) Trusted Third Party, which is reserved for MIDlets developed by authenticated third-party application developers; and 4) Untrusted, which is reserved for MIDlets developed by unverified third-party developers. The first three are authenticated and hence considered ―Trusted‖ protection domains. Further, protection domains are associated with ―Permissions‖ to access a group of APIs called ―Function
Groups‖. Function groups included network-cost related groups such as phone call, network access, and messaging, as well as user privacy related functions such as multimedia recording and location information93. The permission to API-function-group mapping is referred to as Java ME‘s security policy. Java ME does not mandate the selection of a particular security policy and it is left open for specification by Java ME implementing device manufacturers and/or network operators. Individual device manufacturers and network operators define which API-function-groups were ―Sensitive‖ and what ―Permissions‖ would be required to access them94.
In other words, under the Java ME security framework MIDlets (Java ME applications) are classified as ―Trusted‖ and ―Untrusted‖. Trusted MIDlets are source- authenticated applications associated with a trusted protection domain (Manufacturer,
92 For details about Public Key Infrastructure (PKI), see the Appendix 93 For details about Java ME function groups see Appendix 94 From MIDP 2.0 Specification, Final Release, November 2002, Available from http://jcp.org/aboutJava/communityprocess/final/jsr118/index.html, Accessed July 2007
126 Operator, and Trusted Third Party Domains). These trusted MIDlets are provided
―Permissions‖, through security policy, to access to API-function-groups that are considered ―Sensitive‖ by individual device manufacturers and network operators.
Untrusted MIDlets, which are not source-authenticated, are assigned the ―Untrusted‖ protection domain, which allow access to only a few basic APIs such as data storage, media access, and UI (without explicit user confirmation), and HTTP connection (with explicit user confirmation).
In summary, Java ME‘s MIDP 2.0 security architecture provides a framework for managing how Java ME applications (MIDlets) can be deployed over Java complaint phones. More importantly, Java ME platform can identify trusted applications through the use of digital certificates. This allows Java ME to control the deployment of complementary third-party applications on Java ME devices and forms the basis of its
Java Verified application certification program. The following sections describe the Java
Verified program, its key attributes as a certification system, and discuss its implications for the Java ME application developers and the Java ME ecosystem at large.
7.2 The Java Verified Certification Program
Selective and varying implementation of various Java ME components on different device models creates an inconsistent deployment environment for Java ME applications. Hence, Java ME applications might not install and execute consistently across Java enabled devices. Application testing on actual devices has therefore been a crucial aspect of the Java ME application development and distribution. Application distributors such as application publishers, portals, network operators had individually developed their Java application testing programs. This often required application testing
127 against multiple criteria, which increased the testing burden for the Java ME developer as well as application distributors. In order to consolidate the testing requirements for
Java ME applications, Sun in partnership with major device manufacturers and network operators created the Unified Testing Initiative (UTI) in 2003. As of July 2007, Sun
Microsystems along with device manufacturers including Nokia, Motorola, Sony
Ericsson, Samsung, and LG, and network operators Vodafone and Orange had joined the UTI.
The primary objective of UTI, according to UTI members interviewed, was to consolidate the Java ME application testing requirements and provide a centralized industry-accredited testing criterion, wherein multiple stakeholder concerns can be tested in a unified fashion. The UTI members developed a minimum-application-quality criterion for Java ME applications called the Unified Testing Criteria (UTC). Based on the
UTC, the UTI members then launched an application testing and certification program called the Java Verified certification program in early 2004.
The Java Verified program essentially instituted the testing process for Java ME applications (MIDlets), wherein applications passing the UTC were digitally signed against the UTI root certificate. A signed application was assigned to a trusted protection domain in MIDP 2.0, which then allowed access to certain sensitive APIs. All UTI device manufacturer members implemented the UTI root certificate on their devices to allow this protection domain access. According to Sun, this constituted about 65% of the Java ME device market95. In mid 2007, attempting to expand the Java Verified program utility
95 From Sun Press Release, June 24, 2004, ―Orange, T-Mobile Europe adopt Java Verified Program‖, http://www.sun.com/smi/Press/sunflash/2004-06/sunflash.20040624.1.xml, Accessed July 2007
128 across the mobile device market, Sun allowed non-UTI members to implement the UTI root certificate on their devices96.
In the following sub-sections, I provide a detailed overview of the Java Verified certification processes and the UTC.
7.2.1 The Java Verified Process
The Java Verified program defines a process by which the applications can be submitted for testing and signing. The Java Verified process for the application developer is publicly available on the Java Verified website maintained by Sun
(http://www.javaverified.com/).
The process essentially involves four stakeholders – 1) an Application Developer;
2) the Java Verified Program Office (JVPO), which manages developer registration and application submission and delivery to various application distribution catalogs; 3) an
Authorized Testing Lab (ATL), which is third-party testing lab authorized by the JVPO to perform Unified Test Criteria (UTC) testing; and 4) the Certification Authority (CA), which verifies the identity of the developer and provides a digital certificate corresponding to the UTI root certificate to the developer to sign the applications developed by the application developer.
A developer is required to register with Java Verified program on the website.
Registered developers can login and submit their applications on the web portal97.
Through this web portal a submitted application goes through a series of steps, which
96 From Sun Press Release, May 10, 2007, ―Sun Announces Broad Release of UTI Digital Certificate Through Java Verified Program to Help Drive Worldwide Mobile Application Security‖, http://www.sun.com/aboutsun/pr/2007-05/sunflash.20070510.2.xml, Accessed July 2007 97 Java Verified Developer Portal - http://javaverified.com/jvp20dp14/faces/Login.jsp, Accessed July 2007
129 include application upload, ―pretesting‖98, testing, and digital signing. The steps are presented in Figure 7:2.
Reports Application Developer
Signed Application
Submission/ Pass Pass Pass Pretesting Testing Signing Uploading
Fail Fail Fail
Figure 7:2: Overview of the Java Verified testing process99
As a prerequisite of the Java Verified process, a developer has to obtain a PKI100 digital certificate from GeoTrust, a Certification Authority (CA) that verifies developer identity and distributes PKI digital certificates corresponding to the UTI root certificate101 implemented on Java compliant devices of the UTI members. This pre-requisite is required in order to ensure the authenticity and integrity of a developer's application.
According to the Java Verified website, an application has to be digitally signed by a certificate obtained from the CA prior to submission. As part of the Java Verified process, Application ‗pretesting‘ is performed immediately after the digitally signed
98 Pretesting in the context of the application certification refers to testing that is conducted in- house by the developer of an application before submitting it for certification testing. Pretesting generally assures the application developer that the application will pass the certification testing criteria. 99 Adapted from http://www.javaverified.com/, Accessed Jun 2007 100 For details on how digital signatures and Public Key Infrastructure works see Appendix. 101 For details on how digital signatures and root certificates work in a Public Key Infrastructure see Appendix.
130 application is submitted by the developer. According to the Java Verified website, application pretesting is an automatic tool that can ―determine the correctness of certain packaging attributes…and produce[s] a testing report‖ that the application is ready for certification testing102.
Once an application passes application pretesting, the developer takes the following steps –
1) ATL Selection: The developer chooses from a list of testing providers to test
their application against the UTC. As of July 2007, a developer can choose from
four different ATLs, which charge a testing fee for UTC testing. According to the
ATLs, the UTC testing prices ranged upward of $225 for testing an application on
one device model. Further, a developer can directly interface with the ATLs and
can potentially negotiate the testing fee. According to the interviewed ATLs, a
developer submitting multiple applications on several device models can typically
expect to get ‗volume discounts‘.
2) UTC Testing: Once an ATL is chosen and testing fee negotiated, the chosen
ATL performs testing of the application against the UTC. The ATL provides the
developer and the JVPO with the testing results. A formalized report if is sent to
the developer. If an application failed against the UTC, the ATL provides details
of the issues and the steps to reproduce the failing instance. According to the
ATLs, the testing usually takes 3-5 business days, depending upon the load of
application submissions.
3) Application Signing: If an application passes UTC testing it is digitally signed by
a digital certificate corresponding to the UTI root certificate implemented on Java
102 From http://javaverified.com/jvProcess.jsp, Accessed July 2007
131 Verified supported devices. This signature verifies that the application has
passed the UTC testing and seals the application to avoid further modification.
Only the CA can sign the tested application.
4) Application Distribution: A Java Verified signed application is then eligible for
distribution through various UTI members and the Java Verified application
distribution catalogs. The developer can choose to list any, all or none of the
distribution catalogs. The JVPO portal provides the signed application for
download to their respective developers.
7.2.2 The Java Verified Unified Testing Criteria
The UTC forms the core foundation of the Java Verified program. All Java
Verified applications have to pass the tests and guidelines outlined by the UTC. The
UTC covered the MIDlet (MIDP 1.0 and 2.0) application testing for JTWI defined Java
ME platform including Wireless Messaging APIs (JSR 120), Mobile Media APIs (JSR
135), and Bluetooth APIs (JSR 82). The UTC document is publicly available from the
Java Verified website.
The UTC has gone through a few revisions and updates since it official public release in early 2004. As of July 2007, UTC 2.1 was used by the Java Verified program.
Table 7-1 provides a brief history of the UTC evolution. The following description of the
UTC refers primarily to the initial UTC (1.4) document and the subsequent updates in
UTC 2.0 and 2.1 are mentioned in the end of the section.
132
Table 7-1: UTC Evolution Unified Testing Criteria Version Validity Period UTC 1.0-1.4 Early 2004 – Mid 2005 UTC 2.0 Mid 2005 – Mid 2006 UTC 2.1 Mid 2006 – Mid 2007 UTC 2.2 Mid 2007 – Present
As mentioned above, the UTC provided a unified testing framework to avoid retesting of Java ME applications by wireless industry stakeholders. According to UTI members, ―various handset manufacturers, operators, and other parties have established various test programs of their own ―, and there were ―no common denominator‖ for testing, which ―restrict[ed] access to the largest possible audience‖ and increased the testing costs for application developers103. In order to provide a common denominator for Java ME application testing, the UTC incorporated basic test cases that covered testing needs of various device manufacturer and mobile operator testing requirements. In addition to reducing testing fragmentation, UTC assigned the passing applications a trusted third party protection domain specified by MIDP 2.0 security and signing framework. This protected end-user‘s data privacy, data loss, and a unified framework for notifying phone usage and data charges incurred during the operation of the Java Verified application.
UTC 1.4 specified about 50 manual test cases that can be performed manually by a test engineer verifying the appropriate behavior of an application under specified conditions. UTC covered testing application – 1) Launch, which tested the over-the-air
(OTA) application download, installation, and shutdown; 2) User Interface, which tested general usability guideless for application content readability and device button usage; 3)
103 From UTI Whitepaper, Feb 2004, http://www.javaverified.com/, Accessed, July 2007
133 Functionality, which tested basic application features; 4) Operation, which tested basic interaction with underlying device hardware and software; 5) Security, which tested secure network transmissions; 6) Networking, which tested application communication and failure handling; and 7) Localization, which tested for applications support of different languages.
It should be noted that the UTC did NOT cover – 1) Mobile Operators specific tests for network communication protocols (e.g. WAP and GPRS), and location based applications; and 2) Device manufacturer specific tests for the look and feel of the application UI and content censorship issues. These testing of these issues were ―left up to the responsible party‖104.
The updated UTC (2.0) specified some major updates in mid 2005. According a
UTI member, the UTC 2.0 document primarily targeted ―ease of executing the test cases‖ by providing step by step details for executing the UTC tests. In addition to test clarifications and details a few tests were added, which covered application stability and user data privacy tests. Further, developers were required to provide ―application characteristics‖ to the ATLs to speed up test execution. Application characteristics included a flow chart of application functionality and answers to a questionnaire requiring information about application behavior on types of connection used, data accessed, etc.
It should be noted, that an application is required to pass all UTC specified tests on a particular target device model to be granted the Java verified status for the device model. Applications targeting multiple device models require[d] repeated complete UTC testing for every device model. According the UTI members, this was primarily required
104 From UTI Whitepaper, Feb 2004, http://www.javaverified.com/, Accessed, July 2007
134 as ―experience has shown that there can be differences in [Java ME] implementation among different manufacturers‖.
In order to ease the multiple UTC testing of an application for different device models, UTI device manufacturer members provided a list of device models that were grouped into ―device families‖ with a ―lead device‖. A device manufacturer‘s ―device family‖ is assumed to have similar Java ME implementation. This ensured that UTC testing on a device family‘s lead device model would not require retesting for other device models in the device family. In other words, if an application passes the UTC testing on the lead device, it would be Java Verified by default for all the devices in the lead device‘s device family. The JVPO maintains this UTI member‘s device family list as
―Java Verified supported devices‖105.
7.3 The Java Verified Certification System
The Java Verified program provides a certification framework for testing and certifying Java ME applications and in that sense is an application certification system. In this section I present the observations and findings of the Java Verified certification program along conceptual constructs outlined in the conceptual framework. I first discuss the Java Verified program‘s authority structure, and then present some of the imposed constraints and perceived benefits of the program for the Java ME developers.
105 Available on http://javaverified.com/supp_devices.jsp, Accessed July 2007
135 7.3.1 Authority Structure
The Java Verified program was initiated by Sun as the Java ME platform promulgator. Sun, as the certifier, has played an active role in establishing an authority structure for the program so as to manage certification processes and criteria as well as establish widespread support and acceptance from various stakeholders in the Java applications market.
Firstly, Sun initiated the UTI partnership with major device manufacturers and network operators to establish critical Java ME stakeholder support since the inception of the program. According to Sun, the Java Verified has always been an industry- recognized application certification program as the UTI members who designed the program provided about two-thirds of Java compliant devices in the market.
Although this was a reasonable start for gaining support, eventual mandates by other device manufacturers have been limited. This was mostly because the Java
Verified program requires the UTI root certificate implemented on Java compliant devices (to differentiate between certified and uncertified applications), which up until mid 2007 was not available for non-UTI members for implementation106. Further, Java
Verified enjoys a limited support from mobile operators, which are a major distribution channel for deploying Java ME applications. As of July 2007, only a handful of mobile operators have mandated the Java Verified program (Vodafone, Orange, and T-Mobile
Europe). While most mobile operators accept Java Verified applications, they do not mandate all applications to be Java Verified. Furthermore, according to the interviewed
Java ME developers, some mobile operators often remove the UTI root certificate
106 From Sun Press Release, May 10, 2007, ―Sun Announces Broad Release of UTI Digital Certificate Through Java Verified Program to Help Drive Worldwide Mobile Application Security‖, http://www.sun.com/aboutsun/pr/2007-05/sunflash.20070510.2.xml, Accessed July 2007
136 embedded in the mobile devices for their networks, nullifying the benefit of Java
Verifying an application. In that sense, the Java Verified program is not mandated or supported by all application distribution channels. However, Java Verified is increasingly becoming a de-facto certification instrument for Java ME applications.
Secondly, Java is recognized for its vast developer community and their active participation in standardizing application development technologies. Although the UTI has actively taken input from and addressed the concerns of Java ME developers in improving the Java Verified program, the certification program is somewhat narrow in its scope. According to the Java ME developers, the program is quite ―straight-forward‖, but does not provide any mechanisms to cater for testing different application types and diverse developer requirements. First, the Java Verified application program only provides access to one of the four protection domains recommended in the Java ME platform specifications (MIDP 2.0) – the ―Trusted third-party protection domain‖.
Applications that require APIs that cannot be accessed under the trusted third party domain do not benefit from Java Verification. The testing criteria for ensuring quality to such applications require other certification options (such as mobile operator and device manufacturer testing107), which are not managed through the Java Verified program.
Second, the Java Verified program does not implement different procedures for different
Java ME application developers. The program has the same process and certification fee for all types of developers including enterprise, consumer, or ―freeware‖ developers
(who do not sell their applications for profit). In that sense, the Java Verified program is narrow, straight-forward, and unaccommodating of the requirements of the vast
107 Examples include Motorola Application Certification Program (http://qpqa.com/motorola/iden/), Nokia Testing (http://www.forum.nokia.com/info/sw.nokia.com/id/cb55f97d-dbae-4b27-8e14- 77b612435313/Nokia_Test_Criteria_For_J2ME_Applications_v1_0_en.pdf.html), Sprint Java Certification (http://www.crn.com/it-channel/18837923), Cingular Certified solution etc.
137 community of the Java ME developers. According to the interviewed developers, this simplicity and inflexibility undermines the ability of Java Verified to provide ―one-stop‖ shop for all Java ME application testing (one of the prime objectives of the UTI108).
Finally, the control structure of the Java Verified program is distributed across various Java ME stakeholders. First, Sun and the UTI members have relegated the certification authority to multiple third-party testing labs (ATLs) that competitively test, certify, and charge Java ME applications for the Java Verified program. Although the
Java Verified Program Office (JVPO) facilitates the process, according to the developer, their concerns were often directed to ATLs, device manufacturers, and network operators. Second, Sun or the UTI members do not control the way Java Verified applications are deployed and function on mobile devices. Although the Java Verified program provides application quality guarantee for a particular handset model, it does not guarantee that a Java Verified application will consistently deploy and interact with the underlying mobile device hardware across all devices and networks. This is partly due to the mobile operators control over the Java ME security policy. Mobile operators define their own security policy that outlines specific Java ME APIs a Java Verified application can access. Different mobile operators have instituted their own security policies that are not mandated by the Java Verified program.
7.3.2 Constraints
As a certification system, the Java Verified program imposes certain constraints on the application developers (certifiees) that distinguishes certified applications from the
108 The Unified Testing Initiative White Paper, Feb 2004, Page 12, http://javaverified.com/docs/UnifTestInit_wp022304.fm.pdf, Accessed July 2007
138 uncertified. The certification constrains primarily constitute the requirements for testing, signing, and distributing a Java Verified application. From a Java ME developers‘ perspective, the constraints are grouped under two broad categories – direct financial costs and indirect administrative costs of certification.
7.3.2.1 Java Verified Costs
One of the more direct forms of constraints imposed by a certification system is financial costs of certifying. In the case of Java Verified, most of the costs are passed on to the certifiees – the Java ME application developers. The developers have to pay for their authentication, application testing, and signing. According to the developers, these financial costs can often be challenging to overcome, especially for smaller developers.
All developers interviewed regarded the financial burden of the Java Verified program as the primary concern. The financial costs reported here have also been verified by other interviewees (ATLs, JVPO, and Java Verified supporters).
Firstly, Java Verified requires a way to authenticate the developer so that their applications, once certified, can be assigned to the ―Trusted third-party‖ protection domain of the Java ME platform. This authentication is achieved through the PKI supported by MIDP 2.0 compliant devices. Under the PKI scheme the developer has to apply for a digital certificate from a Certificate Authority (CA). The Java Verified program recognizes GeoTrust as the only CA for distributing these digital certificates. The developer applies to GeoTrust for a digital certificate by providing their contact information. GeoTrust, in return for an annual fee, verifies the contact information of the developer and issues a digital certificate. As of July 2007, this fee was approximately
$500 per year.
139 Secondly, and more importantly, the Java Verified testing costs are also borne by the developers. Every application that can be Java Verified has to be tested by the
JVPO authorized ATLs against the UTC. The ATLs charge a testing fee to the developer for the UTC testing. An ATL justifying this UTC testing fee stated that –
―…the test houses have to cover a lot of ground in testing the application for all the necessary criteria. It is true that some of the developers would feel the sting of the cost. But, we as a test house are trying our best to provide testing services at the lowest price possible‖
According to the ATLs interviewed, as of July 2007, the UTC testing fee was upward of $225 for testing an application on a particular device model. Further, the ATLs provide ‗volume discounts‘ for multiple applications testing on multiple device models.
However, according to the developers, these testing prices only seem trivial. As the UTC testing is executed on a particular device, the developer has to pay to test the application for all the devices that the developer has targeted for deployment and distribution.
As mentioned above, the JVPO has attempted to reduce repeated testing for all devices by categorizing devices into device families, wherein application testing on a lead device is sufficient for all devices of the lead device‘s device family. However, the developers reported that even the number of ―lead devices‖ creates an enormous cost burden, as a developer reported –
―…we want to deploy our little app on as many java enabled devices as possible through JV…even with the lead device idea…we still have to pay for tests on more than a 100 lead devices…‖
As of July 2007, there were about 119 lead devices (377 total devices) that were supported by the Java Verified program109.
109 From ―Java Verified— A Description and Update to the Verification and Signing Process for the Java ME Application Developer‖, JavaOne Conference, 2007
140 Further, as the Java Verified program digitally signs every tested application, the application cannot be updated. Any minor application update requires another round of
UTC testing, resulting in increased testing costs.
―…for applications that employ targeted builds [or versions] for different devices, this process can be quite expensive…for instance we have nearly 40 builds for this one application …add semi-annual updates to the mix and we‘re easily looking at $10,000 or more for testing costs…this is obviously cost prohibitive for those of us with rapidly updated applications without deep pockets …‖
Furthermore, if an application fails the UTC tests, the developer can make the necessary changes and resubmit for testing. This resubmission also has an associated retesting fee. Although the retesting fee is often less than the regular testing fee, retesting fee can have a cumulative effect, especially for a developer new to the Java
Verified program, as one developer recounting his initial struggles with Java Verified stated -
―…in the early days we had a crazy failure rate of 80-90%...don‘t even remember how much we spent on the retests…‖
Further, devices are also regularly updated through firmware110. Every device firmware upgrade also requires application retesting that has already been tested and verified for an older firmware version. The UTI whitepaper clearly states this –
―…certain conditions require that an application must be tested more than once. For example, if the device‘s firmware version has been upgraded to add functionality and the application needs to run on both [firmware] versions, then a retest on the additional firmware is required.‖ (pg 9)111
In summary, although the JVPO has tried to keep the testing costs down through competition by authorizing multiple ATLs, all developers interviewed reported testing and retesting costs as cumulative and hence burdensome.
110 A Firmware is software embedded in hardware by the hardware manufacturer to provide direct access to hardware functionality. From http://en.wikipedia.org/wiki/Firmware, Accessed July 2007 111 From UTI Whitepaper, Feb 2004, http://www.javaverified.com/, Accessed, July 2007
141 7.3.2.2 Administrative Costs
In addition to the financial costs associated with Java Verified, the certification system imposes certain indirect constraints on the application developers. These indirect constrains are mostly administrative in nature, but impact the bottom line of application developers.
Firstly, there are certain learning costs of the Java Verified program. Almost all developers and publishers recalled initially high application failure rates and questions for which answers were not always readily available. At least initially, this slowed down the developer‘s development and distribution efforts.
Secondly, the Java Verified process of developer verification and application testing was also reported by some developers as a time consuming process. Although application testing by an ATL generally takes a few business days (4-5), the testing time can vary significantly depending on the ATL workload. An ATL further elaborated -
―…things go crazy before a holiday season…all sorts of movie-based games and apps try to hit the market… we try to maintain our turnaround time…but I would still advise a developer to plan their delivery deadlines to avoid the holiday rush if they can…‖
Finally and probably the most important form of administrative costs, comes in the form of, what can be referred to as, the opportunity cost. The success of the Java
Verified certification program in the Java ME ecosystem depends on the industry-wide and standardized acceptance of the program. As the program is mandated by a few distribution channels and is partially acceptable or unacceptable to others, it can increase the testing burden of for developers attempting to sell their applications through different distribution channels. This is what I refer to as the Java Verified opportunity cost. The opportunity cost of the program for the developer is reflected along two dimensions.
142 First, as the Java Verified program digitally signs the verified Java ME applications against the UTI root certificate, the benefits of Java Verified program can only be ensured if all Java compliant devices implement the UTI root certificate. If the
UTI roots certificates are missing on a device the Java Verified application will be treated as an unsigned, and hence an uncertified application. The Java Verified investments by a developer in this case are essentially wasted. According to the UTI members, all UTI member device manufacturers implement the UTI root certificate. However, several developers reported that all UTI member device manufacturers, at least initially, did not implement the UTI root certificate on all Java compliant devices. Further, even with implementation of UTI root certificate on device, some mobile operators typically remove the UTI root certificate from the devices they sold to their subscribers. A developer stated -
―…carriers impose further restrictions, by removing certificates and adding their own from phones they sell‖
And another confirmed -
―…we often have to physically check what certificates are present on operator-branded phones and then roll out an implementation strategy..JV is good on many phones but you can never assume…‖
Second, as mentioned above, Java Verified applications have access to the trusted-third-party protection domain. The permissions to access specific APIs under the trusted third-party domain are not mandated through the JCP, but are only recommended. This has allowed different mobile operators to define their own API permissions according to the security policy of their choice. These differences in the mobile operator security policy result in different restrictions on a Java Verified application across mobile operators. The developers reported that this severely undermines the benefits of the Java Verified program as a certified application is treated
143 differently by mobile operators. A developer struggling with different US mobile operator security policies said -
―…why did I even get Java Verified? I would have been much better off just going through the security and signing requirements of individual operators....JV is just another waste of time and money if carriers don‘t standardize their security policies‖
The issues of variations in the UTI root certificate implementation and security policy are also confirmed by documentation of several device manufacturers. Motorola, for instance, in their Java ME signing guidelines, clearly state –
―Operators usually customize the Java ME security model by: [1] Removing standard root certificates (e.g., by removing Motorola and UTI/Java Verified root certificates), [2] Embedding their own root certificates, [3] Amending the API access policy for both untrusted and trusted signing domains‖ (pg. 9)112
As a warning, the document further states –
―Developers must pay special attention when selecting a sales channel for their MIDlets by making sure that the root certificate for which their application is signed exists on the targeted handset. For example, a MIDlet trusted by an unbranded handset, such as a generic Motorola retail handset, may not function identically on a branded handset where the Operator has enforced a different trust policy.‖
Hence, the limited implementation of UTI root certificate and inconsistent mobile operator security policies for API access to signed applications undermine the two prime objectives of the Java Verified program – reduced testing costs and enhanced application quality.
112 From ―Mobile Information Device Profile (MIDP) 2.0: Application Testing and Signing‖, January 11 2007, Motorola, http://developer.motorola.com/techresources/testingcertification/testing_signing_programs/MIDlet _Testing_and_Signing.pdf, Accessed July 2007
144 7.3.3 Benefits
Certification benefits an important attribute of a certification system. For the success of a certification system, a set of benefits in some form have to outweigh its constraints for the certification system to be successful in the marketplace. The Java
Verified program has attempted to provide certain benefits to potential certifiees in the
Java ME applications market. The following subsections discuss some of the core claimed benefits of the program from the certifiers‘ (Sun and UTI members) and the certifiees‘ (Java ME application developers) perspective.
7.3.3.1 Unified Application Testing
According to the UTI members, one of the primary objectives of the Java Verified program is to encourage adoption of the UTC as an industry-wide Java ME application testing standard. The UTI hoped that the Java Verified program will ―consolidate‖ multiple testing requirements of different Java ME stakeholders and reduce, if not eliminate, the application testing costs on separate proprietary testing criteria of application distribution channels. The reduced testing costs would save time and money for all Java ME stakeholders.
All developers, while acknowledging the UTI effort, reported little or no test cost savings since the inception of Java Verified. One developer flatly denied any observable cost benefit –
―I have seen cost savings only because I have become smarter and have focused only on a few major devices. I wouldn‘t attribute that to Java Verification, it was my effort, like many other developers, who learned through bitter experiences‖ (Emphasis, original)
145 Another developer highlighted the importance of Java Verified mandates and endorsements by mobile operators in reducing some testing costs –
―…[I could see] the real benefits of the JV coming when Vodafone and Orange started asking for Java Verified applications…before that it was just another program without any teeth…‖
Contemplating on the future of the Java Verified program, he further stated -
―I think JV needs more operator involvement, especially in the Americas where operators still play us by their own tune…handset [manufacturers] support just doesn‘t help‖
Most developers felt that although Java Verification would probably become an industry-wide application testing requirement, many distribution channels, especially network operators, further tested a Java Verified application against their pre-existing proprietary test criteria. The test criteria were only slightly different from the UTC and developers often had to pay for such testing out of their own pocket.
7.3.3.2 Application Quality and Security
Another commonly stated benefit of the UTI and Java Verified vision is to ensure availability of quality and secure applications for the end-users. Following the basic testing guidelines of the UTI members, the Java Verified program essentially guarantees a basic level of application quality and security. An ATL for the program talking about quality of application submitted for Java Verification stated –
―…you should see how many basic errors still pop-up in many [submitted] applications…so yeah the testing bar might be low, but [Java Verified] still screens out so many bad applications…‖
On the other hand, developers reported that the quality check of Java Verified is very generic and hence minimal. Test cases in the initial UTC left a lot of room for
146 interpretation by the ATLs. Examples of these tests from the UTC 1.4 document include
–
―[E.g. 1] Each screen must appear for the time necessary to read all its information...[E.g. 2] The speed of the application is adequate and it does not compromise the application‘s use. The performance of the application is acceptable…[E.g. 3] The application must do what it is meant to do…‖113
However, most developers reported that UTC has considerably improved since the launch of Java Verified, but it still leaves room for interpretation by the tester.
In addition to application quality benefit, according to the JVPO, Java Verified program also provides a degree of application security that can potentially ease the distribution of Java Verified applications. Again the degree of security is minimal, but commenting on application security a UTI representative reported –
―…no set of tests can possibly ensure security, unless maybe if we have the source code of the application, but that gets us into IP [Intellectual Property] issues…I think [Java Verified] does a good job at what can be practically done and that‘s one of the reasons we joined the UTI‖
Although most developers agreed that application security is beneficial for everyone, they had some reservations on the concept of digital signing model implemented by the Java Verified program. One developer speaking about the limits of digital signing itself stated that –
―…all [Java Verified] does in the name of security is saying, ―We certify that this application works, if not, we know where the culprit lives‖…rest all is left to the operator‖
113 From UTC 1.4, 28 September 2004, available from http://javaverified.com/docs/Unified_Test_Criteria.pdf, Accessed July 2007
147 7.3.3.3 Application Distribution and Marketing
Another important benefit of the Java Verified program was the distribution opportunities provided through the UTI member application sales channels. As Java
Verified was designed by the UTI members, all the UTI members gave exclusive access to applications that were Java Verified. UTI member device manufacturers publicly listed only Java Verified applications on catalogs provided to end-users and mobile operators.
Later when Vodafone and Orange joined the UTI, they also provided Java Verified applications for their subscribers. In addition to increased application visibility through catalog listings, Sun also provided exclusive access to their proprietary ―Java Powered‖ logo for marketing Java Verified applications (Figure 7:3). The developers were allowed to embed the logo in the applications that had passed the UTC tests.
Figure 7:3: Java Verified Application Marketing Logo
According to the developers, the distribution and marketing benefits of the Java
Verified program were mixed. Developers that distributed their applications through some distribution channels have benefited, while others have not. The marketing and distribution benefits were primarily reported by developers deploying applications in
Europe, as opposed to the ones who targeted their applications for the US and Americas at large. The reason for this difference was due to wide recognition of Java Verified applications in European market. Even if mobile operators did not officially mandate
Java Verified, they were more open to accept a Java Verified application for distribution due to strong support from device market leader Nokia and major operators like
148 Vodafone and Orange. In the Americas the developers reported lack of strong support from major Java ME stakeholders as most operators either removed the UTI root certificate or severely restricted API access of Java Verified applications through their security policies.
7.4 Market Effects of Java Verified: A Discussion
The Java Verified program has affected the Java ME mobile applications market at several levels. On one level, from the key expert viewpoint, the Java Verified has set a minimal quality standard for Java ME applications that application developers can leverage to market and distribute their applications. On another level, from the key informant viewpoint, the Java Verified seems to have consolidated the application testing requirements (by collaboratively defining the UTC) to reduce some of the repetitive application testing costs for Java ME developers. In this section, taking a unified key expert and informant viewpoint, I discuss some of the nuanced effects of the way Java
Verified program is designed and managed on the technical and commercial aspects of the supply of Java ME mobile applications.
7.4.1 Deployment Compatibility
Although it was expected that application certifications can enhance the deployment or vertical compatibility of the certified application with the underlying platform implementing devices, it seems that the Java Verified program has had little to no impact on deployment compatibility. Broadly, I observed two reasons for the same.
149 As the device manufacturers selectively implement different modules of the modular Java ME platform, Java ME applications are often not compatible with all Java enabled devices. The Java Verified program does not comprehensively test the Java ME applications across all Java enabled devices and hence cannot provide any guarantee that the application will function as intended on all Java devices. The Java ME application developers often tweak or ―port‖ their applications to ensure its deployability and compatibility on different Java enabled devices. A developer with more than a decade of Java development experience when asked about the compatibility benefits of the Java Verified program stated –
―Java‘s WORA [Write One Run Anywhere] principle is certainly a hoax in the mobile world….Java Verified has not made the slightest dent on the hoax…it is still a hoax…‖
Further, as the Java Verified program tests applications on a particular device model, to a certain extent it does assure a developer that the application is compatible with all the devices of that model. However this assurance is contingent on the fact that the UTI root certificates aren‘t removed or the security policy for API access is consistent across devices of the same model. Many developers noted that this is often not the case. First, due to the network operator intervention, all devices of the same model don‘t necessarily have the embedded UTI root certificate. Java Verified applications hence cannot even install appropriately on devices of the same model. Second, the network operators also alter the MIDP security policy for devices on their networks114. Often the
114 According to developers interviewed, major operators do alter the MIDP security policy. This was also confirmed from various developer forums. As an example see Forum Nokia, Java Security Domains, http://wiki.forum.nokia.com/index.php/Java_Security_Domains#Security_Domain_policies_for_a_ number_of_carriers.2C_deviating_from_the_standard, Accessed Dec 2007
150 security policy is more restrictive and hence does not grant access to the APIs an application requires, rendering it inoperable on the devices on those networks.
The Java Verified program does not address such deployment compatibility issues of the Java Verified applications. According to developers, at best, the UTI members only recommend that the operators should not remove the UTI root certificate and/or alter the MIDP recommended security policy. Developers also noted that they were encouraged by the JVPO to directly interface with the network operators to ensure that their Java Verified application will appropriately execute on the devices supported on their networks. In that sense, Java Verified program has had little to no effect on the deployment compatibility of Java ME applications.
7.4.2 Implications for Application Developers
The Java Verified program has shaped the Java application market and has had subtle implications for the Java ME developers. The Java ME application distribution is much more streamlined today, at least in part, due to the UTI and the Java Verified program. Application developers can Java Verify their applications and deploy across
UTI member device manufacturer models and operators. Application distribution is hence much easier for developers targeting devices for UTI operators and device manufacturers which constitute a major share of the Java ME application market.
On the other hand, developers reported that they now need a more strategic approach to distributing their applications. Today there are hundreds of different java enabled devices in the market. It is often difficult to figure out which models can support
Java Verified applications and which ones don‘t. UTI root certificate removal and restrictive security policy of network operators further worsens the matter. Distributing
151 Java Verified applications, hence, can be quite confusing and requires careful and extensive market research. Some developers had even invested in a dedicated staff to conduct such market research.
Further, the market for Java ME applications was always fragmented due to varying implementation of Java ME platform. Java Verified has had no role in alleviating market fragmentation. As Java Verification is tied to a particular device model, it does not allow developers to leverage economies of scale in testing and deploying for multiple
Java enabled devices. The developers still have to individually Java Verify their applications for every targeted device model.
Furthermore, for new application developer the market entry conditions are probably much worse. According to some of the experienced developers, Java ME applications were always easy to develop and required very little startup investments.
However, selling the applications was always an issue. When the developers were asked about some of the issues a market entering developer might face today, they invariably suggested that Java Verification and other testing costs would be especially challenging. Although a new developer, at least initially, can avoid Java Verification, competing with developers that have extensive device-market knowledge and offer strategically Java Verified applications can be a daunting uphill task.
In summary, although the Java Verified program has not directly influence the degree of market fragmentation of entry barriers for Java Me application developer, it certainly has added another strategic dimension to the competitive landscape of the
Java ME marketplace.
Chapter 8
The True BREW Program
The True BREW program is another mobile application certification program for the BREW Qualcomm‘s BREW platform. In this chapter I examine the True BREW program and its implications for the BREW developers. The chapter is organized to first provide a brief overview of the BREW platform to highlight its technical core and business foundations that facilitate the BREW application development, testing, and deployment on BREW enabled mobile devices. Specifically I discuss BREW‘s architecture and application delivery system to provide a contextual grounding of BREW application development and the role of True BREW certification program in the BREW ecosystem.
Next I discuss the True BREW program in detail. In particular, I provide some of the rationales and value propositions of the True BREW program for various BREW stakeholders. Further, I outline its core certification options, processes, and application testing criteria. Following that, I discuss the authority structure of the True BREW program and present some of the constraints and benefits as perceived by the BREW application developers I interviewed. Finally, I analyze and discuss some of the implications of the True BREW program for the application developers in the BREW mobile application ecosystem.
The data for the case was gathered from interviews with various stakeholder representatives in the True BREW program. The stakeholders included the True BREW program management at Qualcomm‘s Internet Services (QIS) division, and Qualcomm‘s authorized testing lab (NSTL Inc.) as well as the BREW developers and publishers. A
153 total of 17 interviews were conducted out of which 13 were senior representatives of
BREW application developer/publisher firms, which had been active since the launch of the True BREW program. Most of the developers/publisher firms were based in North and South America. Hence, their perspective is particularly valid for the BREW market in the Americas, which are extrapolated to describe global BREW markets with reservations. The case also draws information from publicly available True BREW documentation, BREW developer forums hosted by Qualcomm115, and various trade- press articles whenever necessary.
8.1 The BREW Technology
BREW (Binary Runtime Environment for Wireless) is one of the most widely deployed proprietary middleware platforms for various types of cellular mobile devices.
Although BREW can support various cellular air-interface network technologies such as
GSM and CDMA, it was initially especially designed for CDMA cellular devices. The
BREW computing platform was introduced by Qualcomm in early 2001116 and initial
BREW-enabled devices and applications were available in late 2001117. The BREW platform has evolved since its initial offering and three major versions for BREW device implementation are currently available – BREW 1.0, 2.0, and 3.0. As of July 2007,
BREW 3.1 was the most recent version available for implementation.
115 BREW developer forum website http://brewforums.qualcomm.com/index.php, Accessed July 2007 116 See http://brew.qualcomm.com/jsp/brew/en/press_room/press_releases/2001/01_31_01.html, Accessed July 2007 117 See http://brew.qualcomm.com/jsp/brew/en/press_room/press_releases/2001/11_13_01.html, Accessed July 2007
154
User Photo Position Email Push to Talk Browser Video Player Java Applet Interface Sharing Location
Other Extension VM Extension BREW
ASIC Software BREW is air-interface independent and can support GSM/GPRS, UMTS, cdmaOne & CDMA2000 1X/1xEV-DO
Figure 8:1: The BREW Platform Architecture118
Unlike Java ME, which is another middleware platform, BREW is a proprietary
Qualcomm platform that is implemented as an integrated package on mobile devices
(i.e. specific BREW versions). As a platform it provides API access to a range of features including mobile telephony, media, messaging, and networking. Further, BREW is more than just an application development platform. It is also an application delivery and distribution solution. The BREW‘s application distribution component is commonly referred to as the BREW Delivery System (BDS). The BDS provides the framework for mobile operators and the end-users to shop, purchase, download, and install BREW applications over the mobile operator‘s network. Further, BDS manages application billing, wherein application purchase transactions are completed over-the-air (OTA) and the mobile operator bills the end-user monthly phone bill.
In addition, BREW provides the necessary tools for define commercial pricing of
BREW applications. BREW provides various pricing options such as the Subscription,
Purchase, and Demo that a developer can use for application deployment through the
BDS. The Subscription pricing option allows developer to charge for unlimited use of an
118 Adapted from BDS Overview, Whitepaper, Qualcomm QIS, 2003
155 application on a monthly basis. The end-user pays a monthly subscription price for application usage. The price is defined by the developer and the mobile operator and the developer typically receives a share of the monthly revenue generated. The Purchase pricing option allows the developer to charge for application usage according to number of uses, days, elapsed time, or an expiration date. Again the price is defined by the developer and mobile operator. Finally, the Demo pricing option allows a developer to provide a free demonstration version of the application for certain number of uses, time of usage, or elapsed time on the mobile device.
In that sense, BREW is a technology that defines the application development platform as well as the application pricing, billing and delivery infrastructure. A high-level view of the BREW platform architecture and the BDS is shown in Figure 8:1 and
Figure 8:2.
Review QC Apps and App Submission 2 1a Virtual Negotiate Developer Standard Marketplace Pricing 1b Operator Managed 4 Build Catalog of 3 Applications and Set Make Applications Retail Price Available to Catalogs
5 Operator 6 Activiate Catalog Controlled Consumer Views Application Operator Catalog 7 Consumer Buys Distribution Application OTA
9 8 Operator Processes Mediated Usage Billing Record Created
Figure 8:2: The BREW Delivery System119
119 Adapted from BDS Overview, Whitepaper, Qualcomm QIS, 2003
156
Qualcomm licenses BREW technology to device manufacturers as well as mobile operators. The application development platform is implemented by BREW licensing device manufacturers, whereas the BDS is implemented by BREW licensing mobile operators and managed by Qualcomm.
From the BREW application developers‘ perspective, BREW is a tightly integrated application development, testing, deployment, and commercialization technology. BREW, like Java ME and Symbian-OS, uses a Public Key Infrastructure for developer authentication and application deployment on BREW enabled devices using digital signatures120. However, unlike Java ME and Symbian-OS, BREW does not categorize API access. All BREW applications can access any API they require. All
BREW applications hence require developer authentication, testing, and digital signatures for commercial deployment on mobile operator networks.
Further, since BREW‘s launch, Qualcomm has promoted and managed the
BREW application developers through its ―BREW Alliance‖ program. According to an interviewee at Qualcomm, the BREW Alliance program is designed to be ―the prime source of BREW information, support and commercialization for developers‖. The program provides services such as ―technical support, product development guidance, business development and operations support, information resources, promotional opportunities‖ for BREW developers from application concept exploration to final deployment and commercialization121. BREW developers can become a member of the alliance program at three levels – BREW developer, Select BREW developer, and Elite
120 For details on Public Key Infrastructure and Digital Signatures see Appendix. 121 From BREW Alliance Program website - http://brew.qualcomm.com/brew/en/developer/getting_started/alliance.html, Accessed July 2007
157 BREW developer. All BREW developers are required to register with Qualcomm as a
BREW developer by buying a BREW certificate from VeriSign (more details later). As of
July 2007, about 750 developers/Publishers world-wide had registered for BREW application development122. BREW developers can apply for Select and Elite Alliance membership by paying an annual fee123 for preferential access to BREW events, technical support and marketing tools124. About 11% of the BREW developers have
Select and Elite BREW Alliance membership125.
In summary, BREW as computing platform provides a foundation for the commercial development and growth of Qualcomm managed ecosystem of BREW developers (application suppliers), network operators (application buyers/distributors), and device manufacturers (BREW licensees).
8.2 The True BREW Certification Program
The True BREW certification program was launched with the commercial deployment of the BREW platform on mobile devices in late 2001. According to
Qualcomm, the program was part of the BREW vision since its commercial launch in late
2001. The True BREW program was designed to evaluate BREW applications against
―the established levels of stability, quality, and compliance with standard platform requirements that Qualcomm‘s carrier partners demand‖126. The level of stability, quality
122 See http://brew.qualcomm.com/brew/en/developer/directory.html, Accessed July 2007 123 Annual Fee for Select BREW Developer: $5,000; and Elite BREW Developer: $15,000 124 For details of the BREW Alliance program see BREW Alliance Program Website http://brew.qualcomm.com/brew/en/developer/getting_started/alliance.html, Accessed July 2007 125 http://brew.qualcomm.com/brew/en/developer/directory.html, Accessed July 2007 126 From BREW Newsletter, 2001, http://brew.qualcomm.com/brew/en/developer/newsletter/2001/september_2001.html, Accessed July 2001
158 and compliance were established by Qualcomm so as to be able to promote the BREW package to their prime customers – the mobile operators.
Qualcomm, as the proprietary owner of the BREW technology, mandated True
BREW certification for all BREW applications that were deployed by BREW licensing mobile operators. As all BREW applications are downloaded from the mobile operator‘s networks, all commercially available BREW applications are True BREW certified.
Qualcomm certifies BREW applications once it passes True BREW Testing
(TBT). The TBT is essentially a set of Qualcomm defined minimum-application-quality criteria that all certified BREW applications have to pass for application deployment on mobile operator networks for eventual end-user consumption. A TBT passing application is digitally signed to guarantee the source, integrity, and quality of the application. This guarantee is provided by Qualcomm and hence is often referred to as an application certification program.
Although the True BREW program is managed by Qualcomm, the TBT component is outsourced to a Qualcomm authorized third-party test lab – National
Software Testing Labs (NSTL), which recommends True BREW certification for TBT passing applications. NSTL has been the only Authorized Test Lab (ATL) for TBT testing since the True BREW program was established.
In the following sub-sections, I provide a detailed overview of the True BREW certification process, certification criteria, and certification options for various BREW developers.
159 8.2.1 Certification Process
Qualcomm defines the process for certifying BREW applications, which is documented on the Qualcomm‘s BREW website (http://www.brew.qualcomm.com/). The process entails registration of the developer with Qualcomm, application submission on the portal, TBT by NSTL, and finally if the application passes TBT, application pricing for
Over-The-Air (OTA) deployment. Figure 8:3 provides a flow diagram of the True BREW process from the developer‘s perspective.
160
Developer Rework creates BREW Required application
Developer submits application package rd to 3 party lab Developer by Fail submission site Standard testing email of issues executed according to True BREW test guide Yes
Application Entrance Standard Test Submission Yes Criteria Pass Fail? Complete? Executed
No Functional testing No executed according to True BREW test AUT recommended Developer notified by guide for True BREW; email of incomplete Fail Developer notified in submission email
Developer notified by Final check out email that AUT executed according Pass received True BREW to True BREW test status guide
Application enters distribution system as a True BREW application (for a carrier)
Figure 8:3: The True BREW Submission and Testing Process127
8.2.1.1 BREW Developer Registration
127 Adapted from Application developer‘s True BREW Process Overview, Qualcomm, 80-D4299-1 Rev B, June 5 2002
161 All developers are required to register with three entities – Qualcomm, NSTL
(ATL), and a Certificate Authority (CA). Only developers that have registered with all three entities can develop and commercially deploy BREW applications through mobile operator networks. The objective of developer registration is to authenticate BREW developers. Although BREW SDK (Software Development Kit) is freely available for any potential BREW developer from the BREW website, a developer registration with
Qualcomm, ATL, and Certificate Authority is compulsory for all BREW developers wishing to commercialize their applications to end-users.
As part of the developer registration a developer has to apply for an ―Authentic
Document ID‖ from VeriSign (a Certificate Authority). The Authentic Document ID is a code signing certificate that a developer has to use to digitally sign all their applications.
VeriSign as the Certification Authority for BREW applications charges an annual fee for issuing an Authentic Document ID (more details to follow).
Once an Authentic Document ID option is chosen by the developer, VeriSign verifies developer‘s physical identity such as developer‘s contact information and legal registration of operations. After the VeriSign‘s verification the developer is issued an
Authentic Document ID. According to VeriSign‘s website, the process of verification takes an average of five business days. Qualcomm then accepts developer registration with Qualcomm. The developer is considered a registered/authenticated developer once the developer accepts and signs the BREW Developer Agreement with Qualcomm128.
Authenticated developers are provided access to Qualcomm‘s ―BREW Developer
Extranet‖, which contains the tools and information necessary to develop applications for specific BREW compliant devices.
128 BREW Developer Registration available from https://brewx.qualcomm.com/signup/index.jsp?return=companysignup.jsp, Accessed July 2007
162 Finally, the authenticated developer registers with the Qualcomm‘s ATL (NSTL).
NSTL registration allows developers to digitally sign and submit applications for BREW
TBT129.
8.2.1.2 Application Submission
An authenticated developer can design and develop an application using various tools and information available on the BREW Developer Extranet. An application can then be submitted to NSTL through their application submission portal. Developers are encouraged by Qualcomm to ―Pre-Test‖130 the application against the Qualcomm designed TBT criteria so as to increase their chances to pass the TBT tests conducted by NSTL.
In order to submit the application for TBT, the developer has to – 1) ensure that the submitted application is digitally signed by the VeriSign certificate; 2) specify the particular mobile device model the application is designed for; 3) submit an ―Application
Specification Document‖, which essentially outlines the intended functionality of the application; 4) submit the compiled binary versions of the application131; and 5) submit any previous test results if available.
129 NSTL BREW Developer Registration can be done online on https://www.nstl.com/nstl/index.htm, Accessed July 2007 130 Pretesting in the context of the application certification refers to testing that is conducted in- house by the developer of an application before submitting it for certification testing. Pretesting generally assures the application developer that the application will pass the certification testing criteria. 131 Two binary files of the application are required for TBT submission – 1) Windows-compiled binary; and 2) Device-compiled binary
163 8.2.1.3 Application Testing
Once submitted, NSTL performs testing on the application against the TBT criteria. According to NSTL, it takes an average of 3-5 business days to test the application. The testing times can vary by application as they are based on application complexity and the number of applications in the test queue. The developer can check the status of the application through the test submission portal.
Once the TBT is performed, NSTL informs the developer and Qualcomm about the results through a standardized test report. If the application passes all the TBT tests
NSTL recommends the application for True BREW certification. According to NSTL,
Qualcomm typically accepts the recommendation and digitally signs the application against BREW root certificate for distribution on BDS licensing network operators.
8.2.1.4 Application Pricing and Deployment
Once an application is True BREW certified, it is posted on Qualcomm‘s BREW application catalog, where BREW licensing mobile operators can access the certified applications. In order to deploy a BREW application on a mobile operator‘s network, the developer has to negotiate pricing terms with the mobile operator. The price points for the chosen pricing options (subscription, purchase and demo) are negotiated with the mobile operator before final inclusion in the mobile operator‘s application catalog.
According to the developers, a developer typically receives about 80% of the revenues generated by the application, whereas Qualcomm and mobile operators share the remaining 20%.
164 It should be noted that before actual deployment of the application on a mobile operator‘s network, the operator might perform additional application testing according to their own requirements and guidelines, which are shared with the developers through the BREW Developer Extranet.
8.2.2 True BREW Testing Criteria
True BREW Testing (TBT) evaluates a BREW application against the Qualcomm designed test guide referred to as the TBT test criteria. The TBT test criteria essentially evaluate BREW application stability, quality, and compliance with BREW compliant device requirements.
An application has to pass all the TBT tests to be True BREW certified. However, in early 2003, Qualcomm slightly relaxed this requirement by introducing the ―Pass with
Notes‖ status for TBT application. Applications that passed most and failed a few TBT tests were given this Passed-with-Notes status. Providing the Passed-with-Notes status is at the discretion of Qualcomm and NSTL. Essentially, applications that pass with notes were treated as True BREW certified. However, their acceptance for deployment was left at the discretion of the mobile operator132.
The TBT test criteria are grouped into four categories – Entrance Testing,
Standard TBT, Functional Testing, and Final Verification Testing. Other than the final verification testing, all test criteria are performed by the test lab (NSTL). If an application
132 . The scope and treatment of ‗Passed with Notes‘ applications is documented by Qualcomm in – True BREW Testing: Developers Guide to True BREW ―Passed With Notes‖ Process, Qualcomm, 80-D4527-2 Rev. A, March 17, 2003
165 passes all tests conducted by the test lab, Qualcomm conducts the final verification testing to grant the True BREW certification.
1) Entrance Testing: The Entrance criteria are the first set of application tests that
are conducted once an application is submitted for certification. The entrance
tests are conducted to ensure that the attributes of the submitted application
match the ones claimed on the submission portal. These application attributes
include ―privileges‖133 required by the application, its version, appropriate
application icon dimensions134, and appropriate developer signature for the
submitted application.
2) Standard TBT: Once the Entrance criteria are passed, standard TBT testing
commences. The standard TBT criteria check for the core application behavior
on the handset on a live network. First, the standard TBT tests check core
application functionality to ensure that the application – appropriately stores data
during usage, doesn‘t write excessively large files, handles continuous user
inputs etc. Second, the standard TBT tests check core mobile device functionality
to ensure that the application is stable under varying device conditions (low
memory, device alerts, accidental device battery removal etc.). Third, the
standard TBT tests check core network functionality to ensure that the
application does not disrupt appropriate management of incoming calls, SMS
messages, data, and low or no wireless connectivity. Fourth, the standard TBT
133 BREW Application Privileges specify the application's ability to access certain functionality on the device or on the operator's network. An application will not execute if it tries to use any of the associated API's without having the proper privileges. For instance, a BREW 3.0 application can declare privileges to create and write files and ringtones, and access network, device location, telephony and address book functions. 134 Icon transparency and dimensions are defined for every BREW compliant device, which are available on the BREW Developer Extranet
166 tests check core Qualcomm User Interface (UI) requirements such as pre-
defined use of ‗Clear‘ and ‗Send‘ keys; and that the application provides a visual
feedback if processing delays are greater than 2 seconds. Finally, the standard
TBT tests checks for application stability when used for a long period of time. A
Qualcomm designed tool is used to test stability under hours of operation.
3) Functional Testing: In addition to the standard TBT, application functionality
testing135 is performed on the application according to an ―Application
Specification Document‖, which is submitted by the developer with the
application. The Application Specification Document essentially outlines the
application‘s screen-by-screen flow and functionality categorized by Data
storage, Audio, Phone book, Telephony, wireless data. Qualcomm provides a
format template that a developer can use to create the Application Specification
Document to aide functional testing. In addition to functionality, the Functional
testing criteria also checks for UI consistency such as screen display, keypad
input, and scroll bars across all application screens; and appropriateness of
displayed content136.
4) Final Verification: Once an application passes the Entrance, Standard, and
Functional testing criteria, the test lab (NSTL) recommends True BREW
certification for the application. Qualcomm performs the final verification tests to
certify the application. The final verification includes testing for application
signature verification, over-the-air (OTA) application download, installation, and
135 Functional testing employs an industry-recognized exploratory application testing method. The method is documented by James Bach, General Functionality and Stability Test Procedure, v1.0, Satisfice, Inc., Available from www.satisfice.com/tools/procedure.pdf, Accessed July 2007 136 The screen contents should not display ―offensive or inappropriate content‖ as defined by Qualcomm.
167 removal, to ensure that the application can be distributed and deployed
effectively.
8.2.3 True BREW Certification Options
The True BREW certification program certifies applications for every device model chosen for application deployment. If a developer chooses to deploy an application on multiple device models, the application has to be True BREW certified for all chosen device models.
In order to reduce repeated testing costs for certifying an application on multiple devices, the True BREW program provides the flexibility of partial-testing and self-testing certification options for developers. A developer requesting partial-testing or self-testing certification is charged a reduced testing/certification fee (see Table 8-1 for the TBT fee structure). These two certification options can only be used by developers under certain conditions, which are summarized below.
8.2.3.1 Partial-Testing Certification
Qualcomm recommends that developers test BREW applications against the complete TBT described above, so as to be True BREW certified. However, under certain situations an application is only tested against a partial set of TBT criteria at a reduced testing fee.
Every BREW application is tested against the complete TBT criteria on at least one device for True BREW certification. The same application once completely tested on a device can be partially tested on additional devices requested by the developer. The
168 partial TBT does not rigorously test for application‘s effects on core mobile device and network functionality; as such tests have already been conducted on a similar device. If the application passes the partial TBT tests, it is granted True BREW certification for the additional device. The fee for partial testing is lower than a complete test (see Table 8-1 for TBT fee structure).
It should be noted that every application update (new application version) is considered a new application and requires complete TBT on at least one device. Partial testing can be requested for additional devices once the updated application is completely testing on at least one device.
8.2.3.2 Self-Testing Certification
In addition to partial-testing certification, a developer can request a self-testing status from Qualcomm through the ―Self-Test program‖ that was introduced in 2005.
Qualcomm provides the Self-Test status only to Select and Elite BREW Alliance
Developers that have developed a high quantity and quality of BREW applications.
Qualcomm defines the criteria for Self-Test status, which requires developers to have – had at least 100 application tests137 per year; passed 95% or higher for the past 100 application tests; and passed 100% for the past 25 application tests138. A Self-Testing developer essentially performs complete TBT in-house. However, the Self-Tested application is still tested for compliance with criteria such as OTA download and
137 ―Application tests‖ refers to a unique application tested per unique device 138 For details of the BREW Self-Test program see - True BREW® Test Self-Test Program, Qualcomm, 80-D4081-1, Rev. C, January 22 2007; Available from http://www.brew.qualcomm.com/, Accessed July 2007
169 installation by the test lab (NSTL) for a reduced fee (see Table 8-1 for the TBT fee structure).
In order to ensure that the Self-Test status is not abused by the developer, NSTL fully tests a sample of the submitted applications against the TBT. The Self-Test status can be revoked by Qualcomm if any Self-Tested application fails the full or partial True
BREW testing by NSTL.
8.3 The True BREW Certification System
As the True BREW program provides a certification framework for testing and certifying BREW applications, at its core it‘s an application certification system. In this section I present the observations and findings of the True BREW certification program along conceptual constructs outlined in the conceptual framework. I first discuss the
True BREW program‘s authority structure, and then present some of the imposed constraints and perceived benefits of the program for the BREW developers.
8.3.1 Authority Structure
As discussed in previous chapters, the role of certifier and the way it manages a certification program is key aspect of a certification system. In that case of platform certification, the role of certifier is assumed by a platform promulgator that manages the program and attempts to establish control and gain support and acceptance for its certification program in the market. For the True BREW program, Qualcomm has been an active proponent of the BREW platform and the importance of True BREW application certification in the applications market.
170 The True BREW program can be characterized by an integrated, centralized and somewhat inflexible, Authority Structure.
Firstly, Qualcomm introduced the True BREW program as an integrated package for distributing mobile applications to BREW licensing mobile operators. A mobile operator that invests in the BREW has to accept the entire package of BREW processes, criteria, and costs from development to commercialization of BREW applications. In that sense, Qualcomm garnered unrivaled support for the True BREW program from the mobile operators that accepted BREW applications for distribution. As
BREW only provides Over-The-Air deployment and distribution of BREW applications, mobile operators were the only distribution channel for BREW applications. This leads to a complete and unvarying acceptance of True BREW requirements by all BREW application distributing channels (mobile operators).
Secondly, the True BREW program is centrally managed by Qualcomm. There are no competing BREW application certification programs as the True BREW is accepted by all BREW application distribution channels. Although mobile operators can define their own application requirements, the True BREW program is mandatory for deploying BREW applications on their networks. Qualcomm also shares these additional requirements with authenticated BREW developers in a transparent fashion through its
BREW Developer Extranet. Further, Qualcomm has only authorized NSTL as a third- party test lab for True BREW certification of all BREW applications. The interviewed
NSTL representatives, viewed themselves as Qualcomm‘s agents in the certification program and said that major certification process, criteria, and pricing decisions were only approved by Qualcomm (although in consultation with NSTL).
In addition to managing basic operator requirements and interfacing with the testing lab, Qualcomm also centrally controls other stakeholders in the BREW
171 ecosystem. First, Qualcomm manages BREW developers through its Alliance program.
All BREW developers are required to register and authenticate with Qualcomm to True
BREW certify and commercially deploy a BREW application. Second, Qualcomm tightly controls the compatibility of BREW platform implementation across different BREW enabled devices so that the True BREW certified applications are able to execute on all
BREW-enabled devices with little or no porting.
Devices implementing the BREW platform go through a Qualcomm managed
―Handset Readiness‖ program, which defines the process to approve the commercial availability of the BREW enabled device for BREW application development. Qualcomm achieves this by providing a ‗Porting Evaluation Kit‘ (PEK) to device manufacturers. The device manufacturers are required to execute PEK on new BREW enabled devices, as well as their firmware139 upgrades and provide the results to Qualcomm. Based on the
PEK results, Qualcomm classifies the devices as PEK failed (not ready for BREW application development and testing), PEK partially passed or ‗Ready Release 1‘ (ready for BREW application development, but requires firmware upgrade), and PEK passed or
‗Ready Release 2‘ (ready for BREW application development and device commercialization). Device details of RR1 are RR2 devices are posted on BREW developer Extranet for BREW developers as ‗Pre-commercial‘ devices and ‗Commercial‘ devices respectively. Any firmware upgrades for commercial (RR2) devices require the
PEK evaluation. Qualcomm analyzes the results and compares them with results from previous version and classifies the upgraded device as ‗Incompatible‘ (requires BREW application retesting), or ‗Compatible‘ (BREW applications will operate on both firm
139 Firmware is software that is embedded in a hardware device. Firmware is a computer program which is executed by a computer, but is also an intimate and vital part of a piece of hardware. From http://en.wikipedia.org/wiki/Firmware, Accessed July 2007
172 versions and do not require retesting). The ‗Handset Readiness program‘ is managed by
Qualcomm and the PEK results are shared with various BREW licensing operators and
BREW developers. In that sense, the Handset Readiness program is a centralized mechanism to manage application deployment compatibility across different BREW enabled devices140.
Finally, the True BREW program is somewhat inflexible in catering for the diverse community of application developers and their applications. The certification process and costs are unvarying for all types of BREW applications, with no special provisions for non-commercial applications or device pre-installed applications. Further, it was evident in the research that Qualcomm provides almost no special support for low-volume smaller developers. The True BREW program does not provide any special certification options geared towards new or smaller low-volume application developers. On the other hand, it seems that Qualcomm encourages established high-volume generating BREW developers. For instance, larger high-volume developers, who might already have an established in-house testing unit, can choose the cheaper ―self-test‖ option and generate economies of scale. In addition, Qualcomm encourages established local publishers who have established relations with a local mobile operator through its ―BREW Global
Publisher program‖ (BGP)141. Under the BGP, Qualcomm identifies a select group of
140 For details about the Handset Readiness program see Application Commercialization: The Role of True BREW Testing, BREW conference presentation, 2006 by Brett Toerien, Qualcomm; Available from http://brew.qualcomm.com/bnry_brew/pdf/brew_2006/tech801_toerien_applications.pdf, Accessed July 2007 141 The BGP was introduced by Qualcomm in 2003 (http://brew.qualcomm.com/jsp/brew/en/press_room/press_releases/2003/07_09_03.html, Accessed July 2007). By mid 2004, about 12 Publishers were granted the status of BGP by Qualcomm in regions such as U.S., Japan, China, Latin America, and Australia (http://brew.qualcomm.com/brew/en/developer/bgp.html, Accessed July 2007). According to Qualcomm, the selection of regional BGPs ensures a constant flow of applications across various regions and helps facilitate the import/export of BREW-based applications across regions around
173 local publishers in a region and encourages other developers globally to supply applications through a region‘s designated BGP.
8.3.2 Constraints
As a certification system, the True BREW program imposes certain constraints on the application developers (certifiees). The certification constrains primarily constitute the requirements for BREW developer registration, testing, and distributing a TRRE
BREW application wirelessly over the mobile operators network. From BREW developers‘ perspective, the constraints were mostly financial. Although there are TBT process and testing associated administrative costs, almost all BREW developers did not seem to refer to it as a major issue. They were in general overwhelmingly concerned with the financial burden of the True BREW program.
The financial cost burden of the True BREW program are broadly classified as development investments, which refer to basic investments for developing a BREW application; and testing costs, which refer to the costs associated with testing and submitting a BREW application for True BREW certification on various devices. As True
BREW certification is mandatory for commercial deployment of all BREW applications, both development investments and testing costs are considered a direct result of the
True BREW certification program.
the world. The BGP model helps international publishers and developers access local operators without legal, financial and operational issues.
174 8.3.2.1 Development Investments
As mentioned above, all BREW developers wishing to commercialize their applications have to register with Qualcomm. As part of the developer registration a developer is required to apply for an Authentic Document ID (ADID) certificate from the
BREW application Certificate Authority, which charges an annual fee to the developer.
Qualcomm has nominated VeriSign as a CA for issuing the ADID to developers. As of
July 2007, VeriSign provided three options for buying an ADID depending on the number of application signings required by a developer. The developer can buy an Authentic
Document ID to ―digitally notarize‖ (digitally sign) 100 applications for $400, or 500 applications for $895, or 1000 applications for $1295142. It should be noted that the fee is annual and the ADID expires every year even if the developer has not used the ADID to sign the purchased amount of ―digital notarization‖.
In addition to the ADID investment, all BREW developers have to buy a mobile device compiler (ARM complier) to generate device executable binary code. While most development platforms provide these compilers, the BREW compiler is licensed
(annually) for $1,500 from ARM Ltd143.
According to some developers, the costs are especially an issue for a new
BREW developer. One BREW developer noted –
―…you can think of [development costs] as the rent for the office space and forget about it…starting out might be an issue but if you are able to sell a handful of applications the investment is easily recovered…‖
142 Available from http://www.verisign.com/products-services/security-services/code-signing/brew- document-ids/index.html, Accessed July 2007 143 For Details see http://www.arm.com/products/DevTools/RealViewForBREW.html, Accessed July 2007
175 However, the development investments in the ADID and the BREW compiler are unavoidable for all developers. A BREW developer who is unable to make these development investments will not be able to sell the application at all. In that sense they can also be referred to as opportunity costs for a BREW developer.
8.3.2.2 True BREW Testing Costs
Once a developer has made the necessary development investments and developed a BREW application, the developer has to incur various additional costs for testing and certifying the BREW application on mobile devices.
First, a BREW developer has to test the application on actual devices. The
BREW SDK (freely available for all developer) provides a BREW device ―emulator‖ that emulates the behavior of a BREW compliant device on a desktop for application testing purposes. However, according to the interviewed developers, the BREW emulator is often not sufficient to test the execution of the application. The application has to be tested on actual devices to test proper application behavior. All developers interviewed bought several BREW compliant mobile device models to test the BREW application.
CEO of a developer explained the cost issues in detail -
―…it‘s always a safe bet to buy all handsets that your application targets, given that TBT runs on handsets on a live network. Now there are two issues here…one is that every handset costs…and second is that you have to buy a voice and data [network] plan for all handsets to be able to pre-test for TBT…agreed you get a discount on a handset if you buy a voice and data plan with it, but then the plans come with a contract. Now even if you are looking for about 10 handsets, which is a good start for a small developer, your monthly costs can be $500 to $600…if you expand your business and try targeting more handsets, say a hundred, the costs are multiplied‖
176 Second, a BREW developer pays for the True BREW testing for commercial deployment. Initially the testing costs used to vary by the complexity of a submitted
BREW application. According to a developer, the price used to vary from $750144 to
$2,500145. However, later Qualcomm standardized the testing fee for all application types. As of July 2007, a complete TBT for all applications cost $700. The testing fee for various certification options and their associated qualification conditions are presented in the TBT fee structure shown in Table 8-1.
Table 8-1: True BREW Testing Fee Structure146 Certification Conditions Testing Option Fee147 Complete TBT 1. A new application never previously submitted; $700148 only for the first device model 2. A modified version of an application previously submitted; only for the first device model 3. Any application for a pre-commercial device model Partial TBT 1. A new application that passed the first device $250 model; for every additional device model 2. A modified version of an application previously submitted that passed the first device model; for every additional device model Self-Test 1. A new application never previously submitted; for $160 all device models except pre-commercial 2. A modified version of an application previously submitted; for all device models except pre- commercial
In addition to the financial costs of procuring devices with network plans and the application certification fee, some of the developers also highlighted TBT processing time impact on their business. Qualcomm has only authorized NSTL as a third-party test
144 for basic API functionality such as directory and data access 145 for applications using network for data, SMS, phone calls, and location 146 Source: True BREW® Test Submission Guide, Qualcomm, 80-D7258-2 Rev. A, April 23, 2007 147 Per device model 148 Until end of 2006, the Complete TBT Fee was $1000 per device
177 lab for True BREW testing and certification. According to a Qualcomm representative interviewed, the decision to authorize just one third-party test lab was driven by ―the need to control testing costs‖, ―treat all applications in a similar fashion‖, and ―NSTL‘s ability to scale application testing loads‖. A couple of developers noted otherwise. One developer stated –
―…I think everyone is working hard to speed up the process, but our inability to speed up certification under tight deadlines surely hurts…but I think it‘s a necessary evil [that] doesn‘t hold us up for more than a week mostly…‖
In general, from a BREW developer‘s perspective, the True BREW constraints were mostly financial (development investments, device procurement costs, recurring network plan costs, and TBT fees). Although a couple of developers noted TBT process and testing associated administrative costs, most interviewed BREW developers did not seem to refer to it as a major issue. They were in general overwhelmingly concerned with the financial burden of the True BREW program.
8.3.3 Benefits
True BREW as a certification system provides a set of benefits to encourage
BREW developers to certify their applications. A certification system has to provide incentives that in some way outweigh its imposed and mandated requirements and costs for the successful adoption of the certification system. In the case of BREW, as certification is compulsory for all commercial BREW applications, the adoption of the
True BREW certification program is synonymous to the adoption of the BREW platform itself.
178 The benefits of the True BREW program, according to a Qualcomm representative were three-fold. First, the program guaranteed ―a level of trust‖ that an operator could place on a certified application. The certified applications are considered
―secure and stable‖ by the mobile operator and ―that it will not harm the network‖.
Second, the certified application meets a ―base-line quality‖ that ―operators have always expected from applications‖. Finally, the program also guarantees that an application will execute appropriately on a particular ―platform [mobile device]‖ and provide the intended functionality. The security, quality, and functional compatibility guarantee provided by the certification program not only benefits the mobile operator, but also the developer who is
―better able to sell‖ their applications to mobile operators.
According to the developers, on the other hand, the benefits were much broader as the True BREW program was mandated by Qualcomm to commercialize all BREW applications. One developer commenting on the observable benefits of the True BREW program noted –
―…you cannot talk about the real ‗benefits‘ of the program without looking at the what benefits Qualcomm offers for developing applications on the BREW platform, because certification is absolutely mandatory for selling all BREW applications‖
When developers were asked about benefits for developing BREW applications, the developers highlighted the clear role of Qualcomm in assisting developers to develop and commercialize BREW applications. All developers acclaimed the Qualcomm‘s efforts in streamlining and organizing application distribution channels. According to one developer –
―One of the most important reason we started developing BREW games was the simplicity of distributing our applications through [BREW licensing] carriers…‖
179 Further, developers pointed to the advantages of the BREW developer extranet that is regarded as a central information repository from development to commercial distribution. One developer comparing the BREW developer extranet resources to other platforms stated –
―BREW distribution is so much more easy to comprehend and work with…because all you need to know about selling your application comes from one source…everyone you talk to [to sell an application] can be on the same page‖
And another developer highlighted the importance of detailed specifications of existing and upcoming BREW compliant devices –
―…every device has its own form factor and nitty-gritty variations…having all the device details from one source [BREW Developer Extranet] saves us a lot of time and money on market research‖
Another benefit commonly reported by most developers was the ability to extract a greater revenue share of an applications sale to the end-user. Qualcomm essentially mandates the revenue sharing for all BREW applications, where the developer gets an
80% share of the application‘s price. Some developers compared this to, often meek, gains from applications of other platforms.
―Why do we make applications in spite of the testing overheads? Because, BREWs across the board 80-20 is much more effective than [Java ME‘s] 50-50‖
Some developers also pointed to the benefits of application marketing tools, support, billing and revenue sharing process defined by Qualcomm.
8.4 Market Effects of True BREW: A Discussion
As mentioned above, the True BREW program is tightly integrated with the
BREW platform and is mandated by Qualcomm for commercializing all BREW
180 applications. This tight integration of a certification system with a platform has influenced the BREW applications market in a unique way by defining how applications are developed, tested, deployed and distributed to eventual end-users. A consensus in the interviewed key experts suggests that the tight integration of True BREW program with the BREW delivery system is a source of commercial strength for the BREW platform.
According to this expert viewpoint, in essence the program has effectively streamlined application commercialization. Most, if not all, interviewed key informants seemed to agree that such benefits were real and lucrative. In this section, taking a unified key expert and informant viewpoint, I discuss the impact of the True BREW program and
Qualcomm‘s role in ensuring the deployment compatibility of BREW applications. I then outline some of the implications of the program for BREW application developers and publishers.
8.4.1 Deployment Compatibility
Since the introduction of the BREW platform, one of the major concerns
Qualcomm address was the consistent implementation of the BREW platforms.
According to a Qualcomm representative, had designed BREW as an ―integrated solution‖ that could be consistently implemented across various BREW enabled mobile devices so as to allow ―seamless delivery and deployment of [BREW] applications over mobile carrier [operator] networks‖. Given this vision, Qualcomm has assiduously worked towards ensuring application deployment compatibility.
Qualcomm has ensured that backward compatibility maintained in all BREW platform versions. Backward compatibility allows applications designed for previous
BREW versions to be deployed on devices implementing newer versions. Further and
181 more importantly, Qualcomm centrally controls BREW platform implementation and firmware upgrades by BREW licensing device manufacturers. As mentioned above, through its ―Handset Readiness‖ Qualcomm provides a roadmap for device releases and upgrades by different device manufacturers. The program classifies BREW enabled device models at different compatibility levels of BREW implementation (RR1 and RR2 devices). This helps BREW developers to identify which devices their True BREW certified applications would be compatible with. Additionally, the Handset Readiness program aides BREW developers in distinguishing between devices that would need complete TBT or partial TBT for True BREW certification. This allows a developer to plan and control for application design and testing for deployment across targeted devices.
BREW application testing and/or application porting costs for deployment on multiple device models, is hence kept under check. It should be noted that although BREW applications are tested and True BREW certified for a particular device model, most devices models only need partial TBT testing, while some devices no additional testing for a True BREW certified application on a compatible device.
Furthermore, according to many developers the True BREW program quite comprehensively tests application functionality, stability and Over-The-Air deployability of BREW applications. The Application Specification Document required at the time of
TBT submission provides an application‘s functional specifications that are used to test the application on actual devices for True BREW certification. Any issues of applications functional compatibility or deployability are either noted or fail the BREW application for certification. In addition, the implementation of the BDS application delivery system by network operators ensures that the True BREW applications are secure, stable, and deployable on BREW enabled devices. Operators do not have to invest in retesting the applications. In cases where operators have additional requirements Qualcomm collects
182 and disseminates the information to BREW developers. This helps the developer in addressing operator application requirements in design allowing them to deploy the same True BREW certified application across different mobile operators.
In summary, Qualcomm has kept the deployment compatibility in check by maintaining backward compatibility of BREW versions, tightly controlling the device implementation of BREW, and comprehensively testing application functionality, stability and Over-The-Air deployability through the True BREW program.
8.4.2 Implications for Application developers
From the application developers‘ perspective, the implications of the True BREW program are closely associated with the architecture of the entire BREW package. The
BREW application development market since BREW‘s launch has been shaped by the
BREW Delivery System and the True BREW program. In that sense, it is difficult to assess the implications of the True BREW program without considering the overall context of BREW development. Hence, in this section I discuss how the BREW application market conditions have evolved from the perspective of the BREW application developers.
In terms of entry barriers, most developers suggested that development investments and the financial costs of certification could act as a market entry deterrent for a new developer.
The developers, in general are unable to avoid the True BREW certification costs as the True BREW program is universally mandated by BREW application-distributing mobile operators. Essentially the developer has to play by the True BREW rules to enter the BREW application market and make a sale. A market entrant hence would be forced
183 to address these costs upfront, which can be especially challenging as the testing costs can easily go up to tens of thousands for an application. Further, the developers reported that the testing fee hasn‘t reduced at all since True BREW‘s inception149. Most developers pointed to the lack of competition between ATLs as only NSTL was authorized to test BREW applications.
Further, a market entrant typically does not have the requisite knowledge or the devices to pre-test the application for certification, which can lead to certification failures.
A developer recollecting their initial period as a BREW developer stated -
―…we had a number of [application] failures initially mostly because we didn‘t know how to pre-test for certain tests…well we didn‘t even have all the handsets…‖
Every time an application fails, the testing costs accrue and the application release gets delayed. A market entrant hence has to learn though trial and error, while competing with incumbent developers.
Furthermore, the True BREW program does not provide any special certification options or considerations for new developers. Although Qualcomm has introduced changes to the process such as the pass-with-notes application status and partial and self testing options, the developer noted that the changes were geared towards and beneficial for established high-volume developers. The cheaper self-test certification option, for instance, is only available for high-volume application developers who are
―Select‖ or ―Elite‖ members of the BREW Alliance program, which have an associated subscription fee. In a sense, this further tips the balance against a market entrant.
On the flip side, however, a representative from Qualcomm claimed that True
BREW provides a ―level playing field‖ for all developers by providing a an industry
149 Only recently (April 2007), the TBT fee was reduced to 70% by Qualcomm and NSTL.
184 accepted standard of application quality and security. The developers can hence effectively compete by providing ―innovative applications‖ without struggling with quality, security, and compatibility concerns. Further, developers get up to 80% of the True
BREW certified application revenues from the end-user, which from a developer‘s perspective is a relatively attractive revenue model compared to other platforms such as
Java ME.
In addition to market entry barriers, it seems that the BREW applications market has become more consolidated. Developers reported that the True BREW program has to an extent indirectly encouraged BREW application market consolidation.
Again, developers referred to the self-test certification option for high-volume developers as a consolidation enabler that bolsters economies of scale for a few high- volume developers allowing them to outcompete or even acquire smaller developers.
Further, Qualcomm has developed stronger ties with selective application developers and publishers through its Alliance program. Qualcomm through the Alliance program provides priority access to pre-commercial BREW devices, technical support, and cooperative application marketing through operators.
Further, Qualcomm has also established the BREW Global Publisher program
(BGP), through which they identify and partner with established local application publishers of a particular region. According to Qualcomm, BGP is designed to promote and support local developers with ―sufficient knowledge and expertise‖ to develop their own applications, as well as supply applications developed by others from around the globe to their local regions. Qualcomm considers many factors for a developer/publisher to become a BGP including staff capability to deal with international developers, proven track record and relationship with local operators, financial stability, and strong support for BREW relative to other platforms. According to a few developers, the BGPs are given
185 preferential application distribution rights. A European BREW developer exploring the
BGP program also suggested that the conditions for BGP designation are ―suitable for a few large developers as opposed to smaller developers‖. Although the BGP program encourages market development in various regions, in the absence of similar programs for smaller and less established developers, the competitive landscape of the global
BREW applications market is tipped in favor of established larger application developers and publishers. In that sense, the Qualcomm has, at least, indirectly facilitated consolidation in the BREW applications market.
Chapter 9
Cross Case Comparison
In previous chapters I individually examined three different platforms and their certification programs in the mobile applications market. The cases also presented some of the effects of platform certification programs as experienced and perceived by both certifiees and certifiers in the context of mobile applications market. However, the cases primarily highlighted the effects within the domain of a particular platform-based application market. In order to better understand the effects of platform certification in the mobile applications market, it is essential to compare and contrast the observations across the three platforms. In this chapter I draw on the findings from the individual cases and apply the conceptual framework to assess platform certification programs and evaluate their effects on the mobile applications market. I then revise the initial conceptual framework to describe the market effects of platform certification in the mobile applications market. In order to theorize my findings I particularly draw on interviews of key informants (developers) with experiences across the three platforms.
The chapter is structured as follows. I begin by outlining some of the key observed similarities across the three platforms and their certification programs to form a comparative foundation. Following that I compare and contrast the three platforms and their certification programs along the constructs outlined in the conceptual framework. In particular, I refine the key attributes of a certification system along which the certification programs can be differentiated. Specific operationalizations of the attributes in the context of mobile applications market are also discussed. Based on the assessments of
187 the certification programs along the identified attributes, the chapter then assesses their effects on the mobile applications market across the three platforms.
9.1 Similarities across Cases
The three cases essentially represent three distinct markets as application developers typically compete for application deployment on devices that implement the platforms used for developing applications. Although distinct, there are contextual similarities in application development, deployment, and distribution across the three markets. In this section, I identify some of the similarities in the technological underpinnings and business models across the three markets. I first highlight the similarities across the three platforms and then present the commonalities in the administration of their certification programs.
At their core the three platforms are quite similar in scope. All of them provide a design-architecture with a standardized set of Application Programming Interfaces
(APIs) that form the basis of application development. The platforms also provide the developers with an integrated production environment, which isolates applications from technological variations in the underlying computing components such as device processor, memory, display, and input modules, as well as network connectivity components such as SMS, WAP, Bluetooth, and WiFi. In that sense, the platforms are essentially ―developer-facing‖ tools that facilitate the development of complementary applications by streamlining the development process.
In terms of certification as well, the three cases exhibit a range of similarities in their scope. All of them certify mobile applications (a product) for distribution on mobile devices implementing a particular platform. The certifications are also applicable across
188 the global platform-specific applications market and are not restricted by regional or national boundaries. Further, all the certification programs certify applications based on a mix of performance-based as well as prescriptive criteria. The performance-based criteria screen applications for security, quality, and stability on various configurations of specific device models; whereas the prescriptive criteria assess conformance to basic usability guidelines and/or access to potentially sensitive platform interfaces (APIs).
In addition to the similarities in scope, the certification programs are also similar in the way the programs are managed.
Firstly, all three certification programs use a form of authentication framework for developer identity management. The programs use digital certificates to associate the developers with their applications. Developers wishing to certify applications have to verify their identity with a digital certificate authority (such as VeriSign, Geotrust and TC
TrustCenter) that issues digital certificates for digitally signing applications. Using the identity management framework all certified applications can be traced back to the developer. Certified applications can also be blocked or revoked if later found to be misbehaving or malicious. According to the representatives from the certification program offices, this builds trust and accountability across the mobile value chain and provides a framework for application developers to build a brand image circumventing the issues raised by counterfeit software.
Secondly, all the certification programs define a minimal quality threshold.
Extensive in-depth testing of applications is avoided in favor of simple ‗black-box‘ testing.
According to the certification program offices, extensive testing is avoided as – 1) it entails requiring the developers to submit their source-code, which can lead to intellectual property disputes with the developer; and 2) it can easily lead to subjective assessment of quality and undermine the objectivity of the certification program. On the
189 other hand, having a minimal quality bar for the application enables the buyers
(distribution channels such as mobile operator, device manufacturers, and application publishers) to build on top of the certification program and institute additional checks if required. This establishes the certification program as the common baseline for application testing, which avoids application re-testing by different buyers and can hence potentially save developers re-testing costs.
Finally, the platform promulgators as certification agencies outsource the testing component of certification to authorized third-party labs. The third-party labs conduct application testing against the certification-agency-defined testing criteria and directly bill the developers. The platform promulgators do not financially gain from the lab-developer testing transactions. According to the platform promulgators, this facilitates an unbiased assessment of application‘s conformance to the certification criteria and enhances the certification program‘s credibility and integrity.
In summary, platforms as standardized architectures provide an integrative framework for production of complementary applications. Further, across the three cases, platform certification assumes a regulatory function in the supply of mobile applications, wherein applications are differentiated along a minimal quality threshold, developers are held accountable, and platform promulgators attempt to enhance the certification program‘s objectivity and credibility.
9.2 Differences across Cases: Authority Structure Re-Conceptualized
In spite of the common themes there are differences across the three cases.
Firstly, the platforms in themselves differ in terms of their potential capabilities. Symbian, for instance, is a mobile operating system designed for mobile devices with relatively
190 high processing power (also referred to as Smartphones). BREW and Java ME, on the other hand, are middleware platforms for mass mobile devices with relatively low-end processing capabilities.
Secondly, the platform promulgators have different value propositions for mobile value chain actors. Although Qualcomm, Sun, and Symbian as platform promulgators attempt to provide value across the mobile value chain to enhance their platform‘s adoption, they primarily target different sets of actors. For instance, Symbian primarily attempts to leverage allegiance from various mobile device manufacturers, while
Qualcomm primarily markets BREW to mobile operators. On the other hand, Sun primarily targets the allegiance of an already large installed base of desktop Java application developers.
In terms of certification, the differences across the three cases are more systematic. The platform certification programs differ in the way they are designed and managed by the platform promulgators (certifiers). In other words, the Certification
Authority Structure varies across the three programs.
In order to understand the nuanced differences through intra-case analysis, three different components of Certification Authority Structure emerged – 1) Certification
Control Structure, which describes the certifier-instituted policies, processes, and requirements for certification; 2) Certification Coerciveness, which describes the level of certification enforcement and mandates imposed by the certifier; and 3) Certification
Flexibility, which describes the certifier‘s inclusiveness in attracting diverse potential
‗certifiees‘. Together these attributes describe the Authority Structure of a certification system in terms of the control and coerciveness exercised by the certifier and the flexibility the certifier provides to potential certifiees to encourage certification access to diverse certifiees for adopting the certification program. The following sections discuss
191 the specific operationalizations and assessments of each of these constructs in the mobile applications market.
9.2.1 Certification Control Structure
The control structure describes the way a certifier or certification agency manages the certification system. The control structure primarily described the mechanisms through which the certification agency relegates authority to the stakeholders of the certification system. This primarily includes building credibility by identifying, authorizing, and defining the accountability of third-party testing labs. In addition to relegating authority, the control structure also describes a certification agency‘s role in establishing certification requirements; ensuring availability of certification testing documentation, equipment and tools; and possibly ensuring the uniform treatment of certified products by various stakeholders in the product market.
The control structure can be centralized, as opposed to distributed, where the certification agency plays an active role in authorizing and controlling certification labs, developing/sharing certification requirements and equipment, and defining the way certified products are treated by various buyers and distribution channels. In the mobile applications market, the platform promulgator acts as the certification agency, where they either actively control all operational aspects of certification, or outline and relegate its operational control to external certification labs and other stakeholders.
192 9.2.1.1 Certification Control Structure: A comparison across platforms
In order to describe the control structure of the mobile application certification programs, I relied on the insights provided by the key experts of the certification systems. Again the insights were further corroborated by key informant experiences in certifying applications.
The True BREW certification program can be described as a highly centralized control structure for three reasons. First, Qualcomm as the certification agency for the
True BREW program has only authorized one certification testing lab (NSTL). According to key experts at NSTL, Qualcomm played an active role in pricing policies for testing and retesting applications. Although NSTL could recommend pricing policy changes,
Qualcomm had the ―final say‖ on certification pricing150. Further, Qualcomm also provided access to the necessary infrastructure for certification testing such as BREW‘s over-the-air download server and commercial as well as pre-commercial BREW compliant devices. Second, Qualcomm provides an authenticated information repository for BREW developers (the BREW Developer Extranet), which acts as a central source of application development, testing, certification, and distribution information. For instance, a developer can access detailed BREW compliant device specifications and mobile operator guidelines and requirements for application developing as well as testing and deployment of BREW applications. Third, a True BREW certified application functions consistently across the tested devices. According to developers, Qualcomm plays an important role in ensuring consistent functionality of a certified application across various device models. Qualcomm achieves this by tightly managing the device compliance to
150 In 2007, Qualcomm reduced the certification testing price from $1000 to $700 (for complete TBT).
193 the BREW platform (―Handset Readiness program‖), as well as by defining platform integrated application security framework, which allows uniform access to BREW APIs on BREW compliant devices.
Symbian Signed, like True BREW although somewhat less, also has a centralized control structure, wherein Symbian plays an active role in authorizing certification labs, developing/sharing certification requirements and equipment, and controlling the way certified products are treated by Symbian compliant devices and mobile operators. However, Symbian Signed program‘s control structure is somewhat distributed as the program has authorized multiple third-party testing labs for certification testing (three). According to Symbian Signed key experts, the primary rationale behind authorizing multiple testing labs was to determine certification pricing competitively. In that sense Symbian Signed program‘s control over certification pricing is quite limited.
Java Verified, unlike True BREW and Symbian Signed, has a distributed control structure, where Sun and the Unified Testing Initiative members (the Java Verified
Program Office or JVPO) play a limited role in the Java Verified program. First, the
JVPO has authorized multiple certification labs (four) for competitive certification pricing.
Second, the Java Verified portal provides limited information about application development, testing, certification and distribution. Although the JVPO lists the Java ME compliant device available for Java Verification, it does not evaluate their compliance to
Java ME or their availability for testing. Finally, according to developers, the JVPO plays little to no role in ensuring consistent treatment of a Java Verified application across various device models and mobile operators. Mobile operators and device manufacturers can alter the Java ME application security policy or even remove the UTI root certificate that distinguishes a Java Verified application from uncertified applications.
In that sense, the JVPO‘s control in uniform treatment of certified applications is
194 distributed to various mobile operators and device manufacturers deploying Java ME applications.
The control structure of True BREW, Java Verified, and Symbian Signed programs and their relative assessment is summarized in Table 9-1 .
Table 9-1: Relative Assessment of Certification Control Structure across Platforms True BREW Java Verified Symbian Signed Control - Certification pricing - Multiple authorized - Multiple authorized Structure control over only one testing labs for testing labs for authorized third-party competitive competitive testing lab certification pricing certification pricing - Centralized - Limited access to - Centralized Authenticated access application Authenticated to application development, access to development, testing, testing, application certification and certification and development, distribution distribution testing, certification information through information and distribution BREW Developer through Java information through Extranet Verified Portal Symbian Signed - Centralized - Distributed Portal evaluation of devices evaluation of - Centralized (and their firmware devices available evaluation of upgrades) available for testing devices available for for testing - Distributed control testing - Uniform treatment of of application - Uniform treatment of certified applications security policy certified applications through common - Distributed through common application security deployment of UTI application security model root certificate model Relative Highly Centralized Distributed Mostly Centralized Assessment
9.2.2 Certification Coerciveness
The coerciveness of a certification system is described by the conditions that either force or encourage sellers to certify their products. To a large extent the coerciveness can be observed by assessing whether certification is mandatory or
195 voluntary. However, assessing and describing the coerciveness of a certification system can be elusive. This is especially true in markets where there is no central regulatory authority that mandates certification for all products. Given the lack of a central regulatory authority the coerciveness of a certification system is contingent upon distributed mandates and requirements of various distribution channels and buyers. In that sense, the coerciveness of a certification system is the sum of the degree of acceptance of the certified product by various key actors in product distribution. The degree of acceptance can be high, if key actors only accept a certified product for distribution; medium, if key actors give preferential treatment to certified products; or low, if key actors accepted certified as well as uncertified products without reservations.
The mobile applications market does not have a central regulatory authority.
Although, platform promulgators are in a position to regulate and centrally mandate a platform certification program, it is not always a viable option due to their conflicting interest in increasing platform adoption by application developers. The coerciveness of a platform certification program is then contingent upon the degree of acceptance of certified applications by various key distribution channels such as the mobile operator, the device manufacturer, and other application distributors and publishers. Given this situation in the mobile application market, it is best to assess the coerciveness of the certification programs through the collective acceptance of various application distribution channels. In addition to distributor acceptance, certification coerciveness can also be observed through the collective distribution experiences of suppliers (application developers). The coerciveness can be viewed as the opportunity cost an application developer faces if they do not certify their products. These costs can come in the form of missed distribution opportunities or inability to seamlessly install and sell uncertified applications.
196 9.2.2.1 Certification Coerciveness: A comparison across platforms
In order to assess the coerciveness of the mobile platform certification programs,
I relied on the trade press articles, as well as subjective assessments by the interviewed application developers. The developers assessed the degree of acceptance by various mobile operators, device manufacturers and distribution channels. Application developers who were developing applications for more than one platform provided primary comparative experiences of coerciveness of the True BREW, Java Verified, and
Symbian Signed certification programs. Their assessments were further triangulated by developers who were developing applications for just one platform, and key experts of the particular certification program.
True BREW certification clearly has the highest degree of coerciveness of the three certification programs. In the case of BREW, Qualcomm as the platform promulgator takes on the role of a central regulatory authority, whereby it technologically forbids commercialization of uncertified BREW applications. A BREW application end- user cannot transact and install an uncertified BREW application. This forces every
BREW developer to go through the True BREW program to commercialize their applications.
Java Verified certification, on the other hand, is not centrally regulated by Sun.
Unlike BREW, Non-Java-Verified applications can be installed on various Java compliant devices (albeit with restrictions). Although, most (if not all) Java ME application publishers recommended Java Verification, only a limited number of mobile operators require/mandate Java Verified certification151. Most mobile operators accept uncertified
151 As of July 2007, Vodafone Europe, Orange, and T-Mobile Europe accepted only Java Verified applications
197 Java ME applications that are internally tested and certified for distribution. Further, all device manufacturers (that implement Java ME) do not require Java Verified certification for distribution through device shipments (albeit a majority do require152). As uncertified
Java ME applications can be distributed and sold to the end-users, and in that sense the
Java Verified program has a lower degree of coerciveness in comparison to the True
BREW program.
Finally, the Symbian Signed certification program can be described as having a medium level of coerciveness. Symbian Signed certification is an absolute requirement for only certain types of applications – those that access ‗sensitive‘ Symbian APIs.
Symbian technologically necessitates Symbian Signed certification for such sensitive applications, while still allowing installation and distribution of uncertified applications that do not use sensitive APIs. Although, most distribution channels (mobile operators, device manufacturers, and publishers) recommended Symbian signing for all applications, it is not a mandatory requirement for applications that do not access
‗sensitive‘ APIs.
The coerciveness of True BREW, Java Verified, and Symbian Signed programs and their relative assessment is summarized in Table 9-2 .
152 These include the UTI member device manufacturers such as Nokia, Motorola, Sony- Ericsson, LG, and Samsung, which constitute the majority of Java compliant devices available in the market.
198
Table 9-2: Relative Assessment of Certification Coerciveness across Platforms True BREW Java Verified Symbian Signed Coerciveness - Universal Mobile - Majority Device - Universal Mobile Operator and Manufacturer Operator and Device Device Acceptance Manufacturer Manufacturer - Limited Mobile Acceptance for Acceptance Operator ‗sensitive - Universal Acceptance applications‘ Requirement for - Recommended by - Recommended for all Commercial all Distribution applications for Distribution153 channels Distribution Relative High Low Medium Assessment
As a clarifying aside, it should be noted that although control structure and coerciveness of the three cases seem to co-vary, these concepts are distinct and mutually exclusive. For instance, a certification program can be highly centralized, yet minimally coercive. In such a case the certification agency would play an active role in authorizing and controlling certification labs, developing/sharing certification requirements and equipment, and defining the way certified products are treated by various distribution channels; and yet keep certification voluntary. In other words, it is perfectly plausible that in spite of centralized control of certification agency, distribution channels accept certified as well as uncertified products without reservations.
9.2.3 Certification Flexibility
The flexibility of a certification system describes the way a certification agency encourages certification and provides certification access to diverse set of suppliers and their products. Certification flexibility can be operationalized in terms of the availability of
153 Note: BREW only allows OTA (Over-The-Air) distribution through Mobile Operator networks
199 certification options/mechanisms and special provisions/considerations/support for certifying different product types from a diverse set of suppliers.
A certification system‘s flexibility can be high if the certification agency provides special provisions to diverse suppliers and products for certifying products, as opposed to low where the certification agency provides a single route to certification for all types of suppliers and products.
9.2.3.1 Certification Flexibility: A comparison across platforms
In order to assess the flexibility of the mobile platform certification programs, I primarily relied on the subjective assessments by the interviewed application developers.
Their assessments were substantiated by the key experts of the certification programs.
The unified key informant and expert viewpoints suggests that the Symbian Signed program has a high degree of flexibility for two reasons.
First, the Symbian signed program attempts to address requirements of different types of application developers. The program does this by providing special provisions for different types of developers. For instance, High-volume application developers can use self-certification option and reduce certification delay and costs, while smaller developers can use the publisher-certification option to avoid ACS Publisher ID costs.
Further, device manufacturers and network operators who develop application in-house can use channel-certification option to avoid certification delays and costs. Second, the
Symbian Signed program also provides a special mechanism to promote diverse applications. For instance, freeware applications are provided a special certification route; and certification testing can be waived for certain applications through a certification waiver mechanism.
200 Java Verified, on the other hand, does little to address different needs of diverse developers and applications. All types of developers have to certify through the third- party certification route. No special provisions are provided for different developers or different applications. According to a developer, Java Verified has a ―broad brush‖ approach to certify all types of Java developers and applications. In that sense, the Java
Verified program is a less flexible certification program in encouraging inclusiveness of diverse applications and developers.
Finally, the True BREW program can be classified as having medium flexibility.
The program provides certain mechanisms for differing needs of diverse application developers. For instance, it provides special certification provisions for high-volume application developers through its self-test program. However, it does little to encourage low-volume developers who cannot avoid or reduce certification fees. Further, the True
BREW program provides a ―pass-with-notes‖ status for certain applications giving more flexibility to application developers for commercializing applications. However, True
BREW program does not provide special provisions for non-commercial applications.
The Certification Flexibility of True BREW, Java Verified, and Symbian Signed programs and their relative assessment are summarized in Table 9-3.
201
Table 9-3: Relative Assessment of Certification Flexibility across Platforms True BREW Java Verified Symbian Signed Certification - Special - Only Third party - Special certification Flexibility certification certification option provisions for high- provisions for for all types of volume as well as smaller high-volume developers application developers application - No special - Special certification developers provisions for provisions for device - No special diverse manufacturer and provisions for applications operator applications certifying non- - Special provisions for commercial non-commercial applications (freeware) applications. - Provision for certification waiver Relative Medium Low High Assessment
9.3 Market Effects of Platform Certification
Platforms as technological architectures form the basis of production for complementary products. They define the conditions under which platform-based products are developed, distributed and consumed. Hence, a certification system designed for a platform potentially has implications for the market of platform-based products.
I have thus far examined the similarities in scope of platforms and their certification programs across the three cases. I have also highlighted some of the core differences in design and management of the three certification programs. In this section, I examine some of the implications of platform certification for the complementary product market of mobile applications. I specifically highlight the effects of platform certification on the design, deployment and distribution of mobile applications, as well as its influences on the evolving competitive landscape for the
202 mobile applications developers. In doing so, I evaluate the applicability of the conceptual framework outlined in chapter 4 for the mobile applications market and present a revised framework for describing the market effects of mobile platform certifications.
9.3.1 Effects on Platform-Based Products
Mobile applications are the core mobile computing platform-based products.
They complement the underlying platforms and rely on them to achieve their intended functionality. In order to leverage the capabilities of the underlying platform the mobile applications have to be compatible with the varying implementations of the platforms on mobile devices.
From a system‘s view, the application, platform, and the platform implementing device together form an interdependent system with modular subsystems. Any inconsistency in the specification, implementation or usage of any modular subsystem within this interdependent system can lead to, what is called vertical incompatibility. An application designed for a particular platform, can be rendered incompatible with the underlying subsystem if the platforms are not correctly specified, implemented on devices, or inappropriately used by the application. Application certifications by platform vendors can be critical in ensuring the appropriate functioning of the entire device- platform-application system. In that sense, platform certification can be viewed as a post-design mechanism that can potentially ensure compatibility between the vertical modular subsystems.
All the platform certification programs attempt, at least to some extent, to assess this vertical compatibility. Although the primary objective of the certification programs is ensuring application quality and security, they also assess application stability on
203 specific device models implementing the platform. All the certification programs impose constraints on the applications through the certification criteria that outline a battery of tests to ensure that the application is able to install and execute error-free without
―crashing‖. However, vertical compatibility achieved by a certified application is limited for two reasons. First, the certification programs are only designed to certify an application on a particular mobile device model. This does not guarantee vertical compatibility of the application with all platform-implementing mobile devices.
Essentially, by certifying applications for a particular device model, the certification programs forgo the potential opportunity for assessing vertical compatibility across multiple platform-implementing mobile devices. Second, the certification programs do not examine the source-code of the mobile applications. Extensive in-depth testing for compatibility, hence, is challenging and often not possible. The result is that certification programs can only guarantee a minimal level of vertical compatibility of certified applications with just one particular device model.
In the conceptual framework, I had expected that platform certification programs through their certification criteria would be able to address the vertical compatibility of certified platform-based products (Proposition 1154). Although the certification criteria of the three mobile platform certifications enhanced the vertical compatibility of certified applications, they only guaranteed a minimal level of compatibility without comprehensively assessing compatibility for all platform-implementing device models155.
154 Proposition 1 stated – ―A positive relationship exists between the level of certification constraints, specifically certification criteria, and the level of vertical compatibility in the platform- based product market‖ 155 It should also be noted that in the case of software products, comprehensive testing for compatibility or compliance is often impractical due to the products‘ functional complexity. Although behavior of a complex product can be observed under varying conditions, comprehensively replicating different testing conditions might require excessive resource investments, thereby deeming the practice impractical.
204 Hence, the evidence to support Proposition 1 is limited. This limited support for
Proposition 1 is therefore shown as a dotted line in Figure 9:1.
Certification Authority Structure
Control Structure + P2 + No Support
Certification Vertical + Constraints P1 Compatibility Limited Support Figure 9:1: Platform Certification Effects on Vertical Compatibility in Mobile Applications Market
Despite the minimal compatibility guarantee, the cases highlight that differences in the design and management of certification programs influence vertical compatibility of platform-based products. The primary force that seems to influence vertical compatibility is the certification programs‘ control structure. The developers who developed applications for all the three platforms indicated that certified BREW and
Symbian applications were more compatible across different device models, whereas
Java Verified applications often did not even install or execute appropriately on different
Java compliant devices.
According to the developers the Java Verified applications were often incompatible across devices for two main reasons. First, Java ME has many API specification packages that are implemented by device manufacturers on various mobile devices on an as-needed basis. The Java Verified program does not assess Java ME‘s implementation on mobile devices. Although the Java Verified program group similar
Java compliant devices into ―families‖ based on device manufacturer recommendations,
205 developers reported that applications that are certified on a family‘s lead device sometimes give errors on the family‘s member device. In other words, Java ME implementation assessment is distributed across various device manufacturers, which undermines the degree of compatibility achieved by the Java Verified program. Second, the network operators often alter the Java-Verified-recommended application security policy on Java ME devices. This creates inconsistencies in Java Verified application installation and execution on a mobile device on different networks. Again, the Java
Verified program does not centrally mandate an application security policy, which creates compatibility issues on the same device across different networks.
BREW, and to an extent Symbian, provided a tighter integration in the application-platform-device system. Qualcomm, for instance, licenses the BREW platform as an integrated package and manages the release of BREW compliant devices by device manufacturers through its ―Handset Readiness‖ program. In addition to testing BREW implementation, the handset readiness program tests the backward compatibility of a BREW application with the BREW implementation on new device models. Further, Qualcomm provides an integrated application distribution system (BDS) to BREW licensing network operators. The operators cannot alter the application security policy as part of the licensing agreement. This effort to some extent ensures that a certified application installs and executes appropriately on a device across different networks. In that sense, a platform vendor‘s centralized control over unified specification, device implementation, and network‘s application security policy has a positive effect on application compatibility.
In essence, the control structure established by the platform promulgator provides limited room for application incompatibility. Hence, in spite of the limited compatibility guarantee of certification constraints, the certification authority structure,
206 specifically certification control structure, positively influenced vertical compatibility of certified applications. In that sense, Proposition 2156 of the conceptual framework is modified to show direct impact on vertical compatibility in the mobile applications market.
This is shown as a solid line in Figure 9:1.
9.3.2 Effects on Platform-Based Product Market
Thus far I have focused on the effects of platform certification on the design, deployment and distribution of mobile applications by examining the vertical compatibility of complementary applications. In this section, I examine the broader influences of platform certification programs on the structural conditions that define the commercial opportunities and evolving competitive landscape for the mobile application developers.
One of the most fundamental influences of platform certification on the mobile value chain has been to integrate market transactions between application suppliers and buyers. Prior to the introduction of certification, mobile application developers as suppliers transacted directly with application distribution channels such as the network operator, the device manufacturers, and publishers to reach the end-user. Every distribution channel had its own set of requirements and definition of a ―quality‖ application. The application developers typically tested their applications to adhere to requirements of distribution channels on a case-by-case basis. Economies of scale across the distribution channels were limited. Application certification initiatives by platform vendors integrated some of the core testing requirements of various distribution
156 Proposition 2 stated – ―Given a higher level of certification constraints, a strong authority structure will further enhance vertical compatibility in the platform-based product market‖
207 channels. In that sense, platform certification to an extent reduced the transaction costs in the mobile applications market.
However, certification programs impose certain constraints on a potential certifiee. These constraints have impacted the competitive conditions for the application developers. As discussed in the previous chapters, constraints such as the certification process and certification criteria have associated administrative and financial costs for the developers. According to the developers across the cases, the financial costs of certification were especially burdensome for their market operations and profitability.
Firstly, the financial costs of certification across the three cases were too high in comparison to other development investments. The costs were high primarily due to the fact that applications were certified for a particular device. Developers typically certified the same application for multiple devices. With the increasing number of new device models introduced in the market, certification has become a costly affair. Some developers also reported that certifications often cost them more than traditional investments and recurring costs of testing tools, infrastructure, and internal quality assurance management. Table 9-4 summarizes the range and average cost of certifying an application for a particular device.
Table 9-4: Platform Certification Program Pricing157 Platform Certification Application Certification Price per application per device Program Range Average Price True BREW $ 700 $ 700 Java Verified $ 225 - $ 750 $ 450 Symbian Signed $ 270 - $ 800 $ 535
157 Source: Program sponsor websites and own calculations, accessed May 2007
208 Secondly, the financial costs of certification vary for different types of developers.
Certification costs are especially problematic for smaller low-volume developers who developed a handful of applications. A typical application has multiple versions for every device model. As the number of targeted devices of an application to reach the intended consumer segment increases, the certification costs sky rocket, increasing the upfront application deployment costs. According to some smaller low-volume developers, the number of targeted handset models typically range from tens to hundreds, creating certification investments of thousands of dollars, which are often much higher than the application development cost itself. On the other hand, the certification costs were somewhat easier to manage for established high-volume developers, who were able to spread the costs over multiple applications by getting volume certification discounts from authorized certification labs158.
From a structural viewpoint, the financial costs of certification might act as entry barriers for a potential market entrant. As certification becomes a de-facto market requirement, an application developer trying to sell a new application is at a competitive disadvantage. A market entrant is typically unable to leverage certification volume discounts, while competing with incumbent high-volume application developers. In that sense, it can be said that certification has raised entry barriers for the supply of mobile applications. In other words, Proposition 3159 of the conceptual framework is supported in the mobile applications market. This corroboration is shown as a solid line in Figure 9:2.
158 It should be noted that the volume discounts are provided by authorized certification labs. The platform promulgators do not require or provide these discounts. Further, these volume discounts are different from the ―self-certification‖ discounts, which are provided by Qualcomm and Symbian for the True BREW and Symbian Signed programs, respectively, as part of the self-test certification options. 159 Proposition 3 stated – ―A positive relationship exists between the level of certification constraints and the level of entry barriers in the platform-based product market‖
209
Certification Authority Structure
Coerciveness Flexibility
+ + P5 - - Partially Supported Certification + Constraints P3 Supported Market Entry Barriers Certification - Benefits P4 Limited Support Figure 9:2: Platform Certification Effects on Market Entry Barriers in Mobile Applications Market
In addition to certification constraints, it was expected that application developers certifying applications will be able to avail certain certification benefits that were not available for developers prior to the establishment of platform certification. According to
Proposition 4160, if the certification benefits were high, they could balance out the costs imposed by the certification constraints, thereby potentially reducing the entry barriers for new developers. However, across the three cases in the mobile applications market, the evidence cannot corroborate the proposition. Although most developers across the cases reported application production and distribution benefits of certification, they did not perceive them to be particularly helpful when compared to the certification costs.
In the case of Java Verified and Symbian Signed programs, the developers reported that although programs aide in streamlining application testing and reducing
160 Proposition 4 stated – ―A negative relationship exists between the level of perceived benefits and the level of entry barriers in the platform-based product market‖
210 testing overhead, the tests are very basic and do little to test the overall quality of an application. Hence, the developers still had to invest in additional application testing before/after certification. On the other hand, BREW developers seem to be more pleased with the production and distribution benefits of True BREW. However, the developers noted that the benefits were tied to the BREW alliance membership and only a handful of established developers could afford to pay the subscription fee for the alliance program. In that sense, the benefits of the certification program were harder to realize for a new BREW developer. As True BREW certification was always mandated by Qualcomm, the developers suggested that a market entrant would face entry barriers that were not completely alleviated by the selective benefits provided through the BREW alliance program.
In essence, the evidence from the three cases provides limited support for the negative relationship between the level of perceived benefits and the level of market entry barriers. Hence, Proposition 4 is shown as a dotted line in Figure 9:2.
Further, across the three cases I observed that the market entry barriers were contingent upon the authority structure of the certification programs. In particular, the certification programs‘ coerciveness and flexibility seemed to play a crucial role in influencing market entry conditions.
Firstly, a higher level of certification coerciveness forces a developer to certify applications for distribution. For instance, True BREW certification is mandatory for all
BREW applications, which leaves no option for a new developer but to certify. A market entrant hence cannot avoid the certification constraints (costs), which in turn serve as entry barriers. On the other hand, if certification coerciveness is lower, the developer can avoid the certification constraints by choosing not to certify. For instance, Java Verified is not mandated by all distribution channels. A market entering Java ME developer can
211 therefore initially avoid certification costs and hence observes lower entry barriers. In other words, certification coerciveness has a positive impact on the effect of certification constraints on market entry barriers. Causally, it can be said that the relation between certification constraints and market entry barriers is moderated by certification coerciveness.
It‘s interesting to note that the variation in certification coerciveness between
Java ME and BREW, at least to an extent, seems to have impacted their respective developer populations. While the Java ME has certainly benefited from the embedded base of desktop Java developers, it is not unreasonable to assume that the relative number of Java ME developers compared with BREW developers (i.e. thousands versus hundreds), is also due in part to lower level of certification coerciveness of the Java
Verified program. In a sense, it can be said that higher levels of True BREW‘s coerciveness has deterred BREW market entry161.
Secondly, the cases suggest that certification flexibility has an opposite influence on entry barriers. A certification program that provides several certification mechanisms and waivers can assist new developers in saving on certification costs. Symbian Signed, for instance, provides certification waivers to applications not using ‗sensitive‘ APIs, while True BREW certifies applications ―with notes‖ to avoid re-certification costs for applications that do not completely meet the certification criteria. The developers suggested that such provisions and waivers eased the certification cost burden. They
161 It should be noted here that market entry barriers are not directly observable in this research. As discussed in the study‘s research methods, direct observation of entry barriers would entail assessment by a sufficient number of potential entrants at the time of their entry. Such a research approach, however, was challenging and also impractical. Thus, several indirect indicators of market entry barriers are used in this study. They include empirical assessments of the perceptions of the level of entry barriers by developers present in the market prior to the establishment of certification programs; comparisons of the numbers of developers associated with each platform; as well as analytical assessments about the plausibility of an effect
212 also noted that such policies were instituted in response to a barrage of developer requests on forums. As these programs have become more accepting and flexible of developer concerns, a new developer today has an easier access to the market.
Although the certification costs are still high, the flexibility of certification, according to the developers has certainly eased the entry barriers. In that sense, it seems that certification flexibility has played an important role in reducing entry barriers for developers.
Hence, for the mobile applications market, it can be said that the effects of certification constraints on market entry barriers are contingent upon the certification authority structure. However, the same cannot be said about the effects of certification benefits on market entry barriers. In that sense Proposition 5162 is only partially supported. To summarize, greater certification constraints in combination with greater certification coerciveness and reduced flexibility result in increased entry barriers for application developers, while reduced certification coerciveness and increased flexibility alleviate the entry barrier effects of certification constraints. Figure 9:2, outlines the corroborated aspects of the contingency as solid lines, while the uncorroborated aspects are shown as dotted lines.
In summary, I have revised the initial conceptual framework to highlight some of the market effects of platform certifications in the mobile applications market. The revised framework is shown in Figure 9:3.
162 Proposition 5 stated – ―The effects of certification constraints and benefits on entry barriers in the platform-based market will be positively moderated by the certification authority structure‖
213
Certification Authority Structure
Coerciveness Flexibility Control Structure
+ - +
Vertical Compatibility
Certification Market Entry + Constraints Barriers
Figure 9:3: Revised Framework for the Market Effects of Platform Certification in Mobile Applications Market
Chapter 10
Discussion
I have thus far examined mobile computing platform certification programs and evaluated their impact on the mobile applications market. In doing so I theoretically outlined, corroborated, and refined a conceptual framework that can be applied to examine the effects of platform certifications in other similar markets. In this chapter I discuss some of the theoretical and practical implications of mobile platform certifications and address their generalizability to similar markets that might potentially exhibit the phenomenon of platform certifications.
I begin the chapter by conceptually comparing platform certifications with other types of certifications discussed in the literature. In particular, similarities with other forms of product certifications, supplier, and third-party certifications are discussed. This essentially positions the research with the extant literature and provides a theoretical basis for generalization. I then discuss the theoretical and practical implications of platform certifications for some of the key actors in the platform-based markets. In particular, I use the Business Ecosystem view of networked industries, to inform, as well as highlight the implications of platform certification for platform promulgators, buyers, intermediaries, and suppliers of platform-based products.
10.1 Conceptually Framing Platform Certifications
Diverse streams of literature have investigated different types of certifications systems such as product, process, and professional in various socio-economic contexts
215 (Albano & Lizzeri, 2001; Boegh, 2006; Dawson & Lewelling, 1991; Franceschini, Galetto,
& Gianni, 2004; Gould, 2003; Inman & Hubler, 1992; Lingenfelter, 1988; Söderström,
2002; Wohlin & Runeson, 1994). Researchers have also examined their implications for different stakeholders (Backhouse, 2002; Bouckaert, 2000; Crain & Wierschem, 2006;
Fuller & Vertinsky, 2006; Kartha, 2007; Lane & Papathanasis, 1983; Parkinson, 1975;
Terziovski et al., 2003). However, little is known about platform certification systems, where platform promulgators certify platform-based products. In order to understand platform certification systems and theorize their implications for platform-complementary product developers, I must first conceptually situate platform certification with extant literature on certification and address certain questions. How are platform certifications similar or different to other known forms of certifications? Are platform certifications really a form of product certifications? What role does the platform promulgator play in platform certifications? How are platform promulgators similar or different to other third- party certifiers?
In this section, I address such conceptual questions drawing from my observations on mobile computing platform certifications. I begin by comparing platform certifications to product and supplier certification systems. Then I discuss the role of platform promulgator in platform certification systems and compare them with other types of certifiers.
10.1.1 Platform Certification and Product Certifications
It can be argued that platform certification, at its core, is a form of product certification. Essentially, platform certification systems certify the platforms‘
216 complementary products against a minimum threshold of standard, be it quality, security, or compatibility.
Extant literature has examined various types of certification programs, where the focal point of assessment is a product (Dawson & Lewelling, 1991; Hansen, 1997;
Lingenfelter, 1988). Many product certification programs are available for a diverse set of products such as industrial equipment, construction material, and household gadgets including lawn movers, washers, dryers, and boilers, to name a few. These product certification programs essentially focus on the conformance of a product to certain standards, codes and specifications. They primarily cover safety and health concerns of products for consumers at large. They are sponsored and managed by various governmental or quasi-governmental institutions such as international standards development organizations and industrial consortia, for the greater societal good.
Examples of such organizations include FCC163, UL164, and standards development organization such as ISO, ANSI, and IEC165.
Mobile computing platform certifications, as such, are quite similar to these product certification programs. As a product certification mechanism, platform certification programs in the mobile industry focus on the platform-based mobile
163 The FCC or Federal Communications Commission is the US federal government‘s regulatory body responsible for regulating the telecommunications industry in the US at large. For more information see http://www.fcc.gov/. 164 The UL or Underwriters Laboratories Inc. is a US-based, privately-owned, non-profit product safety testing and certification organization that develops standards and test procedures for safety of a range of products, materials, assemblies, equipments, and tools. UL is one of the main labs authorized by the federal US government‘s Occupational Safety and Health Administration (OSHA). For more information see http://www.ul.com/. 165 The IEC or International Electrotechnical Commission is an international, non-profit, standards organization that develops and publishes International standards for a wide variety of electrical, electronic and related technologies for home appliances, office equipment, semiconductors, fiber optics, batteries, etc. IEC publishes standards in collaboration with other international standards development organizations such as IEEE, ISO, and ITU. The IEC also manages conformity assessment schemes to certify equipment, systems or components conformance to International standards. For more information see http://www.iec.ch/.
217 application – a product. These programs assess the conformance of an application against certain standards, codes and specifications that cover application security, quality, and vertical compatibility. However, the platform certification programs thematically differ from a variety of product certification programs.
Firstly, applications are certified along dimensions in addition to ―safety‖ or security requirements. Although the platform certification programs include a set of tests to ensure application safety or security on specific devices and networks, they also test for basic functional quality expectations of an application. For example, the three certification programs I studied require application developers to submit a document outlining the intended functionality and expected behavior of the submitted application.
Although the functional tests of the certification programs are by no means comprehensive, according to the certification labs many applications are rejected on their inability to meet the functional promises. In other words, even if an application is deemed secure and safe for distribution, the certification programs can reject them if they do not meet basic quality guidelines of the certification test criteria.
Secondly, as a by-product of quality testing, applications that are not compatible with the underlying implementation of the platform on a device are also weeded out.
Hence, application compatibility, although not directly, is also ascertained by the platform certification programs. It is important to note that platform certification programs act as a mechanism to assess vertical compatibility of applications. Ensuring vertical compatibility of platform implementation and platform-based products is crucial for platform promulgators as platforms exhibit indirect network externalities (Nicholas Economides,
1996; Farrell & Saloner, 1992). However, with the use of platform certification in the mobile applications market, the costs of ensuring compatibility, at least to an extent, are passed down to the application developers. The developers have to ensure the basic
218 vertical compatibility of their applications so that they can be deployed and tested on devices for certification. Although Java Verified doesn‘t directly test for compatibility,
True BREW and Symbian do include application compatibility guidelines for application installation and functionality for eventual certification.
In summary, platform certifications are similar to product certification programs in that the object of certification is a product. However, they can differ from other forms of product certification programs in terms of the dimensions of certification criteria, which can include product compatibility and quality in addition to safety requirements. Although all forms of platform certifications might not cover the different dimensions of certification, the possibility of assessing compatibility in particular can push the compatibility responsibilities of platform promulgators onto the suppliers of platform- based products.
10.1.2 Platform Certification as Supplier Certifications
Supplier certifications have been discussed in the literature in the context of logistics information management, primarily drawing insights from the manufacturing sectors. Supplier certification programs are characterized as formalized mechanisms employed by buyers or manufacturers to assess and benchmark the quality of their suppliers and vendors (Willis & Huston, 1992). It typically ―involves a thorough examination of all aspects of a vendor‘s performance‖ (Lockhart & Ettkin, 1993), and often includes elements of a supplier‘s conformance to process and product quality standards (Inman & Hubler, 1992). The primary objective of supplier certification is to establish strong supplier-manufacturer relationships in order to enhance the level of trust
219 and communication that is essential for facilitating material flows, enhancing end-product quality, and reducing manufacturing costs (Gould, 2003; Grieco, 1989).
Although platform certification is quite similar to various forms of product certifications, they can also exhibit properties of a supplier certification system. It should be noted that platform certifications are not managed by ―buyers‖ per say but platform promulgators. However, I observed similarities at various levels in the three cases of mobile platform certifications.
Firstly, the mobile computing platform promulgators act on behalf of the application buyers such as network operators, publishers, and device manufacturers, to certify applications for effective application deployment and distribution. The programs to an extent assure application security, quality, and vertical compatibility. This can reduce buyer concerns of overall application quality and can potentially form the basis for effective application supply management for the buyers. Platform certifications can hence be viewed as a form of outsourced supplier certification, wherein supplier products are certified by an independent166 third-party – the platform promulgator.
Secondly, the mobile platform certification programs incorporate a mechanism to identify, authorize, and incentivize quality application development. The mobile platform certification programs have established a form of developer identity management through digital signatures, where they are able to trace as well as block misbehaving certified applications and their developers. This holds the developer accountable for their applications. Developers as suppliers are hence encouraged to produce quality applications to not only salvage their reputation, but also to continue supplying
166 As mentioned in previous chapters, Independence refers to the notion that an organization neither directly facilitates nor influences the buyer-suppler transactions. See (Boegh, 2006) for details.
220 applications. In that sense, platform certifications can also be used as a supplier management and regulatory mechanism.
Thirdly, mobile platform certification programs such as Symbian Signed and True
BREW also provide cheaper self-certification option for high-volume developers.
Conceptually, this self-certification option is very similar to supplier certifications, wherein certain developers are approved to self-certify their applications. The high-volume developers that are granted the ―self-certification‖ status are regularly audited by the platform promulgator. In a sense the developer as opposed to their applications are certified. Therefore the certification program seems like a supplier certification program for a group of high-volume application developers.
Given these conceptual similarities some of the implications of supplier certification for the buyers and eventual end-users can be extrapolated to platform certification as well, albeit with reservations. Several studies have found a impact of supplier certifications on reducing the overall production and distribution costs in a market (Gibson et al., 1995; Gould, 2003; Larson & Kulchitsky, 1998; Lockhart & Ettkin,
1993). An established certification program aides buyers and distributors in streamlining the identification, selection, and negotiation with suppliers. Certification not only provides an effective way to build relationships and reduce transactions costs, but also saves time in bringing quality products to market (Larson & Kulchitsky, 1998). Given competition, such savings can potentially be passed down to the eventual end-user as well. Although to what measureable extent this might be the case for platform certification is an open question for future research, mobile application developers did indicate that certification reduced the overhead of repeated testing by individual application buyers (network operators and device manufacturers). This was more accurately observed in the cases of Symbian Signed and Java Verified, which were instituted in already existing Java and
221 Symbian application markets. Further, it seems that certification has also been favorable to the platform promulgators who have been able to simultaneously increase quality and diversity, as well as reduced cost of complementary applications.
10.1.3 The Role of Platform Promulgator
As discussed above, mobile computing platform certifications are quite similar to product certifications. Conceptually, they also seem like supplier certifications, with elements of outsourced buyer control and supply chain/web management, especially for high volume product developers. In that sense platform certifications can be viewed as a hybrid product-then-supplier certification program.
A unique dimension in this hybrid certification program is the role of platform promulgators. Essentially, the platform promulgators act as third-party ―certifiers‖ to facilitate the transactions between buyers and suppliers of platform-based products.
Based on the role of certifier, researchers have classified most certification programs into three categories – First, Second or Third-party certifications (Boegh, 2006). First- party certification programs include the in-house quality assurance initiatives of a particular economic entity (a supplier). Essentially, a supplier provides a form of legally- binding guarantee to the buyers claiming that their products meet advertised quality criteria. On the other hand, Second-party certifications are buyer managed quality assurance initiatives to differentiate quality or safe products for consumption. They include both individual as well as collective industry-consortium-driven buyer initiatives.
Third party certification initiatives are different from first- and second-party initiatives as they are managed by entities that are independent from the buyer-supplier marketplace
(Boegh, 2006).
222 Most third-party certification programs are managed by government or quasi- governmental institutions for greater societal good or specialized for-profit economic entities that fill a niche to facilitate buyer-supplier transactions. Such third-parties do not have a direct involvement or stake in buyer-seller transactions and hence are often called ―independent third-party certifications‖ (Rada, 1996). However, platform promulgators as third-party certification providers do have a unique stake in the complementary product marketplace. Their primary objective is neither greater societal good nor direct profit making, but to promulgate their platform. In the platform certifications I investigated, representatives of the platform promulgators stressed that their interest lies in ―disseminating‖ their platforms, which is achieved by providing a healthy buyer-supplier ―ecosystem‖ of complementary products. From a network economics perspective, platform promulgators want to encourage platform adoption across both buyers and suppliers of the platform‘s complementary products. They have to balance buyers‘ quality expectations whilst encouraging suppliers‘ productivity and diversity so that they are able to leverage positive network externalities of complementary products for effective platform diffusion. In that sense their role as an
―independent‖ third-party is questionable.
Assuming independence of the certifier, third-party certifications have been explored in many markets (Biglaiser & Friedman, 1994; Lizzeri, 1999; Marette & Crespi,
2003). Studies have found that certification adds value in markets where verification by buyers is expensive, possibility of unobservable quality difference is high, or suppliers are numerous and hence may lack sufficient market reputation to credibly disclose quality (Choi, 1998; Rubinstein & Wolinsky, 1987). Further, third-parties can act as intermediary market gatekeepers, who can lower pricing inefficiencies, search costs, and increased trust in the market (Biglaiser & Friedman, 1994; Resnick et al., 1994; Sarkar et
223 al., 1995). However, their role in the market is contingent upon the assumption that third- parties are independent and driven by a profit-making objective, wherein their business is dependent upon the suppliers. Platform promulgators, as mentioned above, are primarily interested in enhancing platform adoption and creating a diverse and quality ecosystem. Hence, the market efficiency benefits of platform certifications can only be generalized with reservations.
Given the economic interest of platform promulgators in the platform-based product market, they are in a unique position to define and control the platform-based- product market. In order to assess the importance of this unique dimension in platform certification programs, I turn to literature on network markets. In the following section, I discuss the implications of platform certifications on network markets, particularly drawing conceptual insights from the Business Ecosystems view of industrial organization (Iansiti & Levien, 2004a; Moore, 2006).
10.2 Markets with Platform Certification
In industries where technological architectures are used as platforms for the production of complementary products, they exhibit what are commonly referred to as indirect network effects or externalities (Church & Gandal, 1993). Platform-based markets indirectly enhance the network externalities for platform promulgators (West &
Dedrick, 2000). The greater the diversity and number of platform-based products, the greater is the incentive for actors to embrace the platform over other competing platforms. The diffusion and dominance of a platform technology, hence strongly depends on the adoption by both buyers and suppliers of the platform‘s complementary products.
224 The establishment of a platform certification program in such networked markets is bound to have nuanced implications for various market actors. The platform certification program as such positions the platform promulgator as a market regulator.
With sufficient market support and acceptance, the platform promulgators are able to define a threshold standard that the platform-based products must adhere to. Further, as discussed above, platform certification programs can also take the form of a hybrid product-supplier certification system. Given that a platform certification system directly evaluates and approves certain suppliers, in addition to platform-based products at large, the market regulatory role is quite prominent. The platform promulgator then not only regulates the kinds of platform-based products that are supplied, but also determines what kinds of suppliers should be given preference. The regulatory influence of the platform promulgator on the competitive landscape of the platform-based market can hence be astounding.
The business ecosystems view of the industry can particularly insightful in understanding the regulatory role of platform promulgators and the effects of platform certification on platform-based product markets. A business ecosystem is defined as ―an economic community supported by a foundation of interacting organizations and individuals – the organisms of the business world‖ (Moore, 1997)(pg 26). A platform can be viewed as the basis for defining the boundaries of the ecosystem in platform-based product markets. The market regulatory role of the platform promulgator can be conceptually described by the role ―keystones‖ play in a business ecosystem.
Keystones, as hubs in the networked ecosystem of actors assume a leadership role in shaping the market opportunities for other actors that pursue ―niche‖ strategies (Iansiti &
Levien, 2004a).
225 From a business ecosystem view point, the platform promulgator can act as the ecosystem orchestrating keystone that creates and drives the value flow in the industry.
In addition to defining the platform and its interfaces, a platform promulgator through platform certifications, are in a position to dictate what types of products and their suppliers can participate in the platform-based ecosystem. Although as members of a platform-based ecosystem various actors can leverage the platform to gain production and distribution efficiencies, their business depends on what types of products are deemed acceptable by the platform promulgator. However, the regulatory role played by platform promulgators is more complex than it appears. According to the business ecosystems view, the keystones should invest in the ―health‖ of the ecosystem to enhance their profitability (Iansiti & Levien, 2004a). The health of an ecosystem is collectively determined by the ―Productivity‖167, ―Robustness‖168, and ―Diversity‖169 of the ecosystem members (Iansiti & Levien, 2004a; Iansiti & Richards, 2006). The keystone has to constantly enhance ecosystem health to maintain the attractiveness of the ecosystem for new membership. Platform promulgators as keystones are invested in the health of their platform-based ecosystem. The productivity, robustness, and diversity of platform-based product developers are hence critical. Given this view, the extent to which a platform certification program assists or conflicts with the productivity, robustness, and diversity goals of a platform-based product developer is an open question.
167 Ecosystem Productivity refers to the ecosystem actors‘ effectiveness in conducting their business (Iansiti & Levien, 2004a) 168 Ecosystem Robustness refers to the ecosystem actors‘ ability to sustain their business (Iansiti & Levien, 2004a) 169 Ecosystem Diversity refers to the diversity in ecosystem actors‘ and hence the ecosystem‘s innovative ability (Iansiti & Levien, 2004a)
226 In the context of mobile computing platform certifications, I consistently observed the active role Qualcomm, Symbian, and UTI members played in enhancing the benefits of the certification program while reducing the constraints for the developers. The three platform promulgators have constantly upgraded their certification programs to reduce the costs of certification for the developers and ease the certification process. Examples of such efforts include introduction of competition between ATLs to reduce certification fee, provisioning of automated certification tools, providing various certification options, and facilitation of buyer and supplier transactions. On the other hand, platform promulgators also provide special provisions for selective high-volume developers, which can in turn impact diversity and robustness in the developer community at large.
Further, certification pricing, in the case of True BREW, remained constant for years and wasn‘t competitively determined by the ATL. The fee was then dropped 30% as prescribed by Qualcomm in 2006.
Given such observations, it seems that the platform promulgators are addressing the requirements of a healthy ecosystem, while regulating the market participation using the platform certification programs. In a sense, platform certifications can be viewed as a regulatory mechanism used by keystone platform promulgators to drive their ecosystem productivity. In this context, ecosystem productivity refers to the effective production and availability of quality/secure applications. However, such conceptual generalization is merely a suggestion. Theoretical expansion will require studies to investigate other markets with platform certifications.
227 10.2.1 Implications for Platform Promulgators and Powerful Actors
On a practical level, the study raises several implications for other platform promulgators within the mobile applications sector. Of particular note is Microsoft, which has developed the Windows Mobile platform for mobile application developers. Microsoft also provides a platform certification program known as the Mobile2Market program.
Although Windows Mobile did not have a major market presence at the onset of this study, its adoption by various device manufacturers, network operators, and developers is constantly increasing. It would be interesting to investigate how Microsoft balances the requirements of the Mobile2Market certification program with the productivity, robustness, and diversity requirements of enhancing its ecosystem‘s health. More recently, Apple and Google have also designed their proprietary mobile computing platforms for third-party application developers. Although both Apple and Google do not currently offer a certification program, a comparison of their application ecosystem with the ecosystems of competing platforms offering certification programs can provide useful insights on the impact of platform certification on the complex mobile applications market.
Given the prevalence of platform certification programs in the mobile applications market, it seems likely that certification will be a trend for upcoming computing platforms.
This raises an interesting question – Why is platform certification so prevalent in the mobile application markets? It seems likely that the prevalence is due to the security concerns of the network operators who are influential buyers with high bargaining power.
Although platform certifications are also common in similar desktop and server software
228 markets170, according to some of the experienced developers I interviewed, the adoption of such programs is quite patchy due to the lack of powerful buyers/distribution channels. There is no equivalent of a network operator in such markets. Further, as far as platform implementation is concerned, unlike the vertically integrated mobile device manufacturers, there are a plethora of PC hardware component manufacturers. Hence, it seems that it might be harder for platform promulgators in the desktop realm to coordinate and garner support for a certification program.
From a business ecosystem viewpoint, the network operators and mobile device manufacturers can be viewed as ―Hubs‖ that interact with various ―Nodes‖ (application developers). However, the platform promulgators also act as ―Hubs‖ facilitating the production and distribution interactions between the network operators, device manufacturers, and application developers. As discussed above, they act as keystone hubs by specifying the production platforms and managing the ecosystem through certification programs. There exists a possibility of a power struggle between the platform promulgators and other powerful hubs such as the network operators and device manufacturers. It is hence more likely that the platform promulgators might partner with or integrate their operations with other powerful actors. This theoretical suggestion can be observed in the cases of Symbian and Qualcomm, who already have operational stake and ties with the device manufactures. Symbian, for instance, is a joint partnership of several device manufacturers, while Qualcomm has a stake in promoting the sale of their patented chips to various CDMA device manufacturers by building a healthy BREW ecosystem. On the other hand, Sun is a peculiar case. Although Sun
170 For instance, Microsoft also manages certification programs for its Windows desktop and server platforms under the ―Designed for Windows‖ umbrella of logo programs. See http://www.microsoft.com/winlogo/default.mspx for details.
229 drives the UTI partnership of several major device manufacturers and network operators, it has no stake in the operations of various device manufacturers and network operators.
It can be argued that Sun, in order to maintain and leverage their keystone advantage, in the future might attempt to either produce its own device or strategically partner and integrate operations with other powerful actors.
10.2.2 Implications for Intermediaries
Certification in platform-based markets also provides opportunities for intermediation. Of particular note are testing labs that execute the certification testing criteria on behalf of the platform promulgators. These testing labs act as specialized intermediaries in markets with platform certification. As certification intermediaries they are largely dependent on the platform promulgators (certifiers) and platform-based product developers (certifiees). As such they face certain operational risks that are related both to the certification program as well as the growth of the platform-based product markets.
The primary operational risk for testing labs is associated with the certification programs. As an economic entity their business depends on the ability to receive and maintain the designation of an Authorized Testing Lab (ATL) by the platform promulgators. The opportunity to be named an ATL exists for only a short period of time, which requires firms seeking this designation, be knowledgeable about emerging platforms. Although the platform promulgators can withdraw this designation, in the mobile applications market I observed that the relation between platform promulgators and testing labs were generally stable. Hence, the window of opportunity for certification intermediation can be quite small. Testing labs therefore have to be quite aggressive in
230 positioning themselves as certification intermediaries at the onset of a platform certification program.
In addition to being designated as an ATL, the testing labs can face forced competition. The platform promulgators might designate multiple ATLs for their certification program in order to instill ATL competition and competitively reduce certification pricing. Given the fact that platform promulgators such as Symbian and Sun have designated multiple ATLs to reduce certification pricing, testing labs in other platform markets, irrespective of their level of specialization to avoid competition, should be prepared for competition nonetheless. Further, the ATLs I interviewed suggested that an ATL should be able to maintain a cordial relation with the platform promulgators, while competing with other labs along several dimensions including certification pricing, certifiee customer service, testing turnaround time, as well as bundling other testing packages with certification testing171.
The competition from other labs is primarily a short term concern. In the longer term labs face risks from the possible dissolution of the certification program altogether.
On one hand, a platform might lose prominence in a market or become obsolete, thereby leading to the dissolution of a platform certification program. As multiple platforms can compete for dominance in a market for years, the non-linearity of network effects can make it hard to predict the long term success of a platform, presenting a longer-term risk for testing labs. On the other hand, the dominance of a platform might also lead to the dissolution of the platform certification program. As the knowledge and skills necessary to adhere to a platform certification criteria become commonplace, the
171 Example of such testing packages in the mobile applications market includes comprehensive application usability, functional, compatibility, performance testing, and content language testing that are not covered by a given certification testing criterion.
231 platform promulgator might dissolve the certification program. In that sense the operational risk for the testing labs increases over time. Hence, irrespective of the increase or decrease of a platform‘s market dominance, the certification programs seem to have a lifecycle. A testing lab should then have a well formulated entry strategy as new platform certification programs designate certification labs in the initial period and an exit strategy when the platform certification programs dissolve.
10.2.3 Implications for Platform-Based Product Developers
As noted above, platform certifications are essentially geared towards platform- based product developers. The availability and effectiveness of these certification programs can alter the strategic conduct of developers in the way they design, test and distribute their products. In that sense, platform certifications have direct strategic implications for developers.
In platform-based product markets with platform certifications, a developer has to make strategic decisions at at-least two distinct levels. First, the developer has to decide whether to use a particular platform or not? There are a variety of factors that might influence such a decision – A platform‘s range of functionalities, market share, and developer‘s prior experience with similar technologies are a few examples. Second, the developer has to decide whether to certify their product or not? This study suggests that such a decision is influenced by a combination the design, management, and the constraints and benefits of a certification program.
In the mobile applications market, the evaluation of platform certification benefits by a developer will require market assessment and experimentation with certification.
Some platform promulgators (such as Symbian and UTI) provide that strategic option
232 space for a developer to assess the benefits of their certification programs through experimentation. However, other platform promulgators (such as Qualcomm) mandate certification. The developer then has to be prepared to make an ex-ante investment for certifying and distributing their applications. On the other hand, given the complexity of market interactions in the mobile applications market, it might be helpful for developers to be assured of the industry stakeholder support a mandated program provides, while an optional certification program might increase the market-support-assessment costs for the developers.
In addition to the option of certifying applications, the platform certification programs can also be leveraged as a market resource. As noted above, the certification programs encourage the development of intermediaries for product testing. Indirectly the certification programs provide access to an external resource for product testing. The mere availability of a testing option outside the application developer firm can be helpful for the developers. Essentially the financial costs of in-house application testing on various mobile devices and networks can be avoided by outsourcing testing to certification labs. Given economies of scale and sufficient ATL competition, the certification costs might be cheaper than establishing an in-house testing facility.
Although such a strategic behavior is hard to observe, a couple of ATL representatives I interviewed did allude to the possibility of such a practice in the mobile applications market. It is unlikely that certification can act as a comprehensive substitute for in-house quality assurance and testing for a developer, but developers definitely can, at least to an extent, leverage the certification testing as an external application testing resource.
The possibility of strategically leveraging a certification program as an alternate and potentially cheaper testing resource raises another interesting question – At what point does platform certification become the cost of doing business in the mobile applications
233 market? As the mobile computing industry matures, it certainly seems likely that platform certifications will become an integral part of the mobile applications market.
Furthermore, platform certification can also influence platform adoption. The developers are an integral part of the larger platform-based ecosystem and collectively drive an ecosystem‘s success. To what extent do platform certifications influence ecosystem membership – is still an open question. Certainly as observed in the mobile applications market, the constraints, benefits, and administration of certification can impact the inclination of developers to continually develop applications for a platform.
However, given platform lock-ins and limited market share of competing platforms that do not sponsor certification programs, the developers are, more often than not, forced to continue on the platform bandwagon.
Chapter 11
Conclusions
In recent times I have witnessed the emergence of multiple technology platforms and the use of certification programs to evaluate platform-based products in the ICT industry. Such platform certification programs can be viewed as a mechanism through which platform promulgating firms, at least to an extent, regulate participation in the platform-based product market. An understanding and evaluation of platform certifications can hence provide useful insights into the development of emerging markets and the effectiveness of its constituent firms. While platform-based product certification programs have become commonplace in the ICT industry, literature on the implications of such programs on the development of a platform-based market and the effectiveness of its constituent firms has been relatively scant. Although various studies have focused on the phenomenon of certification, the evolution and diffusion of platforms, and the influence of certification or platforms on industry structure per se; limited studies have assessed the implications of platform certifications for an emerging market.
In this study, I addressed this gap by empirically investigating platform certification and assessing its role in shaping a platform-based product market. I specifically focused on the mobile computing industry, evaluating the implications of mobile computing platform certification programs on the platform-based mobile applications/software market. As the mobile applications market has several competing mobile computing platforms with associated application certification programs, it
235 provided an ideal context to investigate the role of platform certifications in influencing a platform-based product market.
In the following sections I conclude the study by summarizing its findings in terms of theoretical and practical implications. I then discuss the generalizability of the findings to other similar markets. Subsequently, I discuss the scope of the research in terms of its limitations. Finally, the chapter concludes with recommendations for future research.
11.1 Research Findings and Implications for Theory and Practice
This study investigated three mobile computing platforms‘ certification programs and qualitatively examined their influences on the firms in the mobile applications ecosystem. In particular, the study examined the Symbian Signed, Java Verified, and
True BREW certification programs.
One of the primary contributions of the study is the development of a conceptual framework that provides a mechanism for characterizing platform certifications and assessing their impact on the platform-based product market. The study first identified key attributes of a generic certification system from the broad literature on product, process, and professional certification and applied them to describe and analyze platform certifications. These key attributes included authority structure, imposed constraints, and perceived benefits of a platform certification program.
Rich data from three cases of platform certifications in the mobile applications market was used to further elaborate and revise the key attributes to describe a platform certification system. In particular, the certification authority structure was conceptually expanded to describe a platform certification system‘s control structure, coerciveness, and flexibility in its design and management. The study described, operationalized, and
236 then compared these expanded constructs across the three platform certification systems.
By conceptually framing platform certifications and empirically assessing their impact on the mobile applications ecosystem, the study presented several findings.
Firstly, platform certifications were perceived as a market regulatory mechanism by the stakeholders and participant firms in the mobile applications market ecosystem. In particular, platform certification programs were used as a framework for third-party application developer identity authentication and authorization by platform promulgators for distributing mobile applications. Secondly, platform certification programs introduced barriers to entry in the mobile applications market. Although certification programs streamlined application distribution, the certification programs‘ authority structure, in particular their control structure and coerciveness lead to certification costs that were perceived as an entry deterrent for new developers. This finding is especially substantial as high entry barriers in an emerging market can potentially hamper innovation and limit its growth. Thirdly, the study also found that certification authority structure; in particular, its control structure influenced the vertical compatibility of the mobile applications with their underlying platforms. Platform certifications with a tighter centralized control structure had a positive impact on the availability of highly compatible certified applications. Achieving complete vertical compatibility, however, will require certifier access to application source-code, which is unlikely to happen anytime soon. Hence, it appears that ‗piecemeal‘ application compatibility will be the norm for some time to come. Finally, the study argued for the suitability of business ecosystems view in furthering the conceptual understanding of platform certifications and its implications for platform promulgators, powerful actors, and developers of platform-based products.
More specifically, platform-based product markets can be viewed as an interdependent
237 business ecosystem of ―keystones‖, ―hubs‖, and ―nodes‖, wherein platform promulgators act as keystones that attempt to leverage powerful actor hubs and platform-based product developer nodes to develop and orchestrate a productive, robust, and diverse ecosystem around their platforms. More specifically, this study shows that the ecosystem construct not only has strategic implications for firms but also, by highlighting the complex relations between firms engaged in providing a service, can be a useful lens in understanding market regulation and performance.
On a practical level, the study provides rich empirical insights into the development of a global mobile applications market. The study offers practical implications for various stakeholders in the mobile applications ecosystem as a whole.
The study suggests the way in which the design and management of a platform certification programs can impact the growth of the mobile applications market. Further, the study identifies several implications of platform certification for other platform promulgators within the mobile applications sector. Managers at platform promulgators such as Microsoft, Google, and Apple can especially benefit from this study. They can apply some of the findings from the study to design and alter the management of their potential and established certification systems. Further, the findings from the study are also informative for powerful actors in the mobile computing industry (such as mobile network operators and device manufacturers). The study suggests that it is highly beneficial for powerful actors to collaborate and even partner with platform promulgators in the design and management of certification programs. The increased quality and security of applications and acceptance of certification programs simultaneously bolster their dominance and enhance application revenue streams. Furthermore, the study also provided strategic insights into the development, deployment, and distribution of mobile applications. The study highlighted various technical and business barriers, issues, and
238 recommendations for mobile application developers. The rich findings from the study will assist applications developers in making effective strategic decisions in competing and supplying platform-based mobile applications. These findings will particularly assist new and upcoming firms in establishing an effective business plan in supplying improved, cost effective, and diverse mobile applications.
Last but not least, this study has especially furthered our understanding of the integrated nature information, technology, and people in influencing the emergence and growth of markets in the information society. The study conceptualized people, not only as users impacted by changing technological tools, but also as creators and regulators of technological change. The study thus provides another case in evidence that describes how people share and strategically leverage/embed information in platforms and certification systems, which in turn influences the types of technologies that is created in today‘s digital economy.
11.2 Generalizability and Limitations
The findings from this study further enhance our understanding of the development of an emerging ICT market. However, the generalizability of the study is somewhat limited. The generalizability concerns of this research are primarily as a result of its limited scope. Hence, the extrapolation of the findings from the study to other similar platform-based markets should be made with reservations.
In terms of its scope, this study essentially investigated the platform certification programs within the context of an emerging software market. The effects of platform certification on the design, development, and distribution of platform-based software products were investigated. An investigation of effects of hardware platform certification
239 programs on the platform-based hardware products might yield different findings, as the physical production, testing, and verification of hardware products have an additional dimension of embedded inter-firm supply-chain transactions. The applicability of the findings from the study to hardware platform-based products (such as consumer electronic devices and ICT equipment) is hence limited. Further, in this study I have drawn conclusions without taking into account platform certification instances in other computing markets. To an extent, this limits the generalizability of the findings to similar platform-based computing markets such as desktop or server software markets.
Generalizing the findings to other computing markets will require a contextual assessment of inter-firm interactions to holistically describe the certification authority structure and evaluate its imposed constraints and perceived benefits.
Given its scope, the findings from this research are also limited due to factors related to research method, design, and theoretical considerations. I discuss each in turn.
This research has several limitations related to the selection of cases and the sampling of their data sources. Firstly, the study investigated three individual cases of platform certification within a given market. The three certification programs were primarily selected due to the wide deployment and the differences in the standardization approach of their underlying platforms on various mobile devices to understand the implications of dominant yet diverse types of platforms. This allowed for a large sampling population and provided an opportunity to gain a broader understanding of the implications of platform certifications on the mobile applications market. However, it is not possible to establish the extent to which these cases are representative of other platforms and their certification programs in the mobile applications market with limited adoption/market share such as Palm-OS and Mobile Linux. This impacts the validity of
240 the findings and their implications for all types of firms within the mobile applications market. Secondly, the research participant sampling strategy to inform the cases also raises limitations. Although the sampling of research participants was primarily stratified and targeted, snow balling was also used as needed to bolster the findings. Such a sampling strategy, however, can also potentially lead to observation of less diverse participant experiences and hence skew the findings. Finally, the study relies heavily on the anecdotal observations and industry experiences of research participants. The research hence rests critically on the ability of the research participants to recollect their past experiences, both positive and negative. Although special care was taken to instigate and prompt rich responses to interview questions, there is always room in such a process to miss out on critical pieces of information that can holistically inform the research questions.
In addition to the research method and design limitations, this study is also limited by the lack of depth in its theoretical base. Case study research often involves investigation at multiple levels. Utilizing several and sometimes competing theoretical constructs is surely not beyond the realm of accepted practice in case study research
(Patton, 2001; Yin, 1994). However, this does lead to some limitations. In this research the simultaneous investigations of constructs from diverse literature and the wide variety of theoretical bases such as network markets, supply chains, standardization, and certification systems has sacrificed depth in informing and advancing a singular theory to comprehensively explain platform certifications and their market implications. Although examining the phenomenon of platform certification rather than testing a particular theory was the central goal of the study, not selecting and expanding a particular theory in depth limits the generalizability and predictive power of the study.
241 The study is hence theoretically broad, but empirically rich nonetheless.
Therefore, any findings from the study are written as broadly applicable statements that should be read within the context and extrapolated with reservations.
11.3 Future Research
The broad nature of the scope of this research provides many avenues for future research.
First and foremost, future research can directly address the primary limitations of this research for greater generalizability and effective extrapolation to similar platform- based markets. In particular, future studies should further investigate other platforms in the mobile applications market. In this study I selected three platforms (and their associated certification programs) with a dominant market share. Future studies should examine other platforms in the mobile applications market to investigate whether platforms with minimal market share also leverage certification in a similar fashion or if there are differences in their management and implications for its stakeholders.
Prominent examples of such programs would be the case of Microsoft‘s Mobile2Market and Palm‘s Palm Compatibility Solution certification program.
In addition to examining mobile computing platforms with limited market share, future studies can also examine platforms that have been introduced for third-party application development more recently by Google and Apple. Although platforms by
Google and Apple do not provide certification programs per say, a longitudinal comparison of product markets of platforms that offer certification and those that don‘t can also provide useful insights into the role of certification in evolution of the emerging mobile applications market.
242 Future research can also further enrich the findings of this qualitative study by assessing quantitative industry data on entry, concentration, productivity, and diversity of the developers in the mobile applications market. Quantitative studies can evaluate the degree to which market entry barriers or overall market consolidation, productivity, and diversity are increased by the design and management of platform certification programs. Furthermore, in this study I observed that certification increases as well as reduces application development and distribution costs. Quantitative studies can be particularly helpful in examining the extent to which market transaction costs are influenced by platform certifications.
In addition to further research in the mobile applications market, future studies can also build theoretical models to bolster the generalizability of this research on similar markets with platform certifications. For instance, future research can develop models to elaborate the effectiveness of using third-party testing labs in reducing market transactions costs. Researchers can also investigate the optimum number of ATLs a platform certification program should offer to reduce transaction costs and increase platform adoption. Another interesting modeling exercise would be to understand the impact of an ATL certifying for multiple platform promulgators on the platform competition and adoption in a market.
On a theoretical level, the study leaves us with several intriguing questions on the nature of platform certifications. Do platform certifications have a lifecycle? If so, what are the factors that lead to their dissolution? And what factors shorten the lifecycle of platform certification programs? Future research can investigate instances of platform certifications in other markets to address such questions. Comparative longitudinal case studies of platform certification programs can yield rich insights into such a phenomenon. Additionally, in this study I observed platform certifications a hybrid form of
243 product and supplier certification. The platform certifications seemed to have evolved from a product certification system to a more supplier centric program. Future research can further the understanding of the evolution of platform certifications by investigating whether platform certifications in other markets also evolve from a product-level to a supplier-level certification system. Further, research can also elaborate on the factors and criteria that drive such an evolution of platform certification systems.
In addition to the nature of platform certifications, the study raises questions on the relationship between the variables that describe the supply of platform-based products. The study specifically examined the supply of products along two dimensions
– the products‘ vertical compatibility, and the producers‘ market entry conditions.
However, the study did not consider the interaction between vertical compatibility and the entry conditions. Excessive vertical incompatibilities in a product-market can impact economies of scale for producers that in turn can potentially deter entry by new producers. Future studies can also investigate the dynamics of such an interaction.
The business ecosystems view also raises several researchable questions. For instance, taking a business ecosystems view of platform-based markets, future research can investigate the extent to which platform certification programs assist or conflict with the developer productivity, robustness, and diversity goals of platform promulgators.
Further, a longitudinal comparison of ecosystem health of platforms with and without certification can yield practical insights for platform promulgators that are considering launching certification programs. Furthermore, future research can also compare the US and European mobile application markets with those in Japan. Japanese network
244 operators have taken an active role in designing application platforms172. In essence, the
Japanese network operators are also the platform promulgators. A comparison of such distinct business ecosystem with the ones in the US and Europe can provide practical insights for the network operators and further enrich the business ecosystems metaphor in understanding the role of platforms in shaping markets.
172 i-Mode is an application development and distribution platform that is collaboratively designed and supported by all three Japanese network operators.
Bibliography
Albano, G. L., & Lizzeri, A. (2001). Strategic certification and provision of quality. International Economic Review, 42(1), 267-283.
Anderson, P., & Tushman, M. L. (1990). Technological Discontinuities and Dominant Designs: A Cyclical Model of Technological Change. Administrative Science Quarterly, 35(4), 604-633.
Andrews, P. P., & Hahn, J. (1998). Transforming supply chains into value Webs. Strategy & Leadership, 26(3), 7-11.
Arthur, W. B. (1989). Competing technologies, increasing returns and lock-in by historical events. The Economic Journal, 99(394), 116-131.
Babbie, E. R. (2004). The Basics of Social Research (3rd ed.): Wadsworth Publishing.
Backhouse, J. (2002). Assessing certification authorities: Guarding the guardians of secure E-commerce? Journal of Financial Crime, 9(3), 217-226.
Baldwin, C. Y., & Clark, K. B. (1997). Managing in an age of modularity. Harvard Business Review, 75(5), 84-93.
Barnes, S. J. (2002). The mobile commerce value chain: Analysis and future developments. International Journal of Information Management, 22(2), 91-108.
Besen, S. M., & Farrell, J. (1994). Choosing how to compete: Strategies and tactics in standardization. The Journal of Economic Perspectives, 8(2), 117-131.
Biglaiser, G., & Friedman, J. W. (1994). Middlemen as Guarantors of Quality. International Journal of Industrial Organization, 12, 509-531.
Blind, K., & Thumm, N. (2004). Interrelation between patenting and standardisation strategies: empirical evidence and policy implications. Research Policy, 33(10), 1583-1598.
Boegh, J. (2006). Certifying Software Component Attributes. IEEE Software, 23(3), 74- 81.
Bouckaert, C. (2000). Will ISO 9000 certification become the norm for insurance intermediaries in France? International Financial Law Review, 19(3), 23-24.
Bresnahan, T. F., & Greenstein, S. (1999). Technological competition and the structure of the computer industry. The Journal of Industrial Economics, 47(1), 541-558.
246 Bresnahan, T. F., & Malerba, F. (1997). Industrial Dynamics and the Evolution of Firms' and Nations' Competitive Capabilities in the World Computer Industry: Stanford University, Department of Economics.
Brynjolfsson, E., & Kemerer, C. F. (1996). Network externalities in microcomputer software: An econometric analysis of the spreadsheet market. Management Science, 42(12), 1627-1647.
Butters, A. M. (2005). Developers‘ Choice Wireless Platforms. Santa Cruz, CA: Evans Data Corp.
Canalys. (2006, 25 Jul). Smart mobile device market growth remains steady at 55%. Retrieved Dec, 2007, from http://www.canalys.com/pr/2006/r2006071.pdf
Chen, K.-M., & Liu, R.-J. (2005). Interface strategies in modular product innovation. Technovation, 25(7), 771-782.
Choi, S. (1998). Market lessons for gatekeepers. Northwestern University Law Review, 92(3), 916-966.
Christensen, C. M., & Rosenbloom, R. S. (1995). Explaining the attacker's advantage: technological paradigms, organizational dynamics, and the value network. Research Policy, 24, 233-257.
Church, J., & Gandal, N. (1992). Network Effects, Software Provision, and Standardization. The Journal of Industrial Economics, 40(1), 85-103.
Church, J., & Gandal, N. (1993). Complementary network externalities and technological adoption. International Journal of Industrial Organization, 11(2), 239-260.
Church, J., & Gandal, N. (1996). Strategic Entry Deterrence: Complementary Products as Installed Base. European Journal of Political Economy, 12, 331-354.
Clark, K. B. (1985). The Interaction of Design Hierarchies and Market Concepts in Technological Evolution. Research Policy, 14(5), 235-251.
Clements, M. T. (2004). Direct and indirect network effects: are they equivalent? International Journal of Industrial Organization, 22(5), 633-645.
Costlow, T. (2004). IEEE certification addresses security standards. IEEE Software, 21(1), 102-103.
Crain, J. K., & Wierschem, D. (2006). Machine Tool Industry Adoption of Software Certification Processes. The Quality Management Journal, 13(2), 38-45.
David, P. A. (1985). Clio and the Economics of QWERTY. The American Economic Review, 75(2), 332-337.
247 David, P. A., & Greenstein, S. (1990). The Economics of Compatibility Standards: An Introduction to Recent Research. Economics of Innovation and New Technology, 1, 3-41.
David, P. A., & Steinmueller, W. E. (1994). Economics of Compatibility Standards and Competition in Telecommunication Networks. Information Economics and Policy, 6, 217-241.
Dawson, C., & Lewelling, J. (1991). Level Playing Fields: International Standards, Product Certification, and the Global Marketplace. Regulation, 14(3).
Dewally, M., & Ederington, L. (2006). Reputation, Certification, Warranties, and Information as Remedies for Seller-Buyer Information Asymmetries: Lessons from the Online Comic Book Market. The Journal of Business, 79(2), 693-729.
Dobson, P. W. (2006). Competing, countervailing, and coalescing forces: the economics of intra- and inter-business system competition. Antitrust Bulletin, 51(1), 175-193.
Economides, N. (1996). The economics of networks. International Journal of Industrial Organization, 14(6), 673-699.
Economides, N., & Himmelberg, C. (1995). Critical Mass and Network Evolution in Telecommunications. In G. Brock (Ed.), Toward a competitive Telecommunications Industry: Selected Papers from the 1994 Telecommunications Policy Research Conference (pp. 31-42). University of Maryland, College Park, MD.
Economides, N., & Salop, S. C. (1992). Competition and Integration Among Complements, and Network Market Structure. The Journal of Industrial Economics, 40(1), 105-123.
Egyedi, T. M. (2001). Strategies for de facto compatibility: Standardization, proprietary and open source approaches to Java. Knowledge, Technology, and Policy, 14(2), 113-128.
Egyedi, T. M., & Dahanayake, A. (2003, Oct 22-24). Difficulties Implementing Standards. Paper presented at the 3rd IEEE Conference on Standardization and Innovation in Information Technology, Delft, The Netherlands.
Egyedi, T. M., & Hudson, J. (2005). A Standard‘s Integrity: Can It Be Safeguarded. IEEE Communications Magazine, 43, 151-155.
Egyedi, T. M., & Joode, R. v. W. d. (2003, October 22-24). Standards and Coordination in Open Source Software. Paper presented at the Standardization and Innovation in Information Technology (SIIT 2003), Delft University of Technology, The Netherlands.
Egyedi, T. M., & Joode, R. v. W. d. (2004). Standardization and Other Coordination Mechanisms in Open Source Software. International Journal of IT Standards & Standardization Research, 2(2), 1-17.
248 Ehrhardt, M. (2004). Network effects; standardisation and competitive strategy: how companies influence the emergence of dominant designs. International Journal of Technology Management, 27(2,3), 272-294.
Ereaut, G. (2002). Analysis and Interpretation in Qualitative Market Research (Vol. 4). Thousand Oaks, CA: Sage Publications.
Farrell, J., & Saloner, G. (1985). Standardization, Compatibility, and Innovation. RAND Journal of Economics, 16(1), 70-83.
Farrell, J., & Saloner, G. (1986). Installed Base and Compatibility: Innovation, Product Preannouncements, and Predation. The American Economic Review, 76(5), 940- 955.
Farrell, J., & Saloner, G. (1988). Coordination Through Committees and Markets. The Rand Journal of Economics, 19(2), 235-252.
Farrell, J., & Saloner, G. (1992). Converters, Compatibility, and the Control of Interfaces. The Journal of Industrial Economics, 40(1), 9-35.
Fomin, V., & Keil, T. (2000). Standardization: bridging the gap between economic and social theory. Paper presented at the International Conference on Information Systems, Brisbane, Queensland, Australia.
Formaini, R. L. (2001). The engine of capitalist process: Entrepreneurs in economic theory. Economic & Financial Review, Fourth Quarter.
Franceschini, F., Galetto, M., & Gianni, G. (2004). A new forecasting model for the diffusion of ISO 9000 standard certifications in European countries. The International Journal of Quality & Reliability Management, 21(1), 32-50.
Fransman, M. (2002). Mapping the evolving telecoms industry: The uses and shortcomings of the layer model. Telecommunications Policy, 26(9,10), 473-483.
Fuller, G. K., & Vertinsky, I. (2006). Market Response to ISO 9000 Certification of Software Engineering Processes. International Journal of IT Standards & Standardization Research, 4(2), 43-54.
Funk, J. L. (2004a). Key technological trajectories and the expansion of mobile Internet applications. Info : the Journal of Policy, Regulation and Strategy for Telecommunications, Information and Media, 6(3), 208-215.
Funk, J. L. (2004b). Mobile Disruption: The Technologies and Applications Driving the Mobile Internet. New York, NY: John Wiley & Sons.
Funk, J. L. (2004c). The Product Life Cycle Theory and Product Line Management: The Case of Mobile Phones. IEEE Transactions on Engineering Management, 51(2), 142-152.
249 Funk, J. L., & Methe, D. T. (2001). Market- and committee-based mechanisms in the creation and diffusion of global industry standards: The case of mobile communication. Research Policy, 30(4), 589-610.
Gallagher, S., & Park, S. H. (2002). Innovation and Competition in Standard-Based Industries: A Historical Analysis of the U.S. Home Video Game Market. IEEE Transactions on Engineering Management, 49(1), 67-82.
Gandal, N. (1995). Competing compatibility standards and network externalities in the PC software market. The Review of Economics and Statistics, 77(4), 599-608.
Gandal, N. (2002). Compatibility, standardization, and network effects: Some policy implications. Oxford Review of Economic Policy, 18(1), 80-91.
Gandal, N., Greenstein, S., & Salant, D. (1999). Adoptions and orphans in the early microcomputer market. The Journal of Industrial Economics, 47(1), 87-105.
Gandal, N., Salant, D., & Waverman, L. (2003). Standards in wireless telephone networks. Telecommunications Policy, 27(5,6), 325-332.
Gartland, M. P. (2005). Interdisciplinary views of sub-optimal outcomes: Path dependence in the social and management sciences. Journal of Socio - Economics, 34(5), 686-702.
Garud, R., & Kumaraswamy, A. (1993). Changing competitive dynamics in network industries: An exploration of Sun Microsystems' open systems strategy. Strategic Management Journal, 14(5), 351-369.
Gibson, B. J., Mundy, R. A., & Sink, H. L. (1995). Supplier certification: Application to the purchase of indus. Logistics and Transportation Review, 31(1), 63-74.
Gifford, J. L., & Stalebrink, O. J. (2002). ITS standardisation: Lessons from the consortium approach. International Journal of Technology Policy and Management, 2(1), 56-71.
Gossain, S., & Kandiah, G. (1998). Reinventing value: The new business ecosystem. Strategy & Leadership, 26(5), 28-33.
Gould, R. A. (2003). Supplier Certification: Strengthing the chain. Quality Congress. ASQ's ... Annual Quality Congress Proceedings, 57, 527-532.
Greenstein, S. (1997). What does industry convergence mean? In D. Yoffie (Ed.), Competing in the Age of Digital Convergence. 201-226: Harvard Business School Press.
Greenstein, S. (1998). Industrial Economics and Strategy: Computing Platforms. IEEE Micro, 18(3), 43-53.
Greenstein, S. (1999). Technological Convergence. In R. C. Dorf (Ed.), Technology Management Handbook: CRC Press LLC.
250 Greenstein, S. (2006). Standards, Complexity and Transitional Technology Markets. In The Standard‘s Edge: The Bolin Group.
Grieco, P. L., Jr. (1989). Why Supplier Certification? and, Will It Work? Production & Inventory Management Review & APICS News, 9(5), 38-42.
Gundlach, G. T. (2006). Complexity science and antitrust? Antitrust Bulletin, 51(1), 17- 30.
Halman, J. I. M., Hofer, A. P., & Vuuren, W. v. (2003). Platform-driven development of product families: Linking theory with practice. The Journal of Product Innovation Management, 20(2), 149-162.
Hansen, E. (1997). Forest certification. Forest Products Journal, 47(3), 16-22.
Hawkins, R. (1999). The rise of consortia in the information and communication technology industries: emerging implications for policy. Telecommunications Policy, 23(2), 159-173.
Henderson, R. M., & Clark, K. B. (1990). Architectural Innovation: The Reconfiguration Of Existing Product Technologies and the Failure of Established Firms. Administrative Science Quarterly, 35(1), 9-30.
Hobday, M. (1998). Product complexity, innovation and industrial organisation. Research Policy, 26(6), 689-710.
Iansiti, M., & Levien, R. (2004a). The Keystone Advantage: What the New Dynamics of Business Ecosystems Mean for Strategy, Innovation, and Sustainability: Harvard Business School Press.
Iansiti, M., & Levien, R. (2004b). Strategy as Ecology. Harvard Business Review, 82(3), 68-78.
Iansiti, M., & Richards, G. L. (2006). The information technology ecosystem: Structure, health, and performance. Antitrust Bulletin, 51(1), 77-110.
Inman, R. A., & Hubler, J. H. (1992). Certify the process, not just the product. Production and Inventory Management Journal, 33(4), 11-14.
Iversen, E. J., & Tee, R. (2006). Standards dynamics and industrial organization in the mobile telecom sector. Info : the Journal of Policy, Regulation and Strategy for Telecommunications, Information and Media, 8(4), 33-48.
Jahn, G., Schramm, M., & Spiller, A. (2005). The Reliability of Certification: Quality Labels as a Consumer Policy Tool. Journal of Consumer Policy, 28(1), 53-73.
Jakobs, K. (2000). Information Technology Standards and Standardization: A Global Perspective: Idea Group Inc.
251 Karasik, M. S. (1985). Environmental Testing Techniques for Software Certification. IEEE Transactions on Software Engineering, 11(9), 934-938.
Kartha, C. P. (2007). An Empirical Analysis of the Impact of ISO Quality Standard Certification. The Business Review, Cambridge, 8(1), 252-257.
Karvonen, J., & Warsta, J. (2004). Mobile multimedia services development: value chain perspective. Paper presented at the Proceedings of the 3rd international conference on Mobile and ubiquitous multimedia MUM '04.
Katz, M. L., & Shapiro, C. (1985). Network Externalities, Competition, and Compatibility. The American Economic Review, 75(3), 424-440.
Katz, M. L., & Shapiro, C. (1986). Technology Adoption in the Presence of Network Externalities. The Journal of Political Economy, 94(4), 822-841.
Katz, M. L., & Shapiro, C. (1992). Product Introduction with Network Externalities. The Journal of Industrial Economics, 40(1), 55-83.
Katz, M. L., & Shapiro, C. (1994). Systems Competition and Network Effects. The Journal of Economic Perspectives, 8(2), 93-115.
Kleijnen, M., Ruyter, K. d., & Wetzels, M. G. M. (2003). Factors Influencing the adoption of Mobile Gaming Services. In B. E. Menneceke & T. J. Strader (Eds.), Mobile Commerce: Technology, Theory and Applications (pp. 202-217). Hershey, PA: Idea Group Publishing.
Klemperer, P. (1987). Markets with Consumer Switching Costs. The Quarterly Journal of Economics, 102(2), 375-394.
Lane, S., & Papathanasis, A. (1983). Certification and Industry Concentration Ratios. Antitrust Bulletin, 28(2), 381-395.
Larson, P. D., & Kulchitsky, J. D. (1998). Single sourcing and supplier certification: Performance and relationship implications. Industrial Marketing Management, 27(1), 73-81.
Levinson, R. J., Romaine, R. C., & Salop, S. C. (2001). The flawed fragmentation critique of structural remedies in the Microsoft case. Antitrust Bulletin, 46(1), 135- 162.
Li, F., & Whalley, J. (2002). Deconstruction of the mobile telecommunication industry: from value chains to value networks. Telecommunications Policy, 26, 451-472.
Liebowitz, S. J., & Margolis, S. E. (1994). Network Externality: An Uncommon Tragedy. The Journal of Economic Perspectives, 8(2), 133-150.
Lingenfelter, G. E. (1988). Evaluating Product Safety Certification Programs. Professional Safety, 33(2), 13-18.
252 Lizzeri, A. (1999). Information revelation and certification intermediaries. The Rand Journal of Economics, 30(2), 214-231.
Lockhart, M., & Ettkin, L. (1993). Vendor certification: Seven steps to a better product. Production and Inventory Management Journal, 34(1), 65-69.
Maass, R. A. (1988). Supplier Certification -- A Positive Response to Just-in-Time. Quality Progress, 21(9), 75-80.
MacInnes, I., Moneta, J., & Caraballo, J. (2002). Business Models for Mobile Content: The Case of M-Games. Electronic Markets, 12(4), 218-227.
Mannermaa, M. (2005). Mobile Application Ecosystems. On T-110.5120 Next Generation Wireless Networks: Helsinki University of Technology.
Marette, S., & Crespi, J. M. (2003). Can Quality Certification Lead to Stable Cartels? Review of Industrial Organization, 23(1), 43-64.
McAfee, P. R., Mialon, H. M., & Williams, M. A. (2004). What Is a Barrier to Entry? The American Economic Review, 94(2), 461-466.
McMullan, J., & Richardson, I. (2006). The Mobile Phone: a hybrid multi-platform medium. Paper presented at the Procedings of the 3rd Australasian conference on Interactive entertainment, Perth, Australia.
Menneceke, B. E., & Strader, T. J. (2003). Mobile Commerce: Technology, Theory and Applications. Hershey, PA: Idea Group Publishing.
Methlie, L. B., & Gressgård, L. J. (2006). Exploring the relationship between structural market conditions and business conduct in mobile data service markets. Journal of Electronic Commerce Research, 7(1), 14-26.
Meyer, M. H., & Dalal, D. (2002). Managing platform architectures and manufacturing processes for nonassembled products. The Journal of Product Innovation Management, 19(4), 277-293.
Meyer, M. H., & Lehnerd, A. P. (1997). The Power of Product Platforms: Free Press.
Meyer, M. H., & Lopez, L. (1995). Technology strategy in a software products company. The Journal of Product Innovation Management, 12(4), 294-306.
Meyer, M. H., & Seliger, R. (1998). Product Platforms in Software Development. Sloan Management Review, 40(1), 61-74.
Meyer, M. H., & Utterback, J. M. (1993). The Product Family and the Dynamics of Core Capability. Sloan Management Review, 34(3), 29-47.
Meyer, M. H., & Zack, M. H. (1996). The Design and Development of Information Products. Sloan Management Review, 37(3), 43-59.
253 Moore, J. F. (1993). Predators and prey: A new ecology of competition. Harvard Business Review, 71(3), 75-86.
Moore, J. F. (1995). The advent of business ecosystems. Upside, 7(12), 30-38.
Moore, J. F. (1997). The Death of Competition: Leadership and Strategy in the Age of Business Ecosystems: Harper Collins Publishers.
Moore, J. F. (2006). Business ecosystems and the view from the firm. Antitrust Bulletin, 51(1), 31-75.
Nguyen, T. N. (2002). The ecology of software: A framework for the investigation of business-IT integration. Journal of American Academy of Business, Cambridge, 2(1), 7-11.
Oren, S. S., & Smith, S. A. (1981). Critical Mass and Tariff Structure in Electronic Communications Markets. Bell Journal of Economics, 12(2), 467-487.
Özsomer, A., & Cavusgil, S. T. (2000). The effects of technology standards on the structure of the global PC industry. European Journal of Marketing, 30(9/10), 1199-1220.
Parkinson, T. L. (1975). The Role of Seals and Certifications of Approval in Consumer Decision-Making. The Journal of Consumer Affairs, 9(1), 1-14.
Patton, M. Q. (2001). Qualitative research and Evaluation methods: SAGE Publications.
Porter, M. E. (1985). Competitive Advantage: Creating and Sustaining Superior Performance. New York: The Free Press.
Qualcomm. (2007). BREW Developer Overview. Retrieved 1st Feb 2007, from http://brew.qualcomm.com/brew/en/developer/overview.html
Rada, R. (1996). Who will test conformance? Association for Computing Machinery. Communications of the ACM, 39(1), 19-22.
Raynor, M. E. (1993). ISO certification. Quality, 32(5), 44-45.
RCRWireless. (2004, 9th Aug). Symbian counts stronger global shipments. RCR Wireless News, 23, 26-27.
RCRWireless. (2005, 22nd Aug). Symbian boosts revenues, shipments, 24, 15-16.
RCRWireless. (2006, 3rd Jul). Smart-phone OS market set for change as entrants contest Symbian. RCR Wireless News, 25, 4-4.
Resnick, P., Zeckhauser, R., & Avery, C. (1994). Roles for Electronic Brokers. Paper presented at the Telecommunications Policy Research Conference.
254 Rodriguez-Dapena, P. (1999). Software Safety Certification: A Multidomain Problem. IEEE Software, 16(4), 31-38.
Rohlfs, J. (1974). A Theory of Interdependent Demand for a Communications Service. The Bell journal of Economics and Management Science, 5(1), 16-37.
Rohlfs, J. (2001). Bandwagon Effects in High-technology Industries: MIT Press.
Rubinstein, A., & Wolinsky, A. (1987). Middlemen. The Quarterly Journal of Economics, 102(3), 581-594.
Rülke, A., Iyer, A., & Chiasson, G. (2003). The ecology of mobile commerce: charting a course for success using value chain analysis. In B. E. M. T. J. Strader (Ed.), Mobile Commerce: Technology, Theory and Applications (pp. 122-144). Hershey, PA.: Idea Group Publishing.
Sabat, H. K. (2002). The evolving mobile wireless value chain and market structure. Telecommunications Policy, 26(9,10), 505-535.
Sanchez, R. (1996). Strategic product creation: Managing new interactions of technology, markets, and organizations. European Management Journal, 14(2), 121-138.
Sanchez, R. (2002). Using modularity to manage the interactions of technical and industrial design. Design Management Journal, 2, 8-20.
Sanchez, R., & Mahoney, J. T. (1996). Modularity, flexibility, and knowledge management in product and organization design. Strategic Management Journal, 17, 63-76.
Sanderson, S., & Uzumeri, M. (1995). Managing product families: The case of the Sony Walkman. Research Policy, 24(5), 761-782.
Sarkar, M. B., Butler, B., & Steinfield, C. (1995). Intermediaries and Cybermediaries: A Continuing Role for Mediating Players in the Electronic Marketplace. Journal of Computer Mediated Communication, 1(3).
Sawyer, S. (2001). Analysis by Long Walk: Some Approaches to the Synthesis of Multiple Sources of Evidence. In E. Trauth (Ed.), Qualitative Research in IS: Issues and Trends (pp. 163-190). Hershey, PA: Idea Group Publishing.
Schmidt, S. K., & Werle, R. (1998). Co-ordinating Technology: Studies in the International Standardization of Telecommunications. Cambridge, MA: MIT Press.
Söderström, E. (2002). A Certification Instrument for Standards Implementation.Unpublished manuscript, Department of Computer Science, University of Skövde.
255 Steensma, H. K., & Fairbank, J. F. (1999). Internalizing external technology: A model of governance mode choice and an empirical assessment. Journal of High Technology Management Research, 10(1), 1-35.
Steinbock, D. (2003). Globalization of wireless value system: from geographic to strategic advantages. Telecommunications Policy, 27(3-4), 207–235.
Stevenson, T. H., & Barnes, F. C. (2002). What industrial marketers need to know now about ISO 9000 certification: A review, update, and integration with marketing. Industrial Marketing Management, 31(8), 695-703.
Tarasewich, P. (2003). Towards a comprehensive model of context for mobile and wireless computing. Paper presented at the Proceedings of American Conference on Informaiton Systems (AMCIS), Tampa, Florida.
Tarnacha, A., & Maitland, C. F. (2008a). The effects of standards competition on market entry: The case of the mobile application markets. In The Standards Edge: Unifier or Divider? : The Bolin Group.
Tarnacha, A., & Maitland, C. F. (2008b). Structural Effects of Platform Certification on a Complementary Product Market: The Case of Mobile Applications. The International Journal of IT Standardization and Standardization Research, 6(2), 40-55.
Terziovski, M., Power, D., & Sohal, A. S. (2003). The longitudinal effects of the ISO 9000 certification process on business performance. European Journal of Operational Research, 146(3).
Tilson, D., & Lyytinen, K. (2006). The 3G transition: Changes in the US wireless industry. Telecommunications Policy, 30(10/11), 569-586.
Tushman, M. L., & Anderson, P. (1986). Technological Discontinuities and Organizational Environments. Administrative Science Quarterly, 31(3), 439-465.
Ulrich, K. (1995). The role of product architecture in the manufacturing firm. Research Policy, 24(3), 419-440.
Varshney, U., & Vetter, R. (2002). Mobile Commerce: Framework, Applications and Networking Support. Mobile Networks and Applications, 7, 185-198.
Vertinsky, I., & Zhou, D. (2000). Product and process certification - Systems, regulations and international marketing strategies. International Marketing Review, 17(3), 231-262.
Voas, J. (1999). Untested software threatens infrastructures. IEEE Software, 16(2), 89- 90.
Voas, J. (2001). Software fault tolerance: Making software behave. IEEE Software, 18(4), 18-19.
256 Voas, J., & Payne, J. (2000). Dependability certification of software components. The Journal of Systems and Software, 52(2,3), 165-172.
Walsham, G. (1995). The Emergence of Interpretivism in IS Research. Information Systems Research, 6(4), 376-394.
Wegberg, M. v. (2004a). Standardization and Competing Consortia: The Trade-Off Between Speed and Compatibility. International Journal of IT Standards & Standardization Research, 2(2), 18-33.
Wegberg, M. v. (2004b). Standardization Process of Systems Technologies: Creating a Balance between Competition and Cooperation. Technology Analysis & Strategic Management, 16(4), 457-478.
Weiss, M., & Cargill, C. (1992). Consortia in the Standards Development Process. Journal of the American Society for Information Science, 43(8), 559-565.
Weitzel, T., Beimborn, D., & Konig, W. (2006). A Unified Economic Model of Standard Diffusion: The Impact of Standardization Cost, Network Effects and Network Topology. MIS Quarterly, 30(Special Issue), 489-514.
West, J., & Dedrick, J. (2000). Innovation and control in standards architectures: The rise and fall of Japan's PC-98. Information Systems Research, 11(2), 197-216.
West, J., & Dedrick, J. (2006). Scope and Timing of Deployment: Moderators of Organizational Adoption of the Linux Server Platform. International Journal of IT Standards & Standardization Research, 4(2), 1-23.
Wheelwright, S. C., & Clark, K. B. (1992). Revoutionalizing Product Development: Quantum Leaps in Speed, Efficiency, and Quality: Free Press.
Willis, T. H., & Huston, C. R. (1992). Supplier certification: Concepts and techniques. Logistics Information Management, 5(1), 32-38.
Windrum, P. (2004). Leveraging technological externalities in complex technologies: Microsoft's exploitation of standards in the browser wars. Research Policy, 33(3), 385-394.
Wohlin, C., & Runeson, P. (1994). Certification of software components. IEEE Transactions on Software Engineering, 20(6), 494-499.
Yin, R. K. (1994). Case Study Research: Design and Methods (2nd ed.). Thousand Oaks: Sage Publications Inc.
Appendix A
Dissertation Keywords
Key word Definition
Technology architecture designed to assist development of third-
Mobile Computing party mobile software applications. A platform provides modular
Platform interfaces called Application Programming Interfaces (APIs) to
access functional components of a mobile device.
A platform that directly interacts with underlying device operating
system and provides programming interfaces for application
Middleware software to access device functions. Architecturally, a
Platform middleware platform is layered on top of the device operating
system providing operating-system-independence for the
middleware platform-based software applications.
An organization responsible for creating, enhancing,
implementing a platform on mobile devices. A platform
Platform promulgator also owns a platform and attempts to increase its
Promulgator adoption by multiple stakeholders including device
manufacturers, mobile network operators, and platform-based
application developers.
Mobile network operators or carriers are organizations that Mobile Network provide and manage the cellular infrastructure for voice and data Operators communication between different mobile devices. They are also
258
in many cases a distribution channel for digital mobile content
and applications.
Mobile device manufacturers are organizations that design,
Mobile Device develop, manufacture, and supply mobile devices for voice and
Manufacturers data communication using mobile network operator
infrastructure.
Application Developers are third-party developers of mobile
applications. They independently design, develop, deploy, and Mobile Application distribute applications for various mobile devices. In this Developers document they especially refer to developers of applications for
cellular mobile devices.
Application publishers are third-party Independent Software
Mobile Application Vendors (ISV) of mobile applications, who not only develop the
Publishers applications but also serve as an aggregator of applications from
other third-party application developers.
Platform A division of the platform promulgator responsible for designing Certification and managing the operations a platform certification program. Program Office
Authorized Testing Lab or Authorized Certification Lab. An
organization authorized by a certification sponsor, in the case of
ATL platform certification, a platform promulgator, for administrating a
process for application submission, testing, signing, and
certification on behalf of the certification sponsor.
Implementation In computer science, an implementation is a realization of a
259
technical specification or algorithm as a program, software
component, or other computer system on hardware. In the case
of platforms, implementation refers to physically embedding the
specifications of the platform architecture and its component
rules on a hardware device.
A part of the software development process that makes a
software component functionally and available for functional use. Deployment Deployment is also commonly referred to as installation of a
software component.
A malicious software application that is either intentionally
designed for or consequentially results in the functional Malware disruption of the underlying hardware or other software
components.
International Mobile Equipment Identity is a code embedded in a IMEI cellular phone, which identifies each cellular phone uniquely.
EXE An executable software application
SIS An executable Symbian software application
MIDlet An executable Java MIDP software application
SMS Short Message Service
MMS Multimedia Message Service
A management system through which digital certificates are Certification published, suspended, renewed or revoked. A Certification Management Authority typically runs certificate management systems to keep System track of their responsibilities and liabilities.
Appendix B
Interview Instruments
B.1 Representatives of Certification Program Offices & Certification Program Supporters
Background
1. What is your role in the organization?
2. How long have you been working for your organization?
3. Please describe your role in the design/management of the certification program.
Application Platform Certification Program
1. Could you briefly describe the certification program, in terms of Purpose, Scope,
Processes, Criteria, and their associated Costs
2. How does the program stamp/seal a certified application?
3. Can the program identify/detect an uncertified application? If so, How?
4. Can the program revoke/recall a certified application? If so, How?
Certification Authority Structure
1. Could you please describe your organizations role in the design/management of
the certification program?
2. How, according to you, involved is the platform promulgator [Symbian, Sun,
Qualcomm] in the design, establishment, and management of the certification
program?
a. In terms of investments, ownership, and administrative assistance?
b. In terms of encouraging/incentivizing certification by developers?
261 c. In terms of direct support provided to application certifying developers?
d. In terms of the ―final say‖ in accepting and/or rejecting applications?
3. Who would you identify as the primary and official supporters of the program?
[Operators, Device manufacturers, and Others]
4. Could you please describe the nature of your relation with the Certification
Program Office/Supporters?
5. Do you have any affiliation with the certification program‘s partners/supporters? If
so, how do you think it has influenced the support for the program?
6. Why was the process of testing for application certification outsourced to third-
party testing labs?
7. What, according to you, was the selection criterion for selecting ATLs?
8. How many ATLs were selected? And Why?
9. Do you think the certification program has changed as the program gained more
supporters/acceptance? If so –
a. How has it changed the certification criteria, if at all?
b. How has it changed the certification process, if at all?
c. How has it changed the certification costs, if at all?
10. More broadly, how has the platform certification program evolved/changed since
your organization started providing the certifications, if at all?
Imposed Certification Constraints
Certification Criteria
1. How rigorous and comprehensive do you think are the certification test cases in
identifying issues of Application – Design, Security, Compatibility?
2. According to your experience, Please comment on –
a. The ease of executing the certification test criteria/test-cases.
262 b. The extent to which the certification criteria can influence application
design, if at all.
3. How successful do you think application developers have been in certifying
applications? [Certification Failure]
a. What are the major issue(s) in failing applications?
b. Has certification success rate of submitted applications changed over
time? If so, how and why?
Certification Process
1. Could you please describe the certification process from application submission
to eventual distribution in detail to the best of your knowledge?
2. Are there any exceptions to the general process of certification? If so, please
describe.
3. Is there multiple certification options/mechanisms provided to different types of
developers for certifying their applications? If so, please describe.
4. According to your experience, Please evaluate the process of certification in
terms of the following –
a. The transparency of the certification process to the developers.
b. The usefulness of publicly available documentation on the certification
process.
c. The time it takes to certify an application compared to the time it takes to
execute the test criteria?
5. Does your organization provide additional support to developers for the
certification process? If so, how?
6. Has the process of certification changed since the certification program‘s
establishment? If so,
263 a. Could you please describe the changes?
b. Why were these changes introduced?
c. Do you think these changes have impacted the compatibility of certified
applications? If so How?
Certification Cost
1. What is your organizations role in establishing certification pricing? Please
describe.
2. If you were involved in certification pricing –
a. What were the primary factors that influenced certification pricing?
b. Were bulk certifications and discounts considered? Why or Why not?
3. Could you please comment on the cost of certification for your organization?
a. [Equipment required to test for certification]
b. [Availability of equipment required for certification testing]
c. [Cost and availability of qualified test engineers]
Market Effects and Comparison
1. What according to you is the role of certification in the mobile application market?
2. Please describe how the market is different compared to the hypothetical
situation where the certification program was not established?
3. Do you see a parallel of the certification programs in mobile applications market
to other industries/markets? If so, how are they similar/different?
4. Do you think that platform certification has made it easier/difficult for developers
to – [Response codes - Certification Criteria, Process, Cost]
a. Port applications across platforms? If so, How?
b. Rapidly develop applications? If so, How?
c. Deploy applications on different handsets? If so, How?
264 d. Focus more on developing new and creative applications? If so, How?
e. Enter new geographic markets? If so, How?
f. Generate economies of scale? If so, How?
g. Make distribution partnerships? If so, How?
5. Do you think platform certification has made it easier/difficult for new application
developers to develop and sell applications? Why or Why not?
a. [Response codes - Certification Criteria, Process, Cost]
b. [Response codes - Production and Marketing Benefits]
6. Do you think platform certification has increased/decreased the number of
developers on the platform?
7. Based on your experiences - how would you compare the certification program
with other platform certification programs in the mobile industry? –
a. In terms of Application design assistance and complexity?
b. In terms of Availability of technical and deployment support?
c. In terms of Application compatibility and interoperability?
d. In terms of Application‘s cost of production?
e. In terms of Application‘s Time-To-Market?
f. In terms of Application buyer support and recognition?
g. In terms of Increased or Decreased competition?
Wrapping up
1. Could you please share some of your contacts in other certification program
offices/network operators/device manufacturers/authorized certification labs who
would be in a position to help answer some of these questions? [Interview
Time/Rolling Sample]
265 B.2 Representatives of Authorized Certification Labs
Background
1. What is your role in the organization?
2. How long have you been working for your organization?
3. What is the geographic scope of your organization? – Offices and Sales
4. How many employees does your organization have?
Application Platform Certification Program(s)
1. How many mobile application certification programs does your organization
manage as an Authorized Certification Lab?
a. Platform Certification programs
b. Other Certification programs (including network operator and device
manufacturer application certifications and other hardware/software
certification programs)
2. Since when has your organization been involved with certification program(s)?
3. Could you please briefly describe your organization‘s role in each certification
program?
4. How many years of experience does your organization have with testing for
application platforms?
For the platform certification your organization provides [Symbian, Java ME,
BREW] –
Certification Authority Structure
1. Who is/are the sponsor(s) of the certification program your organization
manages?
266 2. What was your organization‘s role in the design of the certification program, if at
all?
3. Who according to you are the primary supporters of the certification program?
[Operators, Device manufacturers, and Others]
4. What is the nature of your relation with the certification program supporters?
5. How has the relation evolved, if at all?
6. How has the platform certification program evolved/changed since your
organization started providing the certifications? [Response Codes -
Administrative support vs. Endorsements vs. Adaptations of certification
program]
Imposed Certification Constraints
Certification Criteria
1. How rigorous and comprehensive do you think are the certification test cases in
identifying issues of Application – Design, Security, Compatibility?
2. According to your experience, Please comment on –
a. The extent to which the certification criteria influence application design, if
at all.
b. The ease of executing the certification test criteria/test-cases.
3. How successful do you think application developers have been in certifying
applications? [Certification Failure]
a. What are the major issue(s) in failing applications?
b. Has certification success rate of submitted applications changed over
time? If so, how and why?
Certification Process
267 1. Could you please describe the certification process from application submission
to certification in detail?
2. According to your experience, Please describe the process of certification in
terms of the following –
a. The transparency of the certification process to the developers.
b. The usefulness of publicly available documentation on the certification
process?
c. The time it takes to certify an application compared to the time it takes to
execute the test criteria?
3. Do you provide additional support to developers for the certification process? If
so, how?
4. Has the process of certification changed since the certification program‘s
establishment? If so,
a. Could you please describe the changes?
b. Why were these changes introduced?
c. Do you think these changes have impacted the compatibility of certified
applications?
Certification Cost
1. What is your role organization‘s in certification pricing?
a. Do you have flexibility in setting certification pricing?
b. Do you provide bulk certification discounts?
2. Could you please comment on the cost of certification for your organization?
a. [Equipment required to test for certification]
b. [Availability of equipment required for certification testing]
c. [Cost and availability of qualified test engineers]
268 3. Do you provide additional services in addition to platform certification? If so,
could you please describe these services?
Market Effects and Comparison
1. What according to you is the role of certification in the mobile application market?
2. Please describe how the market is different compared to the hypothetical
situation where the certification program was not available?
3. Do you see a parallel of the certification programs in mobile applications market
to other industries/markets? If so, how are they similar/different?
4. Do you think that platform certification has made it easier/difficult for developers
to – [Response codes - Certification Criteria, Process, Cost]
a. Port applications across platforms? If so, How?
b. Rapidly develop applications? If so, How?
c. Deploy applications on different handsets? If so, How?
d. Focus more on developing new and creative applications? If so, How?
e. Enter new geographic markets? If so, How?
f. Generate economies of scale? If so, How?
g. Make distribution partnerships? If so, How?
5. Do you think platform certification has made it easier/difficult for new application
developers to develop and sell applications? Why or Why not?
a. [Response codes - Certification Criteria, Process, Cost]
b. [Response codes - Technical and Marketing Benefits]
6. Do you think platform certification has increased/decreased the number of
developers on the platform?
269 7. [If your organization is responsible for multiple certification programs] Based on
your experiences - how would you compare the certification programs in terms of
–
a. Application design assistance and complexity?
b. Availability of technical and deployment support?
c. Application compatibility and interoperability?
d. Application‘s cost of production?
e. Application‘s Time-To-Market?
f. Application buyer support and recognition?
g. Increased or Decreased competition?
Business Model
1. What is your organizations core competency? [Testing, Platform Certification,
Application Porting, Application Development, Other Certifications]
2. Has your core competencies evolved since your appointment as an authorized
certification lab? If so, how?
3. What are the three most important challenges for your business as a platform
certification lab?
4. How has self-certification impacted your business, If at all?
5. Who would you identify as your competitors? Why?
Wrapping up
1. Could you please share some of your contacts in other certification program
offices/network operators/device manufacturers/authorized certification labs who
would be in a position to help answer some of these questions? [Interview
Time/Rolling Sample]
270 B.3 Representatives of Mobile Application Developers
Background
1. What is your role in the organization?
2. How long have you been working for your organization?
3. What is the geographic scope of your organization? – Offices and Sales
4. How many employees does your organization have?
5. Could you please describe the types of mobile applications that your organization
develops/publishes and distributes?
6. How many applications does your organization develop on average in a year?
Mobile Application Platforms
1. What mobile application platform(s) do(es) your organization use to develop
mobile applications?
2. How many years of experience does your organization have with the application
platform standards?
3. What according to you is the primary objective your organization‘s choice of
application development platform(s)? Please describe –
a. In terms of the fit between the platform strengths and your organization‘s
application types.
4. What additional development and distribution technologies does your
organization employ?
a. Please describe how these technologies assist application development,
deployment and distribution.
Mobile Application Platform Certification Programs
1. Does your organization certify applications?
271 2. For how long has your organization been certifying applications?
3. Has your organization been developing applications before the introduction of
platform certification?
4. Which platform certification programs does your organization use?
5. Which additional certification programs does your organization use?
(Operator/Device/Other)?
Certification Authority Structure
1. How would you describe the role of platform promulgators
[Symbian/Sun/Qualcomm] in certifying your applications?
2. Could you mention the three most important buyers of your organization‘s
Applications?
a. Mobile Operators? Or Mobile Device Manufacturers? Or Directly to End-
Users?
3. Do your primary buyers require platform certification? If so, which?
4. Do your primary buyers impose additional certification requirements? If so, what?
And how?
Imposed Certification Constraints
For the platform certification your organization uses [Symbian, Java ME, and/or
BREW] –
Certification Criteria
1. Please comment on the comprehensiveness of the certification criteria.
2. How rigorous do you think are the certification test cases in identifying issues of
Application
a. Design
b. Security
272 c. Compatibility (including backward platform compatibility)
3. To what extent do the certification criteria influence application design, if at all?
4. How easy do you think is executing the certification test cases before certification
submission?
5. How successful do you think your organization has been in certifying applications
since you started certifying?
a. Has your success rate changed over time? If so, how?
b. What according to you were the major issue(s) in failing applications?
Certification Process
1. Could you please describe the certification process in detail from application
submission to eventual distribution?
2. Please comment on the transparency of the certification process.
a. How clear do you think is the certification process?
b. How helpful is the publicly available documentation in understanding the
process?
3. How familiar are you with the certification usage agreements and clauses? If very
to somewhat, can you comment on the transparency of the agreement?
4. How long do you think it takes to certify an application compared to the time it
takes to execute the test criteria?
Certification Cost
1. Please comment on the cost of certification for your organization.
a. Direct cost to certify one application
b. Equipment required to test for certification
c. Availability of equipment required to test for certification
d. Cost and availability of qualified test engineers
273 2. How does not certifying applications affect your revenues and buyer/partner
relations, if at all? (opportunity cost)
3. When do you think did your organization first explore the certification option and
why?
Market Effects
1. Do you think that platform certification has made it easier/difficult for developers
to – [Response codes - Certification Criteria, Process, Cost]
a. Port applications across platforms? If so, How?
b. Rapidly develop applications? If so, How?
c. Deploy applications on different handsets? If so, How?
d. Focus more on developing new and creative applications? If so, How?
e. Enter new geographic markets? If so, How?
f. Generate economies of scale? If so, How?
g. Make distribution partnerships? If so, How?
Perceived Certification Benefits
1. Has platform certification assisted your organization in developing applications
on the platform standard? [Production support] If so, Please describe in terms of
–
a. Application design assistance and complexity
b. Availability of technical and deployment support
c. Application compatibility and interoperability (including backward platform
compatibility)
2. Has platform certification assisted your organization in distributing applications?
[Marketing Support] If so, Please describe in terms of –
a. Application‘s cost of production
274 b. Application‘s Time-To-Market
c. Application buyer support and brand recognition
d. Co-marketing with platform promulgators or other application distributors
e. Increased or Decreased competition
Market Effects and Comparison across Certification Programs
1. Do you think that [the level of production support received from] platform
certification has made it easier/difficult for other developers to –
a. Port applications across platforms? If so, How?
b. Rapidly develop applications? If so, How?
c. Deploy applications on different handsets? If so, How?
d. Focus more on developing new and creative applications? If so, How?
2. Do you think that [the level of marketing support received from] platform
certification has made it easier/difficult for developers to –
a. Enter new geographic markets? If so, How?
b. Generate economies of scale? If so, How?
c. Make distribution partnerships? If so, How?
3. Do you think platform certification has made it easier/difficult for new application
developers to develop and sell applications? Why or Why not?
a. [Response codes - Certification Criteria, Process, Cost]
b. [Response codes - Production and Marketing Benefits]
4. Do you think platform certification has increased/decreased the number of
developers on the platform?
5. If your organizations use multiple certification programs - How would you
compare the certification programs in terms of (based on your experiences) –
a. Application design assistance and complexity?
275 b. Availability of technical and deployment support?
c. Application compatibility and interoperability? (including backward
platform compatibility)
d. Application‘s cost of production?
e. Application‘s Time-To-Market?
f. Application buyer support and recognition?
g. Increased or Decreased competition?
Wrapping up
1. Once again, what according to you are the primary objectives your organization‘s
choice of platform certifications?
2. Could you please share some of your contacts in other application
developers/publishers who would be in a position to help me in this study?
[Interview Time/Rolling Sample]
Appendix C
Research Participant Recruitment Emails
C.1 Mailing the Certification Program Offices & Certification Program Supporters
Subject: Requesting Participation in an Academic Study
Dear [Certification Program Office/Supporter] Management,
I am a PhD Student at The Pennsylvania State University, USA, conducting a study on the evolution of various mobile computing platforms. In particular, I am exploring mobile application certification, technology standardization, and developer management issues across the mobile value chain.
This study is an academic project for my dissertation, where I am trying to highlight some of the practical issues in managing the evolution of the mobile computing ecosystem. As part of my research, I am conducting interviews with several global mobile developers, publishers, platform vendors, and application certification agencies worldwide to understand the global mobile applications market through their experiences.
In that regard, I was wondering if someone at the [Symbian Signed, Java
Verified, True BREW] program office could take out some time to provide their experiences and perspective on the growth of the [Platform] and the [Symbian Signed,
Java Verified, True BREW] certification program. As [Platform] is one of the most ubiquitous computing platform for mobile devices, the [Symbian Signed, Java Verified,
True BREW] Program Office‘s help can provide unmatched insights for my study.
277 Please note that the participating member of the program office will not be asked to share information and experiences that are considered confidential by them, the program office, or program‘s member organizations. Further, they can withdraw their participation at anytime during the study. If you have any questions about the study, please feel free to email me at [email protected].
I would really appreciate if someone at the Java Verified program office can take out about 30 minutes to an hour for a phone conversation. It would be of immense help for my study.
I look forward to hearing from you and thank you for your time.
Regards,
Ankur Tarnacha PhD Candidate College of Information Sciences and Technology The Pennsylvania State University Phone: +1-814-883-5441 http://www.personal.psu.edu/aut106/
C.2 Mailing the Authorized Certification Labs
Subject: Requesting an Phone Conversation
Hello [Organization_Name]‘s Management,
I am a graduate student at Pennsylvania State University (USA), conducting a study for my thesis on the evolution of mobile computing platforms and their effects on the growth of the mobile applications market. As part of my research, I am interviewing several mobile developers, publishers, testing agencies, and platform vendors worldwide to understand the global mobile application market through their experiences.
In that regard, [Organization_Name] was referred by a developer I interviewed recently. I was wondering if it is possible to have a telephone conversation with a
278 member of management at [Organization_Name]. I am interested in
[Organization_Name]‘s role in the market and insights and perspective on some of the development, testing and certification issues.
As [Organization_Name] is a [True BREW, Symbian Signed, Java Verified]
Certifier, [Organization_Name]‘S participation can provide crucial insights for my study.
In return for your participation, I can provide you with my findings at no charge. It would be great if a member of the management can take out about 30 minutes to an hour for a phone conversation.
I look forward to hearing from you and thank you for your time.
Regards,
Ankur Tarnacha PhD Candidate College of Information Sciences and Technology The Pennsylvania State University Phone: +1-814-883-5441 http://www.personal.psu.edu/aut106/
PS: Please note [Organization_Name]‘s participation in this study is confidential.
In the event of any publication resulting from the research, no personally identifiable information will be shared. Further, the participating member will not be asked to share information and experiences that they are not comfortable sharing, and they can withdraw their participation at anytime during the study.
If you have any questions about the details of the study, please feel free to email me at [email protected].
C.3 Mailing on Developers’ Generic Email Addresses
Subject: Participation Request
279 Dear [Organization_Name]‘s Management,
I am a researcher at The Pennsylvania State University, USA, conducting a study on the evolution of mobile computing platforms and their effects on the development, deployment, and distribution of mobile applications. As part of my research, I am conducting interviews with several mobile developers, publishers, and platform vendors worldwide to understand the global mobile application market through their experiences.
In that regard, I would love to have a phone conversation with a member of the management to discuss [Organization_Name]‘s business, experiences and issues faced in the mobile application market. As one of the leading mobile application developers for
[BREW, Java ME, Symbian] platforms, [Organization_Name]‘s participation can provide crucial insights for my study.
In return for your participation, I will provide you with my findings at no charge.
It would be great if a member of the management can take out about 30 minutes to an hour for a phone conversation. I look forward to hearing from you and thank you for your time.
Regards,
Ankur Tarnacha PhD Candidate College of Information Sciences and Technology The Pennsylvania State University Phone: +1-814-883-5441 http://www.personal.psu.edu/aut106/
PS: Please note that [Organization_Name]‘s participation in this study is confidential. In the event of any publication resulting from the research, no personally identifiable information will be shared. Further, the participating member will not be asked to share information and experiences that they are not comfortable sharing, and they can withdraw their participation at anytime during the study. If you have any
280 questions about the details of the study, please feel free to email me at [email protected].
C.4 Mailing a Rolling Developer Contact Directly
Subject: Requesting a Phone Conversation
Hello Mr. [Direct_Contact],
I am a researcher at The Pennsylvania State University, USA, conducting a study on the evolution of mobile computing platforms and their effects on the development, deployment, and distribution of mobile applications. As part of my research, I am conducting interviews with several mobile developers, publishers, and platform vendors worldwide to understand the global mobile application market through their experiences.
I was referred to you by [XYZ], who suggested that you might be able to help. I would love to have a phone conversation with you to discuss [Organization_Name]‘s business, experiences and issues faced in mobile application development and distribution. As [Organization_Name] is one of the leading mobile application developers for [BREW, Java ME , Symbian] platforms, your participation can provide crucial insights for my study.
In return, I can provide you with the findings of my study at no charge.
It would be great if you can take out about 30 minutes to an hour for a phone conversation. I look forward to hearing from you and thank you for your time.
Regards,
Ankur Tarnacha PhD Candidate College of Information Sciences and Technology The Pennsylvania State University Phone: +1-814-883-5441
281 http://www.personal.psu.edu/aut106/
PS: Please note that you will not be asked to share information and experiences that you are not comfortable sharing. Further, you can withdraw their participation at anytime during the study. If you have any questions about the details of the study, please feel free to email me at [email protected]
Appendix D
List of Supporting Documents
The following documents were collected during the course of the study. These documents primarily provide information on the mobile computing platforms and their certification programs. Some of these documents were directly referenced in the study, while others were used to substantiate information provided by the interviewed key experts.
General Functionality and Stability Test Procedure (1999), James Bach, 22 pages, Satisfice Inc
J2ME Building Blocks for Mobile Devices (2000), White Paper on KVM and the Connected, Limited Device Configuration (CLDC), Sun Microsystems
Mobile Information Device Profile (2000), JCP Specification Version 2.0, Java 2 Platform Micro Edition, Sun Microsystems
How do I get my Symbian OS application signed? A guide to Symbian Signed (2000), Version 2.4, Symbian
Connected, Limited Device Configuration (2000), Specification version 1.0a, Java 2 Platform Micro Edition, Sun Microsystems
Connected Limited Device Configuration (2000), Specification version 1.1, Java 2 Platform Micro Edition, Sun Microsystems
Over The Air User Initiated Provisioning Recommended Practice for the Mobile Information Device Profile (2001), Version 1.0, Sun Microsystems
MIDP APIs for Wireless Applications: A Brief Tour for Software Developers (2001), White Paper, Sun Microsystems
Over The Air User Initiated Provisioning Recommended Practice for the Mobile Information Device Profile (2001), Version 1.0, Sun Microsystems
An Introduction to the API Capabilities of BREW (2002), Mahesh Moorthy, BREW 2002 Conference
283
The Road to Profit is Paved with Data Revenue (2002), White Paper, Qualcomm Internet Services
TRUE BREW™ Testing Overview (2002), Karen Crossland, BREW 2002 Conference, Qualcomm Internet Services
Application Developer‘s TRUE BREW Test Guide: Requirements and Test Cases (2002), 80-D4187-1 Rev E, Qualcomm Internet Services
Application Developer‘s TRUE BREWTM Process Overview (2002), 80-D4299-1 Rev C, Qualcomm Internet Services
Application Distribution with Verizon Wireless (2002), Adrian Velthuis, White Paper, Verizon Wireless
BREW and J2ME: A Complete Wireless Solution for Operators Committed to Java (2003), White Paper, Qualcomm Internet Services
BREW Delivery System (BDS) Overview (2003), White Paper, Qualcomm Internet Services
TRUE BREW® Testing: Developers Guide to TRUE BREW ―Passed With Notes‖ Process (2003), 80-D4527-2 Rev. A, Qualcomm Internet Services
TRUE BREW® Process Overview (2003), 80-D4299-1 Rev. D, Qualcomm Internet Services
Adapting your MIDlets to the Sony Ericsson T610/T616/T618 and Z600 (2003), Special Interest Paper, Sony Ericsson
Java™ in Sony Ericsson mobile phones (2003), White Paper, Sony Ericsson
Java™ Device Test Suite: Go to Market Faster with High-Quality Product (2003), White Paper, Sun Microsystems
Java™ Technology for the Wireless Industry (2003), Specification Version 1.0, Java 2 Platform Micro Edition, Sun Microsystems
Understanding MIDP 2.0's Security Architecture (2003), Jonathan Knudsen, Sun Microsystems
Why is a different operating system needed? (2003), White Paper, Rev 3.0, Symbian
BREW Connection (2004), Qualcomm Internet Services, Spring 2004
Starting with BREW (2004), 80-D4725-1 Rev. A, Qualcomm Internet Services
284
Application Commercialization: The Role of TRUE BREW® Testing (TBT) (2004,2005,2006), BREW 2004, 2005, and 2005 Conferences, Qualcomm Internet Services
The Java Verified Program Guide (2004), Version 1.0, UTI
Unified Testing Criteria for Java(TM) Technology-based Applications for Mobile Devices (2004), Version 1.4, UTI
Unified Testing Initiative (2004), White Paper, Sun Microsystems
Symbian Signed: Outline of Self Certification setup and audit process (2004), Version 1.0, Symbian
Symbian Signed: Self Certification Program – Process, Policy and Guidelines (2004), Symbian
Creating the mass market for Symbian OS (2004), White Paper, Version 1.4, Symbian
Symbian on Java (2004), Martin De Jode, Version 2.05, Symbian
How do I get my Symbian OS application signed? A guide to Symbian Signed (2005), Version 2.3, Symbian
BREW App Note: Privilege Checking (2005), 80-D4924-1 Rev. A, Qualcomm Internet Services
Overview of Sprint Nextel‘s MIDP 2.0 API Security (2005), Sprint Application Developer Program, Sprint Nextel
The Recommended Security Policy for GSM/UMTS Compliant Devices (2005), Addendum to the Mobile Information Device Profile version 2.0.1, JCP, Sun Microsystems
Technical Note: Missing Root Certificates For Java Verified (2005), Version 1.0, Forum Nokia
Unified Testing Criteria: The Main Differences Between the Criteria Versions 1.4 and 2.0 (2005), Version 1.0, UTI
Unified Testing Criteria for Java(TM) Technology-based Applications for Mobile Devices (2005) Version 2.0, UTI
At the heart of the smartphone revolution (2005), White Paper, Symbian
Testing Checklist for Symbian C++ Applications (2006), Forum Nokia
285
Unified Testing Criteria for Java(TM) Technology-based Applications for Mobile Devices (2006), Version 2.1, UTI
MIDP 2.0: Signed MIDlet Developer's Guide (2006), Version 2.0, Forum Nokia
Nokia Test Criteria for Java™ ME Applications (2006), Version 1.0, Forum Nokia
Getting Started with Mobile Java (2006), v1.1, Forum Nokia
Signing applications for Sony Ericsson UIQ 3 phones (2006), Developer Guidelines, Sony Ericsson
Symbian Signed Test Criteria (2006), Version 2.10.0, 10 February 2006, Symbian
Symbian Signed Test Criteria (2006), Version 2.11.0, 13 November 2006, Symbian
Porting to UIQ 3 for Sony Ericsson UIQ 3 phones (2006), Special Interest Paper, Developer World, Sony Ericsson
Java™ Platform, Micro= Edition, CLDC – MIDP2.0for Sony Ericsson UIQ 3 phones (2006), Developer Guidelines, Developer World, Sony Ericsson
Signing applications for Sony Ericsson UIQ 3 phones (2006), Developer Guidelines, Developer World, Sony Ericsson
Symbian OS Version 9 and Secure Hardware is the Foundation for Secure DRM (2006), Craig Heath and Alexander Klimov, Symbian
Platform Security - a Technical Overview (2006), Mark Shackman, Version 1.2, Symbian
Testing and Signing with Symbian Platform Security (2007, 2006, 2006), Version 1.5, 1.4, 1.3, Nokia Corporation deliveryOne Overview (2007), Tech-706, BREW 2007 Conference
Real World Location Deployments (2007), Kevin Tsurutome, BREW 2007 Conference
Evolution of the BREW Solution (2007), BREW 2007 Conference
TRUE BREW® Test Self-Test Program (2007), 80-D4081-1, Rev. C, Qualcomm Internet Services
TRUE BREW® Test Submission Guide (2007), 80-D7258-2 Rev. A, Qualcomm Internet Services
Application Developer‘s TRUE BREW Test Guide: Requirements and Test Cases (2007), 80-D4187-1 Rev D, Qualcomm Internet Services
286
Security Requirements for Authorized Wireless AT&T Devices: An Overview of AT&T Security Certificate Architecture Policies (2007), Security White Paper, Document Number 16047, Rev 1.0, AT&T Developer Program
Mobile Information Device Profile (MIDP) 2.0: Application Testing and Signing (2007), Motorola
Introduction to Mobile Java (2007), v1.2, Forum Nokia
Java™ Platform, Micro Edition, CLDC – DoJa™ 2.5 OE (2007), Version R2A, Developer Guidelines, Sony Ericsson
Java™ Platform, Micro Edition, CLDC – MIDP 2.0 (2007), Developer Guidelines, Sony Ericsson
Java Verified— A Description and Update to the Verification and Signing Process for the Java ME Application Developer (2007), TS-5397, JavaOne Conference
Tackling Java ME Device Fragmentation: Orange and Sun Collaboration (2007), TS- 5051, JavaOne Conference
Avoiding Common Failures in Symbian Signed and Nokia Tests (2007), Forum Nokia
The UIQ Platform for mobile applications in Sony Ericsson phones (2007), Tutorial, Developer World, Sony Ericsson
Application Integrity and Security for mobile applications in Sony Ericsson phones (2007), Tutorial, Developer World, Sony Ericsson
Releasing an Application for mobile applications in Sony Ericsson phones (2007), Tutorial, Developer World, Sony Ericsson
Routes to Market for mobile applications in Sony Ericsson phones (2007), Tutorial, Developer World, Sony Ericsson
Phone Manufacturer or Platform Approved Capability Request Form (2007), Symbian Signed
Nokia Test Criteria for Symbian C++ Applications (2007), Version 1.8, Forum Nokia
Signing Tips part of the Essential Symbian OS series (2007), 2nd Edition, Symbian
Appendix E
A Primer on Network Markets
The effects of platform certification on the mobile application market are influenced to some extent by the characteristics of the overall mobile telecommunications market. One significant characteristic of the market is that it is subject to, what are commonly referred to as ―network effects‖, and thereby exhibits characteristics of a so-called ―network market‖.
In this appendix, I present the theoretical literature on the industrial organization of network markets and highlight the core concepts, attributes, and forces that shape networked markets. In particular I elaborate on different types of network effects and identify the characteristics and structural attributes of network markets. Further, literature on the strategic conduct and performance of firms in network markets is also reviewed.
Specific emphasis is given to the importance of standards, compatibility, and complementarity in understanding the strategic behavior of firms in network markets. In doing so, I seek to situate this study in the broader context of industrial organization of network industries.
E.1 Network Effects and its Sources
Many industries are characterized by network effects, wherein the consumer benefit or utility derived consumption depends on the number of other consumers using similar goods. The goods in such industries have little or no value if used in isolation and their utility increases as additional consumers purchase similar goods. For instance, the
288 utility of a fax machine to a user depends on the number of other fax machine users. A fax machine used in isolation has no utility if there are no fax machine users to exchange information and its utility increases with increasing number of fax machine users. Such positive consumption/demand externalities are called network effects.
Markets exhibiting network effects differ from traditional industries in terms of their structure, conduct and performance. Extensive research has been conducted, especially by economists, to understand the development, growth, and strategic implications of network effects. Some of the pioneering theoretical studies on network effects were conducted in the telecommunications industry, where network effects were first observed as a positive feedback or demand externalities (Oren & Smith, 1981;
Rohlfs, 1974). Michael Katz and Carl Shapiro (1985) and many other economists subsequently termed such effects as "network externalities". A network externality is classically defined as the increasing utility that a user derives from consumption of a product, as the number of other users who consume the same product increase (Katz &
Shapiro, 1985). In other words, a network externality is the increase in the net value of an ―action‖ as the number of ―agents‖ taking equivalent actions increases173 (Liebowitz &
Margolis, 1994).
Katz and Shapiro (1985) also distinguished between two types of network externalities – direct and indirect. Direct network externalities are generated when the value of a good depends on the number of the agents consuming the exact same
173 An increase in the utility a user derives from consumption of a product as the number of other users who consume the same product increase is more formally referred as a ―positive network externality‖. A negative network externality, on the other hand, is defined as the reduction in the utility as the number of users increase. Negative network externalities result from resource limitations. For instance, a freeway is a limited resource and as every additional driver on the freeway decreases the value of the freeway to drivers (users) on the freeway. However, for the purpose of the literature review I considered positive network externalities as they are more prominent in resource rich ICT industries.
289 product. The use of telephones, fax machines, and computers on communication networks are typical examples of products that exhibit such direct network externalities.
Indirect network externalities, on the other hand, arise when the value of a product increases as the number or the variety of, complementary products increases. The key difference between direct and indirect externalities is that direct externalities depend on the network of consumers of a product, whereas indirect externalities depend on the extended network of consumers of a product‘s supporting/complementary products. A primary example often quoted in the literature is the indirect effect of the availability of complementary software for hardware products. Other examples include the availability of camera lenses for camera bodies and cartridges for printers (Katz & Shapiro, 1994;
Schmidt & Werle, 1998). In essence, markets for complements to network goods exhibit indirect network externalities. Such indirect externalities have also been referred to in the literature as complementary externalities or the ―hardware/software‖ paradigm (Church &
Gandal, 1992; Katz & Shapiro, 1994).
In order to understand the market implications of network effects, various researchers have identified their sources and mechanisms (Besen & Farrell, 1994;
Nicholas Economides, 1996). Four essential themes have been widely observed as the source of network effects – consumer expectations, coordination between consumers, switching costs, and product compatibility.
Firstly, network externalities are driven by consumer expectations. Consumers choose products in network markets based on the expected adoption by others since the product‘s value depends on the number of others purchasing similar products. Rival firms in network markets hence try to influence consumers‘ expectations in order to maximize their profits. Sales figures are often exaggerated to show leadership in the installed base over rivals in order to attract consumers. Besen and Farrell (1994)
290 illustrate this point by elucidating how IBM and Microsoft tried to influence consumer expectations so as to enhance the adoption of OS/2 and Windows respectively (Besen &
Farrell, 1994). Secondly, network externalities are driven by coordination between consumers. If consumers are able to coordinate product purchases, they are able to reduce their risk of choosing a weak network and enjoy higher network benefits in a larger, stronger network. Hence, the greater the possibility of coordination among consumers the greater will be the network effects (Farrell & Saloner, 1988; Schmidt &
Werle, 1998). Thirdly, switching costs for consumers between products in network markets has also been observed to play a critical role in determining the extent of network effects (Farrell & Saloner, 1986). Due to incompatibilities between networks and their complementary goods, consumers cannot freely switch between competing products in network markets. Hence, they face switching costs or barriers that prevent them from entering into another network. If one considers not only the change in product but also the change in the network of users that switching brings, these costs are also referred to as ―social cost of switching‖ wherein the consumer not only abandons the product but also the network of consumers and complements a product enjoys
(Klemperer, 1987).
Finally, product compatibility with complementary artifacts plays a critical role in determining the magnitude of network effects (Church & Gandal, 1996). Although definitions of compatibility vary in the literature (Nicholas Economides, 1996; Farrell &
Saloner, 1992), two products are compatible when the cost of combining them to produce additional services is free (David & Greenstein, 1990; Gandal, 1995; Schmidt &
Werle, 1998). A product with greater number and diversity of compatible complementary products can create higher switching costs for the consumer (Church & Gandal, 1996).
291 Hence, a product market with sizeable and robust complementary product markets will exhibit greater network externalities.
E.2 Characteristics of Network Markets
Researchers have also conceptually formalized network markets by studying how they differ from traditional markets. Economists, in particular, have shown that network markets are characterized by – 1) critical consumer mass; 2) greater market instability; and 3) historical path dependence (David, 1985; Nicholas Economides, 1996;
Katz & Shapiro, 1986).
Firstly, network markets are driven by the expectations of a critical consumer mass. The demand for a good in a network market is a function of the expected size of the network or its extended complementary network (Besen & Farrell, 1994; Nicholas
Economides, 1996; Katz & Shapiro, 1985, 1994). This size of the network of consumers is often referred to as the ―installed base‖ for the product (Farrell & Saloner, 1986).
Various economists have shown that there exists a critical mass of installed base that is required for sustainable growth of a network market (Nicholas Economides, 1996).
Economides and Himmelberg (1995) portray critical mass as a "chicken and the egg" problem, wherein the expected network size can be too small to induce consumers into the network thereby halting network growth (Nicholas Economides & Himmelberg,
1995).
Secondly, network markets are instable or ―tippy‖ (Besen & Farrell, 1994). They are characterized by so called ―bandwagon effects‖, wherein the value and adoption of a product exponentially increases after the critical mass of consumer is reached (Rohlfs,
2001). This bandwagon effect can tip the balance of competing products or technologies
292 towards a product with a larger consumer network. Researchers have observed such bandwagon effects in many network markets including standards competition in videocassette, fax machine, compact disc, television, and internet markets (Rohlfs,
2001).
Finally, network markets exhibit positive adoption feedback, wherein consumers can get ―locked-in‖ to a product as the consumer network grows (Arthur, 1989; David,
1985). History in product or technology usage is hence important to understand network market evolution. This effect is often referred as ―path dependence‖. Thus, path dependency creates inefficiencies, the extent of which are partially determined by small differences in initial conditions that lead to outcomes that are costly to change (Liebowitz
& Margolis, 1994). Hence, effects of decisions by earlier adopters on the decisions of later adopters are often significant in network markets. The case of the QWERTY keyboard is a classic example of the path dependence problem (David, 1985). The dominance of the QWERTY keyboard today is not thought to be due to its superiority for typing but instead because it was invented before the Dvorak keyboard (Besen & Farrell,
1994; David, 1985; Katz & Shapiro, 1994).
The observed importance of critical mass, bandwagon effects, and path dependence in network markets has implications for the competitive landscape as well.
Researchers have shown using examples of various network markets that a qualitatively inferior technology/product can effectively compete with a superior technology/product and win if it can establish a critical installed base early (Katz & Shapiro, 1986, 1992).
Users who invest in a network product that turns out to be an inferior technology later, face ―excess inertia‖ and switching costs to adopt a superior technology (Farrell &
Saloner, 1985, 1986). As the adoption process is path dependent, a relatively inferior technology or product can win given a strong established network.
293 E.3 Conduct and Performance in Network Markets
Given the peculiar characteristics of network markets, various researchers have highlighted strategic behavior imperatives in network markets. Three essential themes have been emphasized in understanding the conduct and performance of network markets – the importance of technology standards, product compatibility, and leveraging product complementarity.
E.3.1 Importance of Technology Standards
Technology standards are defined in the literature as ―a set of technical specifications adhered to by a producer‖ to create standardized products (David &
Greenstein, 1990). The importance of establishing technology standards in network markets has received considerable attention in the literature. As network markets are highly instable due to positive adoption feedback, they exhibit inefficiencies and can often lead to market failure. Socio-economic impact of such inefficiencies can potentially be significant for the introduction and evolution of innovative products (Farrell & Saloner,
1985). Public policy and industrial organization literature emphasizes the importance of technology standards to alleviate such inefficiencies (Besen & Farrell, 1994; Gandal,
1995, 2002). Once a standard is established in a network market, products can be developed based on the accepted standard so as to leverage the network externalities for faster product adoption (Wegberg, 2004a).
Although technology standards enhance the efficiency of a network market, various researchers have emphasized the importance of the standards setting or standardization in achieving the socio-economic benefits. Standards can be created
294 through collaborative (committee-based) mechanisms or competitive market forces
(market-based) (Farrell & Saloner, 1988). In committee-based standardization a standard is agreed upon by a committee and then introduced into the market. This provides a framework to achieve technical coordination, wherein globally recognized standards development organizations (SDOs) or industry consortia document a standard and attempt to build a market consensus (Jakobs, 2000; Weiss & Cargill, 1992).
Research suggests that committees, although complex, play a significant role in ensuring market efficiencies by creating technologically integrated business communities
(Hawkins, 1999). The literature also provides key arguments in favor of the committee- based approach, which include potential for increased social welfare, greater economies of scale, and affordable product prices (Blind & Thumm, 2004; Ehrhardt, 2004; Fomin &
Keil, 2000). In market-based standardization, multiple standards are introduced into a market to compete for the position of ―de-facto standard‖ (Funk & Methe, 2001). This process of standard selection is also often called ―ex-post standardization‖, as a technological standard is accepted as an industry-wide standard if more users adopt it.
The proponents of the market-based approach point to the basic drawbacks of the centralized approach, which include the possibility of stifling innovation in an immature market, a static, inflexible outlook toward a dynamic market, a time-consuming approach, and the possibility of mandating an inferior standard/technology (David &
Greenstein, 1990; Gifford & Stalebrink, 2002; Wegberg, 2004a).
E.3.2 Product Compatibility
Another theme emphasized in the literature critical for the evolution of network markets is product compatibility. Establishment of technology standards subsequently
295 assists actors in developing standardized products thereby alleviating market inefficiencies and instability created by path dependency and bandwagon effects (Farrell
& Saloner, 1985). However, many researchers have observed that actors in network markets often attempt to strategically leverage network effects to out-compete rivals and create a monopoly (Garud & Kumaraswamy, 1993; Windrum, 2004). This can be done by creating path dependence by using proprietary technology or manipulating the development and adoption of technological standards (Besen & Farrell, 1994; Farrell &
Saloner, 1986; Gartland, 2005).
In order to address such concerns researchers have gone beyond standardization and explored a more fundamental concern in ensuring sustainable socio-economic efficiency in network markets – product compatibility. Research suggests that, although a standard is widely accepted, firms often attempt to differentiate their products by altering a standard‘s implementation in their products (David &
Steinmueller, 1994; Egyedi & Dahanayake, 2003; Egyedi & Hudson, 2005). This can make standardized products incompatible, which gives an opportunity to producers to exploit network effects in marketing their products and retaining existing customers.
From a welfare perspective, this might lock-in consumers in a potentially inferior technology where multiple technologies compete (Fomin & Keil, 2000).
Researchers have discussed the importance of niche market opportunities, tools and strategies in alleviating incompatibilities and foster welfare gains. Farrell and
Saloner (1992), for instance, stress the development of interfaces, converters and adapters to increase compatibility in realizing the economic benefits of standardization
(Farrell & Saloner, 1992). More recent literature also discusses how compatibility can be achieved through standardization through various forms of initiatives, be it formal committees, consortia, or strategic alliances of standard promoting firms (Egyedi, 2001;
296 Egyedi & Joode, 2004). In particular, studies by Tineke M. Egyedi discuss various forms of standardization initiatives in open source software and provide a coordination framework through which standardization initiatives can address compatibility. Such standardization strategies are referred to as ―compatibility strategies‖ that can be employed by standardization committees, consortia, or alliances alike in ensuring compatibility across standards (Egyedi, 2001; Egyedi & Joode, 2003, 2004).
E.3.3 Systems Competition and Complementarity
In addition to the role of standardization and compatibility in assessing conduct and performance of network markets, the concept of ―systems competition‖ has attracted considerable attention in the literature. Katz and Shapiro (1994) formally defined product systems as a group of ―strongly complementary‖ products that generate value in combination (Katz & Shapiro, 1994). Examples of strongly complementary products include nuts and bolts that together provide fastening services; ATM machines and cards that together provide transaction services; and camera bodies and lenses that together provide photographic services. Conceptually such markets are complementary, wherein growth and success of one strongly depends on the other. In such markets product complements compete together as a complementary system for widespread adoption (Dobson, 2006).
Systems competition is fairly common in network markets and poses coordination challenges for both firms and consumers alike. A firm developing a new architecture for a microprocessor, for instance, must know whether complementary software will be provided to work on the new microprocessor. Although issues of coordinating such investments arise in many markets, the sort of coordination required
297 by systems competition is often more extensive employing mechanisms for long-term contractual coordination with component suppliers and industry-wide standard development activities (Katz & Shapiro, 1994; Wegberg, 2004b).
Systems competition and product complementarity have especially been observed by economists in ICT industries. As mentioned above, such system effects have also been referred to as the ―hardware/software‖ paradigm, wherein the success of a hardware product depends not merely on its technological advantages, but also (and often more crucially) on varieties of software applications available in the market (Church
& Gandal, 1992). The hardware/software paradigm explains such effects as an indirect network externality that is created by increased availability of complementary software products (Katz & Shapiro, 1994). Researchers have developed several models illuminating the hardware/software paradigm to understand technology adoption, market structure, and strategic behavior of firms in networked complementary markets (Church
& Gandal, 1992, 1993, 1996; Nocholas Economides & Salop, 1992; Gandal, 1995).
Further, various empirical studies have documented the influence of complementary network externalities on the economics (Brynjolfsson & Kemerer, 1996) and structural evolution of ICT industries (Bresnahan & Greenstein, 1999; Gallagher & Park, 2002;
West & Dedrick, 2000).
Appendix F
A Primer on Public Key Infrastructure
Public Key Infrastructure or PKI is a security architecture that provides an increased level of confidence for exchanging information in unsecure environments. The
PKI architecture allows parties in a dialog to establish recipient and sender confidentiality and provides integrity of information exchanged between them174. These guarantees are delivered using a mathematical technique called Public Key
Cryptography that uses a pair of related cryptographic keys to verify the identity of the sender (signing) and/or to ensure privacy (encryption). The PKI techniques were primarily developed to secure information exchange over insecure networks such as the
Internet. PKI can also be used just as easily for information exchanged over private networks, including corporate internal networks.
F.1 Public Key Cryptography
Public key cryptography uses a pair of mathematically related cryptographic keys often called the public-private key pair. If one key is used to encrypt information, then only its related key can decrypt that information. A public key of this pair is made public and is freely distributed and available for all users. The other key is a public-key- corresponding (and unique) private key, which is kept secret and not shared amongst
174 Information integrity refers to a guarantee that the information has not been tampered with during its exchange
299 users. A private key enables you to prove, unequivocally, that you are who you claim to be.
In practice, a user generates a pair of public/private key and publically shares the public key with all the other users. If someone wants to send confidential information, they encrypt the information with your public key and send it across an unsecure environment/network. You can then decrypt the information using your private key. As you are the creator of your public-private key pair, only you can decrypt the information message using the private key. Hence, the person using the private key can be certain that the information it is able to decrypt must have been intended for them. In this way the information recipient is authenticated.
However, the recipient cannot be certain who the information is from. The PKI allows for that as well. If the sender wishes to prove to a recipient that they are the source of the information they use their private key to digitally sign a message (a digital signature). Unlike the regular handwritten signature, this digital signature is different every time it is made. A unique mathematical value, determined by the content of the message, is calculated and then this value is encrypted with the sender‘s private key – creating the digital signature for this specific message. The digital signature typically attached to the end of the message and sent. The sender‘s public key is then retrieved by the recipient to compare the digital signature of message contents with those sent by the sender. If the values match, the recipient knows that the person controlling the private key corresponding to the public key sent the information. They also know that the information has not been altered since it was signed. In this way the PKI authenticates the sender and also guarantees information integrity.
Public key cryptography is therefore used for the encryption/decryption as well as signing/verification of information. Encrypting information ensures privacy by preventing
300 unintended disclosure, and signing messages authenticates the sender of the message and ensures the message has not been modified since it was sent.
F.2 Digital Certificates
A digital certificate is the information that refers to a public key that has been digitally signed by an independent entity called the Certification Authority (CA).
Certificates typically include information about the published identity of the generator of a public-private key pair, the key length, the encryption algorithms used, and dates of validity of the certificate and the actions the key can be used for. A certificate is not essential to operating a PKI, but provides a scheme to locate information about the owner of a private key. People receiving information protected using a public key system with digital certificates can check with the CA to receive the identity/contact information submitted to the CA by the sender. This provides user identity details in addition to information confidentiality and integration provided by the public key cryptography.
F.3 Certification Authority
As mentioned above, digital certificates store the public keys along with other relevant information such as user information, expiration date, and its usage. These digital certificates are stored in a secure database that is maintained by a Certification
Authority or CA. A CA issues and verifies digital certificates. The CA takes responsibility for identifying the correctness of the identity of the person asking for a certificate to be issued, and ensures that the information contained within the certificate is correct.
301 A user applying for a certificate from a CA typically generates their own key pair and sends a signed request containing their public key to the CA for validation. The CA then makes various background identity checks to assess that you are who you say you are. The CA could be thought of as the PKI equivalent of a passport agency. Once the user provides the necessary credentials to confirm their identity, the CA issues a digital certificate. The issued digital certificates are also digitally signed by the CA for users to know that the information contained in the certificate is authentic and confirmed by the
CA.
A CA may provide different classes of certificates based on the quality of the checks that were carried out before the certificate was issued. There are four general classes of certificate – Class 1, 2, 3 and 4. Class 1 certificates can be acquired by simply supplying an email address, while Class 2 certificates require additional personal information to be supplied. Class 3 certificates, on the other hand, can only be acquired after checks have been made as to the requestor‘s identity. Further, Class 4 certificates are used by governments and organizations needing very high levels of identity verification.
VeriSign, Geotrust, Entrust, and RSA security are examples of prominent independent organizations that act as certification authorities for various types of digital certificates.
F.4 Certificate Verification and Revocation
As mentioned above, the public key certificate is digitally signed by the CA to prevent its modification or falsification. This signature is verified and validated against the digital certificates of a list of approved ―Root CAs‖ contained within various software
302 applications such as internet browsers. As the CA certificates embedded in various software applications are at the root of all certificate validation, their certificates are also sometimes referred to as ―Root Certificates‖.
The PKI with digital certificates, as a system, relies upon publishing certificates so that people are able to communicate with each other. Certificates, however, expire as the identity information contained in them can change or become invalid. A CA can let others users know when certificates are no longer valid in two ways. First, certificates can be deleted from the CA database. As a result, any attempt to find them to check that they still exist will fail and anyone looking for them would know that they have been revoked. Second, as deleting the record does not tell the person asking for the information why it is not there, a system of ―Revocation lists‖ has been developed to inform the users why and when a certificate was removed. If a user‘s certificate is added to the revocation lists of the CA‘s database, the user is essentially banished from using the security features of the PKI-certificate system.
Appendix G
Platforms’ Secure API-Function Mapping
G.1 Symbian-OS API-Capability Matrix
Symbian-OS security architecture provides access to underlying device functionality by categorizing its APIs as ―capabilities‖ that are mapped onto specific device functions. Access to these capabilities is provided through different levels of application certification that is granted by the application end-user (User Grantable),
Symbian Signed program (Symbian Signed Grantable), or the Device manufacturer
(Device Manufacturer Grantable). Table G-1 shows this API-Capability mapping.
Table G-1: API-Capability Matrix for Symbian-OS175 Unrestricted User Grantable Symbian Signed Device Manufacturer Grantable Grantable About 60% ReadUserData User Grantable Symbian Signed of the APIs WriteUserData Capabilities Capabilities are NetworkServices + + Unrestricted. LocalServices Location TCB They do not UserEnvironment ReadDeviceData DRM require any WriteDeviceData NetworkControl verification PowerMgmt MultimediaDD for access. SurroundingsDD AllFiles ProtServ CommDD TrustedUI DiskAdmin SwEvent
175 Source: Mark Shackman (2006), Platform Security: a Technical Overview, Version 1.2, http://developer.symbian.com/main/downloads/papers/plat_sec_tech_overview/platform_security _a_technical_overview.pdf, Accessed December 2007
304 G.2 Java ME API Function Groups
Java ME security architecture provides access to underlying device functionality by categorizing its APIs into ―function groups‖ that are mapped onto specific device functions. Access to these function groups is provided through the ―security policy‖ on
Java ME mobile devices. The security policy varies with every Java ME device model and its underlying network infrastructure operator176. Table G-2 lists the MIDP 2.0 function groups and their descriptions.
176 For details about Java ME Security Policies of different network operators see – Hartti Suomela (2007), Java ME Security Domain Policies, Forum Nokia, http://download.java.net/mobileembedded/developerdays/2008/TS-4-JavaMESecurityPolicies- final.pdf, Accessed Feb 2008
305
Table G-2: Java ME MIDP 2.0 Function Groups and their Descriptions Function Groups Description Network/cost-related groups Phone Call Represents Permissions to any function that result in a voice call. Call Control Represents permissions to any function that results call setup or teardown of a restricted network connection Net Access Represents permissions to any function that results in an active network data connection (for example GSM, GPRS, UMTS, etc.); such functions must be mapped to this group. Low Level Access Represents permissions to any function that results in an active low level network data connection (for example Sockets, etc.); such functions must be mapped to this group Messaging Represents permissions to any function that allows sending or receiving messages (for example, SMS, MMS, etc.) Restricted Represents permissions to any function that allows sending or Messaging receiving messages to a restricted messaging service (for example, Cell Broadcast, etc.) Application Auto Represents permissions to any function that allows a MIDlet Invocation suite to be invoked automatically (for example, push, timed MIDlets, etc.) Local Connectivity Represents permissions to any function that activates a local port for further connection (for example, COMM port, IrDA, Bluetooth, etc.) Authentication Represents permissions to any function that gives a MIDlet suite access to authentication functionality User-privacy-related groups Multimedia Represents permissions to any function that gives a MIDlet suite recording the ability to do any kind of multimedia recording (for example capture still images, or to record video or audio clips). Read User Data Represents permissions to any function that gives a MIDlet suite Access the ability to read a user's phone book, or any other data in a file or directory. Write User Access Represents permissions to any function that gives a MIDlet suite Data the ability to add or modify a user's phone book, or any other data in a file or directory. Smart Card Represents permissions to any function that gives a MIDlet suite Communication the ability to communicate with the smart card. Location Represents permissions to any function that gives a MIDlet suite access to Location information Landmark Represents permissions to any function that gives a MIDlet suite access to Landmark information
306 G.3 BREW API Privilege Levels
The BREW APIs included with the BREW SDK represent a group of interfaces with their own set of functions to use in BREW application development. The BREW API
Reference that lists the available interfaces and their functions is provided with the documents in the BREW SDK User Doc available on the BREW website177.
BREW devices support an Application Execution Environment (AEE) to load and execute BREW applications. Essentially, the AEE is the foundation of BREW. BREW applications use the AEE shell interface to access shell services, which permit access to a wide variety of lower-level services provided by the mobile device. The BREW shell handles system services such as application management, resource management functions, device and application configuration and management, and access to all external services. The AEE has a set of associated bit ―flags‖ that define the ―privilege levels‖ that an application can have. An application can have zero or more privilege levels based on the values stored in the bit flags of the AEE. These flags can be used to test the privileges an application has to access the underlying device functionality. As an example, the AEE privilege level flag bits for BREW 3.1 are listed in Table G-3.
177 For example, see the BREW 3.1 API Reference list, available on https://brewx.qualcomm.com/bws/content/gi/docs/brew_api_reference/brew3.1/en/online/BREWA PIReference.htm, Accessed Feb 2008.
307
Table G-3: AEE Privilege Level Flags for BREW 3.1178 AEE Privilege Level Description Flag PL_FILE The application has ‗create‘ and ‗write‘ access to files and databases. PL_NETWORK The application has access to the functions in the INetMgr Interface and ISocket Interface. PL_TAPI The application has access to telephony functionality. PL_DOWNLOAD The application has access to the IDownload interface, which contains functions for accessing BREW application download servers (this privilege level is available only to carriers and device manufacturers). PL_SHARED_WRITE The application has access to the shared application directory, which allows applications to share files. PL_POS_LOCATION The application has access to position-location functionality. PL_SYSTEM The application has all of the above privilege levels and additional functionality (this privilege level is only available to carriers and device manufacturers). PL_WEB If set, allows an application to instantiate IWeb. PL_NETWORK is a super-permission of PL_WEB. PL_RINGER_WRITE If set, allows application to create IRINGERMGR_Create() ringer tones. One doesn't need the privilege level set to play ringer tones. PL_SECTORINFO If set, allows application to access IPOSDET_GetSectorInfo(). PL_ADDRBOOK If set, allows application to access to Address Book
178 Source: BREW 3.1 API Reference list
VITA
Ankur Tarnacha
EDUCATION Ph.D. in Information Sciences and Technology (2008), Pennsylvania State University M.S. in Electrical Engineering (2003), Pennsylvania State University B.Engg. in Electronics (2000), Motilal Nehru National Institute of Technology, India
PUBLICATIONS Journal Articles and Book Chapters Tarnacha, A., & Maitland, C. F. (2008). Structural Effects of Platform Certification on a Complementary Product Market: The Case of Mobile Applications. The International Journal of IT Standardization and Standardization Research, 6(2), 40-55. Tarnacha, A., & Maitland, C. F. (2008). The effects of standards competition on market entry: The case of the mobile application markets. In The Standards Edge: Unifier or Divider?: The Bolin Group. Tarnacha, A., & LaPorta, T. F. (2007). E-STROBE. In A. Safwat (Ed.), Wireless Ad hoc and Sensor Networks: Springer. Conference Proceedings and Presentations Tarnacha, A., & Maitland, C. F. (2006, September 29 – October 1). Standards Competition and the Role of Intermediation in the Supply of Mobile Applications. Paper presented at the The 34th Annual Research Conference on Communication, Information and Internet Policy, Vienna, Virginia, USA. Tarnacha, A., & Maitland, C. F. (2006, August 14-16). Entrepreneurship in Mobile Application Development. Paper presented at the Eighth International Conference on Electronic Commerce, Fredericton, New Brunswick, Canada Tarnacha, A., Maitland, C. F., vanGorp, A. F., & Westerveld, R. (2006, August 14 - 16). A Multi-Layer Approach to the Study of Inter-Organizational Wireless Infrastructure. Paper presented at the 8th International Conference on Electronic Commerce, Fredericton, New Brunswick, Canada. Maldonado, E., Ortiz, J. A., & Tarnacha, A. (2005, Summer). Municipal Wi-Fi Networks. American Sociological Association - Science, Knowledge and Technology (ASA-SKAT) Tarnacha, A. (2005, April 9). On Location Privacy of Commercial Location Based Services. Paper presented at the MindBend Symposium, Pennsylvania State University, USA. Bauer, J. M., Lin, Y. C., Maitland, C. F., & Tarnacha, A. (2004, October 1-4). Mobile Communications Policy and the Transition to Next Generation Wireless Service. Paper presented at the Telecommunication Policy Research Conference (TPRC), Virginia, USA. Tarnacha, A., & LaPorta, T. F. (2003, October 6 - 9). E-STROBE: An Adaptive Beacon Activation Algorithm for Sensor Localization. Paper presented at the 58th IEEE Vehicular Technology Conference.
AWARDS AND PROFESSIONAL ACTIVITIES Recipient of the AT&T Wireless Graduate Fellowship, 2007 Ad-hoc reviewer for The Information Society Journal, The Journal of Information Technology, Computers & Industrial Engineering, and The i-Conference Active member of the Institute of Electrical and Electronics Engineers (IEEE); Center for the Information Society, Pennsylvania State University; and Standards Interest Group, Institute for Information Policy, Pennsylvania State University