Platform Coring on Digital Software Platforms (Schriften zur Business Analytics und zum Informationsmanagement) 3658347988, 9783658347987

Citation preview

Benedict Bender

Platform Coring on Digital Software Platforms

Schriften zur Business Analytics und zum Informationsmanagement Reihe herausgegeben von Carsten Felden, FG Wirtschaftsinformatik/Fak. 6, TU Bergakademie Freiberg, Freiberg, Deutschland

Die Reihe beschäftigt sich mit dem Themenkomplex der Business Analytics aus der Sicht der Wirtschaftsinformatik. Im Spannungsfeld der Mensch-AufgabeTechnik-Systeme werden einerseits fachliche Fragestellungen adressiert, die im Kontext der Business Analytics managementorientierter oder innovativer Lösungsansätze bedürfen. Andererseits werden methodische Ansätze beleuchtet, um gewonnene Ergebnisse zu neuen Lösungs- und Denkansätzen aufzuzeigen. Hervorstechendes Merkmal dieser Reihe ist es, dass fachliche Dimensionen mit algorithmischen und analytischen Dimensionen verknüpft werden, um den Charakter der Business Analytics angemessen aufzeigen zu können. Daher integriert diese Reihe auch unterschiedliche Wissensgebiete, um zum wissenschaftlichen Diskurs beitragen zu können.

Weitere Bände in der Reihe http://www.springer.com/series/15759

Benedict Bender

Platform Coring on Digital Software Platforms

Benedict Bender Potsdam, Germany Dissertation, Universität Potsdam, 2020

Schriften zur Business Analytics und zum Informationsmanagement ISBN 978-3-658-34798-7 ISBN 978-3-658-34799-4 (eBook) https://doi.org/10.1007/978-3-658-34799-4 © The Editor(s) (if applicable) and The Author(s), under exclusive license to Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2021 This work is subject to copyright. All rights are solely and exclusively licensed by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. The publisher, the authors and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, expressed or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations. Responsible Editor: Marija Kojic This Springer Gabler imprint is published by the registered company Springer Fachmedien Wiesbaden GmbH part of Springer Nature. The registered company address is: Abraham-Lincoln-Str. 46, 65189 Wiesbaden, Germany

Abstract

Digital software platforms such as iOS or Android evolve quickly. Through regular updates, their set of built-in (core) functionalities increases significantly. Innovation in terms of introducing new functionality allows developers to strengthen the platform amidst competition. However, it can hurt contributors in the platform ecosystem when introducing core features that are already provided by third-party developers, which is referred to as platform coring. So far, platform coring remains underexplored and is not sufficiently understood to provide meaningful guidance for the parties involved. Thus, this thesis addresses the research gap to better understand the phenomenon of platform coring and related implications. The combination of four studies provides insights into the stakeholder perspectives, which are integrated with theoretical findings to provide a comprehensive understanding of platform coring. The thesis reveals coring to be a common phenomenon on software platforms. Third-party developers perceive platform coring differently, whereby their motivation to contribute is the key factor. The effects of coring for contributors depend on the type of coring performed. In general, affected applications are used less after coring. Third-party developers use countermeasures to prevent coring if it is perceived negatively and considered as likely to happen to their contributions. Platform owners are well-advised to carefully consider the benefits and risks for their platform ecosystem. Thereby, the thesis contributes by highlighting avenues to employ platform coring for the competitive advantage of the platform and ecosystem simultaneously. Keywords: Platform Coring, Digital Platforms, Software Platforms, Platform Integration, Mobile Device Platforms, Browser Platforms

v

Zusammenfassung

Digital Software Plattformen entwickeln sich kontinuierlich weiter. Mittels regelmäßiger Updates stellen Plattformen wie iOS und Android zusätzliche CoreFunktionen bereit. Innovative Funktionen stellen für Softwareplattformen ein wesentliches Differenzierungsmerkmal dar, weshalb Plattformen mit zusätzlichen Funktionen ihre Wettbewerbsposition stärken können. Gleichzeitig besteht jedoch die Gefahr Entwicklern im Plattform-Ökosystem zu schaden, insofern CoreFunktionen bereitgestellt werden, welche bereits durch Drittanbieter angeboten werden. Dieser Vorgang wird als “Plattform Coring” bezeichnet. Plattform Coring wurde bisher nicht systematisch untersucht. Der gegenwärtige Forschungsstand bietet den beteiligten Parteien auf strategischer Ebene keine ausreichende Hilfestellung hinsichtlich Plattform Coring. Diese Arbeit adressiert die Forschungslücke, indem das Phänomen des Plattform Corings und resultierende Implikationen untersucht werden. Vier Arbeiten beschreiben das Konzept und bieten Einblick in die Perspektive der Stakeholder. Ihre Zusammenführung und theoretische Anreicherung bietet ein umfassendes Bild zu Platform Coring. Die Ergebnisse der Arbeit zeigen, dass Plattform Coring ein typisches Phänomen von Softwareplattformen darstellt. Die Einstellung der Entwickler gegenüber Plattform Coring variiert. Dabei stellt ihre Motivation, Entwicklungen für die Plattform bereitzustellen, einen Schlüsselfaktor dar. Die Effekte von Coring variieren in Abhängigkeit des Coring-Typs. Generell werden von Coring betroffene Applikationen weniger häufig genutzt. Schutzmaßnahmen werden eingesetzt, wenn Coring negativ empfunden und als wahrscheinlich eingeschätzt wird. Plattformbetreiber sollten die Vor- und Nachteile von Coring für ihr Plattformökosystem sorgfältig abwägen. Die Arbeit zeigt auf, wie Plattform Coring gleichzeitig zum Vorteil für die Plattform als auch des Ökosystem genutzt werden kann.

vii

viii

Zusammenfassung

Schlagwörter: Platform Coring, Digitale Plattformen, Software Plattformen, Plattform Integration, Plattformen für mobile Geräte, Browser Plattformen

Contents

1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 3

2

Related Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Platform Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Central Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Software Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Platform Ecosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Innovation in the Platform Context . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Stakeholder of Platform Innovation . . . . . . . . . . . . . . . . . 2.3.2 Innovation on Software Platforms . . . . . . . . . . . . . . . . . . 2.4 Platform Coring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Complementary Market Entry and Platform Coring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Research Gap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7 7 9 10 13 19 19 20 23

Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Summary Paper 1 – Coring Fundamentals . . . . . . . . . . . . . . . . . . 3.2 Summary Paper 2 – Boundary Resources . . . . . . . . . . . . . . . . . . 3.3 Summary Paper 3 – Perspectives on Coring . . . . . . . . . . . . . . . . 3.4 Summary Paper 4 – Developers’ Attitude towards Coring and use of Countermeasures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Coherent Research Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Paper Combination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31 32 34 35

3

24 27

38 40 42

ix

x

4

5

Contents

Coring on Digital Platforms—Fundamentals and Examples from the Mobile Device Sector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Related Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Digital Platforms and Business Ecosystems . . . . . . . . . . 4.2.2 Coring on Digital Platforms . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Related Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Coring Systematization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Effects in Different Coring Modes . . . . . . . . . . . . . . . . . . 4.4 Case-Study Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 Selection of Comparison Objects . . . . . . . . . . . . . . . . . . . 4.4.3 Data Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.4 Analysis Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Coring Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 Involved Parties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.2 Aims of the Involved Parties . . . . . . . . . . . . . . . . . . . . . . . 4.5.3 Structural Inequalities in the Partnership . . . . . . . . . . . . . 4.5.4 Opportunities of Coring . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.5 Risks of Coring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.6 Coring as Beneficial Cooperation for Platform Advancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.2 Future Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.3 Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Impact of Integration on Application Success and Customer Satisfaction in Mobile Device Platforms . . . . . . . . . . 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Related Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Participation on Digital Platforms . . . . . . . . . . . . . . . . . . 5.2.2 Platform Openness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.3 Boundary Resources as Integration Mechanism . . . . . . . 5.3 Hypotheses Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Model Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 Aspects of Platform Integration . . . . . . . . . . . . . . . . . . . .

45 46 47 47 49 51 52 54 55 55 56 59 60 62 63 63 66 67 68 69 70 71 72 73 74 75 79 80 81 82 82 83 83 86 86

Contents

xi

5.5 5.6

Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Model Operationalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.1 Model categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.2 Control variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.3 Application Success Measurement . . . . . . . . . . . . . . . . . . 5.6.4 Customer Satisfaction Measurement . . . . . . . . . . . . . . . . 5.7 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7.1 Descriptive Analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7.2 Regression Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7.3 Integration Success Model . . . . . . . . . . . . . . . . . . . . . . . . . 5.7.4 Integration Satisfaction Model . . . . . . . . . . . . . . . . . . . . . 5.8 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.8.1 Results Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.8.2 Theoretical Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . 5.8.3 Practical Implications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.8.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.8.5 Future Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

92 93 96 97 98 99 99 99 100 101 105 106 106 107 109 111 111 112 113

Platform Coring in the Browser Domain—an Exploratory Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Related Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Research Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Sampling Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.2 Interview Structure and Data Collection . . . . . . . . . . . . . 6.3.3 Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.1 Motivation and Attitude Towards Coring . . . . . . . . . . . . 6.4.2 Coring Likelihood . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.3 Perceived Effects and Implications of Coring . . . . . . . . 6.4.4 Anti-Coring Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.5 Core Developer Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

119 120 122 125 127 129 130 131 133 137 138 140 141 143 146 147

6

xii

7

8

Contents

Entering Complementary Markets on Software Platforms—The Third-Party Perspective . . . . . . . . . . . . . . . . . . . . . . . 7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Related Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.2 Complementary Market Entry . . . . . . . . . . . . . . . . . . . . . . 7.2.3 Complementors’ Reactions . . . . . . . . . . . . . . . . . . . . . . . . 7.2.4 Protection Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Model Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.1 Attitude Towards Complementary Market Entry . . . . . . 7.3.2 Perceived Likelihood of Complementary Market Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.3 Measures to Prevent Complementary Market Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.1 Survey Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.2 Control Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.3 Data collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.4 Data Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5 Analysis and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.1 Measurement Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.2 Dataset Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.3 Hypothesis Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.4 Sub-Model Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.1 Theoretical Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.2 Practical Implications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.4 Future Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Effects of Platform Coring on Complements Usage — The Salesforce Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Related Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3 Hypothesis Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

149 150 152 153 153 154 155 156 156 158 161 163 163 165 166 167 168 170 170 172 175 178 178 183 187 188 190 191 194 201 201 203 204

Contents

8.4 8.5 8.6 8.7 8.8

xiii

Reference Case: Salesforce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

206 207 211 215 219

Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1 Integration of the Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.1 Existence of Platform Coring . . . . . . . . . . . . . . . . . . . . . . 9.1.2 Types of Coring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.3 Coring Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.4 Countermeasures against Platform Coring . . . . . . . . . . . 9.1.5 Coring Likelihood . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.6 Reaction to Platform Coring . . . . . . . . . . . . . . . . . . . . . . . 9.1.7 Effects of Coring on Application Usage . . . . . . . . . . . . . 9.2 Practical Implications of the Results . . . . . . . . . . . . . . . . . . . . . . . 9.2.1 Third-Party Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2.2 Platform Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2.3 Coring as a Competitive Advantage . . . . . . . . . . . . . . . . .

221 221 221 223 226 227 228 229 230 231 231 233 236

10 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Future Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

239 239 240 242

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

245

9

List of Figures

Figure 1.1 Figure 2.1 Figure 2.2 Figure 2.3 Figure 2.4 Figure 2.5 Figure 3.1 Figure 3.2 Figure 3.3 Figure 4.1 Figure 4.2 Figure 4.3

Figure 5.1 Figure 6.1 Figure 6.2 Figure 7.1

Thesis structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Typical software platform configurations . . . . . . . . . . . . . . . . Central actors in platform ecosystems for software platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Value system comparison based on Jacobides et al. (2018) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Platform competition among multiple platforms . . . . . . . . . . Platform coring and intra-platform competition . . . . . . . . . . . Overview contributions regarding platform ecosystem stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Association between developers’ motivation and coring perception (Bender et al., 2019) . . . . . . . . . . . . . . . . . . . . . . . . Research model with attitude towards coring, perceived coring likelihood, and use of countermeasures . . . . . . . . . . . . Systematization of coring activities on digital platforms . . . . Corresponding functions of WhatsApp and iOS for internet-based messaging . . . . . . . . . . . . . . . . . . . . . . . . . . Time gap histogram until similar asynchronous functionalities were available in corresponding software component (per first mover) . . . . . . . . . . . . . . . . . . . . . . . . . . . Platform integration research model . . . . . . . . . . . . . . . . . . . . Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Core Concepts in the Relationship between Motivation and Attitude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Research Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 9 15 18 20 27 31 37 39 53 57

62 93 126 132 162

xv

xvi

Figure 7.2 Figure 8.1 Figure 8.2 Figure 8.3

List of Figures

Integrated Model with Three Regressions on Central Model Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Initial release of survey extensions on the Salesforce AppExchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reviews per week comparison . . . . . . . . . . . . . . . . . . . . . . . . . Reviews per week distribution for survey extensions (boxplots) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

169 209 212 214

List of Tables

Table 2.1 Table 2.2 Table Table Table Table

3.1 3.2 3.3 4.1

Table 5.1 Table 5.2 Table 5.3 Table 6.1 Table 6.2 Table 7.1 Table 7.2 Table 7.3 Table 7.4 Table 7.5 Table 7.6

Definitions of software platforms . . . . . . . . . . . . . . . . . . . . . . . . Definitions of (platform) ecosystems in the software context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Systematization of coring types with examples from iOS . . . . Overview of research papers characteristics . . . . . . . . . . . . . . . Overview of research papers findings . . . . . . . . . . . . . . . . . . . . Release date comparison of similar software functions in WhatsApp and Apple’s iOS . . . . . . . . . . . . . . . . . . . . . . . . . . Concepts related to platform integration . . . . . . . . . . . . . . . . . . Integration model operationalization for the Apple iOS platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Regression model A (application performance) and model B (customer satisfaction) . . . . . . . . . . . . . . . . . . . . . Interview Partner Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interview Findings Concepts and Themes related to Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related Literature Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . Model Construct Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Regression Model A—Attitude Towards Complementary Market Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Regression Model L—Perceived Likelihood of Complementary Market Entry . . . . . . . . . . . . . . . . . . . . . . . . Regression Model M—Measures to Prevent Complementary Market Entry . . . . . . . . . . . . . . . . . . . . . . . . . . Hypothesis Testing Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11 14 32 40 41 61 87 94 102 129 132 164 171 173 173 174 175

xvii

xviii

List of Tables

Table 7.7 Table 7.8 Table 7.9 Table 8.1 Table 8.2 Table 8.3 Table 9.1 Table Table Table Table Table

9.2 9.3 9.4 9.5 9.6

Variations of Model Constructs Depending on the Browser Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . Variations of Model Constructs Depending on Their Multiplatform Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Model Measurement Operationalization (Survey) . . . . . . . . . . Descriptive data of Salesforce AppExchange snapshots . . . . . Comparison of reviews per week before and after coring activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DID-Model results for number of reviews per week . . . . . . . . Occurrence of platform coring on the considered software platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of platform coring aspects and options . . . . . . . . . . Third-party developers attitude towards platform coring . . . . . Measures to prevent platform coring . . . . . . . . . . . . . . . . . . . . . Factors of coring likelihood from different perspectives . . . . . Exemplary effects between coring of userand developer-related functionality . . . . . . . . . . . . . . . . . . . . . .

176 177 191 210 212 213 223 225 227 228 229 234

1

Introduction

Abstract

Digital software platforms such as iOS or Android evolve quickly. Through regular updates, their set of built-in (core) features increases. While innovation allows strengthening platforms amidst competition, it can hurt contributors when introducing core features that are already provided by third-party developers (Platform Coring). This chapter provides an introduction and overview of the coring phenomenon and related challenges for the platform owner. Software platforms, as a specific type of innovation platforms, allow for the integration of external innovation capability within a uniform platform architecture. Following Tiwana et al. (2010) a software platform is understood as “extensible codebase of a software-based system that provides core functionality shared by the modules that interoperate with it and the interfaces through which they interoperate”. Through the open paradigm of software platforms, third parties can contribute functionality in the form of capsuled modules (Tiwana et al., 2010). Software platforms are primarily regarded as innovation platforms “which consist of technological building blocks that are used as a foundation on top of which a large number of innovators can develop complementary services or products” (Evans & Gawer, 2016). In contrast to transaction platforms that facilitate transactions and exchange among participants, the aspect of extensibility and external innovation is key. Thereby, software platforms offer users more functionality than a single entity could achieve alone (Eisenmann et al., 2011). The platform owner (e.g. Apple) provides basic functionality through the platform core (e.g. iOS), whereas thirdparty developers provide more specialized functionality through software applications (e.g. WhatsApp) that are typically distributed over platform-specific marketplaces (e.g. AppStore). Platform users combine the core functionality with selected © The Author(s), under exclusive license to Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2021 B. Bender, Platform Coring on Digital Software Platforms, Schriften zur Business Analytics und zum Informationsmanagement, https://doi.org/10.1007/978-3-658-34799-4_1

1

2

1

Introduction

third-party modules to configure the platform corresponding to their individual needs (Olleros, 2008; Bosch & Bosch-Sijtsema, 2010). Platforms usually coexist and compete with each other (Cennamo & Santalo, 2013). The aspect of platform competition applies for software platforms in particular, since compared to hardware-related components they are easily exchangeable (migration costs are relatively low). In the context of multi-sided software platforms, owners compete not only for users, but also for third-party developers as a source of innovation (Rochet & Tirole, 2003; Armstrong, 2006). Through network effects, both sides of the platform are interrelated (Song et al., 2018). The aspect of innovation is essential for platforms to succeed in competition. Continuous innovation is required to build and maintain a competitive advantage (Kankanhalli et al., 2015; Toppenberg et al., 2016). Providing novel functionality is a major component of innovation for software platforms (de Reuver et al., 2017; Nambisan et al., 2017). Platform owners have to address both platform sides in terms of innovation. Platform owners provide boundary resources for third-party developers that allow them to realize applications (Eaton et al., 2015). Differentiation can be achieved by providing resources that allow developers to realize applications more efficiently than competing platforms (Kimet al., 2016; Ye & Kankanhalli, 2018). For platform users, owners provide functionality through the platform core to attract users to their platform. While platform owners usually provide basic functionality (e.g. web-browser, e-mail client on smartphones) for the mass market, third-party contributors provide more specialized functionality (Olleros, 2008; Haile & Altmann, 2016). By providing better functionality than competing platforms, owners can differentiate themselves and thereby attract users (Nikou et al., 2014). However, providing extended core functionality can result in competition with developers, especially when owners introduce functionality similar to that which is already available through third-party complements (Gawer & Cusumano, 2014; Parker & Alstyne, 2018). Platform owners are at an advantage because they can enforce their interests through platform governance (Huber et al., 2017; Constantinides et al., 2018). Software platforms progress over time (Eaton et al., 2015; de Reuver et al., 2017). Through platform updates, new features are introduced to the platform core. While platform innovation is considered a critical success factor for software platforms (Kankanhalli et al., 2015), negative consequences might arise if introduced features replace external contributions (Gawer & Cusumano, 2014). Introducing functionality to the platform core which was previously provided by third-party extensions is referred to as “platform coring”. Platform coring can be considered an innovation strategy for platform owners (Nambisan et al., 2017; Parker & Alstyne, 2018). From the platform owner’s

1.1 Thesis Structure

3

perspective, coring helps strengthen the platform amidst competition, control for platform functionality and secure additional revenues. From a sequential innovation perspective, cored functionality may serve as a foundation for additional innovations (Parker & Alstyne, 2018). Therefore, entering complementary markets by providing similar functionality might be attractive for platform owners, although negative consequences concerning further contributions from third-party developers are likely to be involved (Gawer & Cusumano, 2014; Kim et al., 2016). Coring is likely to affect the use of third-party contributions. Since users might prefer default core functionality over contributed third-party functionality, their importance is assumed to diminish over time. For commercial providers, coring can be seen as a threat to their business model. Since owners rely on third-party developers for platform innovation, related aspects have to be handled with care (Boudreau, 2012; Kim et al., 2016). Platform owners have to balance their interests on the platform market level (inter-platform competition) with the dynamics in their respective platform ecosystem (intra-platform competition) to achieve long-term success. While coring allows owners to strengthen the platform in competition among platforms, the effects of coring on the micro-perspective, i.e. the platform and ecosystem level, are assumed to be more complex and not yet known. Platform coring has not yet been sufficiently explored in the literature. Even though the need for third-party contributions as a source of innovation has been recognized (Gawer & Cusumano, 2014; Lusch & Nambisan, 2015), the perception and effects of platform coring remain unclear. Understanding the third-party perspective on platform coring is necessary to adjust related activities and thereby ensure continuous innovation by external partners as a foundation for the competitive advantage and long-term success of software platforms. Understanding the micro-perspective is important to provide strategic guidance for the parties involved. This thesis aims to close this research gap by exploring the most relevant issues related to platform coring. The thesis contributes in various ways. First, the thesis confirms the prevalence of coring on software platforms. Second, insights into the stakeholder perspective provide a comprehensive understanding of coring. Finally, the thesis highlights avenues to employ coring for the advantage of the platform and ecosystem simultaneously.

1.1

Thesis Structure

The thesis is structured into six chapters (see Figure 1.1). The following chapter briefly highlights related literature and points out the research gap addressed by the thesis. Chapter three provides a summary of all contributions and highlights the

4

1

Introduction

Chapter 1: Introduction

- Relevance of the Topic - Motivation of Study Interest

Motivation

Chapter 2: Related Literature

- Platform Focus: Software Platforms - Innovation on Software Platforms - Research Gap: Platform Coring

Theoretical Foundation

Study 1: Coring on Digital Platforms (Mobile Device Platforms)

Study 2: The Impact of Integration on Application Success

Study 3:

Chapter 3-7 : Contributions

Coring in the Browser Domain

Study 4:

Individual Contributions

Attitude Formation and Protection Mechanisms

Coherent Research Program

Chapter 8: Salesforce Analysis

- Platform Coring in the Professional Sector - E ect of Platform Coring on Application Usage

Chapter 9: Discussion

- Integration of the Results (per Topic) - Implications for the Parties involved (per Stakeholder)

Chapter 10: Summary

- Limitations - Future Research - Concluding Remarks

Figure 1.1 Thesis structure

Integration of the Results

Concluding Remarks

1.1 Thesis Structure

5

coherent research program. Chapter four provides insights in the effect of platform coring on third-party complements usage in the professional sector. Subsequently, the research findings are integrated in Chapter five and related research questions are discussed. Finally, the results are summarized, limitations are presented and avenues for future research are highlighted.

2

Related Research

Abstract

Digital software platforms such as iOS or Android evolve quickly. Through regular updates, their set of built-in (core) features increases. While innovation allows strengthening platforms amidst competition, it can hurt contributors when introducing core features that are already provided by third-party developers (Platform Coring). This chapter briefly summarizes literature related to platform coring and complementary market entry. Moreover, central definitions are discussed and the perspective on platform coring are explained. Digital platforms as a recent form of organization are gaining importance in literature and practice (de Reuver et al., 2017; Constantinides et al., 2018). Industry-wide platforms in general and software platforms in particular allow the integration of third-party innovation within a coherent infrastructure (Ghazawneh & Henfridsson, 2013; Saadatmand et al., 2019). This chapter briefly reviews the literature related to this thesis and describes the platform focus used in this thesis. For the sake of brevity, descriptions of typical effects related to digital platforms are avoided in this section. Relevant effects and related phenomena are discussed in related papers (Evans, 2003; Parker & Van Alstyne, 2005; Armstrong, 2006; Boudreau, 2010; Song et al., 2018).

2.1

Platform Focus

Given the emergence of digital platform research, different categorizations of platforms exist (de Reuver et al., 2017). This section describes the platform focus set for this thesis. Evans and Gawer (2016) distinguish platforms based on their key © The Author(s), under exclusive license to Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2021 B. Bender, Platform Coring on Digital Software Platforms, Schriften zur Business Analytics und zum Informationsmanagement, https://doi.org/10.1007/978-3-658-34799-4_2

7

8

2

Related Research

function, i.e. matching, interaction, complements or ecosystem, resulting in four different platform types: transaction, innovation, integrated, and investment. Transaction platforms facilitate transactions or exchanges between platform users. Transaction platforms aim to match supply and demand in an efficient way, whereby the matching may involve tangible goods (trade exchange, e.g. eBay) or intangible services (ride sharing, e.g. Uber or flat sharing, e.g. Airbnb). Innovation platforms serve as a foundation for other firms to develop complementary products, technologies or services. Complements are provided from firms or individual parties that are part of the platform ecosystem. Linux as an operating system is an innovation platform that allows complementary software products to be built upon the modular system architecture. Integrated platforms combine characteristics of transaction and innovation platforms into a single platform. Software platforms typically combine multiple platform types. Software platforms can be understood as innovation platforms (as they allow complementary software modules to be built) and as transaction platforms (as they match supply and demand for extended functionality with their application marketplaces). The example of the mobile device platform Apple iOS is an integrated platform (type 2). The Apple AppStore (marketplace) constitutes the transaction platform which allows it to gather additional functionality, whereas the iOS software platform with the related software development kit constitutes the innovation platform which allows third parties to develop complementary software applications for the mobile devices running iOS. Finally, the group of investment platforms involves companies that pursue a platform portfolio strategy. Those companies act as holding companies or active platform investors (Evans & Gawer, 2016). The focus of this thesis is placed on software platforms that are known for their extensibility, which allows third parties to provide complementary software modules (Tiwana et al., 2010) which in turn makes them highly interesting for coring activities. Software platforms are primarily considered as innovation platforms that allow for complements in the form of software modules. Figure 2.1 depicts two typical software platform configurations according the components provided. Software platforms that only provide an extensible basis (type 1) serve as an innovation platform. Most software platforms, depending on the focus, can be considered as integrated platforms since they typically incorporate marketplaces to gather complementary software products. Thereby the marketplace serves as element to facilitate transactions among the parties involved, which fits the idea of a transaction platform (e.g. Android with the PlayStore and iOS with the AppStore) (Ghazawneh & Henfridsson, 2015). As such, software platforms that provide an extensible platform core with related boundary resources and a marketplace infrastructure can be considered

2.2 Central Definitions Platform Type

Characterization (Key Function)

9 Element in Software Platform Context

Software Platform

1

Foundation for Complementarities

Innovation

Transaction

Facilitates Transactions

(Open) Core Platform & Boundary Resources

Marketplace

2 Software Platform

Extensible Software Platform

(Integrated) Software Platform Extensible Software Platform with associated Marketplace Component for Extension Distribution

Figure 2.1 Typical software platform configurations

as integrated platform (type 2). Whereas an extensible software platform alone (type 1) does constitute a software platform (Tiwana et al., 2010), a marketplace that is part of an integrated software platform (type 2) as a stand-alone component does not. In addition to the type of platform, the aspect of openness is widely recognized as an important aspect of platforms (Eisenmann et al., 2009; Boudreau, 2010; Ondrus et al., 2015). Gawer and Cusumano (2014) distinguish between internal or companyspecific and external platforms. Internal platforms are focused on a single firm to provide a technology. For them, innovation capabilities are limited to the boundaries of the firm. In contrast, external platforms are open for external parties to provide complements for the platforms. Thereby, industry-wide platforms are able to benefit from external innovation capabilities (Gawer, 2014). For this thesis, the focus is placed on external, industry-wide software platforms. While platform coring is assumed to occur on internal platforms as well, related activities are governed within a single firm, whereas for external platforms associated ecosystems with multiple stakeholders and potentially conflicting interests make platform coring a complex and interesting aspect of platform innovation.

2.2

Central Definitions

This section defines the central terms used in this thesis. For the two most important ones, “software platform” and “platform ecosystem”, different definitions and their

10

2

Related Research

emergence are discussed. Subsequently, the understanding of these terms applied in this thesis is explained.

2.2.1

Software Platform

Whereas the platform concept has already been discussed separately in a number of different research streams, research on software platforms combines work from different disciplines (de Reuver et al., 2017). More recently, the domain of technological platforms and more lately software platforms are part of platform research. Research on software platforms is closely related to the domain of technological platforms (Evans et al., 2008; Gawer, 2014). Within the field, different perspectives on platform research are discussed. Among these are economic considerations that focus on platforms as multisided markets, as well as the engineering perspective in which platforms are considered as technological architectures (Gawer, 2014). The group of software platforms differs in many respects from product- or service-focused platforms that were included in platform research earlier on (Yoo et al., 2010; de Reuver et al., 2017). For instance, the costs of reproducing software artefacts are almost non-existent. Moreover, software platforms affect transactions between related parties in that they simultaneously allow for external contribution and retain control for the platform owner (Ghazawneh & Henfridsson, 2013; Eaton, 2016). Research on software platforms considers both the technological characteristics and market-focused aspects of software platforms. Within the group of software platforms, different definitions for the term emerged along with the development of each individual research focus. In the following, different terms and their emergence are compared and the understanding of the concept for this thesis is established. Table 2.1 provides an overview of influential research on platforms that has led to the recent understanding of software platforms as technological infrastructures embedded in an ecosystem with different parties involved. Focusing on research studying software platforms, the work of Gawer and Cusumano (2002) serves as a central foundation for the group of platforms as technological systems. While not specifically aimed at software platforms, the work has often been considered by later studies of software platforms. Evans et al. (2008) examines software platforms with a focus on interoperability and the provision of services to external components. Here, the focus is on the central function of the platform as the heart of the economies and ecosystems. Later definitions, such as the one by Baldwin and Woodard (2009), cover structural characteristics of plat-

Focus

Platforms as technological systems

Software

Platform Architecture

Software

Source

Gawer and Cusumano (2002)

Evans et al. (2008)

Baldwin and Woodard (2009)

Tiwana et al. (2010)

Software Platform

Platform

Software platform

Platform

Term

Table 2.1 Definitions of software platforms

A product is a ‘platform’ when it is one component or subsystem of an evolving technological system, when it is strongly functionally interdependent with most of the other components of this system, and when end-user demand is for the overall system, so that there is no demand for components when they are isolated from the overall system. A software program that makes services available to other software programs through Application Programming Interfaces (APIs). A set of stable components that supports variety and evolvability in a system by constraining the linkages among the other components. The system is partitioned into a set of ‘core’ components with low variety and a complementary set of ‘peripheral’ components with high variety. The extensible codebase of a software-based system that provides core functionality shared by the modules that interoperate with it and the interfaces through which they interoperate.

Definition

Software Platform: Baldwin and Woodard (2009) Platform Ecosystem: Gawer and Cusumano (2002)

Gawer and Cusumano (2002) Evans et al. (2008)

Gawer and Cusumano (2002)

Conceptual Foundation(s)

2.2 Central Definitions 11

12

2

Related Research

forms and their architectural components. Their conceptualization is guided by the research described above. Tiwana et al. (2010) combine the previous understandings by explicitly addressing the term “software platform” and considering the interplay between technical artifacts, governance mechanisms and the surrounding ecosystem. In essence, their conceptualization provides a theoretically well-founded concept of software platforms taking into account their architecture, related control mechanisms and embeddedness in platform ecosystems. The definition has been considered in many recent studies (Benlian et al., 2015; de Reuver et al., 2017) and itself served as a basis for central concepts such as the boundary resource model (Ghazawneh & Henfridsson, 2013). The definition by Tiwana et al. (2010) is adopted for this thesis, as it captures the key characteristics of software platforms and their integration in platform ecosystems, as well as their interdependence with related control mechanisms. Therefore, software platform is referred to as an “extensible codebase of a software-based system that provides core functionality shared by the modules that interoperate with it and the interfaces through which they interoperate” (Tiwana et al., 2010). For external, industry-wide platforms, third parties contribute modules to software platforms. A module is understood as a “[...] software subsystem that connects to the platform to add functionality to the platform” (Tiwana et al., 2010). Depending on the context, modules are also referred to as applications, extensions, or add-ons. For example, modules are typically termed “applications” on mobile device platforms (Kankanhalli et al., 2015; Comino et al., 2019), while “extensions” is common for browser platforms (Tiwana, 2015a; Tiwana, 2015b; van Angeren et al., 2016). For the context of this thesis, these terms are considered as equivalent synonyms for modules in the context of software platforms. Platform owners provide platform boundary resources to allow for third-party contributions. Simultaneously, platform owners use boundary resources to enforce their interests (Ghazawneh & Henfridsson, 2013). Adjusting boundary resources allows platform owners fine-grained control of development activities on the platform (Eaton et al., 2015). Ghazawneh and Henfridsson (2013) define boundary resources as “the software tools and regulations that serve as the interface for the arm’s-length relationship between the platform owner and the application developer”, which explicitly highlights the control aspect. For software platforms, boundary resources typically “consist of a Software Development Kit (SDK) and a multitude of related [Application Programming Interface] APIs” (Ghazawneh & Henfridsson, 2013). Applications have to conform to the requirements and guidelines set by the platform owner to become published on the platform (Gawer, 2014). Typically, modules are distributed using platform-specific application marketplaces. Following

2.2 Central Definitions

13

Ghazawneh and Henfridsson (2015), an application marketplace is referred to as a “platform component that offers a venue for exchanging applications between developers and end-users [...]”. Application marketplaces have three central roles: they provide a catalogue to match supply and demand, facilitate transactions, and provide an institutional infrastructure for regulatory and legal aspects (Ghazawneh & Mansour, 2015). Platform governance refers to the combination of policies and mechanisms that multisided platforms use to govern their operations and maintain the related ecosystem (Tiwana et al., 2010; Song et al., 2018). Software platforms typically provide development guidelines and specifications that software modules must fulfil to become available on the platform (Ghazawneh & Henfridsson, 2013; Gawer, 2014). Moreover, application reviews are used to ensure that the applications conform to the requirements and control for available functionality. For example, Apple strictly controls all functionality available for mobile devices through the exclusive Apple AppStore. Every application submitted to the marketplace is reviewed prior to its release on the marketplace (Eaton et al., 2015).

2.2.2

Platform Ecosystem

Software platforms are embedded within related platform ecosystems (Tiwana et al., 2010). Generally, the platform ecosystem encompasses the different actors that interact with the platform. Platform ecosystems link the technical infrastructure with the group of actors involved in the processes of value creation and value capture (Hein et al., 2019). The foundation of the ecosystem concept stems from the biological context in referring to the interdependence of the different actors, which can also be applied to the software platform context (Jacobides et al., 2018). Similar to the platform concept, different definitions exist. Table 2.2 presents central ecosystem definitions in the software platform context. Tiwana et al. (2010) define the ecosystem term from an architectural perspective, in which the ecosystem is composed of the platform and related modules. Their view of ecosystem elements was shaped by the work of Gawer and Cusumano (2002). Some of the recent definitions of software platforms incorporate the ecosystem directly (Thomas et al., 2014; Lusch & Nambisan, 2015). Other conceptualizations distinguish the ecosystem from an organizational or technical view (de Reuver et al., 2017). Thereby, the similarities of the technical view of ecosystems, such as de Reuver et al. (2017), exemplifies the overlap with the software platform concept. Conceptualizations, depending on their foundation, involve different aspects of ecosystems. Jacobides et al. (2018) identify the three streams of business

14

2

Related Research

Table 2.2 Definitions of (platform) ecosystems in the software context Source

Focus

Term

Definition

Gawer and Cusumano (2002) Tiwana et al. (2010) de Reuver et al. (2017)

Innovation

Platform Ecosystem

Software Platforms Digital Platforms

Ecosystem

Jacobides et al. (2018)

Ecosystem Organization

Ecosystem

Hein et al. (2019)

Digital Platforms

Platform Ecosystem

The network of innovation to produce complements that make a platform more valuable The collection of the platform and the modules specific to it Technical view: A collection of complements (apps) to the core technical platform, mostly supplied by third-party; Organizational view: Collection of firms interacting with a contribution to the complements. An ecosystem is a set of actors with varying degrees of multilateral, nongeneric complementarities that are not fully hierarchically controlled. A digital platform ecosystem comprises a platform owner that implements governance mechanisms to facilitate value-creating mechanisms on a digital platform between the platform owner and an ecosystem of autonomous complementors and consumers.

Ecosystem

ecosystems, innovation ecosystems and platform ecosystems. Business ecosystems view ecosystems as a collection of organizations that are involved in value creation. Innovation ecosystems are focused around an innovation which is enabled through the combination of actors with different competencies. Platform ecosystems focus on technology products, where the combination of the platform owner and complementors’ contributions make the platform more valuable to users. The platform thereby serves as the connecting element between the different actors involved (Jacobides et al., 2018).

2.2 Central Definitions

15

Whereas the architectural setup of a platform is included within the software platform concept, the ecosystem perspective adds an actor-based view that provides guidance on the boundaries of platforms involving different roles. Thereby, platform ecosystems in the software platform context typically distinguish between three central actors, i.e. platform owner, third-party developer and users (Ghazawneh & Henfridsson, 2013; Tiwana, 2015b; Hein et al., 2019). Whereas the understanding of ecosystems in the software platform context is guided by the definition given by Tiwana et al. (2010), the recent understanding of Hein et al. (2019) specifically addresses the different roles of the actors involved in digital platform ecosystems. Therefore, this thesis adopts the notion put forth by Hein et al. (2019) with its specific focus on the characteristics of software platforms, since these are critically important for the context of this thesis. Given the unique nature of software platforms and their related platform ecosystem, this section provides an overview of the different roles involved in software platform ecosystems. The attractiveness of digital software platforms results from the possibility to integrate external innovation in a common infrastructure and thereby provide more value (e.g. in terms of functionality) than a single entity could achieve alone (Eisenmann et al., 2011). In this regard, the surrounding ecosystem plays a critical role concerning innovation and platform positioning (Boudreau, 2010; Eisenmann et al., 2011; Parker et al., 2017). Thereby, three actors are of primary importance: the platform owner, third-party developer, and user (as depicted in Figure 2.2).

Figure 2.2 Central actors in platform ecosystems for software platforms

The platform owner is responsible for providing and maintaining the platform. Aside from the technical platform basis required to execute applications, the owner

16

2

Related Research

provides basic platform functionality referred to as core functionality. Software platforms provide a reasonable amount of functionality, even without extensions (Ghazawneh & Henfridsson, 2013). For example, mobile devices such as the iPhone or Android-based devices offer functions such as a browser, email or photography. Following the idea of functional separation (Olleros, 2008), the platform itself contains functionality relevant for a great proportion of users (mass market), while third parties extend platform functionality through more specialized applications (Bosch & Bosch-Sijtsema, 2010; Haile & Altmann, 2016). In order to allow for external innovation and software contributions, the platform owner provides boundary resources (Eaton et al., 2015). These involve software development kits (SDKs) to be employed by third-party developers to realize modules for the platform. For example, Apple provides an iOS SDK that allows them to develop applications for Apple devices that run the mobile operation system, iOS. Furthermore, application programming interfaces (APIs) are provided to access platform features and data (Um et al., 2013). The platform owner is also responsible for providing a marketplace that allows for the distribution of applications for the platform. Related governance mechanisms allow the platform owner to control the functionality distributed via the marketplace. The exclusiveness of marketplaces on software platforms varies (Ghazawneh & Henfridsson, 2015). Especially more closed platforms allow for a single marketplace only. In contrast, more open platforms allow for additional marketplaces as well as the distribution of functionality using code packages (without the need to use a marketplace) (Koch & Kerschbaum, 2014; Ghazawneh & Henfridsson, 2015). Third-party developers contribute applications to the software platform. By utilizing the development resources provided by the platform owner (platform boundary resources), developers deploy applications to extend the platform’s core functionality. The modular platform architecture in combination with the boundary resources provided allow developers to realize applications efficiently (Bosch & Bosch-Sijtsema, 2010; Koch & Guceri-Ucar, 2017; Xue et al., 2019). During application development, developers need to conform to the specifications and guidelines set by the platform owner (Ghazawneh & Henfridsson, 2013). Typically, application reviews are part of the governance mechanisms of software platforms. Once applications have passed the review process successfully, their applications are available on the application marketplace for distribution (Eaton et al., 2015; Ghazawneh & Henfridsson, 2015). Finally, the group of users utilizes platform functionality. For users, the functionality of a platform is a combination of platform core functionality and third-party applications. Platform marketplaces allow users to browse available applications and

2.2 Central Definitions

17

gather related functionality. Typically, marketplaces provide free and paid applications (Ghazawneh & Henfridsson, 2010). Once a user buys a paid application, the platform owner directs a specified proportion of the revenue to the corresponding third-party developer (revenue sharing) (Oh et al., 2015). Additionally, marketplaces allow users to review and rate applications. Users are able to provide feedback on third-party applications, request additional functionality, and provide platform owners with feedback on the platform (Ghazawneh & Mansour, 2015). Platform ecosystems are known to allow for the coordination of independent entities as well as complementarities as a result of their modularity (Jacobides et al., 2018). Figure 2.3 depicts the value creation in a platform ecosystem and its structural differences compared to the market-based and hierarchy-based assembly of products (Jacobides et al., 2018). In contrast to buyer-supplier relations, ecosystems and software platforms in particular allow the customer to choose among complements (e.g. software applications) and thereby to individually configure the desired solution. For example, users are able to choose among applications on mobile device platforms (e.g. from the AppStore). In contrast to market-based situations, customers in an platform ecosystem choose from a range of products or software applications that are underpinned by a common technological basis (core, i.e. iOS) and adhere to specifications set by the platform owner (Ghazawneh & Henfridsson, 2013; Jacobides et al., 2018). Platform owners can extend the locus of value creation from within the firm to the ecosystem participants (Kapoor, 2018). Platforms thereby allow for the integration of external innovation for the platform’s advantage. To some extent, ecosystem-based value provision can be understood as a combination of a hierarchy-based value system and a market-based value system (see Figure 2.3). As a result of their structure, competition in the context of software platforms and the associated ecosystem is different from both market-based and hierarchybased systems. The group of third-party developers is in competition with each other to attract users to their platform applications. Similar to the contribution itself, third-party developers are in competition with the platform owner, who provides functionality through the platform core (see Figure 2.5). Whereas third parties typically provide complementary functionality to the platform core, through coring the similarity between core and third-party applications increases and simultaneously increases competition between the two (core and third-party applications). As a result, coring shifts competition dynamics in the platform context.

18

2

product

Related Research

User / Customer

product Focal Firm Product

Hierarchy-based Value System

Provide parts of overall product

Supplier Component A

product & optional complementarities

Ecosystem-based Value System

Complementor A

Supplier Component B

User / Customer

Supplier Component B

Provide complements Complementor B

Sell focal product Focal Firm Product

Complementor C

tfor

t sys Eco m/

Pla

Supplier Component A

Buy separate products

Supplier Component B

Supplier Component B

User / Customer

Market-based Value System

Sell separate products

Supplier Component A

Supplier Component B

Supplier Component B

Figure 2.3 Value system comparison based on Jacobides et al. (2018)

em

2.3 Innovation in the Platform Context

2.3

19

Innovation in the Platform Context

Innovation and related management activities are largely influenced by the increasing importance of digital infrastructures and technologies. Traditional innovation concepts do not appropriately reflect the characteristics of digital innovation (Nambisan et al., 2017). Following Nambisan et al. (2017), digital innovation is understood as “the creation of (and consequent change in) market offerings, business processes, or models that result from the use of digital technology”. Subsequently, they state that in digital innovation “digital technologies and associated digitizing processes form an innate part of the new idea and/or its development, diffusion, or assimilation”. The embeddedness of digital technologies and processes fits the nature of software platforms where innovation processes and outcomes are digital artifacts (Tiwana et al., 2010). Innovation on industry-wide software platforms, particularly external innovation, is mainly concerned with contributed software modules that extend platform functionality beyond the functionality of the platform core (Gawer & Cusumano, 2014). Examples from software platforms highlight the extent of functionality contributed by third parties. Allen (2012) found that thirdparty functionality exceeded the functionality provided by the platform core in terms of lines of code in the case of WordPress.

2.3.1

Stakeholder of Platform Innovation

The aspect of innovation is of great importance for all stakeholders in the platform ecosystem (Gawer & Cusumano, 2014). For platform owners, innovation is of importance concerning the competition with other platforms. Usually, digital platforms coexist and are in direct competition, as exemplified in Figure 2.4. Innovation allows a platform to differentiate itself from competing platforms. Thereby, continuous platform innovation is considered a critical success factor for digital platforms (Kankanhalli et al., 2015; Toppenberg et al., 2016). More innovative platforms could gain market share and motivate additional parties of both sides (third-party developers and users) to join the platform (Parker et al., 2017). As a result of network effects, this strengthens the platform and its position within the competition. Nonetheless, platform owners are highly dependent on contributors given the importance of thirdparty complements in platform competition (Song et al., 2018). Innovation is of importance for third-party developers as well. Innovation regarding boundary resources impacts developers’ possibilities to contribute functionality to the platform as well as their efficiency in implementing modules and is known to be a factor when users choose between competing platforms (Hsieh & Hsieh, 2013;

20

2

Platform 1

Third-party Developer

Related Research

Platform 2

Platform 3

User

Competition Contributions / Use

Figure 2.4 Platform competition among multiple platforms

Kim et al., 2016). Another aspect is that users are more likely to join more innovative platforms, which is why developers are interested in contributing to platforms with a great and increasing market share, as they serve as potential users for their modules on the platform (Koch & Kerschbaum, 2014). Therefore, innovation is also important for the group of users. Through external innovation, platforms are able to offer customers a wide range of functionalities (Eisenmann et al., 2011; Allen, 2012). Furthermore, the demand users place on software platforms changes over time, as such platforms need to adopt changing requirements to remain successful.

2.3.2

Innovation on Software Platforms

Software platforms serve as an environment for external innovation, as they allow external parties to provide features on the platform. Thereby, the aspect of generativity makes digital platforms unique and is of great importance for innovation on software platforms (Tilson et al., 2010). Generativity is understood as “a technology’s overall capacity to produce unprompted change driven by large, varied, and uncoordinated audiences” (Zittrain, 2005). Generativity allows the use of external innovation to the platform’s advantage as design capability is shifted to external parties (Ghazawneh & Henfridsson, 2013). For software platforms, the boundary resources provided by the platform owner allows developers to contribute functionality and thereby add value to the platform. While the aspect of generativity is known as a key source of a platform’s value (Yoo et al., 2010), platform owners are concerned with finding the appropriate degree of control in innovation activities. Similar challenges regarding autonomy exist for

2.3 Innovation in the Platform Context

21

instance in production systems (Gronau, 2019). While a greater level of openness and less control lead to more and more diverse contributions on platforms (Parker & Alstyne, 2008; Boudreau, 2010), they are not without drawbacks. Greater levels of freedom may result in a lack of integration and uniformity. The aspect of integration and a common environment is of great importance for digital platforms, as platform owners are interested in directing related innovation activities on their platforms. While control of platform activities ensures the integrity of the platform and its complements, shifting control to external parties encourages innovation by contributors (Boudreau, 2010; Tiwana et al., 2010; Parker & Alstyne, 2018). Platform boundary resources may help to resolve the paradox of control and generativity in software platforms (Ghazawneh & Henfridsson, 2013). Boundary resources allow third parties to contribute, but simultaneously allow platform owners to direct and control innovation activities in a dynamic way (Eaton et al., 2015). Managing Innovation on Software Platforms Software platforms and related governance mechanisms largely determine the development and assimilation of contributed modules. Thereby, they act as a mechanism to coordinate related activities (Jacobides et al., 2018; Saadatmand et al., 2019). This is why they are an important part of and tool for digital innovation management, which is understood as “the practices, processes, and principles that underlie the effective orchestration of digital innovation” (Nambisan et al., 2017). Managing innovation on digital software platforms aims to realize an effective orchestration of digital innovation. Orchestration thereby refers to the combination of core and third-party functionality to provide functionality for platform users. Orchestration in itself is necessary because a platform is composed of different components. Effective orchestration on software platforms can be separated into two major aspects. First, the design of the platform and related boundary resources allows for an effective orchestration (static aspect). Platform owners are challenged to find the right level of modularity and control to allow for an effective composition of functionality (Ghazawneh & Henfridsson, 2013; Eaton et al., 2015). A prerequisite for the effective orchestration is an efficient development process for contributors. Second, the effective orchestration as part of digital innovation management requires the owner to decide which architectural platform component (core or peripherals) provides which functionality. The aspect of functional separation between platform components poses a challenge for the platform owner (dynamic aspect). Many aspects should be considered to achieve an optimal functional separation. Furthermore, given the inherent dynamic nature of software platforms, the functional separation is subject to change over time. Platform coring as a mechanism is part of managing functional orchestration on software platforms.

22

2

Related Research

Functional Separation on Software Platforms From an architectural perspective, a platform is composed of core components and peripherals. Following Baldwin and Woodard (2009), the architecture allows a distinction between the relatively stable core components that show a relatively low variety and peripheral components with higher variety that serve as complements to the stable core. For software platforms, the core provided by the platform owner comprises basic functionality (e.g. mail client), whereas third parties contribute complements to extend functionality (e.g. social media applications) (Tiwana et al., 2010; Gawer & Cusumano, 2014; Haile & Altmann, 2016). Platform owners, as the entity maintaining the platform resources as well as core functionality, are in charge to decide which functionality is provided by the platform core and subsequently which functions are left to the third-party complementor (Parker & Alstyne, 2018). While functionality could coexist in the core as well as peripherals (Bender & Gronau, 2017), the assumption that in case of direct competition the default (core) function will usually win, poses a challenge for complementors. Moreover, the aspect is to be seen in light of the power imbalance and control possibilities of the platform owner. Different aspects may impact the decision as to which functionality the platform owner provides through the platform core and calls for related management activities (den Hartigh et al., 2016). The availability of development resources must be considered. Platform owners are not able to develop all functionality themselves (Eisenmann et al., 2011). Opening digital platforms allow them to integrate external innovation. Platform owners are therefore likely to focus on important functions to be provided through the platform core (Gawer & Cusumano, 2014). Therefore, strategic importance is likely to be considered for core functionality. Thereby, aspects such as functional relevance for their business model are important. The functional importance for the user is also of great relevance, since functionality is likely to determine the user’s perception of a software platform. The aspect of control is also of importance. Platform owners are interested in controlling activities on their platform (Boudreau, 2010; Eaton, 2016; Parker & Alstyne, 2018). If functionality is provided through third-party complements, the platform, i.e. the owner, is dependent on the third-party developer for provision and advancement of the functionality. While this might be less critical for specialized functionality, platform owners are less likely to accept this dependence on central, mass-market relevant functionality (Olleros, 2008). As such, platform owners are likely to provide important functionality themselves. Another aspect related to control is platform access. During development, platform owners have more direct and greater access to platform resources than third-party developers using the boundary resources (Tiwana, 2015b;

2.4 Platform Coring

23

Karhu et al., 2018). Since some functionality requires extended platform access, these features can only be provided by the platform owner. The aspect of functional separation which is necessary for effective orchestration as part of digital innovation management has not yet been sufficiently explored. Maintaining an optimal functional separation between the core and peripherals is an ongoing management task for platform owners. Software Platforms as Dynamic System Software platforms progress over time (Eaton et al., 2015; de Reuver et al., 2017). Given their modular architecture (core and peripherals), change and progress occurs for both components, which are interdependent. While innovation activities for the individual modules are subject to the group of third-party developers, progress of the platform core is subject to the platform owner. The platform core is regularly updated and both introduces additional platform features and extends established ones (de Reuver et al., 2017). Extended boundary resource features as part of the core can be the foundation for third-party complements (Um et al., 2013; Parker & Alstyne, 2018). While the importance of innovation in terms of introducing new features is undeniable, negative side-effects could occur. Gawer and Cusumano (2014) point out that during platform evolution, platform owners are offered chances to enter complementary markets (Gawer & Henderson, 2007; Gawer & Cusumano, 2014; Parker & Alstyne, 2018). Through the provision of new core features, existing functionality provided by third-party modules can be replaced. While providing new functionality is uncritical, providing core functionality that is already provided by third parties affects developers in the platform ecosystem. Providing functionality in the platform core that was previously provided by third-party extensions is referred to as “platform coring”.

2.4

Platform Coring

Aspects related to the idea of platform coring are found in studies from the economical context (see Section 2.4.1). Lately, studies on complementary market entry in specific involve software platforms. While this research stream covers a marketfocused perspective of aspects related to coring, previous studies do not capture the architectural specifics of software platforms. As a result, the associated dynamics resulting from the interdependence between the ecosystem actors are not appropriately covered. Even though the two research streams are different, findings from the economics perspective may provide guidance for research on platform coring which includes

24

2

Related Research

the perspective of software platforms with their unique architecture and design. Therefore, the following section provides a brief review on effects of complementary market entry in the digital platform context. This section briefly highlights the existing understandings of platform coring. Platform coring is understood differently depending on the individual research focus. Considering the time of platform coring, differences become apparent. While some studies consider platform coring as the emergence of a platform, other studies consider platform coring to occur as part of platform evolution. Gawer and Cusumano (2008) understand coring as the act of creating a new platform. In a similar vein, Saarikko (2016) considers coring as the emergence of a platform. In contrast, Toppenberg et al. (2016) understand coring as part of a platform’s continual innovation strategy and focus on the integration of products into the platform core, thereby addressing the dynamic aspect of innovation management. For this thesis, the notion of platform coring during platform evolution is followed. As such, the dynamic nature of software platforms as evolving systems is addressed. Prior research on platform coring can be differentiated according to the platform type considered. Saarikko (2016) studies platform coring using a case study approach with a service platform. Other studies involve technological platforms (Gawer & Cusumano, 2008; Toppenberg et al., 2016). Software platforms are rarely considered regarding platform coring, which constitutes the focus of this thesis. This thesis focusses on platform coring as part of the continuous digital innovation management (platform evolution) of software platforms. While the existing literature does not capture the characteristics of software platforms in regard to platform coring adequately, the following section presents literature related to the idea of platform coring as it pertains to this thesis and afterwards explains the understanding of platform coring.

2.4.1

Complementary Market Entry and Platform Coring

From a broader perspective, research on platform coring can be situated in the domain of complementary market entry research. However, even though the two research streams are somehow related, major aspects differentiate the two, which may be attributed to their roots. Research on complementary market entry originates in the field of economics, where platforms are considered as markets (Gawer, 2014). In contrast, platform coring stems from the information systems field and regards platforms as complex technological architectures. Platform coring thereby considers the specifics of software platforms (Bender & Gronau, 2017). Even though software platforms constitute a multisided market, they differ in many respects from other

2.4 Platform Coring

25

platform types, such as product platforms (de Reuver et al., 2017). Considering related aspects is important to understand the effects and implications in the software platform context. The difference in focus pertains to the scope of consideration. Whereby complementary market entry focuses on platform markets as a whole, platform coring considers the layered architecture of software platforms. In particular, boundary resources are disregarded in the literature on complementary market entry (Li & Agarwal, 2016; Cennamo, Gu, & Zhu, 2018; Wen & Zhu, 2019). However, boundary resources form an important element in integrating external innovation to the platform’s advantage (Eaton et al., 2015). While boundary resources allow for generativity, they simultaneously allow one to retain control over innovation activities on the platform (Ghazawneh & Henfridsson, 2013). Thus, they form a constitutive element of software platforms and are highly important for their operation and for the integration of external innovation. Moreover, the two fields differ as far as the types of platforms considered. Platform coring focuses specifically on the group of software platforms and accounts for their particularities with regard to their architecture, including boundary resources (Ghazawneh & Henfridsson, 2013), governance mechanisms (Song et al., 2018), and ecosystem (Ceccagnoli et al., 2012). In contrast, research on complementary market entry (CME) involves multiple platform types. For instance, transaction platforms are regularly considered within complementary market entry research (Edelman & Lai, 2016; Lee et al., 2018). Innovation platforms with a technical focus (Gawer & Henderson, 2007), as well as software platforms, are included in newer studies but are not a focus of studies on CME (Foerderer et al., 2018; Wen & Zhu, 2019). Taken together, whereas research on CME focuses on the competitive aspects and related market dynamics, research on CME fails to appropriately address the architectural specifics and technological dynamics of software platforms. However, research aimed at attaining a better understanding of competitive dynamics on software platforms requires a consideration of their unique architecture, which is the focus of platform coring research. Research on Complementary Market Entry This section provides a brief review of the effects of complementary market entry in the digital platform context. Results from the economic perspective may provide guidance for research on platform coring, which includes the perspective of software platforms with their unique architecture and design. Recent research involves studies from both technological (Gawer & Henderson, 2007; Gawer & Cusumano, 2014) and software platforms in particular (Foerderer et al., 2018; Wen & Zhu, 2019). Following the economic perspective

26

2

Related Research

of platforms as markets, aspects such as demand, price and innovation were studied. Mixed findings exist regarding the demand for contributions in the field of complementary market entry. Studies have identified increased demand as a result of complementary market entry (Cennamo, Gu, & Zhu, 2018; Foerderer et al., 2018). Foerderer et al. (2018) suggest that increased demand for respective complements is the result of a spillover effect. Li and Agarwal (2016) find that the effect varies depending on complementors’ size. Whereby positive effects were found for the group of large complementors, negative effects were found for small complementors. Concerning the prices of affected complements, complementors were found to raise the prices for their contributions, allowing them to capture rents (Wen & Zhu, 2019). Diverging results have been found for complementors’ further innovation activities on the platform. Prior studies have found efforts to be either increased, decreased, or shifted to other domains. Complementary market entry results in increased innovation efforts. Related efforts involve the improvement of existing complements (Foerderer et al., 2018), as well as the release of new ones (Cennamo, Gu, & Zhu, 2018). Decreased innovation efforts have been identified for affected complements (Cennamo, Gu, & Zhu, 2018; Wen & Zhu, 2019). This applies to the time of complementary market entry as well as prior entry, when complementors perceive owners’ entry as likely (Wen & Zhu, 2019). Except for increased or reduced efforts, developers are found to shift innovation efforts to unaffected domains, which allows them to soften competition (Wen & Zhu, 2019). Cennamo, Gu, and Zhu (2018) found that the extent of complementary market entry determines complementors’ reactions. Whereas entry may allow for a positive spillover in demand, repeated entry leads developers to shift innovation to other gernes (Cennamo, Gu, & Zhu, 2018). Extensive entry was found to lead to fewer complementors joining the platform to provide innovations (Lan et al., 2019). Especially more lately, studies on CME considered software platforms. Related findings guide recent thining on platforms as markets whereby complementary market entry is an important event for complementors. However, research focusing on software platforms as the complex technological infrastructures as they are is required. This may allow resolving contradictory findings of previous research, understanding the dynamics related to software platforms as open innovation infrastructure, and finally providing strategical guidance from ecosystem participants.

2.5 Research Gap

2.5

27

Research Gap

While the coring-related studies incorporate digital platforms, previous research fails to address the perspective and characteristics of software platforms in particular (see Section 2.4.1). Therefore, this thesis aims to develop a notion of platform coring for software platforms. Following Bender and Gronau (2017), platform coring in the context of software platforms is understood as the “integration of several functionalities provided by third-party applications into the platform core”. Platform coring thereby specifically addresses the introduction of functionality the previously existed in the platform ecosystem. The integration of functionality into the platform core is thereby to be differentiated from the introduction of totally new functionality by the platform owner. Coring specifically addresses the situation in which functionality introduced to the core previously was available in third-party complements. Figure 2.5 depicts the idea of platform coring.

Third-party Developer

Platform

User

A1

Competition

Dev. 1

User 1 A2 Coring

Dev. 2

A3

User 2

Platform Core

A4 Dev. 3

User 3

Boundary Resources A5 Legend Dev. n An

- Developer - Application

Figure 2.5 Platform coring and intra-platform competition

Given the fact that platform coring remains unexplored in the context of software platforms so far, this thesis seeks to provide the fundamentals related to platform coring. First of all, a common understanding of coring that covers the characteristics of platform coring is required. Then, the question of whether platform coring is present on software platforms is of importance to assess the relevance of coring for software platforms. Characteristics of coring activities could be used to differentiate between coring activities. Therefore, the thesis aims to assess:

28

2

Related Research

RQ1: Does platform coring occur on software platforms? While coring of user-related functionality involves negative effects for third parties, especially concerning functional differentiation, previous research has revealed the possibility of advanced platform boundary resources to form the basis of new complements (Um et al., 2013; Parker & Alstyne, 2018). Thus, the role and advancement of platform boundary resources should be explored in more detail. To confirm the role of platform boundary resources, their employment beyond the required minimum should be explored. Moreover, their contribution to enhanced application performance should be evaluated. RQ2: Does the use of platform boundary resources contribute to third-party application success? Platform owners depend on third-party developers to voluntarily contribute to their platform. Third-party contributions constitute a major requirement for success in competitive platform markets (Boudreau, 2010; Parker et al., 2017). Platform owners are therefore highly interested in keeping third-party developers motivated to contribute to their platform (Ryu et al., 2014; Kim et al. 2016). Since contributors are most affected by coring activities of the platform owners, their perspective is of interest to ensure continuous innovation. The question of how third-party developers perceive platform coring is therefore important for platform owners. Moreover, since platform owners are dependent on external innovation, the reaction of third-party developers to platform coring is of great interest. This allows the platform owners to adjust coring activities for the sake of their platform. Therefore, this thesis aims to explore: RQ3: How do third-party developers perceive platform coring? RQ4: How do third-party developers react to platform coring activity? Depending on the coring assessment of third-party developers, their aim might be to protect their applications from coring attempts of the platform owner in order to preserve their complements in the platform context (Huang et al., 2013; Oh et al., 2015). Exploring potential measures to prevent platform coring is thus of importance for complementors. Therefore, the thesis aims to evaluate: RQ5: Which measures can third parties use to prevent platform coring? RQ6: Do third parties actively employ countermeasures to prevent platform coring?

2.5 Research Gap

29

To provide strategical guidance for third-party developer, understanding the effects of platform coring on their applications is necessary. Whereas different aspects of platform coring have been studied (see Section 2.4), the effects on the usage of third-party complements remain largely unexplored. In commercial environments, application usage is of importance to complementors as it is directly related to their revenue. To provide strategical guidance for complementors, the thesis aims to explore: RQ7: Which effect does platform coring has on the usage of affected third-party applications? The idea of this thesis is to explore the most relevant questions with regard to platform coring. As a first step, the fundamentals of coring will be discussed. After an understanding of platform coring on software platforms is developed, the existence of coring will be validated. Afterwards, the phenomenon will be explored in more detail from the perspective of the third-party developer as being influenced the most from coring activities. Platform owners are highly interested in ensuring continuous platform progress.

3

Contributions

Abstract

Digital software platforms such as iOS or Android evolve quickly. Through regular updates, their set of built-in (core) features increases. While innovation allows strengthening platforms amidst competition, it can hurt contributors when introducing core features that are already provided by third-party developers (Platform Coring). This thesis combines multiple articles concerning platform coring. This chapter provides a brief overview of the articles of this thesis. Related articles are combined in an integrated perspective. This chapter provides a brief overview of the four articles that are part of this thesis. In the platform ecosystem context, multiple parties are involved in and affected by platform coring. Figure 3.1 depicts the stakeholder perspective focused in the respective contributions. Study 1

Study 3

Platform Owner Study 2

Study 4

Third-party Developer

User

Figure 3.1 Overview contributions regarding platform ecosystem stakeholders © The Author(s), under exclusive license to Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2021 B. Bender, Platform Coring on Digital Software Platforms, Schriften zur Business Analytics und zum Informationsmanagement, https://doi.org/10.1007/978-3-658-34799-4_3

31

32

3

Contributions

Paper 1 provides an overview of platform coring, whereby all three perspectives are considered. Paper 2 focuses on boundary resources employment and related effects whereby the effects on the user perspective are included. Within paper 3 the initiator of platform coring (platform owner) and the stakeholder being the mostaffected (third-party developer) are focused. Paper 4 focuses on the contributors’ perspective in particular to understand their view on platform coring.

3.1

Summary Paper 1 – Coring Fundamentals

Paper 1: Coring on Digital Platforms – Fundamentals and Examples from the Mobile Device Sector The contribution “Coring on Digital Platforms – Fundamentals and Examples from the Mobile Device Sector” provides an overview of platform coring for digital software platforms (Bender & Gronau, 2017). The paper provides three central contributions. First, a systematization of platform coring activities is provided. Coring activities are differentiated according to the maintenance of the cored application as well as the amount of coring. Application maintenance specifies whether the application that is cored is still available on the platform after the coring activity as a thirdparty application. The amount of coring differentiates between whether the full application functionality is cored or only some functions are (partly) cored. The amount of coring thereby allows an assessment of whether the respective thirdparty application remains a functional differentiation to the corresponding core functionality. Table 3.1 outlines the four coring modes with examples from the Apple mobile device platform iOS.

Table 3.1 Systematization of coring types with examples from iOS Coring Systematization Amount of Coring

Application Maintenance Yes

Full

Similar functionality is provided by the platform and the application is maintained, e.g. Apple Music (vs. Spotify)

Partial

Parts of the functionality are provided by the platform and the application is maintained, e.g. iMessage (vs. WhatsApp)

No Similar functionality is provided by the platform and the application is not maintained, e.g. Shortcuts vs. Workflow Parts of the functionality are provided by the platform and the application is not maintained, e.g. Siri vs. stand-alone Siri App

3.1 Summary Paper 1 – Coring Fundamentals

33

Second, using a case-study approach from the Apple iOS platform for mobile devices, the paper demonstrates the existence of platform coring for the instant messaging domain. The paper compares the functionality of WhatsApp with the internet-based messaging application iMessage, which is part of the platform core (iOS). Thereby, 27 corresponding functions could be identified between the two applications, which were subsequently compared in terms of their release time. The analysis reveals that over three-quarters of the functions are available on WhatsApp first and iMessage afterwards. In that regard, functionality was available first in the third-party application and later released in the platform core, which fulfils the definition of platform coring. Third, the paper presents the aspect of coring from the different viewpoints of the central actors on software platforms to reflect their perspectives. While the platform owner, as the entity conducting coring, can be considered the active part, the third-party developers are more or less passive as no action is necessary for their application functionality to be incorporated into the core. Given the power imbalance between the platform owner and the third-party developers, the abilities of third-party developers are rather limited. Opportunities and risks associated with the coring phenomenon on digital platforms are discussed. While advantages related to coring mainly exist for the platform owner, the disadvantages are experienced by third-party developers. The paper provides an opportunity to shape coring as a beneficial combination for platform owners and third-party developers. Therefore, the paper differentiates between user-related functions and system functions. User-related functions are features that are used by platform users and provide them with direct functional value. As such, they can be accessed by the user directly, which might be provided by either the platform core or third-party applications. System functions are employed during application development by the group of developers to realize applications. As such, they can be considered part of the boundary resources that allow developers to realize their applications. Better and more advanced boundary resources in general allow developers to achieve a higher effectivity and efficiency during application development (Bender, 2020). Thus, a platform could differentiate itself from competing platforms through the provision of boundary resources (Ryu et al., 2014; Kim et al., 2016). The quality and usefulness of boundary resources is known to be an important criterion for third-party developers when choosing between competing platforms (Koch & Kerschbaum, 2014). Therefore, coring of boundary resources is assumed to be perceived as highly positive. In contrast, coring of user-related functionality is assumed to be perceived more negatively, since the functional differentiation of third-party applications diminishes. Once the platform core provides similar functionality, the application is no longer required from a functional standpoint.

34

3

Contributions

Therefore, platform owners are able to provide third-party developers with additional value by realizing the right level of modularity and provision of system functions to allow for generativity and simultaneously allow for their efficient realization on the platform (Ghazawneh & Henfridsson, 2013; Eaton, 2016; Parker & Alstyne, 2018). Platform owners could realize a symbiotic relationship with developers by focusing on system functions for coring primarily and conducting coring for userrelated functions only if it accelerates platform progress.

3.2

Summary Paper 2 – Boundary Resources

Paper 2: The impact of integration on application success and customer satisfaction in mobile device platforms The contribution “The impact of integration on application success and customer satisfaction in mobile device platforms” explores platform integration and related effects on performance measures for mobile device platforms (Bender, 2020). Integration is understood as the use of boundary resources during application development. The degree of integration is defined as the extent to which boundary resources are employed to utilize platform resources during application development. The paper provides three major contributions. First, the paper explores the possibilities of platform integration on mobile device platforms. The paper reviews existing literature and integrates related findings to develop a notion of platform integration on software platforms. As a result, the paper proposes a platform integration model for mobile device platforms with seven different categories. Second, the generic platform integration model is operationalized to account for the specifics of Apple mobile device platform iOS. The model allows platform integration for third-party applications to be measured individually. Third, the model is tested with data from over 82,000 applications from the Apple iOS platform. Regression analysis reveals platform integration to impact application performance. Moreover, platform integration has a positive impact on both application performance and customer satisfaction. Application performance is measured as the category-specific rank of an application, while customer satisfaction is measured as the average rating of the current application version. The contribution provides valuable insights for both platform owners and thirdparty developers. For the group of developers, platform integration is assumed to increase effectivity and efficiency. The use of boundary resources can be used to gain advantages, which is especially important in hypercompetitive settings such as digital platforms (Sangaralingam et al., 2012). Even though integration allows for enhanced performance, it simultaneously creates dependencies. Once developers

3.3 Summary Paper 3 – Perspectives on Coring

35

use boundary resources for their applications, their applications rely on them for proper operation. Moreover, as boundary resources are platform-specific, application multihoming becomes more complex as functionalities might not be available on other platforms (Cennamo, Ozalp, & Kretschmer, 2018). For platform owners, the paper reveals the dual role of platform boundary resources. While providing good boundary resources allows owners to attract thirdparty developers and therefore to differentiate themselves from competing platforms, they can also be used to realize lock-in effects. Integrated applications rely on boundary resources and therefore switching platforms requires additional effort. Previous studies have revealed that developers with more integrated applications are less likely to leave a platform (Tiwana, 2015a). Applications that employ platform resources ease coring endeavors by platform owners. Realizing similar functionality requires less effort, since parts of the application already depend on platform resources. Taken together, integration allows developers to achieve superior performance, but simultaneously creates dependencies that ease coring endeavors for the platform owner.

3.3

Summary Paper 3 – Perspectives on Coring

Paper 3: Platform Coring in the Browser Domain – An Exploratory Study The contribution “Platform Coring in the Browser Domain – An Exploratory Study” focusses on the third-party developer’s perspective on browser platforms (Bender et al., 2019). The study reveals that platform coring occurs on browser platforms as well and is not a specificity of mobile device platforms. Extension developers have experienced and platform core developers have confirmed that coring occurs on browser platforms. Interviews with 13 third-party developers and two platform owners from Mozilla Firefox and Google Chrome were conducted to gather first-hand insights into platform coring from the most concerned stakeholders. The interviews provide insights into the developers’ perceptions of platform coring, their likelihood assessments of individual extensions to be cored, as well as the use of countermeasures. The paper provides three contributions to research. Earlier studies have considered coring on a theoretical level only. This study is the first to investigate the coring aspect for the different stakeholders that are affected by platform coring. The insights reveal platform coring to be a more complex phenomenon than previously assumed. Especially for the group of developers, the complexity of coring perception is uncovered. Previous studies from commercial software platforms have assumed coring

36

3

Contributions

to be perceived negatively by third-party developers due to the potential loss of differentiation, users, and related revenue streams (Bender & Gronau, 2017; Parker & Alstyne, 2018). The browser platforms considered are open-source (Firefox) or built upon open-source components (Chrome based on Chromium). The results reveal that the aspect of coring is perceived differently depending on the motivation to contribute to a browser platform. Developers with primarily intrinsic motivations perceive coring positively, while developers with extrinsic motivations perceive coring negatively. Negative attitudes can be mediated using attribution or compensation mechanisms (see Figure 3.2). Second, the paper discusses the likelihood that extensions will be cored, as well as related implications. Developers assume extensions are more likely to be cored if they are popular, provide generic functionality relevant for many users, and are easy to use. Developers were in accordance that platform owners are capable of coring browser extensions. Third, the paper is the first to discuss potential countermeasures to platform coring on software platforms. Measures to prevent coring are distinguished in strategic and technical countermeasures. Technical countermeasures aim to hinder coring (e.g. source-code encryption) attempts by platform owners. In contrast, strategic measures aim to make coring less attractive for platform owners (e.g. through multihoming). The study is the first to consider the perspectives of both developers and platform owners in one study. During the interviews, core developers stated and third-party developers confirmed that boundary resources make them more effective during development and are an important mechanism to differentiate between competing platforms. Therefore, the type of functionality cored is of importance. This confirms earlier research and highlights the importance of boundary resources and application integration on software platforms (Eaton et al., 2015; Karhu et al., 2018). Moreover, the study confirms the need to differentiate between the types of functionality (userrelated and boundary resources) in the context of coring. The study provides valuable insights into the perception of and reaction to platform coring by third-party developers. Motivation is key for their perception of platform coring. Platform owners confirm conducting coring and acknowledge the importance of boundary resources.

positive

individual need

fun social good

skill development

credit

awareness

common vison showcase

market presence

Figure 3.2 Association between developers’ motivation and coring perception (Bender et al., 2019)

Attitude

Motivation

intrinsic

extrinsic

negative

partnership/ compensation

monetization

job qualification

3.3 Summary Paper 3 – Perspectives on Coring 37

38

3.4

3

Contributions

Summary Paper 4 – Developers’ Attitude towards Coring and use of Countermeasures

Paper 4: Entering Complementary Markets on Software Platforms – The Third-Party Perspective The contribution “Entering Complementary Markets on Software Platforms – The Third-Party Perspective” develops a research model to explain attitude formation, coring likelihood, and the employment of coring countermeasures by developers. The developed model is tested among third-party developers for Mozilla Firefox and Google Chrome. The study extends the qualitative interview approach of Bender et al. (2019) using an quantitative survey approach with 655 responses. The research model inhibits three central model constructs, namely the attitude towards coring, the perceived coring likelihood, and anti-coring measures (see Figure 3.3). Developers’ attitude towards coring is primarily shaped depending on their motivation to contribute to a browser platform. Intrinsic motivation to contribute to a platform includes fun and skill development and contributes to a positive perception of coring. In contrast, extrinsic motivation such as financial aspirations and career development contribute to a negative perception of coring. Coring awareness in terms of understanding the motivations and implications of coring contributes towards a positive perception of platform coring. The model aims to explain the likelihood that an extension will be cored from the developers’ perspective. The perceived likelihood of coring from the developer’s perspective was chosen, since related strategic reactions (e.g. countermeasures) are triggered by their perception rather than the actual likelihood. Earlier coring activities positively impact the perceived coring likelihood. Popular extensions are perceived as more likely to be cored. Application complexity decreases coring likelihood, as such less complex applications are more likely to be cored. The resources required to operate an application are irrelevant for the perceived coring likelihood. The employment of countermeasures by third-party developers depends on both previous constructs, the attitude towards coring as well as the perceived likelihood of coring. Neither of the elements alone is sufficient to explain the employment of countermeasures. However, their combination provides valuable insights. Countermeasures are employed if developers have a negative attitude towards coring and perceive coring as likely for their extension. Moreover, countermeasure employment varies depending on the release strategy and browser environment. Measures are more often taken for multihoming applications and in the Chrome environment. Taken together, developers’ motivation to contribute to a software platform is confirmed as a mediating factor concerning the perception of coring. Perceived

-0.03

-0.141*

0.298***

0.412***

-0.249***

0.085*

-0.243***

Application Category

Perceived Coring Likelihood

R = 24.9%

Attitude towards Coring

R = 13.2%

0.032**

-0.047

R = 35.4%

Regression Model M

Multihoming

* p