Chapter 19. Open Source

Programming in the New Unix Community

Table of Contents

Unix and Open Source
Best Practices for Working with Open-Source Developers
Good Patching Practice
Good Project- and Archive-Naming Practice
Good Development Practice
Good Distribution-Making Practice
Good Communication Practice
The Logic of Licenses: How to Pick One
Why You Should Use a Standard License
Varieties of Open-Source Licensing
MIT or X Consortium License
BSD Classic License
Artistic License
General Public License
Mozilla Public License

Software is like sex — it's better when it's free.

-- Linus Torvalds

We concluded Chapter 2 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 Chapter 16 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.