Why Open Source Works Jim Herbsleb School of

Why Open Source Works Jim Herbsleb School of Computer Science Carnegie Mellon University +1 412 268 8933 jdh@cs. cmu. edu 1

Key Differences § Open source − − − 2 Development work done by users User-developers determine functionality Developers choose work assignments Emergent coordination spacer Potentially redundant effort Open technical discussions § Commercial − − − Developers seldom users Product managers determine functionality Management assigns work Bureaucratic coordination Redundant effort avoided Closed technical discussions

Development Work Done by Users § Much more likely to get the functionality right − § Unspoken, implicit, hidden requirements are not a problem − § 3 Major class of errors is eliminated Extreme form of “participatory design” Prototyping happens naturally

User-Developers Determine Functionality § Marketing and product management functions in commercial software Very familiar with how purchasing decisions made − Often know very little about actual use, users − Often a huge gap between attributes that drive purchases and attributes that drive usefulness and usability − § § 4 Decisions in open source based on user concerns, not purchaser concerns Caveat -- non-developer users don’t count!

Developers Choose Work Assignments § Presumably many factors involved: What is interesting and challenging − What functionality does that user/developer need − What is most likely to be included in the product − What will enhance reputation and standing − § Developer choices range across projects Larger pools of potential work assignments and developers permits better match − Requires efficient brokering − 5

Emergent Coordination § Minimal management structure − § § Core group with commit privileges Management by those with demonstrated technical merit Participation mirrors dependencies Very few developing new functionality − Many more fixing bugs − Very large numbers reporting bugs − 6

Potentially Redundant Effort § § § Generates alternative solutions Alternatives generated exactly where people are able to identify interesting technical alternatives Sample many places on the risk/reward continuum − 7 Alternatives have high option value

Open Technical Discussions § § § 8 Draws on very large pool of potential experts Newbies can catch up with minimal distractions to existing staff Preserves design rationale

Productivity Core Developers Only 45 40 35 30 25 20 15 10 5 0 MRs (X 10) Commercial ne rdf tw er k ed ito r xp intl in st al l js t yo u la E D C B A Ap ac he KLOCA Mozilla Mockus, A. , Fielding, R. , & Herbsleb, J. D. Two Case Studies of Open Source Software Development: Apache and Mozilla (2002). ACM Transactions on Software Engineering and Methodology, 11, 3, pp. 309 -346. 9

“Post Feature Test” Defect Density 10

“Post Release” Defect Density 14 28 10 11 0. 7 0. 1

Open Source Open Questions § Resource allocation process − − § § Effects of patronage, hybrid models Security − − § − 12 Race from discovery to exploit to deployment Race from discovery to patch to distribution and installation Limitations of open source − § Modeling, understanding Brokerage tools Only maintenance and evolution? How about highly collaborative stages like high-level design, architecture? Collaboration technology