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

About This Presentation
Title:

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

Description:

POP3 server available, need POP3 client ... as co-developers is your least-hassle route to rapid code improvement and effective debugging' ... – PowerPoint PPT presentation

Number of Views:152
Avg rating:3.0/5.0
Slides: 14
Provided by: cesCl
Learn more at: http://cecas.clemson.edu
Category:

less

Transcript and Presenter's Notes

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


1
The Cathedral and the Bazaar A Look at
Open-Source
ECE 417/617Elements of Software Engineering
Stan Birchfield Clemson University
2
Two ways to develop Software
  • Cathedral
  • Well-organized, full-time development team
  • Followed by corporate teams
  • Bazaar
  • Loosely-organized, volunteer hackers

Can it work?
Eric Raymond, The cathedral and the bazaar,
1999
3
Fetchmail story
  • Need access mail from stand-alone computer
    thats not always on-line
  • Cant 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 developers personal itch
  • Necessity is the mother of invention

5
Dont 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-impleme
    nt 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
  • Im 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 theyre 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
    wont usually need your code itll 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 theyre
    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
    youre right
Write a Comment
User Comments (0)
About PowerShow.com