Transcript 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
Two ways to develop Software
Cathedral
• Well-organized, fulltime development
team
• Followed by
corporate teams
Bazaar
• Loosely-organized,
volunteer “hackers”
Can it work?
[Eric Raymond, “The cathedral and the bazaar”, 1999]
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 standalone computer (need to tack on end of
email address)
Initial motivation
•
•
“Every good work of software starts by
scratching a developer’s personal itch”
“Necessity is the mother of invention”
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
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?
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
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
Release early, release often
• Cathedral:
– Release occasionally  buggy code 
alienate users
• Bazaar:
– Release often  motivate developers 
maximize development time
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
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
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.”
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