The Cathedral and the Bazaar (abbreviated CatB)
Musings on Linux and Open Source by an Accidental Revolutionary is an essay, and later a book, by Eric S. Raymond
- Every good work of software starts by scratching a
developer's personal itch.
- Too often software developers spend their days grinding away for pay at programs they neither need nor love
- To solve an interesting problem, start by finding a problem that is interesting to you.
- Good programmers know what to write. Great ones know what to rewrite (and reuse).
- An important trait of the great ones is constructive laziness. They know that you get an A not for effort but for results, and that it’s almost always easier to start from a good partial solution than from nothing at all
- Linus Torvalds, for example, didn’t actually try to write Linux from scratch.
- Plan to throw one away; you will, anyhow.
- You often don’t really understand the problem until after the first time you implement a solution.
- If you have the right attitude, interesting problems will find you.
- When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
- Treating your
users as co-developers is your least-hassle
route to rapid code improvement and effective debugging.
- Given a bit of encouragement, your users will diagnose problems, suggest fixes, and help improve the code far more quickly than you could unaided.
- Author thinks Linus’ cleverest and most consequential hack was not the construction of the Linux kernel itself, but rather his invention of the Linux development model.
- If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.
- Release early. Release often. And listen to your customers.
- Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
- Given enough eyeballs, all bugs are shallow.
- coined as Linus’ law
- Debugging is parallelizable
- Adding more beta-testers may not reduce the complexity of the current “deepest” bug from the developer’s point of view, but it increases the probability that someone’s toolkit will be matched to the problem in such a way that the bug is shallow to that person.
- Linus seems to the author to be a genius of engineering (rather than an innovative genius of design in the way that, say, Richard Stallman or James Gosling (of NeWS and Java) are), with a sixth sense for avoiding bugs and development dead-ends and a true knack for finding the minimum-effort path from point A to point B.
- Delphi effect can tame development complexity even at the complexity level of an OS kernel
- In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you’ve winkled them all out. Thus the long release intervals, and the inevitable disappointment when long-awaited releases are not perfect. In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena - or, at least, that they turn shallow pretty quick when exposed to a thousand eager co-developers pounding on every single new release. Accordingly you release often in order to get more corrections, and as a beneficial side effect you have less to lose if an occasional botch gets out the door.
- Given enough eyeballs, all bugs are shallow.
- Smart data structures and dumb code works a lot better than the other way around.
- It’s no fun to be responsible for fixing bugs in a program you don’t understand.
- 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.
- The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
- If you are completely and self-deprecatingly truthful about how much you owe other people, the world at large will treat you like you did every bit of the invention yourself
- Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
- When you hit a wall in development it’s often time to ask not whether you’ve got the right answer, but whether you’re asking the right question.
- Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.
- Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
- When writing gateway software of any kind, take pains to disturb the data stream as little as possible - and *never* throw away information unless the recipient forces you to!
- When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
- A security system is only as secure as its secret. Beware of pseudo-secrets.
- Security by obscurity is no security
- Provided the development coordinator has a medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.
Preconditions for bazaar style
- When you start community-building, what you need to be able to present is a plausible promise. Your program doesn’t have to work particularly well. It can be crude, buggy, incomplete, and poorly documented. What it must not fail to do is convince potential co-developers that it can be evolved into something really neat in the foreseeable future.
- it is absolutely critical that the coordinator be able to recognize good design ideas from others.
- The problem with being clever and original in software design is that it gets to be a habit - you start reflexively making things cute and complicated when you should be keeping them robust and simple.
- A bazaar project coordinator or leader must have good people and communications skills. While coding remains an essentially solitary activity, the really great hacks come from harnessing the attention and brainpower of entire communities.