1 / 13

The Cathedral and the Bazaar: A Look at Open-Source

The Cathedral and the Bazaar: A Look at Open-Source. ECE 417/617: Elements of Software Engineering. Stan Birchfield Clemson University. Cathedral Well-organized, full-time development team Followed by corporate teams. Bazaar Loosely-organized, volunteer “hackers”.

rendor
Download Presentation

The Cathedral and the Bazaar: A Look at Open-Source

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. The Cathedral and the Bazaar: A Look at Open-Source ECE 417/617:Elements of Software Engineering Stan Birchfield Clemson University

  2. Cathedral Well-organized, full-time development team Followed by corporate teams Bazaar Loosely-organized, volunteer “hackers” Two ways to develop Software Can it work? [Eric Raymond, “The cathedral and the bazaar”, 1999]

  3. Fetchmail story • Need: access mail from stand-alone computer that’s not always on-line • Can’t simply forward • POP3 server available, need POP3 client • Obvious feature missing from existing clients: replying to email from stand-alone computer (need to tack on end of email address)

  4. Initial motivation • “Every good work of software starts by scratching a developer’s personal itch” • “Necessity is the mother of invention”

  5. Don’t reinvent the wheel • “Good programmers know what to write. Great ones know what to rewrite (and reuse).” • 9 existing programs were close • Selected ‘fetchpop’ first • Linus Torvalds started, not from scratch, but with Minix

  6. Never fear refactoring • “Plan to throw one away; you will, anyhow.” – Brooks • ‘popclient’ by Carl Harris was more cleanly written, but lacked some key, difficult-to-implement features • Stay or switch?

  7. Be kind and share • “When you lose interest in a program, your last duty is to hand it off to a competent successor.” • Carl Harris handed ‘popclient’ code to Eric Raymond

  8. Users as developers • “Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging” • Power was underestimated until Linux • “I’m basically a very lazy person who likes to get credit for things other people actually do” – Linus Torvalds

  9. Release early, release often • Cathedral: • Release often  buggy code  alienate users • Bazaar: • Release often  motivate developers  maximize development time

  10. Linus’ Law • Linus’ Law: “Given enough eyeballs, all bugs are shallow.” • “Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.” • “Debugging is parallelizable.” • Cathedral: bugs are tricky, insidious, deep; takes months of scrutiny by dedicated few to develop confidence that they’re all found; inevitable disappointment when bugs appear in final release • Bazaar: bugs appear quickly with thousands of co-developers; less to lose when bugs appear • “Delphi effect” – averaged opinion of a mass of observers (equally expert or ignorant) is more reliable than opinion of random observer [sociologists] • Release early and often minimizes theoretical loss of efficiency due to duplication of effort by debuggers

  11. Importance of data structures • Which is more important, clean code or clean data structures? • “Smart data structures and dumb code works a lot better than the other way around.” • “Show me your [code] and conceal your [data structures], and I shall continue to be mystified. Show me your [data structures], and I won’t usually need your [code]; it’ll be obvious.” – Brooks

  12. Imitating Linux • How did Raymonds imitate Linux? • Releasing early and often • Grew beta list by adding everyone who contacted him • Emailed beta list, encouraging people to participate • Listened to beta testers, polling them about design decisions and encouraging them when they sent patches and feedback • Received bug reports, fixes, thoughtful criticism, feature suggestions, ... • “If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.”

  13. Strive for simplicity • ‘fetchmail’ was more complicated than it needed to be • Late in the project, Raymond threw away a bulk of the code • Result? Simpler manual, simpler setup, simpler configuration • No lost functionality • “Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.” – Antoine de Saint-Exupery • When code is getting better and simpler, you know you’re right

More Related