Sage Journals: Discover world-class research

Abstract

Extant platform research focuses on how platform owners’ governance behaviors directly affect complementors. This study explicates the multilateral interdependence among different groups of producers within a platform ecosystem. We theorize about how platform owners’ governance design may create frictions between platform providers and complementors. While open governance grants greater autonomy to platform providers, it also cultivates a more complex ecosystem for complementors. Since ecosystem complexity raises the cost of product customization, complementors will be less willing to port an existing complement to a more complex ecosystem, that is, less likely to multihome. The negative effect is weakened as the complementor has greater experience with the destination ecosystem or when the complement exhibits a greater level of modularity. Our analysis of newly launched apps in Apple’s iOS and Google’s Android smartphone ecosystems finds supportive evidence. We discuss implications for the burgeoning literature on platform ecosystems and complementors.

Keywords

platform governance ecosystem complementor multihoming modularity app

Research on platform ecosystems is growing rapidly as digital platforms pervade the new economy faster than ever (McIntyre & Srinivasan, 2017). Platforms coordinate autonomous innovators by standardized interfaces instead of hierarchy or market, such that a vast number of external actors can join the platform ecosystem and create complementary products for platform users (Cennamo, 2018). Much of this literature focuses on platform governance, that is, how platform owners utilize rules, constraints, and inducements to address market failures and enable interactions (Boudreau & Hagiu, 2009; Zhang, Li, & Tong, 2020).

In a platform ecosystem (e.g., Android’s ecosystem), we can distinguish between the platform (i.e., Android), platform owner (i.e., Google), platform providers (e.g., Samsung and Huawei), and complementors (e.g., app developers). Both platform providers and complementors are “producers” in the ecosystem, while “consumers” are end users. Platform research to date emphasizes how platform governance can prompt positive externalities (or indirect network effects) between producers and consumers (Boudreau, 2012; Cennamo & Santaló, 2013; Zhu & Iansiti, 2012). Yet increasingly, digital technologies have enabled firms to organize as platforms around which various types of producers coalesce into ecosystems (Jacobides, Cennamo, & Gawer, 2018; Shi, Li, & Chumnumpan, 2020). The multilateral interdependent relationships among different groups of producers could be a source of frictions in collaborative production (Adner, 2017) to which platform research has paid limited attention (with exceptions, such as Hagiu, 2014; Simcoe & Watson, 2019).

In this article, we address the research question of how platform governance may create unintended costs for complementors. Platform scholars describe “open governance” by the extent to which important decision rights about the platform’s attributes and interfaces are devolved by the platform owner (Boudreau, 2010; Chen, Pereira, & Patel, 2020; Tiwana, 2014).¹ While open governance empowers various platform providers (e.g., smartphone producers) to manage the interface through which users consume complements (e.g., as is the case of Android; Eisenmann, 2008; Eisenmann, Parker, & Van Alstyne, 2009), it also breeds a more complex ecosystem, relative to rival platform ecosystems (e.g., iOS), in the eyes of the complementors (e.g., app developers; Kapoor & Agarwal, 2017). Potential complementors will face an increasing number of unique platform interfaces and intensified needs for accompanying product redesigns (Agarwal & Kapoor, 2019). We propose that the investments required to attain customized complementarity with a more complex platform ecosystem deters complements’ multihoming to that ecosystem. Multihoming refers to the cases where an iOS app becomes available on Android, a PlayStation video game becomes available on Switch, or a Chrome extension becomes available on Firefox.

Our analysis leverages the context of the iOS- and Android-based smartphone ecosystems. The diversity of hardware devices and operating systems provides a unique setting to study the idea of ecosystem complexity and its implications for app developers’ multihoming. We assemble a proprietary sample of newly launched top-performing mobile apps and track their entry into a new platform ecosystem. Survival analysis supports our prediction that a new platform ecosystem’s complexity relative to the original ecosystem where the app has been launched reduces the likelihood of the app’s multihoming. We further show that app developer firms’ experience with the new ecosystem and the extent to which they modularize app development using components like software development kits (SDKs) attenuate the aforementioned negative effect. Our results remain robust after accounting for the selection bias and endogenous treatment regarding the original ecosystem entry.

The study makes three contributions to the literature. First, we shift attention from platform competition to its repercussion for complementors. Current literature emphasizes platform owners’ governing of the complementors (Eaton, Elaluf-Calderwood, Sorensen, & Yoo, 2015; Rietveld, Schilling, & Bellavitis, 2018), while much less is known about the behaviors and challenges of complementors (Agarwal & Kapoor, 2019; Rietveld & Eggers, 2018; Zhang et al., 2020). Our article elucidates complementors’ multihoming decisions based on the hidden cost they face in diversifying into a new ecosystem. We extend the recent debate attributing similar coordination frictions to platforms’ architectural design and technological transition (Cennamo, Ozalp, & Kretschmer, 2018; Ozalp, Eggers, & Malerba, 2019). Second, our study enriches the platform governance literature. Previous research on governance revolves around contractual and institutional arrangements. To fully understand the implications of platform governance, we link contractual control (i.e., open vs. proprietary platforms) with technological consequences. We show that open governance, while favorable in prompting ecosystem growth (Simcoe & Watson, 2019), may cause unintended technological complexity for complementors due to increased platform interfaces. That sheds light on the key organizational challenge for platform owners to balance variety with ecosystem complexity (Cennamo & Santaló, 2019). Third, we explicate how complementors may contribute to alignment of the platform ecosystem. Extant research maintains that the responsibility for leading interdependent parties toward realignment lies with the ecosystem leader (Adner, 2017). In examining how complementors overcome multihoming costs, we reveal complementors’ strategies of coping with coordination frictions; they can either build ecosystem-specific knowledge to absorb them internally or eschew such investment by leveraging modular components outside their organizational boundaries. Taken together, we find that complementors play a more salient role in maintaining ecosystem-level complementarities than portrayed in the existing literature.

Literature and Theory

Complementor Multihoming in Platform Ecosystems

We consider a platform a stable set of common technological assets and standards used across a product family (Thomas, Autio, & Gann, 2014). The functionality of a platform can be extended by third-party innovators that leverage the platform’s standardized interface upon which they can create their own, complementary products (Gawer & Cusumano, 2014). We define an ecosystem as comprising a multilateral set of firms that are individually autonomous yet depend on one another to materialize a value proposition (Adner, 2017). In technology industries, that typically includes firms cospecializing in varying domains of expertise and originating from diverse industries, such as those providing hardware devices, networks, software products, and content (Yoo, Henfridsson, & Lyytinen, 2010).

The very logic of organizing as a platform is to leverage the generative potential of distributed innovation agency and economies of specialization (Cennamo & Santaló, 2019). Platform scholars maintain that a platform owner should strive to attract an increasing number of complementors, which are the source of indirect network effects (Cennamo & Santaló, 2013), while preventing them from supplying the same complementary product to its rival platforms (i.e., multihoming; Landsman & Stremersch, 2011).² To platform owners, complementors’ multihoming will undermine the platform’s advantages derived from network effects as well as its differentiated market position (Venkataraman, Ceccagnoli, & Forman, 2018). Complementors, on the other hand, often have incentives to multihome due to cross-platform scale economies (Landsman & Stremersch, 2011). Relative to the cost of product development, the returns from expanded market reach could be substantial (Corts & Lederman, 2009). Multihoming also allows complementors to counter the risk of hold-up and expropriation by platform owners (Huang, Ceccagnoli, Forman, & Wu, 2013).

Nevertheless, multihoming does not come by easily for complementors. Extant literature suggests that complementors face multihoming costs ensuing primarily from the platform’s technological design (Cennamo et al., 2018). While advanced technological architecture is a source of differentiation and competitive advantage for platform owners, it may limit the overall content available and impair the quality of multihomed complements (Anderson, Parker, & Tan, 2014; Ozalp, Cennamo, & Gawer, 2018). This is because reconfiguring an existing complement to a more advanced architectural design incurs significant costs due to asset specificity in product development. Such costs are often noncontractible and may discourage potential complementors. To extend this research, we further examine the costs of customization in relation to ecosystem participants other than the platform owner itself. We ascribe the source of such costs to platform governance.

Platform Governance Design

It is widely recognized that platform owners assume the unitary role of orchestrating the functioning of platform ecosystems (Gawer & Cusumano, 2008). They do so by setting non-pricing governance rules for complementors and other ecosystem participants (Rietveld, Seamans, & Meggiorin, 2020; Thomas et al., 2014). In this study, we view a platform’s governance design through the partitioning of decision rights between the platform owner and ecosystem participants to access, augment, or distribute the platform technology (Chen et al., 2020; Karhu, Gustafsson, & Lyytinen, 2018; Tiwana, 2014).

An open-governance design implies the devolution of decision rights from platform owners (Boudreau, 2010). Greater decision rights will translate into more autonomy to third-party producers that adopt the platform (Eisenmann et al., 2009; Wareham, Fox, & Cano Giner, 2014). Since these cospecialized producers possess more comprehensive knowledge about the immediate market they serve than does the platform owner, an open design would result in enhanced specialization and better servicing of customers’ heterogeneous needs, thereby improving the overall value proposition of the ecosystem (Parker, Van Alstyne, & Jiang, 2017). A closed design, by contrast, allows the platform owner to retain proprietary control by limiting other parties’ decision rights to the platform (Schilling, 2009; West, 2003). The strategic trade-off on how much decision rights the platform owner should relinquish has been a central question in platform research (Karhu et al., 2018).

At any point in time, rival platforms may display differentiated governance designs ranging from fully open to fully closed ones (Chen et al., 2020; Schilling, 2009). In more open platforms, platform owners devolve more decision rights to platform providers and allow them to maintain the interface through which users consume complementary goods and experience the platform (Eisenmann, 2008; Eisenmann et al., 2009). Current research on platform governance primarily concerns the direct access granted to complementors and the platform owner’s role as a self-interested orchestrator in regulating complementors (Eaton et al., 2015; Parker & Van Alstyne, 2018; Rietveld, Ploog, & Nieborg, 2020). In extending this inquiry, we draw on ecosystem theory to consider how platform governance design may lead to frictions in collaborative production in an ecosystem. Next, we explicate the interrelations among platform governance design, ecosystem complexity, and multihoming cost in the context of smartphone ecosystems.

Hypotheses

Ecosystem Complexity and Multihoming Decision

Ecosystem complexity refers to the structure of interdependence for complementors, defined by the number of unique components in the ecosystem that they need to interact with to materialize their value proposition (Kapoor & Agarwal, 2017). The greater the number of unique components, the higher the ecosystem complexity for complementors. Within a platform ecosystem, complexity stems particularly from the allocation of decision rights between platform owners and platform providers (Eisenmann, 2008). Different platform providers seek to augment the platform interface in ways that best suit their own customers’ immediate needs and differentiate from rivals. However, platform interfaces are the main junction points in the ecosystem (Agarwal & Kapoor, 2019). Decentralizing control of the interface could undermine the stability of standardized assets and raise ecosystem complexity (Baldwin & Woodard, 2009).

Consider smartphone ecosystems. Open governance delegates the role of platform providers to smartphone producers (Eisenmann et al., 2009). Android’s open platform permits handset makers, such as Samsung, HTC, and Huawei, to not only produce and distribute Android-based devices but also manage the interface between app developers and consumers by reprogramming the platform. That results in a diverse range of sizes, features, and capabilities among Android handsets and, most importantly, many differentiated, nonstandardized versions of Android operating system (Karhu et al., 2018). Each configuration of operating systems and handsets constitutes a unique platform interface (Kapoor & Agarwal, 2017). The growing number of unique interfaces leads to a more complex structure of interdependence in a smartphone ecosystem (Garud, Jain, & Kumaraswamy, 2002).³

From the ecosystem perspective, platform openness enhancing the variance in hardware devices also increases the risk of ecosystem complexity for complementors. That results in frictions between hardware development and complement production because of their conflicting goals: While hardware producers seek differentiation in their market, complementors pursue a wider market reach with minimum marginal cost. To multihome, a complementor must reconfigure an existing complement to the specifications of the destination ecosystem and particularly to a new set of platform interfaces (Agarwal & Kapoor, 2019). The greater the number of unique interfaces a complement is customized against, the more complex trade-offs complementors will face in product redesign. A design interacting well with one interface may fall short in compatibility with another. That elevates nonfungible, ecosystem-specific learning and adaptation costs for complementors (Jacobides et al., 2018). Thus, complementors will be less likely to customize an existing complement to a more complex constellation of interdependence (i.e., the destination ecosystem).

Hypothesis 1: The greater the complexity of a destination ecosystem relative to a complement’s original ecosystem, the less likely the complement is to multihome onto that destination ecosystem.

Heterogeneity of Complementors and Complements

While the complexity of destination ecosystems deters multihoming because of increased costs in reconfiguring an existing complement, this main effect is likely to be heterogeneous. In this section, we focus on certain characteristics of complementors and complements that are associated with variations in multihoming costs. We examine how the main effect of relative ecosystem complexity varies depending on the complementor’s destination ecosystem experience and the complement’s modular components.

Destination ecosystem experience

In examining complementor heterogeneity in tackling ecosystem complexity, we first emphasize the importance of internal capability building. Past experience generates trial-and-error learning that guides future behavior (Levitt & March, 1988). Intrafirm learning can occur in platform owners, which helps them respond to new market situations positively (Seamans & Zhu, 2017). We extend it to complementors and explore how experiential knowledge helps absorb complexity-induced multihoming cost.

We have argued that due to ecosystem complexity, potential complementors will encounter a greater number of unique platform interfaces and intensified needs for accompanying product redesigns. Complementors’ redesign process involves experimenting with a range of alternative designs to accommodate the broad variations of platform interfaces that interact with their own unique design solutions. Greater structural interdependence also implies increased accompanying design changes in response to ongoing changes in various interfaces (Sanchez & Mahoney, 1996; Schilling, 2000). Such knowledge is often acquired through learning by doing. This is because of a lack of formal communication channels among loosely coupled organizations in an ecosystem where coordination is achieved via standardized interfaces instead of overt communication (Sanchez & Mahoney, 1996). Complementors with more experience with the destination ecosystem understand better the integration of their existing designs with unique interface specifications and where adaptations may be necessary to accommodate customization requirements. Given improved search efficiency and diminished experimentation costs, experienced complementors will need less investment to attain customized complementarity. That enables them to multihome and exploit cross-platform scale economies, despite the high level of destination ecosystem complexity presented.

Moreover, in digital innovations, user participation constitutes an important channel of knowledge acquisition and alleviates the cost of feasibility test in product development (Ye & Kankanhalli, 2018). Each renewed product version builds on previous versions by incorporating users’ incremental feedback on the complement’s actual performance. More experienced complementors have more chances of receiving feedback on the fit between their design solutions and users’ devices. Such a hill-climbing approach to knowledge accumulation is subject to time compression diseconomies, and the resulting knowledge is internalized into routines that guide complementors in improving complementarity with the same ecosystem. That allows experienced complementors to identify which design solutions can be deployed to reconfigure an existing complement in a way that efficiently accommodates a destination ecosystem’s complex interfaces. Therefore, we propose that porting a complement to a more complex ecosystem incurs diminishing learning and adaptation costs for complementors with more experience with that ecosystem.

Hypothesis 2: Complementors’ experience with the destination ecosystem positively moderates the negative relationship between relative ecosystem complexity and the likelihood of multihoming.

Modular components

Now we explore complementors’ external capability search in pursuit of ecosystem-specific customization. Due to modularity in platform architectures, knowing the detailed workings of all other interdependent parties is not necessary (Baldwin & Woodard, 2009; Schilling, 2000). Without such knowledge, complementors can still leverage the capability of cospecialized parties in product design, production, and delivery (Thomas et al., 2014). Following Adner and Kapoor (2010), we direct attention to modular component providers that are part of a platform ecosystem.

The modular architecture of platforms not only facilitates the supply of complements but also induces continuous development of technical inputs comprising these very complements. Modular technologies allow fungible inputs to be separated and recombined into new innovations (Schilling, 2000). Input modules, used as building blocks, can be created independently without knowing how they will be ex post bundled by various complementors (Yoo, Boland, Lyytinen, & Majchrzak, 2012). That opens a competitive market for third-party firms and individuals who cospecialize with complementors and supply heterogeneous input modules. They may build on platform owners’ technological resources to introduce more advanced and diverse functionalities. They may also assimilate certain complementors’ innovative features and best practices into input modules. We argue that complementors can eschew some of the multihoming cost as they draw on modular components in product development.

To illustrate, consider technical development facilities, such as SDKs, in the smartphone context. With embedded digital capabilities, SDKs can perform a whole range of functionalities deemed desirable by complementors. While smartphone platform owners often offer such basic platform resources as code libraries, third-party vendors have become the major supplier of discrete functional toolkits, including SDKs. To create more value, SDK providers tend to offer cross-platform components that allow an app to perform the same function in multiple platform ecosystems at a minimal marginal cost (Corts & Lederman, 2009; Ozalp et al., 2018). As the app developer takes advantage of SDKs in developing an app for the original ecosystem, it is made aware of the same SDKs that are also offered for other platforms.

The value of a cross-platform component depends partly on the extent to which it can achieve adequate customized complementarity with each of the major ecosystems. While ecosystem complexity prevents an existing complement from exploiting cross-platform scale economies, these preprogrammed modular components can help complementors comply with the new platform’s unique interfaces and release them from the complex structural interdependence that forms the primary cost of multihoming (Tiwana, 2014). In other words, part of the technical and product development capability that complementors deploy to overcome complexity problems lies outside of their organizational boundaries (Jacobides & Hitt, 2005). Complementors can focus all the customization efforts on their own domain of expertise (Iansiti & Levien, 2004) while engaging in capability search that locates pockets of external modular components for coping with multiple platform interfaces (Selander, Henfridsson, & Svahn, 2013). From an ecosystem perspective, modular components can mitigate the friction between platform providers and complementors by filling the gap in their alignment. For complements containing more modular components, ecosystem complexity would incur less nonfungible customization cost in multihoming. Therefore we propose the following:

Hypothesis 3: Complements’ use of modular components positively moderates the negative relationship between relative ecosystem complexity and the likelihood of multihoming.

Method

Research Setting and Data

Since the launch of iOS App Store and Google Play (formerly Android Market) in 2008, the mobile apps industry has been experiencing exponential growth. In 2015 alone, mobile apps were downloaded 156 billion times, generating $34.2 billion in annual revenues (IDC, 2016). The smartphone context is a classic market in which modern platform ecosystems compete. Apple’s iOS ecosystem is notably hierarchical, in that it exerts tight control over hardware devices and software distribution. To catch up with Apple, Google openly licensed the Android operating system to smartphone producers in a bid to accelerate the diffusion of its platform (Bresnahan, Davis, & Yin, 2015). One of the main reasons for multihoming is to avoid being overcommitted to a losing platform (Tiwana, 2014). For developers in general, Android has been by far the biggest platform since the number of Android device shipments long surpassed that of iOS; the gap was ever widening until Android claimed around 75% of the global smartphone market.⁴ While there is a trade-off between market reach and financial success given the varied positioning of the platforms (Cennamo, 2019), both present equally appealing opportunities to app developers (Bresnahan et al., 2015). Hence, our context is apt for examining multihoming behaviors.

We focus on mobile apps from the Health and Fitness category on both platforms. Given previous research on platform competition (Cennamo & Santaló, 2013), we purposely choose a nongame category, where it is relatively rare to use exclusivity contracts, which prevent an app from multihoming for an extended period of time. The Health and Fitness category includes a variety of apps related to bodybuilding and working out (e.g., Nike Training Club), healthy eating (e.g., MyFitnessPal), health tracking (e.g., Flo), pedometers and sports GPS (e.g., Pacer), and yoga and meditation (e.g., Calm), among others. While most apps are fully functional on a smartphone, some popular ones, such as Fitbit and Garmin Connect, need to be paired with additional hardware (e.g., smart wearables) for distinct functions (e.g., tracking sleep and stress). Unlike apps in some categories that are predominantly reliant on in-app purchase for value capture, Health and Fitness apps do not appear to have a predisposition to one platform ecosystem than another, reducing the confounding effects on the apps’ initial homing choices. Our main data source is the leading mobile intelligence firm Apptopia (www.apptopia.com), which tracks and archives information about app downloads, revenues, and usage for more than 50 countries. The full data set includes over 4,000 top-ranked apps, accounting for more than 80% of downloads and revenues earned by the Health and Fitness category. Apps in the sampling frame are less likely to be developed by amateurs, who may differ from professional entrepreneurs in motivations and are indifferent to multihoming (Boudreau, 2018).

We select newly launched apps in the two platform ecosystems based on release information from Apptopia as well as the other two leading market analysts, App Annie and Sensor Tower. Our final sample comprises 91 iOS apps and 47 Android apps that were launched in the last quarter of 2014.⁵ We choose Quarter 4 2014 because Google Play–edition phones—Google’s initiative to reduce unique platform interfaces and mitigate fragmentation—were phased out by then. Thus, our sample is not confounded by platform owners’ countermeasures on complexity. We track the multihoming behavior of these apps from release to the end of 2015. Following Kapoor and Agarwal (2017), we aggregate daily data, for example, app rankings, downloads, and revenues provided by the intelligence firm, to the monthly level to smooth out data fluctuations. Combined with other data sources, that is, Sensor Tower, Search Man, and Mobile Action, we collect all the information about the main explanatory and control variables for our study, such as app developer experience, app size, and app update frequency. To measure ecosystem complexity, we obtain data from Statista on monthly market shares of the top 10 smartphone OEMs within the Android ecosystem. Our final data set covers 997 monthly observations of the 138 apps. It is an unbalanced panel because apps drop out of the data set once they multihome.

Dependent Variable

Multihoming

In our context, multihoming refers to app developers publishing the same app on both Google Play and iOS App Store. We examine the multihoming choice of app developers by observing whether they introduce the same app in the rival ecosystem after its initial launch. We use a dummy variable taking a value of 1 if an app appears in more than one ecosystem from its initial launch to December 31, 2015. We observe 98 single-homed apps and 40 multihomed apps, of which 20 apps launched first on iOS and the other 20 apps launched first on Android, in our sample. On average, app developers that had first launched the app on Google Play spent less time (4.22 months) until porting the same app to iOS App Store than the other way around (6.10 months).

Independent Variables

Relative ecosystem complexity

The variable is measured by the complexity of the destination ecosystem minus that of the original ecosystem. In our context, ecosystem complexity refers to the structural interdependence that the app developer needs to accommodate when developing for a given smartphone ecosystem. It is characterized by the diversity of configurations of operating systems and handsets with which an app’s design and production must be aligned in order to fully realize its functions as conceived. In the Android ecosystem, app developers need to customize their apps to various unique combinations of Android versions and hardware specifications. Handset manufacturers, such as Samsung, Sony, Huawei, Xiaomi, and HTC, introduce a whole range of devices with varying sizes, features, and capabilities. Conversely, the rival platform owner Apple maintains a hierarchical system with full control over hardware specifications.

The platform interfaces an app needs to interact with primarily include existing smartphones rather than new sales. Complementors may ensure that the app functions well only on a subset of all compatible smartphones, often leading brands, due to design trade-offs. The measure proxies for unique interfaces that an app must accommodate to reach a given market share of smartphones in an ecosystem. Following Kapoor and Agarwal’s (2017) approach, we measure ecosystem complexity by the sum of the squares of monthly global market shares for smartphone OEMs in the ecosystem. It ranges from 0.09 to 0.12 for the Android ecosystem and takes a value of 1 for the iOS ecosystem.⁶ To facilitate interpretation, we take the inverse value of ecosystem complexity and compute the difference between the complexity of the competing ecosystem and that of the original ecosystem to measure relative ecosystem complexity, such that, for instance, an iOS app multihoming to Android would face greater complexity. Unlike Kapoor and Agarwal (2017), we use the global market share of handsets to calculate the variable, assigning more balanced weights to other major brands of Android devices, such as Huawei, LG, and Samsung.

Moderators

Destination ecosystem experience

This refers to the app developer firm’s experience with the destination ecosystem before the focal app was ported to the same ecosystem. We combine data from Apptopia with those from Sensor Tower, Search Man, and Mobile Action and manually collect information about the number of apps that were released (in all categories in a given platform ecosystem) by the developer (Kapoor & Agarwal, 2017). Due to data skewness, we log-transform this variable. In the robustness checks, we use (a) an alternative, dummy variable to reflect the qualitative difference between developers having and not having destination ecosystem experience and (b) a product term of the number of prior apps and time since the last app was released in order to account for the recency effect. The results are consistent. We test the moderating effect of destination ecosystem experience while controlling for app developers’ experience with the original ecosystem.

Complement modularity

This is measured by the log of 1 plus the ratio of an app’s SDK to its size. SDK is the collection of technical modules for app development available on an ecosystem’s central technology platform (Tiwana, 2014). App developers use SDKs to add features they desire when developing an app. Without utilizing SDKs, developers must write an app from scratch for each platform ecosystem. Previous research shows that app size is reflective of coding efforts and development cost (Ghose & Han, 2014), and the number of SDKs indicates the extent to which complementors utilize modular components. While SDKs can increase app size, the ratio of SDK to app size can generally reflect the degree of modularity relative to the total programming efforts into a new app (Schilling, 2000). More SDKs alongside a smaller app size indicate limited own coding and reduced development cost. Fewer SDKs combined with a larger app size suggest a greater amount of own coding. When using the number of SDKs instead of the ratio, we obtain consistent results.

In line with our hypothesis development, we use app SDKs in the original ecosystem to account for the cost of porting to a new ecosystem resulting from product development choices. Our extensive conversations with app developers suggest that when the complementor utilizes SDKs in developing a complement for the original platform ecosystem, it should be made aware of the same third-party modular components that are also offered by this SDK provider and compatible with other platform ecosystems. That would, ex ante, reduce their own work on customization.

Control Variables

We control for a number of app-level, developer-level, and ecosystem-level variables that may influence an app’s tendency of multihoming. Our app-level control variables consist of app size, total updates, total revenue, downloads, rankings, and hardware. We measure them using data from the original ecosystem to reflect their ex ante impacts on multihoming. App size, that is, the digital storage an app occupies (logged), reflects the app’s development cost and, by extension, its multihoming cost (Ghose & Han, 2014). Total updates refers to the frequency of updates of an app (logged), indicating how much the developer has invested in this app in the original ecosystem.

Developers may use the first platform to test the market and later leverage the success by outbound multihoming (Cennamo et al., 2018). We therefore control for total revenue per month (logged), including revenues from sales, in-app purchases, and advertising earned by the app in the original ecosystem (Garg & Telang, 2014). Similarly, we control for monthly downloads (logged) in the original ecosystem. Both total revenue and downloads are proxies for market performance of an app; highly downloaded apps do not necessarily, and indeed often do not, generate significant revenue. Furthermore, app developers tend to face significant ex ante uncertainty about an app’s quality. We use app ranking to measure the perceived quality of an app in the original ecosystem. It takes a value of −1 if the app ranks in the top 150, −2 for rankings between 151 and 300, −3 for rankings between 301 and 450, and −4 for rankings beyond 450. Higher values denote higher rankings of the app and could predict its perceived quality by users of competing platforms. In a robustness test, we replace app ranking with app rating (from 1 to 5) to control for quality. The results remain consistent. Hardware is a dummy variable that takes a value of 1 if an app is associated with tangible components in usage, such as smart wearables, and 0 otherwise. The bundling of an app with complementary hardware may preclude app multihoming when the hardware is ecosystem specific. In much the same way as we measure destination ecosystem experience (moderator), we control for the developer’s original ecosystem experience by the logged number of apps that were released before the focal app was launched in the original ecosystem. Greater original ecosystem experience may delay an app’s outbound multihoming.

Finally, we control for ecosystem-level variables. Competition by similar apps in the destination ecosystem is likely to be an impediment for app developers to port their apps to that ecosystem. To measure app-specific competition, we count the number of similar apps as the focal app in the same subcategory during 1 month before and after its release. Original ecosystem volatility describes the fluctuation of downloads in the Health and Fitness category of the original ecosystem. We measure volatility using the total number of daily top 20 downloaded apps’ downloads as a proxy for performance dynamics.⁷ A volatile market environment may prompt developers to seek cross-platform scale economies. Table 1 provides the descriptions of the variables.

Table 1

Variable Descriptions

Variable	Time Variant	Measurement
Relative ecosystem complexity	Yes	Ecosystem complexity measured by the sum of the squares of monthly global market shares for smartphone OEMs in the ecosystem; for ease of interpretation, we take the inverse value of ecosystem complexity to compute the difference between the complexity of the destination ecosystem and that of the original ecosystem
Destination ecosystem experience	Yes	Logged number of apps that were released in the destination ecosystem before the focal app was ported to the same ecosystem
Complement modularity	No	Logged ratio of software development kits to app size
App size	No	Logged digital storage an app occupies
Original ecosystem experience	No	Logged number of apps that were released before the time when the focal app was first launched
Total updates	Yes	Logged frequency of updates of an app
Top rank	Yes	Takes a value of −1 if the app ranks top 150, −2 for rankings between 151 and 300, −3 for rankings between 301 and 450, and −4 for rankings beyond 450
Total revenue	Yes	Total revenue per month (logged), including revenues from sales, in-app purchases, and advertising earned by the app in the original ecosystem
Hardware	No	A dummy variable that takes a value of 1 if an app is associated with tangible components in usage and 0 otherwise
Downloads	Yes	Total monthly downloads of an app (logged)
Competition	No	Number of similar apps as the focal app in the same subcategory in the destination ecosystem during 1 month before and after its release
Original ecosystem volatility	Yes	Volatility measure using the total number of daily top 20 downloaded apps’ downloads in the Health and Fitness category of the original ecosystem
Complexity difference	Yes	Google ecosystem complexity minus iOS ecosystem complexity
Business model	No	Takes a value of 1.5 for apps that charge a higher-than-average price for download and in-app purchase revenue / total revenue > advertising revenue / total revenue; 1 for apps that are free or paid at a lower-than-average price for downloads and in-app purchase revenue / total revenue > advertising revenue / total revenue; 0.5 for apps that are not free and in-app purchase revenue / total revenue ≤ advertising revenue / total revenue; 0 for apps that are free to download and in-app purchase revenue / total revenue ≤ advertising revenue / total revenue

Estimation Approach

We employ discrete-time proportional hazard survival models to test our hypotheses. The models are intended to estimate the likelihood of an app launched in the original ecosystem multihoming to the destination ecosystem in a given time period. The estimation method allows for a fully nonparametric estimation of the baseline hazard. Survival models can handle time-varying covariates, besides controlling for unobserved individual heterogeneity. That helps identify the effects of survival time on duration in multihoming. The right-censoring problem, in that some apps in our sample did not multihome within the observation period, can also be accommodated (Allison, 1984). Since our data are analyzed on a monthly basis, we employ a complementary log-log (cloglog) transformation (Tsoukas, 2011). The cloglog model is a discrete-time implementation of the Cox proportional hazard model that assumes continuous failure times (Prentice & Gloeckler, 1978). We thereby obtain the discrete-time representation of an underlying continuous-time proportional hazard. It allows for hazard rate analysis with extreme maximum and extreme minimum distributions, and it has the advantage of not being symmetrical around the inflection point.

Results

Table 2 provides descriptive statistics and the correlation matrix. We note a relatively high and negative correlation between relative ecosystem complexity and complement modularity. That suggests that Android apps tend to use more SDKs than iOS apps, as one would expect. The variance inflation factor values range from 1.31 to 9.79, which are below the common cutoff of 10 regarding multicollinearity.

Table 2

Descriptive Statistics and Correlation Matrix of Variables

Variable	M	SD	Min.	Max.	1	2	3	4	5	6	7	8	9	10	11	12
1. Multihoming	0.02	0.13	0.00	1.00
2. Relative ecosystem complexity	0.37	0.82	−0.91	0.91	−.01
3. Destination ecosystem experience	0.13	0.45	0.00	4.08	−.00	−.03
4. Complement modularity	0.44	0.70	0.00	3.18	.02	−.66	.02
5. App size	2.76	1.14	0.41	5.58	.00	.22	−.06	−.54
6. Original ecosystem experience	1.60	1.46	0.00	4.36	−.13	.04	.13	−.04	.05
7. Total updates	0.95	0.88	0.00	3.87	.08	−.44	−.05	.19	.06	−.03
8. Top rank	−1.61	1.05	−4.00	−1.00	−.06	.02	.01	−.08	.17	.08	.13
9. Total revenue	5.05	3.78	−4.61	12.80	−.03	−.10	−.08	−.03	.17	.14	.26	.31
10. Hardware	0.14	0.34	0.00	1.00	.05	−.10	−.05	−.02	.05	.20	.08	.07	.10
11. Downloads	6.30	3.55	0.00	13.91	.06	−.12	.07	.26	.01	.08	.32	.28	.39	.03
12. Competition	9.89	7.27	0.00	33.00	.03	−.36	.08	.25	−.10	−.02	.02	.07	.01	.05	.02
13. Original ecosystem volatility	1.13	0.46	0.63	2.88	.04	−.09	.00	.09	−.01	−.04	−.04	−.02	−.20	.02	−.09	.07

Table 3 reports the results from the cloglog model. The model estimates the hazard rate that an app launched in the original ecosystem multihomes to the destination ecosystem and, hence, exits from a single-homing strategy. A cloglog model allows the regression coefficients to have a proportional hazard rate interpretation. The reported coefficients can be exponentiated to obtain hazard ratios, interpreted as the multiplier of the baseline hazard of the app exiting from its single-homing strategy when the explanatory variable increases by one unit. An increase in hazard can also be interpreted as shortening the time period for which an app remains exclusive to the original ecosystem and as increasing the likelihood of multihoming to the destination ecosystem. All standard errors are clustered by app. Model 1 is the baseline model that includes control variables only. In Model 2, we include the variable relative ecosystem complexity, as well as the main effects of destination ecosystem experience and complement modularity, to test Hypothesis 1. In Model 3, we include the interaction term between relative ecosystem complexity and destination ecosystem experience to test Hypothesis 2. In Model 4, we include the interaction term between relative ecosystem complexity and complement modularity to test Hypothesis 3. Model 5 is the fully specified model that includes all predictors and interaction terms.

Table 3

Cloglog Model Estimation of the Determinants of Multihoming

Variable	(1)	(2)	(3)	(4)
Relative ecosystem complexity (Hypothesis 1)	−0.01 (SE = 0.01; p = .066)	−0.02 (SE = 0.01; p = .001)	−0.02 (SE = 0.01; p = .001)	−0.03 (SE = 0.01; p = .057)
Destination ecosystem experience	0.01 (SE = 0.00; p = .017)	0.06 (SE = 0.02; p = .003)	0.01 (SE = 0.00; p = .058)	0.08 (SE = 0.00; p = .000)
Complement modularity	0.07 (SE = 0.03; p = .007)	0.13 (SE = 0.07; p = .050)	0.11 (SE = 0.01; p = .000)	0.08 (SE = 0.01; p = .000)
Relative Ecosystem Complexity × Destination Ecosystem Experience (Hypothesis 2)		0.10 (SE = 0.01; p = .000)		0.07 (SE = 0.01; p = .000)
Relative Ecosystem Complexity × Complement Modularity (Hypothesis 3)			0.08 (SE = 0.01; p = .000)	0.11 (SE = 0.00; p = .000)
App size	0.00 (SE = 0.01; p = .752)	0.02 (SE = 0.04; p = .616)	0.02 (SE = 0.02; p = .437)	0.02 (SE = 0.03; p = .593)
Original ecosystem experience	−0.01 (SE = 0.00; p = .000)	−0.02 (SE = 0.00; p = .000)	−0.02 (SE = 0.00; p = .000)	−0.03 (SE = 0.00; p = .000)
Total updates	0.01 (SE = 0.02; p = .596)	0.04 (SE = 0.02; p = .036)	0.01 (SE = 0.02; p = .752)	0.01 (SE = 0.02; p = .827)
App ranking	−0.01 (SE = 0.01; p = .255)	−0.02 (SE = 0.03; p = .600)	−0.02 (SE = 0.01; p = .187)	−0.02 (SE = 0.01; p = .191)
Total revenue	0.00 (SE = 0.00; p = .959)	−0.00 (SE = 0.00; p = .902)	0.00 (SE = 0.00; p = .335)	0.00 (SE = 0.00; p = .185)
Hardware	0.03 (SE = 0.01; p = .001)	0.06 (SE = 0.03; p = .036)	0.05 (SE = 0.02; p = .002)	0.05 (SE = 0.05; p = .319)
Downloads	0.00 (SE = 0.00; p = .859)	−0.00 (SE = 0.01; p = .803)	0.00 (SE = 0.00; p = .748)	0.00 (SE = 0.00; p = .124)
Competition	0.00 (SE = 0.00; p = .000)	0.00 (SE = 0.00; p = .000)	0.00 (SE = 0.00; p = .000)	0.00 (SE = 0.00; p = .000)
Original ecosystem volatility	−0.02 (SE = 0.00; p = .000)	0.03 (SE = 0.01; p = .005)	0.01 (SE = 0.02; p = .457)	0.02 (SE = 0.01; p = .126)
N	997	997	997	997
Log pseudolikelihood	−55.18	−60.62	−79.50	−80.40

Note: Coefficients are reported as marginal effects.

Hypothesis 1 posits that the higher the complexity of the destination ecosystem relative to that of the original ecosystem, the lower the likelihood of multihoming. This prediction is supported in all models (Models 2, 3, 4, and 5). The coefficients for relative ecosystem complexity are negative and marginally significant (b = −0.01, p < 0.1, in Model 2). Thus, higher relative ecosystem complexity is associated with a lower likelihood of an app “exiting” from single-homing and adopting the multihoming strategy.

Hypothesis 2 suggests that the effect of relative ecosystem complexity on the likelihood of multihoming will be positively moderated by destination ecosystem experience, such that the negative relationship will become weaker when the developer’s destination ecosystem experience is higher. We find support for Hypothesis 2, as the coefficient for the interaction term between relative ecosystem complexity and destination ecosystem experience is positive and statistically significant in Model 3 (b = 0.10, p < .001) and Model 5 (b = 0.07, p < .001).

Hypothesis 3 predicts that the effect of relative ecosystem complexity on the likelihood of multihoming will be positively moderated by complement modularity, such that the negative relationship will become weaker when the degree of complement modularity is higher. We find support for Hypothesis 3, too, as the coefficient for the interaction term between relative ecosystem complexity and complement modularity is positive and statistically significant in both Model 4 (b = 0.08, p < .001) and Model 5 (b = 0.11, p < .001).

Figure 1 illustrates the moderation effects by plotting the predicted hazard of an app’s multihoming as a marginal function of relative ecosystem complexity, given high (blue line) and low values (red line) of the developer’s destination ecosystem experience and complement modularity, respectively. The y-axis is the marginal probability of multihoming with respect to relative ecosystem complexity, and the x-axis is relative ecosystem complexity. To plot the relationships, we use estimates from the full model (Model 5) and hold all other variables at their respective means. High and low measures refer to values of one quarter standard deviation above and below the respective means (i.e., to ensure that the values of the variables fall in the range between min and max values). In Figure 1a, both lines are below zero, indicating the negative effect of relative ecosystem complexity on the probability of multihoming (i.e., the main effect, Hypothesis 1). In addition, the red line is consistently above the blue line, indicating that high destination ecosystem experience “elevates” the marginal effect of relative ecosystem complexity on the probability of multihoming. In other words, destination ecosystem experience positively moderates the negative effect of relative ecosystem complexity (i.e., Hypothesis 2). Figure 1b exhibits a similar pattern for the moderating effect of complement modularity (i.e., Hypothesis 3).

Figure 1

Graphical Plots of Interaction Effects: (a) Relative Ecosystem Complexity, Destination Ecosystem Experience, and Multihoming and (b) Relative Ecosystem Complexity, Complement Modularity, and Multihoming

Robustness Tests

We consider various sources of confounding factors that might bias our results. First, we contemplate how the entry sequence may introduce endogeneity. Our hypothesis implies that apps entering a more complex ecosystem first may be more likely to multihome to the less complex one. In other words, Android apps may have a higher propensity to be ported to iOS than the other way around, such that an app’s original ecosystem entry and the rate of multihoming could be simultaneously determined. Furthermore, the original ecosystem choice might not be random but rather a function of app-specific and developer-specific characteristics, raising further concerns of endogeneity. This systematic effect of entry sequence on the rate of multihoming could be tackled by either a Heckman’s two-stage model correcting for selection biases (Heckman, 1979) or an endogenous treatment-effects model correcting for endogenous entry (Rietveld, 2018).

To correct for selection biases, we perform a two-stage Heckman model by separating our sample into two as per the app’s entry choice for the original ecosystem. We use prior app-level and ecosystem-level variables to predict the first-stage ecosystem entry choice. We include ecosystem complexity difference (i.e., the difference between the complexity of Android and that of iOS), complement modularity, original ecosystem experience, app size, and hardware.⁸ Previous research suggests that a complement’s performance is dependent on the demand-side characteristics of platform adopters (Rietveld & Eggers, 2018). By extension, app developers may base the first homing decision on the fit between the app’s business model and platform users’ characteristics.⁹ Since business model is unlikely to be related to the error term of multihoming, which is driven by cross-platform scale economies, we use it as an exclusion restriction. Our context has a distinct feature in that the two platforms have users of different willingness to pay. An important ex ante reason for the app developer to choose iOS versus Android as the first home is whether the app is intended to generate revenue from users or advertisers. Taking inspirations from the exploitation/exploration literature (Lavie & Rosenkopf, 2006; Stettner & Lavie, 2014), we code business model as 1.5 for apps that charge a higher-than-average price for download and if in-app purchase revenue / total revenue > advertising revenue/total revenue; 1 for apps that are free or paid at a lower-than-average price for downloads and if in-app purchase revenue / total revenue > advertising revenue / total revenue; 0.5 for apps that are not free and if in-app purchase revenue / total revenue ≤ advertising revenue / total revenue; and 0 for apps that are free to download and if in-app purchase revenue / total revenue ≤ advertising revenue / total revenue. We generate inverse Mills ratio from the first-stage model and include it in our second-stage regression, which predicts the likelihood of multihoming. As shown in Table 4, we find an insignificant inverse Mills ratio in the sample that first entered iOS. Ecosystem complexity difference matters only when apps are first released on Google Play. This is possibly due to a lower baseline probability of iOS apps multihoming to Android and hence a “floor effect,” which is consistent with Figure 1, where relative ecosystem complexity exhibits a diminishing marginal effect as it increases in value. When apps are first released on iOS, the positive effect of the developer firm’s Android experience (destination ecosystem experience) is strengthened, due to the transition from a less complex ecosystem to a more complex one. For the subsample entering Android first, the positive effect is much smaller in terms of magnitude, and a Wald test indicates significant difference between the coefficients (χ² = 3.85, p < .05). We obtain similar results for complement modularity: The positive effect of complement modularity is strengthened as apps are ported from a less complex ecosystem to a more complex one. The results largely support our hypotheses.

Table 4

Robustness Test: Heckman Models for Subsamples by Initial Entry

Variable	(1)	(2)	(3)	(4)
Variable	Android First = 1	Android First = 1	Android First = 0	Android First = 0
Ecosystem complexity difference	0.47 (SE = 1.42; p = .738)	7.02 (SE = 3.45; p = .042)	−0.47 (SE = 1.42; p = .738)	0.99 (SE = 1.29; p = .442)
Destination ecosystem experience		0.04 (SE = 0.02; p = .048)		0.08 (SE = 0.04; p = .040)
Complement modularity	0.38 (SE = 0.02; p = .000)	−0.03 (SE = 0.12; p = .818)	−0.38 (SE = 0.02; p = .000)	0.41 (SE = 0.16; p = .008)
Business model	−0.03 (SE = 0.02; p = .064)		0.03 (SE = 0.02; p = .064)
App size	0.07 (SE = 0.01; p = .000)	−0.03 (SE = 0.04; p = .435)	−0.07 (SE = 0.01; p = .000)	0.09 (SE = 0.03; p = .006)
Original ecosystem experience	0.02 (SE = 0.01; p = .002)		−0.02 (SE = 0.01; p = .002)
Total updates		−0.05 (SE = 0.03; p = .059)		0.02 (SE = 0.01; p = .184)
App ranking		−0.00 (SE = 0.03; p = .923)		−0.03 (SE = 0.01; p = .006)
Total revenue		0.00 (SE = 0.01; p = .647)		−0.00 (SE = 0.00; p = .846)
Hardware	0.14 (SE = 0.03; p = .000)	−0.04 (SE = 0.07; p = .621)	−0.14 (SE = 0.03; p = .000)	0.15 (SE = 0.06; p = .008)
Downloads		0.01 (SE = 0.01; p = .382)		0.01 (SE = 0.01; p = .226)
Competition		0.00 (SE = 0.00; p = .919)		0.00 (SE = 0.00; p = .955)
Original ecosystem volatility		0.03 (SE = 0.02; p = .200)		0.04 (SE = 0.02; p = .015)
Inverse Mills ratio		0.04 (SE = 0.13; p = .748)		−0.23 (SE = 0.15; p = .122)
N	997	279	997	718
Log pseudolikelihood	−557.44	−17.32	−557.44	−42.34

Note: Coefficients are reported as marginal effects.

To further correct for endogeneity that arises from entry sequence, we follow Rietveld (2018) to perform a endogenous treatment-effects model. In a setup similar to the Heckman model, we use the first stage regression to model the impacts of endogenous treatment for the original ecosystem entry on our key explanatory variable, relative ecosystem complexity. That allows us to correct for nonrandom assignment of apps into the first platform ecosystem and, conditional on that, estimate the influences of our hypothesized variables on the decision to multihome. We use the command stset in Stata to process the original data in a way consistent with duration models, and thus we can continue to account for right-censoring. After the endogenous treatment is factored in, the results of the second stage (i.e., multihoming entry) remain supportive of our hypotheses, as shown in Table 5.

Table 5

Robustness Test: Eprobit Model for Endogenous Treatment Effects

First Stage	(1)	Second Stage	(2)
Relative ecosystem complexity		Multihoming
Original ecosystem experience	−0.02 (SE = 0.02; p = .275)	Relative ecosystem complexity (Hypothesis 1)	−1.20 (SE = 0.54; p = .026)
Complement modularity	−0.55 (SE = 0.10; p = .000)	Destination ecosystem experience	0.96 (SE = 0.52; p = .067)
App size	−0.13 (SE = 0.02; p = .000)	Complement modularity	1.09 (SE = 0.98; p = .264)
Hardware	−0.26 (SE = 0.07; p = .000)	Relative Ecosystem Complexity × Destination Ecosystem Experience (Hypothesis 2)	1.10 (SE = 0.58; p = .060)
Business model	0.19 (SE = 0.04; p = .000)	Relative Ecosystem Complexity × Complement Modularity (Hypothesis 3)	0.82 (SE = 0.48; p = .086)
Constant	1.00 (SE = 0.09; p = .000)	App size	0.03 (SE = 0.18; p = .860)
		Original ecosystem experience	−0.34 (SE = 0.14; p = .016)
		Total updates	0.11 (SE = 0.14; p = .436)
		App ranking	−0.08 (SE = 0.17; p = .657)
		Total revenue	0.05 (SE = 0.03; p = .111)
		Hardware	0.38 (SE = 0.48; p = .433)
		Downloads	−0.07 (SE = 0.05; p = .191)
		Competition	0.00 (SE = 0.02; p = .799)
		Original ecosystem volatility	0.12 (SE = 0.21; p = .555)
		Constant	−1.12 (SE = 1.89; p = .553)
N	997		997
Log pseudolikelihood			−653.51

Although the entry sequence effect is corrected for, we exercise caution regarding the two moderators that may too be endogenous in our context. One might wonder why an app developer with destination ecosystem experience would choose to launch a new app first in another ecosystem. Our discussions with practitioners suggest that a once-Android-oriented developer (i.e., having successfully launched numerous apps on Android) can and does launch new apps on iOS first when the business model is reliant on in-app purchase and the target market is high-willingness-to-pay users. A corroborative fact is that destination ecosystem experience and original ecosystem experience appear uncorrelated in our sample (r = .04). In this regard, our Heckman and endogenous treatment models help alleviate the concern of endogeneity. Nonetheless, there may be other unobserved reasons for an experienced developer to enter a certain ecosystem first, and we cannot rule that out.

With respect to SDKs, our theory suggests that the extent to which an app’s initial development relies on SDKs may have an impact on its portability later on. There remains a risk of reverse causality in that multihoming apps may simply be more complicated and require more SDKs. While we cannot fully rule out this risk, our SDK measure and the control variable of app size can partially account for that. Another confounding issue is whether iOS and Android systematically differ in their use of SDKs. If Android apps inherently have more SDKs, it may be easier for them to multihome to iOS than the other way around, creating an alternative explanation vis-à-vis ecosystem complexity. In our sample, Android apps do have more SDKs than iOS apps on average. This is likely because Android apps rely more heavily on advertising in generating revenues, which in turn drives their use of third-party SDKs. Given that these SDKs tend to be Android specific, they would not influence how portable the app is to iOS and hence should not confound our results.

Third, some apps in our sample were launched simultaneously in both ecosystems, which may raise the issue of left truncation and result in possible estimation biases. Industry wisdom suggests that it takes usually 1 week, and rarely but up to 4 weeks, for iOS App Store to review and approve the release of an app, while the process is less stringent and much faster for Google Play. In this regard, we have 24 apps (among a total of 162) that simultaneously launched (in the same month) on both iOS App Store and Google Play, accounting for 15% of the full sample. In our main specification, we do not include apps that were released simultaneously, because (a) they may deal with complexity in ways different from our theory and (b) it is hard to distinguish between the original and destination ecosystems for them. Yet the way we constructed our data may erroneously identify some sequential multihomers as simultaneous multihomers. Therefore, we include these apps in a robustness check. We use two criteria to decide which of the two ecosystems is the original ecosystem before we run the models. We first regard as the original ecosystem the one on which the app was released earlier by date. Alternatively, in cases where the app was introduced on the same day, we refer to the ecosystem with which the developer of the app had more experience. We consider whether the very first app developed by the firm was released in one ecosystem or the other. In addition to the cloglog model, we apply conventional binary-response panel data models (i.e., probit and logit models) with normal random effects when estimating discrete-time duration models. Such models can help correct for unobserved heterogeneity. All the results reported in Table 6 remain qualitatively consistent. But we caution against extending our findings to the group of simultaneous multihomers since our theory may not say much about how these apps are developed. In an unreported regression, we also reconstruct our data to the weekly level. Given that it could take as little as 1 week for the platform owner to approve a new app release, we use 1 week as a gap to weed out simultaneously multihoming apps. We also employ an alternative cutoff of 4 weeks to account for the review process in iOS App Store. All results are consistent and support our hypotheses.

Table 6

Robustness Test: Alternative Models for the Sample Including Simultaneous Multihoming Apps

Variable	(1)	(2)	(3)
Variable	Cloglog	Probit	Logit
Relative ecosystem complexity (Hypothesis 1)	−0.03 (SE = 0.01; p = .070)	−0.03 (SE = 0.01; p = .000)	−0.03 (SE = 0.01; p = .001)
Destination ecosystem experience	0.06 (SE = 0.02; p = .001)	0.05 (SE = 0.01; p = .000)	0.05 (SE = 0.02; p = .001)
Complement modularity	0.08 (SE = 0.02; p = .000)	0.07 (SE = 0.02; p = .000)	0.07 (SE = 0.02; p = .000)
Relative Ecosystem Complexity × Destination Ecosystem Experience (Hypothesis 2)	0.04 (SE = 0.02; p = .080)	0.03 (SE = 0.01; p = .026)	0.04 (SE = 0.02; p = .068)
Relative Ecosystem Complexity × Complement Modularity (Hypothesis 3)	0.11 (SE = 0.00; p = .000)	0.11 (SE = 0.02; p = .000)	0.11 (SE = 0.01; p = .000)
App size	0.02 (SE = 0.03; p = .541)	0.01 (SE = 0.02; p = .540)	0.02 (SE = 0.03; p = .559)
Original ecosystem experience	−0.02 (SE = 0.00; p = .000)	−0.02 (SE = 0.00; p = .000)	−0.02 (SE = 0.00; p = .000)
Total updates	0.00 (SE = 0.02; p = .876)	0.00 (SE = 0.01; p = .961)	0.00 (SE = 0.02; p = .912)
App ranking	−0.02 (SE = 0.02; p = .213)	−0.02 (SE = 0.01; p = .247)	−0.02 (SE = 0.01; p = .239)
Total revenue	0.00 (SE = 0.00; p = .135)	0.00 (SE = 0.00; p = .000)	0.00 (SE = 0.00; p = .050)
Hardware	0.05 (SE = 0.05; p = .324)	0.04 (SE = 0.04; p = .369)	0.04 (SE = 0.05; p = .358)
Downloads	0.00 (SE = 0.00; p = .080)	0.00 (SE = 0.00; p = .003)	0.00 (SE = 0.00; p = .057)
Competition	0.00 (SE = 0.00; p = .003)	0.00 (SE = 0.00; p = .000)	0.00 (SE = 0.00; p = .002)
Original ecosystem volatility	0.02 (SE = 0.01; p = .090)	0.01 (SE = 0.01; p = .090)	0.02 (SE = 0.01; p = .104)
N	1021	1021	1021
Log pseudolikelihood	−81.11	−83.89	−82.40

Note: Coefficients are reported as marginal effects.

Finally, since Apple’s smartphones tend to introduce major improvements on the previous model, one might argue that the diversity of Apple’s smartphone configurations presents varied interfaces to app developers. To examine the sensitivity of the results, we acquired data from Localytics and Unity on various generations of smartphones within the iOS ecosystem and followed Kapoor and Agarwal’s (2017) approach to calculate the sum of the squares of monthly global market shares. It is based on the premise that the sales dispersion over different generations of iPhone may affect the score of relative complexity between iOS and Android, to the extent that the rate of multihoming could change with the varying complexity of the iOS ecosystem, all else equal. The complexity score for iOS does vary from 0.16 to 0.21. Our analysis obtains qualitatively consistent results.

Discussion

In this article, we examine the implications of ecosystem complexity resulting from its central platform’s governance design. While an open design is desirable from a platform owner’s perspective, it may lead to unintended frictions between different ecosystem participants, a situation characterized by ecosystem complexity (Kapoor & Agarwal, 2017). We show that one consequence of complexity involves greater customization cost for complementors’ multihoming to a more complex ecosystem. Since multihoming is a key avenue for market expansion, platform governance design may have critical impacts on start-up complementors’ survival and growth. Nonetheless, we find that complementors can cope with ecosystem complexity through internal capability building or external capability searching. Placing platform governance at the nexus of multilateral interactions in ecosystems, our study yields new insights into the dynamics among platform governance, ecosystem complexity, and complementors’ innovation cost.

Our study confirms that ecosystem complexity discourages multihoming. We view complexity as a new type of transaction cost typical of ecosystems. It arises not from asset specificity or uncertainty in bilateral contracts but from structural misalignment of interdependent parties upon whose multilateral interactions the value proposition depends (Adner, 2017). In our context, such transaction costs determine the boundary of the complementor—whether or not it extends to a new platform ecosystem and forms cooperative relationships with a new configuration of interdependent parties (Santos & Eisenhardt, 2005). Unlike traditional transaction costs, coordination frictions in an ecosystem are too complex to decompose into a collection of independent, dyadic interactions (Davis, 2016). As the central platform is most deeply involved in the network of multilateral interactions, whether the platform owner can balance conflicting goals without requiring hierarchical governance and remain an omnipotent orchestrator should not be assumed (Cennamo & Santaló, 2019). Our study shows that when an open-governance design causes the platform owner to lose control over coordination of hardware development and complement production, it is complementors who are left to shoulder the cost of misalignment and frictions. Although open governance favors platform owners in the short term (Boudreau, 2010), it may have long-term ramifications for the entire ecosystem.

Another notable feature of the platform-centric research is that it assumes complementors to play a submissive role (McIntyre & Srinivasan, 2017). Being subject to platform owners’ market power and control, it seems that complementors can only absorb adverse impacts of platform strategies or exit the market outright. The agency for tackling complexity and realigning ecosystem participants also arguably lies with the platform owner (Adner, 2017). By contrast, we lay emphasis on complementor heterogeneity, arguing that some complementors can cope with ecosystem complexity better than others. We show that complementors can build technical capabilities internally or leverage capabilities of other ecosystem participants. Utilizing user feedback to achieve customized complementarity involves an incremental process of experimentation and experiential learning. That is consistent with the organizational learning thesis (Levitt & March, 1988).

Furthermore, complementors can circumvent the adaptation needs by leveraging the modular product architecture. Modularity allows complementors to utilize development capabilities lying outside of their organizational boundary but within the ecosystem (Adner & Kapoor, 2010). We view this as essentially an exchange relationship: Platform owners delegate the task of realignment to modular component providers, who seize the rent-generation opportunities in return. In doing so, platform architecture affords ecosystems sufficient flexibility without involving overt managerial fiat or explicit coordination from an ecosystem leader (Jacobides et al., 2018). This has implications for the platform market structure. While we cannot empirically verify whether and how ecosystem complexity affects app developers’ first homing choice, our model reasonably assumes that the initial entry is driven primarily by commercial reasons (i.e., business models) and that complexity affects the multihoming decision to the extent that many apps may remain available only on the less complex platform. Researchers maintain that more outbound multihoming weakens the platform’s differentiation and more inbound multihoming reduces users’ switching cost to a rival platform ecosystem (Landsman & Stremersch, 2011). Hence, one implication of our findings is that complex platforms would face higher risk of market tipping to their disadvantage. As modularity curtails the impact of ecosystem complexity, it also helps prevent market tipping (Simcoe & Watson, 2019).

We note several caveats in our findings, which nonetheless pave the way for future research. First, we cannot effectively control for platform owners’ openness to complementors. In our context, that typically occurs through app review policies and tends to change from time to time. Future research on complementors may explore the entry barrier arising from both technology openness and market openness. Similarly, in addition to our measure of complexity capturing the number of interfaces in a platform ecosystem, additional factors, such as the quality of interfaces, may raise cospecialization requirements. Despite that ecosystems are evolving along increasingly divergent pathways (Simcoe & Watson, 2019), a growing amount of middleware is produced, which may lessen the influence of cospecialization requirements and facilitate simultaneous multihoming (Miric & Ozalp, 2020). We encourage future research to further explore the implications of middleware for a complement’s market-entry choice and timing. Second, despite our use of a two-stage model to control for selection biases, complementors’ first homing choice could still be subject to unobserved confounding effects, including complementors’ firm-specific homing sequence. As with previous studies, we cannot definitively establish causality for the experience effects. We thus caution about the potential endogeneity around app developers’ experience that is left uncorrected for. That nonetheless invites future research to investigate how complementors’ innovation routines affect their ecosystem-specific investments. Similarly, since some SDKs perform functions related to an app’s business model (e.g., monetization), the use of specific SDKs could be endogenous to the first homing decision. That would be translated into a risk of reverse causality as SDK uses are determined ex ante by the intended release pattern. Last, the sampled app category lacks exclusivity arrangements, and exclusivity may play a dampening role in multihoming decisions. That could render our theory less applicable to other contexts (e.g., video games).

Taking up recent calls for greater research attention to complementors (McIntyre & Srinivasan, 2017; Yoo et al., 2012), this study investigates the inhibiting and facilitating factors for complementor multihoming in the context of platform ecosystems. Given the growing importance of ecosystems in today’s digital economy, understanding the organization and coordination of broader ecosystem participants—beyond the dyadic relationship between platforms and complementors—will prove an important agenda.

Footnotes

Acknowledgements

The authors are grateful for the guidance by editor William Schulze and two reviewers, Carmelo Cennamo, and participants at the Academy of Management Surrey Conference. We acknowledge support from the University of Melbourne Early Career Researcher Grant (ECR0182020), National Natural Science Foundation of China (71873136), and University of South Carolina Center for International Business Education and Research (CIBER) grants.

ORCID iDs

Liang Chen

Tony W. Tong

Notes

References

Adner

2017. Ecosystem as structure. Journal of Management, 43: 39-58.

Adner

Kapoor

2010. Value creation in innovation ecosystems: How the structure of technological interdependence affects firm performance in new technology generations. Strategic Management Journal, 31: 306-333.

Agarwal

Kapoor

2019. Two faces of value creation in business ecosystems: Leveraging complementarities and managing interdependencies. Working paper. The Wharton School, Philadelphia.

Allison

P. D.

1984. Event history analysis: Regression for longitudinal event data. Beverly Hills, CA: Sage.

Anderson

E. G.

Parker

G. G.

Tan

2014. Platform performance investment in the presence of network externalities. Information Systems Research, 25: 152-172.

Baldwin

C. Y.

Woodard

C. J.

2009. The architecture of platforms: A unified view. In Gawer

(Ed.), Platforms, markets and innovation: 19-44. Cheltenham, UK: Edward Elgar.

Boudreau

K. J.

2010. Open platform strategies and innovation: Granting access vs. devolving control. Management Science, 56: 1849-1872.

Boudreau

K. J.

2012. Let a thousand flowers bloom? An early look at large numbers of software app developers and patterns of innovation. Organization Science, 23: 1409-1427.

Boudreau

K. J.

2018. “Crowds” of amateurs and professional entrepreneurs in marketplaces. Working paper.

10.

Boudreau

K. J.

Hagiu

2009. Platform rules: Multi-sided platforms as regulators. In Gawer

(Ed.), Platforms, markets and innovation: 163-191. Cheltenham, UK: Edward Elgar.

11.

Bourgeois

L. J.

1985. Strategic goals, perceived uncertainty, and economic performance in volatile environments. Academy of Management Journal, 28: 548-573.

12.

Bresnahan

Davis

Yin

P.-L.

2015. Economic value creation in mobile applications. In Jaffe

A. B.

Jones

B. F.

(Eds.), The changing frontier: Rethinking science and innovation policy. Chicago: University of Chicago Press.

13.

Cennamo

2018. Building the value of next-generation platforms: The paradox of diminishing returns. Journal of Management, 44: 3038-3069.

14.

Cennamo

2019. Competing in digital markets: A platform-based perspective. Academy of Management Perspectives. https://doi.org/10.5465/amp.2016.0048

15.

Cennamo

Ozalp

Kretschmer

2018. Platform architecture and quality tradeoffs of multihoming complements. Information Systems Research, 29: 461-478.

16.

Cennamo

Santaló

2013. Platform competition: Strategic trade-offs in platform markets. Strategic Management Journal, 34: 1331-1350.

17.

Cennamo

Santaló

2019. Generativity tension and value creation in platform ecosystems. Organization Science, 30: 617-641.

18.

Chen

Pereira

Patel

P. C.

2020. Decentralized governance of digital platforms. Journal of Management. https://doi.org/10.1177/0149206320916755

19.

Corts

K. S.

Lederman

2009. Software exclusivity and the scope of indirect network effects in the U.S. home video game market. International Journal of Industrial Organization, 27: 121-136.

20.

Davis

J. P.

2016. The group dynamics of interorganizational relationships: Collaborating with multiple partners in innovation ecosystems. Administrative Science Quarterly, 61: 621-661.

21.

Eaton

Elaluf-Calderwood

Sorensen

Yoo

2015. Distributed tuning of boundary resources: The case of Apple’s iOS service system. MIS Quarterly, 39: 217-243.

22.

Eisenmann

2008. Managing proprietary and shared platforms. California Management Review, 50: 31-53.

23.

Eisenmann

T. R.

Parker

Van Alstyne

M. W.

2009. Opening platforms: How, when and why? In Gawer

(Ed.), Platforms, markets and innovation. London: Edward Elgar.

24.

Garg

Telang

2014. Inferring app demand from publicly available data. MIS Quarterly, 37: 1253-1264.

25.

Garud

Jain

Kumaraswamy

2002. Institutional entrepreneurship in the sponsorship of common technological standards: The case of Sun Microsystems and Java. Academy of Management Journal, 45: 196-214.

26.

Gawer

Cusumano

2008. How companies become platform leaders. MIT Sloan Management Review, 49: 28-35.

27.

Gawer

Cusumano

M. A.

2014. Industry platforms and ecosystem innovation. Journal of Product Innovation Management, 31: 417-433.

28.

Ghose

Han

S. P.

2014. Estimating demand for mobile applications in the new economy. Management Science, 60: 1470-1488.

29.

Hagiu

2014. Strategic decisions for multisided platforms. MIT Sloan Management Review, 55: 71-80.

30.

Heckman

J. J.

1979. Sample selection bias as a specification error. Econometrica, 47: 153-161.

31.

Huang

Ceccagnoli

Forman

D. J.

2013. Appropriability mechanisms and the platform partnership decision: Evidence from enterprise software. Management Science, 59: 102-121.

32.

Iansiti

Levien

2004. Strategy as ecology. Harvard Business Review, 82: 68-78.

33.

IDC. 2016. Worldwide mobile applications forecast, 2016-2020. Framingham, MA: International Data Corporation.

34.

Jacobides

M. G.

Cennamo

Gawer

2018. Towards a theory of ecosystems. Strategic Management Journal, 39: 2255-2276.

35.

Jacobides

M. G.

Hitt

L. M.

2005. Losing sight of the forest for the trees? Productive capabilities and gains from trade as drivers of vertical scope. Strategic Management Journal, 26: 1209-1227.

36.

Kapoor

Agarwal

2017. Sustaining superior performance in business ecosystems: Evidence from application software developers in the iOS and Android smartphone ecosystems. Organization Science, 28: 531-551.

37.

Karhu

Gustafsson

Lyytinen

2018. Exploiting and defending open digital platforms with boundary resources: Android’s five platform forks. Information Systems Research, 29: 479-497.

38.

Kochhar

Hitt

M. A.

1998. Linking corporate strategy to capital structure: Diversification strategy, type and source of financing. Strategic Management Journal, 19: 601-610.

39.

Landsman

Stremersch

2011. Multihoming in two-sided markets: An empirical inquiry in the video game console industry. Journal of Marketing, 75: 39-54.

40.

Lavie

Rosenkopf

2006. Balancing exploration and exploitation in alliance formation. Academy of Management Journal, 49: 797-818.

41.

Levitt

March

J. G

. 1988. Organizational learning. Annual Review of Sociology, 14: 319-338.

42.

McIntyre

D. P.

Srinivasan

2017. Networks, platforms, and strategy: Emerging views and next steps. Strategic Management Journal, 38: 141-160.

43.

Miric

Ozalp

2020. Paradox of middleware: Innovation enabler and creativity constraint. Working paper, Academy of Management Annual Meeting Proceedings.

44.

Ozalp

Cennamo

Gawer

2018. Disruption in platform-based ecosystems. Journal of Management Studies, 55: 1203-1241.

45.

Ozalp

Eggers

J. P.

Malerba

2019. Hitting reset: How the dynamics of platform evolution affect the value of firm experience. Working paper, Academy of Management Annual Meeting Proceedings.

46.

Parker

Van Alstyne

2018. Innovation, openness, and platform control. Management Science, 64: 3015-3032.

47.

Parker

Van Alstyne

Jiang

2017. Platform ecosystems: How developers invert the firm. MIS Quarterly, 41: 255-266.

48.

Prentice

R. L.

Gloeckler

L. A.

1978. Regression analysis of grouped survival data with application to breast cancer data. Biometrics, 34: 57-67.

49.

Rietveld

2018. Creating and capturing value from freemium business models: A demand-side perspective. Strategic Entrepreneurship Journal, 12: 171-193.

50.

Rietveld

Eggers

J. P.

2018. Demand heterogeneity in platform markets: Implications for complementors. Organization Science, 29: 304-322.

51.

Rietveld

Ploog

J. N.

Nieborg

2020. The coevolution of platform dominance and governance strategies: Effects on complementor performance outcomes. Academy of Management Discoveries. https://doi.org/10.2139/ssrn.3615719

52.

Rietveld

Schilling

M. A.

Bellavitis

2018. Platform strategy: Managing ecosystem value through selective promotion of complements. Organization Science. https://doi.org/10.1287/orsc.2019.1290

53.

Rietveld

Seamans

Meggiorin

2020. Market orchestrators: The effect of platform certification on complementor performance and behavior in the context of kiva (2010-2013). Working paper.

54.

Sanchez

Mahoney

J. T.

1996. Modularity, flexibility, and knowledge management in product and organization design. Strategic Management Journal, 17: 63-76.

55.

Santos

F. M.

Eisenhardt

K. M.

2005. Organizational boundaries and theories of organization. Organization Science, 16: 491-508.

56.

Schilling

M. A.

2000. Toward a general modular systems theory and its application to interfirm product modularity. Academy of Management Review, 25: 312-334.

57.

Schilling

M. A.

2009. To protect or to diffuse? Tradeoffs in appropriability, network externalities and architectural control. In Gawer

(Ed.), Platforms, markets and innovation: 192-218. London: Edward Elgar.

58.

Seamans

Zhu

2017. Repositioning and cost-cutting: The impact of competition on platform strategies. Strategy Science, 2: 83-99.

59.

Selander

Henfridsson

Svahn

2013. Capability search and redeem across digital ecosystems. Journal of Information Technology, 28: 183-197.

60.

Shi

Chumnumpan

2020. Platform development: Emerging insights from a nascent industry. Journal of Management. https://doi.org/10.1177/0149206320929428

61.

Simcoe

Watson

2019. Forking, fragmentation, and splintering. Strategy Science, 4: 283-297.

62.

Stettner

Lavie

2014. Ambidexterity under scrutiny: Exploration and exploitation via internal organization, alliances, and acquisitions. Strategic Management Journal, 35: 1903-1929.

63.

Thomas

L. D. W.

Autio

Gann

D. M.

2014. Architectural leverage: Putting platforms in context. Academy of Management Perspectives, 28: 198-219.

64.

Tiwana

2014. Platform ecosystems: Aligning architecture, governance, and strategy. Burlington, MA: Morgan Kaufmann.

65.

Tsoukas

2011. Firm survival and financial development: Evidence from a panel of emerging Asian economies. Journal of Banking & Finance, 35: 1736-1752.

66.

Venkataraman

Ceccagnoli

Forman

2018. Multihoming within platform ecosystems: The strategic role of human capital. Working paper, Georgia Tech Scheller College of Business Research Paper No. 18-8, Atlanta, GA.

67.

Wareham

Fox

P. B.

Cano Giner

J. L.

2014. Technology ecosystem governance. Organization Science, 25: 1195-1215.

68.

West

2003. How open is open enough? Melding proprietary and open source platform strategies. Research Policy, 32: 1259-1285.

69.

Kankanhalli

2018. User service innovation on mobile phone platforms: Investigating impacts of lead userness, toolkit support, and design autonomy. MIS Quarterly, 42: 165-187.

70.

Yoo

Boland

R. J. J.

Lyytinen

Majchrzak

2012. Organizing for innovation in the digitized world. Organization Science, 23: 1398-1408.

71.

Yoo

Henfridsson

Lyytinen

2010. The new organizing logic of digital innovation: An agenda for information systems research. Information Systems Research, 21: 724-735.

72.

Zhang

Tong

T. W.

2020. Platform governance matters: How platform gatekeeping affects knowledge sharing among complementors. Strategic Management Journal. https://doi.org/10.1002/smj.3191

73.

Zhu

Iansiti

2012. Entry into platform-based markets. Strategic Management Journal, 33: 88-106.

Platform Governance Design in Platform Ecosystems: Implications for Complementors’ Multihoming Decision

Abstract

Keywords

Literature and Theory

Complementor Multihoming in Platform Ecosystems

Platform Governance Design

Hypotheses

Ecosystem Complexity and Multihoming Decision

Heterogeneity of Complementors and Complements

Destination ecosystem experience

Modular components

Method

Research Setting and Data

Dependent Variable

Multihoming

Independent Variables

Relative ecosystem complexity

Moderators

Destination ecosystem experience

Complement modularity

Control Variables

Estimation Approach

Results

Robustness Tests

Discussion

Footnotes

Acknowledgements

ORCID iDs

Notes

References