2. Does Code Architecture Mitigate Free-riding in the Open Source Development Model? Carliss Y. Baldwin and Kim B. Clark Open Source Conference Harvard Business School June 19, 2003

3. Slide 2 © Carliss Y. Baldwin and Kim B. Clark, 2003 Yes How? Read the paper! Executive (Level 1) Summary Does Code Architecture Mitigate Free-riding in the Open Source Development Process?

4. Slide 3 © Carliss Y. Baldwin and Kim B. Clark, 2003 Modular Structure Option Value Two Properties of Code Architecture

5. Slide 4 © Carliss Y. Baldwin and Kim B. Clark, 2003 Modularity  Module = a set of tasks –separable from others; –with additive incremental value –Unit of design substitution –No. of modules = j

6. Slide 5 © Carliss Y. Baldwin and Kim B. Clark, 2003 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.

7. Slide 6 © Carliss Y. Baldwin and Kim B. Clark, 2003 Option Value  Design process is a search under uncertainty  Design substitution is optional  Versions are evidence of option values being realized over time

8. Slide 7 © Carliss Y. Baldwin and Kim B. Clark, 2003 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

9. Slide 8 © Carliss Y. Baldwin and Kim B. Clark, 2003 This paper  Characterizes software as a “non-rival” good  Characterizes Open Source Development in terms of two linked games  Interacts games with code architecture  Looks at Nash equilibria vs. “Robinson Crusoe” option (coding alone)  Defines a voluntary collective development process as sustainable if equilibrium payoff to Workers is greater than Robinson Crusoe payoff

10. Slide 9 © Carliss Y. Baldwin and Kim B. Clark, 2003 Related Literature  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 (motives are rational)  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 form)

11. Slide 10 © Carliss Y. Baldwin and Kim B. Clark, 2003 Level 2 Summary: Open Source Development Process This paper looks at the early stages, only. “Involuntary Beneficence” Decision to join and work or free-ride + “Voluntary Revelation” Decision to publish code, comments, etc. Suggests that those stages of the process can be characterized in terms of two linked games.

12. Slide 11 © Carliss Y. Baldwin and Kim B. Clark, 2003 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 #define clear_block(addr) \ __asm__("cld\n\t" \ "rep\n\t" \ "stosl" \ ::"a" (0),"c" (BLOCK_SIZE/4),"D" ((long) (addr)):"cx","di")

13. Slide 12 © Carliss Y. Baldwin and Kim B. Clark, 2003 First game—“Involuntary Beneficence”  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).  Decision 2: Within collective, –Work; or –Free-ride “Private provision of public goods” game

14. Slide 13 © Carliss Y. Baldwin and Kim B. Clark, 2003 “Involuntary Beneficence”—Intuition  Cooking dinner (lot size = 6 portions) –One stew = Not modular, no option value »The one cook has no incentive to join the collective! –Stew, salad, dessert = Modular »Three cooks have incentive get together –Two different stew recipes = Option value »Two cooks, pick the best recipe after the fact –Three courses, two recipes per course = Modules with option value »Six cooks will voluntarily join and cook  Wine-tasting (lot size = 12 portions)  Collective recipe book (lot size = print run)

15. Slide 14 © Carliss Y. Baldwin and Kim B. Clark, 2003 “Involuntary Beneficence”—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 that coding alone.  Modularity and option value are economic complements: more of one makes more of the other more valuable.

16. Slide 15 © Carliss Y. Baldwin and Kim B. Clark, 2003 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 classical Prisoners’ Dilemma game

17. Slide 16 © Carliss Y. Baldwin and Kim B. Clark, 2003 There are many ways to “fix” a Prisoners’ Dilemma game  Reduce the cost of communicating –Internet, email, newgroups  Increase the rewards –Desire to reciprocate, feelings of altruism –The “Reputation Game”  Create a repeated game –Contingent strategies (eg. Tit-for-Tat) –Can support cooperation in equilibrium

18. Slide 17 © Carliss Y. Baldwin and Kim B. Clark, 2003 Code Architecture and the Prisoners’ Dilemma Game  Modularity –reduces the cost of a unit of contribution –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  Both –give the initial architect more reason to publish an early-stage codebase

19. Slide 18 © Carliss Y. Baldwin and Kim B. Clark, 2003 Level 3 Summary: A Voluntary, Collective Development Process Requires:  For existence: –Developer-users –Non-rivalrous goods –Code architecture with modules and/or options –Communication speeds matched to the coding interval –Methods of SYSTEM INTEGRATION  For efficiency: –Ways to know who’s working on what –Ways to know which module design is better or best (Module-level testing)  For robustness (to solve the Prisoners’ Dilemma game): –Rewards for communication –Iteration with an indeterminate horizon

20. Slide 19 © Carliss Y. Baldwin and Kim B. Clark, 2003 Implications for Firms  Those competing in the same space –Code Architecture matters! »More Modules => Not good »More option value => Not good »Modules and option value = Really bad!  Those supplying complements –???

21. Slide 20 © Carliss Y. Baldwin and Kim B. Clark, 2003 Thank you!