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, full- time development team Followed by corporate teams Bazaar Loosely-organized, volunteer “hackers” [Eric Raymond, “The cathedral and the bazaar”, 1999] Can it work?

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 from stand- alone computer (need to tack on end of 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 often  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 – ed 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