The Cathedral and the Bazaar

Bart Massey 2010/10/05
Thanks to Dave Vu for notes on previous in-class discussion

Reading: The Cathedral and the Bazaar

What is this paper about?

• Source-sharing as reuse?
• The awesome difficulty of canonicalizing email addresses?
• Forking and handoffs?

In fact, I think Linus's cleverest and most consequential hack was not the construction of the Linux kernel itself, but rather his invention of the Linux development model. When I expressed this opinion in his presence once, he smiled and quietly repeated something he has often said: `I'm basically a very lazy person who likes to get credit for things other people actually do.' Lazy like a fox. Or, as Robert Heinlein famously wrote of one of his characters, too lazy to fail.

Why did Raymond write it?

• Cathedral->new way of building software in a fast order
• What he was trying to get? people interest in open source
• What
  • new way of developing software
  • compare contrast how things were being developed

• Why

  • capture fetchmail experience
  • promote himself

• Throughout the document, Linus was portrayed as father of open source

  • Unix came from proprietary AT&T
  • Berkeley license (open source)
  • Linux is GPLed
  • GNU ignored?
  • agenda? Try to make fetchmail problem bigger for better reward

• Adversarial?

  • vs GNU/FSF/Free
  • eliza, emacs

Leadership in OSS

I made one serious attempt around 1992 to get a lot of the Ohio code formally merged into the official Emacs Lisp library. I ran into political trouble and was largely unsuccessful.

What about Raymond's argument?

• Read Mythical Man-Month

• The stages of open source

  • Hobbyist
  • Free sofware (Richard Stallman) (FSF->free software foundation)
  • Open source ("free beer")

• When is cathedral-style appropriate?

  • Big & complicated: need management structure
  • Small: don't need management structure
  • overhead of duplication or overhead of management (reduce duplication and error, but at a price)?

Things to think about

• Are we trending away from releasing "early and often" in OSS? If so, why?
• There is a lot of discussion about how cool user-driven debugging is. How does this match your experience? What kind of things influence this?
• Reverence for Brooks? Interesting. "Plan to throw one away" is an aphoris m Brooks now regrets (Intro to Mythical Man-Month 25th Anniversary Edition).
• Technical details of mail? Communication style?

Size and Success

One interesting measure of fetchmail's success is the sheer size of the project beta list, fetchmail-friends. At the time of latest revision of this paper (November 2000) it has 287 members and is adding two or three a week.

How does improvement in communication (i.e., the Internet / Web) affect scaling? c.f. the discussion of Brooks' Law.

Security

Another lesson is about security by obscurity. Some fetchmail users asked me to change the software to store passwords encrypted in the rc file, so snoopers wouldn't be able to casually see them.

I didn't do it, because this doesn't actually add protection. Anyone who's acquired permissions to read your rc file will be able to run fetchmail as you anyway—and if it's your password they're after, they'd be able to rip the necessary decoder out of the fetchmail code itself to get it.

All .fetchmailrc password encryption would have done is give a false sense of security to people who don't think very hard.

• But ignore Raymond and encrypt on-disk passwords

Legal

One thing many people think the traditional mode buys you is somebody to hold legally liable and potentially recover compensation from if the project goes wrong. But this is an illusion...

Some more stuff

• "Plausible Promise" in initial i-mode?
• Specification and design? Discovery?
• "Linux was the first project for which a conscious and successful effort to use the entire world as its talent pool was made." No.
• Opening the can of motivation worms. "egoboo". money. curiosity. what?