The enclosed forthcoming ISR commentary is simply the context of this study,
not the working paper for the study to be presented.
Tiwana
1
Influence of Platform Modularity
on Platform Abandonment
An Empirical Study of Firefox Extension Developers
Amrit Tiwana
Presented at The University of Minnesota
September 27, 2010
http://www.pragmatictheory.com/
Page
Agenda
Research Problem
Theoretical Development
Methodology & Results
Contributions & Implications
Tiwana
3
Software-Based Platforms
An extensible ecosystem of inter-operating software applications
iPhone OS,
Firefox
Module
apps,
extensions
Module
Platform Module
Module
Ecosystem
1. Competition increasingly among platform ecosystems
– Compete for developers & users
– Innovation outside firm boundaries
– New functionality never envisioned by platform designers
2. Platform success hinges on attracting & retaining developers
… iPhone vs. Blackberry
… Modules often non-portable, idiosyncratic
Tiwana
Platform abandonment: Post-adoption discontinuance by a module
developer
5
http://www.pragmatictheory.com/
Page
Research Question
Software platform
modularity
?
How?
Why?
Software platform
abandonment?
RQ1.1: How does platform modularity influence systems integration
costs?
1. Technical modularity
2. Organizational modularity (decision rights configuration)
RQ1.2: How do systems integration costs influence platform
abandonment?
•
Changes in any subsystem can trigger integration problems
Ongoing (re)-integration costs
Tiwana
•
6
Two Overarching Ideas Developed
Idea #1
Systems
Integration
Costs
Technical
Modularity
Organizational
Modularity
Platform
Abandonment
Idea #2
Tiwana
7
http://www.pragmatictheory.com/
UoA = Module
Page
Summary of Key Findings
Technical Modularity
Loose-coupling
(-)
Systems
Integration
Costs
Standardization
(+)
Platform
Abandonment
Intention
(-)
(+)
Mediated-moderation
Tiwana
Organizational
Modularity
8
Modular Systems Theory
Design principle for complex systems
Any complex system
Module
Module
Core
Module
“Codebase”
Module
• Interacting subsystems ~ interdependent and independent
• Intentionally increase independence among subsystems
– Allows subsystems to independently evolve yet interoperate
• A relative construct (Baldwin-Clark 2006)
9
• Both technical and organizational property (Langlois 2002)
http://www.pragmatictheory.com/
Tiwana
– Two modules of same platform can differ in their modularity
– UoA = module
Page
Technical & Organizational Modularity
Technical modularity: Degree to which a module is looselycoupled to the platform codebase via standardized interfaces.
1. Loose-coupling…internal changes in a module don’t ripple out
2. Interface standardization… stable, predefined module interfaces
Organizational modularity: Division of module-specific decision
rights between platform owner and module developer.
– where does authority for technical decisions reside
… key element of org structure (Nault 1998)
– shared between module developer & platform owner
•
This encompasses…
features
functionality
design
implementation
–
user interface
Platform owner
(centralized)
Module developer
(modularized)
(shared)
Tiwana
–
–
–
–
10
Systems Integration Costs
IS
“Integration” difficulty
Goodhue et. al 2009
Org theory
“Coordination costs”
Gulati-Singh 1998
Industrial economics
“Systems integration”
Brusoni 2001
Computer science
“Software composability”
Messerschmitt-Szyperski
Product development
“Complementary integration” Nambisan 2002
Two Types of Integration Costs
2 underlying dimensions
M
M
M
Core
M
M
Core
M
M
M
Module-Platform Integration
Cross-Module Integration
Effort required by module developer to manage dependencies between module and
http://www.pragmatictheory.com/
Tiwana
11
• platform codebase (module-platform integration)
• other modules (cross-module integration)
Page
Research Model
Technical Modularity
H1
Loose-coupling
mediation
-
Systems
Integration
Costs
Standardization
H2
Module-Platform
+
Platform
Abandonment
Intention
Cross-module
mediation
H3(+)
Mediated-moderation
H4(-)
Mediated-moderation
Tiwana
Organizational
Modularity
12
Research Methodology
Survey of Mozilla Firefox extension developers
… UoA = module (extension)
… 6,500 modules (extensions)
Why the Firefox platform?
1.
2.
3.
4.
No principal-agent relationship (removes agency confounds)
No money involved (removes pricing confounds (Tirole 2003))
Open source code (removes IP confounds)
Prevents confounding effects from cross-platform differences
342 usable responses (~34%)
… Secondary data on several variables (from source code)
… All 13 categories; no “experimental” add-ons
Stable psychometrics (EFA; α >.8)
Tiwana
… New scales for systems integration cost, abandonment
13
http://www.pragmatictheory.com/
Page
Hypothesis Testing Approach
H3, H4:
Mediated-moderation
Technical Modularity
(Muller 2005 Psyc
Bulletin procedure)
H1, H2: Sobel mediation test
Loose-coupling
Systems
Integration
Costs
Standardization
Platform
Abandonment
Intention
Rival Explanations (13 controls)
Tiwana
Organizational
Modularity
14
Controls for Rival Explanations
1. Module technical characteristics
–Module complexity
-.25***(4.5)
–Cross-module dependencies
-.03(.63)
–Open source/ proprietary dummy§
.04(1.1)
–Extension type (12 dummies; 1 kept)§
.1*(2.03)
–Module evolution rate (ver# / months)§
-.19***(-4.3)
2. Module market characteristics
–Module subsumption risk
.02(.59)
–User base (# downloads)§
.02(.23)
–Perceived extension portability
-.01(-.32)
–User interest (# reviews)§
-.1(-.77)
3. Developer characteristics
–Developer tenure (# years)§
.19***(4.2)
–Developer experience (# extensions)§
-.03(-.82)
4. Process characteristics
-.1*(2.1)
–Platform decision rights centralization
-.02(-.35)
15
http://www.pragmatictheory.com/
Tiwana
–Outcome control
§ = secondary data
Page
Results
H1
Sobel mediation
T-stat = 1.73*
Technical Modularity
-.03(.86)
Loose-coupling
LC*Std
-.7**(-2.5)
-
.13(.88)
Systems
Integration
Costs
.32(1.4)
Standardization
+
H4
H4 (-)
-.69**(-2.6)
.76***(8.4)
.15**(2.4)
Platform
Abandonment
Intention
+
.88***(14.9)
Cross-module
R2 = 26.7%
Module-Platform
(Controls 10.1%)
H3(+)
.49*(2.3)
-.24***(-4.5)
.05(.32)
Sobel mediation
T-stat = 1.87*
-.08(-1.5)
H3
Sobel mediation
T-stat = 1.77*
Organizational
Modularity
H2
Sobel mediation
T-stat = 1.21
Tiwana
16
Bootstrap of 1,000, 2,000, and 5,000 in PLS model
Organizational Modularity…
…weakens loose-coupling’s benefits …strengthens standardization’s benefits
LC decreases SI costs
more when DRs lean
towards platform owners
…than when they lean
towards module developers
Standardization decreases
SI costs more when DRs
lean towards module
developers
...than when they lean
towards platform owners
Organizational Modularity
Tiwana
17
http://www.pragmatictheory.com/
Page
Theoretical Contributions
Software platform
modularity
How?
Why?
Software platform
abandonment?
1. Why: Systems integration costs
2. Fit: Technical modularity benefits contingent on org modularity
3. Unexplored tensions within tech modularity dimensions
Tiwana
18
Future Work
1. How much modularity is just right?
– When do modularization costs overwhelm benefits?
2. Designing IT portfolios for evolvability
– SOA and ongoing re-integration costs
3. Software platforms as “ecosystems” (forthcoming ISR)
– Platform exclusivity, evolutionary dynamics, multi-homing
– iPhone, Android, Ubuntu
Tiwana
20
http://www.pragmatictheory.com/
Page