html5-img
1 / 12

Why Open Source Works

Why Open Source Works. Jim Herbsleb School of Computer Science Carnegie Mellon University +1 412 268 8933 jdh@cs.cmu.edu. Open source Development work done by users User-developers determine functionality Developers choose work assignments Emergent coordination spacer

holland
Download Presentation

Why Open Source Works

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Open source 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 Key Differences

  3. 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

  4. 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!

  5. 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

  6. 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

  7. 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

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

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

  10. “Post Feature Test” Defect Density

  11. “Post Release” Defect Density 0.1 0.7 0.1 14 28 10

  12. 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

More Related