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

Key Differences Open source Commercial 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 Major class of errors is eliminated Unspoken, implicit, hidden requirements are not a problem 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 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

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

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 Alternatives have high option value

Open Technical Discussions 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 5 10 15 20 25 30 35 40 45 MRs (X10) KLOCA Apache A B C D E layout js rdf netwerk editor intl xpinstall Commercial 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.

“Post Feature Test” Defect Density

“Post Release” Defect Density 14 28 10 0.1 0.7

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