The Institutions of Innovation Carliss Y. Baldwin ITM Seminar April 16, 2004 Slide 1 © Carliss Y. Baldwin and Kim B. Clark, 2004 The Institutions of Innovation The Great Chain of Design and Production Architecture + Design Procurement + Production Product Use Users' Willingness to Pay Competition + Market Structure Price * Quantity – Cost – Investment "Free Cash Flow" Discount for Time and Risk Value $$$ Rational Investment in New Products and Design Architectures Slide 2 © Carliss Y. Baldwin and Kim B. Clark, 2004 The Institutions of Innovation Neoclassical Economics Architecture + Design Procurement + Production Product Use Users' Willingness to Pay Competition + Market Structure Price * Quantity – Cost – Investment "Free Cash Flow" Discount for Time and Risk Value $$$ Rational Investment in New Products and Design Architectures Slide 3 © Carliss Y. Baldwin and Kim B. Clark, 2004 The Institutions of Innovation Neoclassical Financial Economics Architecture + Design Procurement + Production Product Use Users' Willingness to Pay Competition + Market Structure Price * Quantity – Cost – Investment "Free Cash Flow" Discount for Time and Risk Value $$$ Rational Valuation of an Existing Enterprise Slide 4 © Carliss Y. Baldwin and Kim B. Clark, 2004 The Institutions of Innovation Management Studies Architecture + Design Procurement + Production "Marketing" Product "Operations" Use Users' Willingness to Pay Competition + Market Structure Price * Quantity – Cost – Investment "Strategy" + I-O Economics "Free Cash Flow" Rational Investment in New Products and Design Architectures Slide 5 Discount for Time and Risk Value $$$ "Finance" © Carliss Y. Baldwin and Kim B. Clark, 2004 The Institutions of Innovation New Product Development Architecture + Design Procurement + Production Product Use Finally, Designs + Architecture matter to someone! Users' Willingness to Pay Competition + Market Structure Price * Quantity – Cost – Investment "Free Cash Flow" Discount for Time and Risk Value $$$ "Semi-Rational" Investment in New Products and Design Architectures (can select for effective and efficient practices) Slide 6 © Carliss Y. Baldwin and Kim B. Clark, 2004 The Institutions of Innovation Design Rules, Volume 1 Architecture + Design Procurement + Production Product Economic Institutions Use Users' Willingness to Pay "We can't model this part yet" "Stay Tuned for DR2!" Competition + Market Structure Price * Quantity – Cost – Investment "Free Cash Flow" Discount for Time and Risk Value $$$ More Rational Investment in New Products and Design Architectures "Power of Modularity" Results Designs are options Modular architectures multiply options Modules and Experiments are complementary Modular designs evolve in a semi-structured way via modular operators. Slide 7 © Carliss Y. Baldwin and Kim B. Clark, 2004 The Institutions of Innovation Unfortunately, Economic Institutions have first-order effects on Value! Architecture + Design Procurement + Production Product Use Users' Willingness to Pay Competition + Market Structure Can't Retire Yet! Price * Quantity – Cost – Investment "Free Cash Flow" Discount for Time and Risk Value $$$ Rational Investment in New Products and Design Architectures "Power of Modularity" Results Designs are options Modular architectures multiply options Modules and Experiments are complementary Modular designs evolve in a semi-structured way via modular operators. Slide 8 Institutions of Innovation Architecture = a Production Function for Designs Institutions are equilibria of sets of linked games What institutions do the designs "need" to evolve? What does competition do to payoffs? Can competitive effects be predicted ex ante? Cui bono? Who benefits? © Carliss Y. Baldwin and Kim B. Clark, 2004 The Institutions of Innovation Open Source Development is one of the "Institutions" Architecture + Design Procurement + Production Product Use Users' Willingness to Pay Competition + Market Structure Price * Quantity – Cost – Investment "Free Cash Flow" Discount for Time and Risk Value $$$ Rational Investment in a New Open Source Architecture "Power of Modularity" Results Designs are options Modular architectures multiply options Modules and Experiments are complementary Modular designs evolve in a semi-structured way via modular operators. Slide 9 Institutions of Innovation Architecture = a Production Function for Designs Institutions are equilibria of sets of linked games What institutions do the designs "need" to evolve? What does competition do to payoffs? Can competitive effects be predicted ex ante? Cui bono? Who benefits? © Carliss Y. Baldwin and Kim B. Clark, 2004 What this paper does Characterizes software as a “non-rival” good Characterizes Open Source Development in terms of two linked games with three stages (join, work, reveal) Interacts games with code architecture Looks at Nash equilibria vs. “Robinson Crusoe” alternative (coding alone) Defines a voluntary collective development process as sustainable if the equilibrium payoff to Workers is greater than Robinson Crusoe payoff Slide 10 © Carliss Y. Baldwin and Kim B. Clark, 2004 Open Source is— New System of Property Rights Complementary Institutional Structure(s) GNU GPL Many Software Development Processes— Social Movement Free Software One Method? A Bunch of Organizations + Governance Structures Slide 11 © Carliss Y. Baldwin and Kim B. Clark, 2004 Related Literature—Vast Eric Raymond – – – – Software is a non-rival good; cost of revelation “Scratching an itch” “Reputation game” “Enough eyeballs” Rishab Ghosh (“cooking pot”, generalized exchange) Lerner and Tirole (simple economics, reputation=>Wealth) Justin Pappas Johnson (“public provision of private goods”) Harhoff, Henkel and von Hippel (“free revelation”) James Bessen (users benefit from a customizable codebase) Von Hippel and von Krogh, O’Mahony, Benkler (this is a new institutional/organizational form) Slide 12 © Carliss Y. Baldwin and Kim B. Clark, 2004 We position our work in a different economics literature We start with a (specific) production process and a related (non-arbitrary) production function Go on to derive/deduce the institutional structures that can support the production process, hence “deliver the value” of the production function – “New Institutional Economics” » “Institutional Structure of Production” or ISP Aoki-Hurwicz-Greif institutions – An institution is an equilibrium of a set of linked games, plus summary beliefs that are self-confirming as the play unfolds. Slide 13 © Carliss Y. Baldwin and Kim B. Clark, 2004 A production function for design processes We assert— The production function of any design process can be written as: V = I(t){V(Min) + S max Vj(kj ; sj )} – Costs j Thresholds A Minimal System kj Costs Modules/Options The specifics of this function are determined by the architecture of the design = architecture of the system Vs are often recursive—> modules within modules Process/function can be extensive, but IS MAPPABLE Slide 14 © Carliss Y. Baldwin and Kim B. Clark, 2004 If this function is descriptively true, we should be able to derive the institutions needed to sustain design processes as equilibria of linked games (plus summary beliefs) about instances of this function An Instance = An Architecture Slide 15 © Carliss Y. Baldwin and Kim B. Clark, 2004 Software Development Processes Are Design Processes New System of Property Rights GNU GPL Social Movement Design Processes Many Software Development Processes — Free Software One Method? A Bunch of Organizations + Governance Structures Slide 16 © Carliss Y. Baldwin and Kim B. Clark, 2004 Open Source is a set of complementary institutional structures that sustain lots of design processes— => A “test” of our production function thesis =>Prediction: Open Source institutional structures should arise as equilibria of some specifications of our function, ie, for some architectures of codebases. Slide 17 © Carliss Y. Baldwin and Kim B. Clark, 2004 Two Properties of Code Architecture Modular Structure Option Value Slide 18 © Carliss Y. Baldwin and Kim B. Clark, 2004 Modularity Module – – – – = a set of tasks separable from others; with additive incremental value Unit of design substitution No. of modules = j Global Design Rules Module A Slide 19 Module B Module C Module D © Carliss Y. Baldwin and Kim B. Clark, 2004 Modularity Applies to groups of tasks. Modular in design ≠ Modular at runtime – Linux is modular in design but monolithic at runtime. » So is Unix – Minix is modular at runtime, but (arguably) monolithic in design. Slide 20 © Carliss Y. Baldwin and Kim B. Clark, 2004 Option Value Design process is a search under uncertainty Design substitution is optional Versions are evidence of option values being realized over time Global Design Rules v.1 Version 1.0 Version 1.2 Version 1.5 Version 1.8 Slide 21 © Carliss Y. Baldwin and Kim B. Clark, 2004 Modularity and Option Values are “architectural properties” because (1) They are observable in early and incomplete code releases; and (2) They affect the way the codebase evolves, ie., gets built out Slide 22 © Carliss Y. Baldwin and Kim B. Clark, 2004 How Modularity and Option Value Work — Intuition/Analogy Cooking dinner (Rival good: lot size = 12 portions) – One big stew = Not modular, no option value » A cook has no incentive to join with other cooks – Meat, salad, dessert = Modular, j=3 » Three cooks have incentives to get together – Two different stew recipes = Option value, s > 0 » Two cooks, pick the best recipe after the fact – Three courses, two recipes per course = Modules with option value » Six cooks will voluntarily join up, cook, and feed each other » May feed an additional 6-18 people (free riders) Collective Church recipe book (Non-rival good) – Contributions = #courses x #recipes per course Slide 23 © Carliss Y. Baldwin and Kim B. Clark, 2004 Open Source Development Process 1 Design 2 Contribute 3 Code 4 Post 5 Integrate 6 Test 7 Report Bugs 8 Patch This paper looks at the early stages, only. Suggests that those stages of the process can be characterized in terms of two linked games. “Involuntary Altruism” Decision to join and work or free-ride Slide 24 + “Voluntary Revelation” Decision to publish code, comments, etc. © Carliss Y. Baldwin and Kim B. Clark, 2004 The Two Linked Games Work (write code, patch, etc.) Reveal (publish code, comments, etc.) /* bitmap.c contains the code that handles the inode and block bitmaps */ #include <string.h> #include <linux/sched.h> #include <linux/kernel.h> #define clear_block(addr) \ __asm__("cld\n\t" \ "rep\n\t" \ "stosl" \ ::"a" (0),"c" (BLOCK_SIZE/4),"D" ((long) (addr)):"cx","di") Slide 25 © Carliss Y. Baldwin and Kim B. Clark, 2004 First game—“Involuntary Altruism” Decision 1: – Join a collective development process; or – Code in isolation If a developer joins and works, his/her work product will automatically benefit other joiners (who may be free-riding). Standard, convenient assumption. Decision 2: Within collective, – Work; or – Free-ride “Private provision of public goods” game Slide 26 © Carliss Y. Baldwin and Kim B. Clark, 2004 First Game—Formal Setup Non-rival good—agents’ outside alternative is to code alone, involuntary revelation=>free-riding Two-stage (join/work), one round. Work interval equals the time needed to code one module; All work synchronous. – Or endogenous sequences to exhaust modules/option value Subgame perfect Nash equilibrium – Sequential or simultaneous entry – Pure, mixed and evolutionarily stable strategies Code Architecture visible to agents – – – – Some number of symmetric modules, j ≥ 1 Value per module = v/j; Cost per module = c/j Some option value per module (s ≥ 0) “Perfect” and “imperfect” information Slide 27 Number of workers is the outcome of equilibrium © Carliss Y. Baldwin and Kim B. Clark, 2004 First Game—Results If codebase is NOT modular and has NO option value, a working developer does just as well coding in isolation as joining the collective. If codebase is modular OR has option value, working developers do better in the collective than coding alone. Modularity and option value are economic complements: more of one makes more of the other more valuable (Baldwin and Clark, Design Rules, 2000) Slide 28 © Carliss Y. Baldwin and Kim B. Clark, 2004 The Equilibrium Number of Working Developers in a Game of Involuntary Beneficence as a Function of Cost-to-Value Ratio, c/v, and Number of Modules, j (Imperfect Information, Redundant Effort) No. of Modules 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Slide 29 Cost/Value per Module 10% 1 4 6 9 11 13 15 18 20 22 25 27 29 32 34 36 38 41 43 45 20% 1 3 4 6 8 9 11 13 14 16 17 19 21 22 24 25 27 29 30 32 30% 1 2 3 5 6 7 8 10 11 12 13 14 16 17 18 19 20 22 23 24 40% 1 2 3 4 5 6 6 7 8 9 10 11 12 13 14 15 16 17 17 18 50% 1 1 2 3 4 4 5 6 6 7 8 8 9 10 11 11 12 13 13 14 60% 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 10 10 70% 1 1 1 2 2 2 3 3 4 4 4 5 5 5 6 6 6 7 7 7 80% 1 1 1 1 1 2 2 2 2 3 3 3 3 4 4 4 4 4 5 5 90% 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 3 100% 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 © Carliss Y. Baldwin and Kim B. Clark, 2004 The Number of Developers Working in Equilibrium, nj*, as a Function of the Cost-to-Technical-Potential Ratio, c/s, and the Number of Modules, j (Perfect Information, Option-driven Effort) No. of Modules Cost/Technical Potential 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Slide 30 25% 2 6 12 16 25 30 42 48 54 70 77 84 104 112 120 128 153 162 171 180 189 220 230 240 250 50% 0 2 3 8 10 18 21 24 27 30 44 48 52 56 60 64 85 90 95 100 105 110 115 120 150 75% 0 0 0 4 5 6 7 16 18 20 22 24 26 42 45 48 51 54 57 60 63 66 92 96 100 100% 0 0 0 0 0 0 7 8 9 10 11 12 26 28 30 32 34 36 38 40 42 44 46 72 75 150% 0 0 0 0 0 0 0 0 0 0 0 0 0 0 15 16 17 18 19 20 21 22 23 24 25 Note: E(v) =.399s Ten developers on each module © Carliss Y. Baldwin and Kim B. Clark, 2004 Second Game—“Voluntary Revelation” In real life, developers do not have to reveal their code to one another Suppose two developers each have coded a module (sunk cost) Can send it to the other, but communication is costly One bears a cost to benefit the other This is a canonical Prisoners’ Dilemma game Slide 31 © Carliss Y. Baldwin and Kim B. Clark, 2004 There are many ways to encourage cooperation in a Prisoners’ Dilemma game (Axelrod) Reduce the cost of communicating – Internet, email, newgroups Increase the rewards – Desire to reciprocate (Ernst Fehr) – Feelings of altruism (Benkler) – The “Reputation Game” (Lerner-Tirole) Create a repeated game – Contingent strategies (eg. Tit-for-Tat) – Can support cooperation in equilibrium Slide 32 © Carliss Y. Baldwin and Kim B. Clark, 2004 Code Architecture interacts with the Prisoners’ Dilemma Game Modularity – – – – reduces the cost of a unit of contribution creates opportunity for reciprocation creates many different “chunks of reputation” creates larger “space” of repeatable games Option value – provides improvable modules, thus creates “contests with winners” (reputation) – makes the arrival of the end-game a surprise Slide 33 © Carliss Y. Baldwin and Kim B. Clark, 2004 The effect of linking the two games Reputation/repetition only has to overcome the cost of communicating (r/j) “Work” motivated by the value of own code: – v/j > c/j for the developer “Joining” motivated by access to others’ code (non-rival good) Potentially very large continuation value: V – c/j – r/j + Rj for each developer Slide 34 © Carliss Y. Baldwin and Kim B. Clark, 2004 Conclusions: A Voluntary, Collective Design Process Requires— For existence: – – – – – Designer-users Non-rivalrous goods A design architecture with modules and/or options Communication speeds matching the design interval for one module Methods of SYSTEM INTEGRATION AND TESTING (omitted here—see DR1 and Bessen) For efficiency: – Ways to know who’s working on what – Ways to know which module design is better or best (Module-level testing—see DR1, contrast to Bessen) For robustness (to solve the Prisoners’ Dilemma game): – Rewards for communication – Iteration with an indeterminate horizon (not strict repetition) Slide 35 © Carliss Y. Baldwin and Kim B. Clark, 2004 A theoretical horse race: Microsoft vs. Linux Assume: one firm, one collective, j modules Equal quality output Developer-users will purchase proprietary system instead of coding modules for a collective system if the price of proprietary system < their cost of coding Cost per developer of collective system with j modules = c/j (for Workers, 0 for free-riders) So Max proprietary system price = c/j So Max revenue = Nc/j (N is number of customers) Cost of creating proprietary system comparable to collective system = c if no option value; = kj*c if option value (we show this…) Slide 36 © Carliss Y. Baldwin and Kim B. Clark, 2004 Horse race Under these assumptions, we show: NPV of the proprietary codebase = Nc/j – c = Nc/j – kj*c If N ≤ kj*j kj* and j are consequences of code architecture; kj* is increasing, concave in j Slide 37 if codebase is modular if codebase is modular and has option value; and no commercial opportunity exists (though sunk cost assets may survive) © Carliss Y. Baldwin and Kim B. Clark, 2004 Thank you! Slide 38 © Carliss Y. Baldwin and Kim B. Clark, 2004