Software is like sex — it's better when it's free.
--
Linus Torvalds
We concluded Chapter2 by observing the largest-scale pattern in
Unix's history; it flourished when its practices most closely
approximated open source, and stagnated when they did not. We then
asserted in Chapter16 that
open-source development tools tend to be of high quality. We'll begin
this chapter by sketching an explanation of how and why open-source
development works. Most of its behaviors are simply intensifications
of long-established Unix-tradition practices.
We'll then descend from realm of abstraction and describe some
of the most important folk customs that Unix has picked up from the
open-source community — in particular, the community-evolved
guidelines for what a good source-code release looks like. Many of
these customs could be profitably adopted by developers on other modern
operating systems as well.
We'll describe these customs on the assumption that you are
developing open source; most are still good ideas even if you are
writing proprietary software. The open-source assumption is also
historically appropriate, because many of these customs found their
way back into proprietary Unix shops via ubiquitous open-source tools
like
patch(1),
Emacs, and GCC.