In the early days of Unix, components of the operating system, its libraries, and its associated utilities were passed around as source code; this openness was a vital part of the Unix culture. We described in Chapter 2 how, when this tradition was disrupted after 1984, Unix lost its initial momentum. We have also described how, a decade later, the rise of the GNU toolkit and Linux prompted a rediscovery of the value of open-source code.
Today, open-source code is again one of the most powerful tools in any Unix programmer's kit. Accordingly, though the explicit concept of “open source” and the most widely used open-source licenses are decades younger than Unix itself, it's important to understand both to do leading-edge development in today's Unix culture.
Open source relates to code reuse in much the way romantic love relates to sexual reproduction — it's possible to explain the former in terms of the latter, but to do so is to risk overlooking much of what makes the former interesting. Open source does not reduce to merely being a tactic for supporting reuse in software development. It is an emergent phenomenon, a social contract among developers and users that tries to secure several advantages related to transparency. As such, there are several different ways to approaching an understanding of it.
Our historical description earlier in this book chose one angle by focusing on causal and cultural relationships between Unix and open source. We'll discuss the institutions and tactics of open-source development in Chapter 19. In discussing the theory and practice of code reuse, it's useful to think of open source more specifically, as a direct response to the problems we dramatized in the tale of J. Random Newbie.
Software developers want the code they use to be transparent. Furthermore, they don't want to lose their toolkits and their expertise when they change jobs. They get tired of being victims, fed up with being frustrated by blunt tools and intellectual-property fences and having to repeatedly re-invent the wheel.
These are the motives for open source that flow from J. Random Newbie's painful initiatory experience with reuse. Ego needs play a part here, too; they give pervasive emotional force to what would otherwise be a bloodless argument about engineering best practices. Software developers are like every other kind of craftsman and artificer; they want, not so secretly, to be artists. They have the drives and needs of artists, including the desire to have an audience. They not only want to reuse code, they want their code to be reused. There is an imperative here that goes beyond and overrides short-term economic goal-seeking and that cannot be satisfied by closed-source software production.
Open source is a kind of ideological preemptive strike on all these problems. If the root of most of J. Random Newbie's problems with reuse is the opacity of closed-source code, then the institutional assumptions that produce closed-source code must be smashed. If corporate territoriality is a problem, it must be attacked or bypassed until the corporations have caught on to how self-destructive their territorial reflexes are. Open source is what happens when code reuse gets a flag and an army.
Accordingly, since the late 1990s, it no longer makes any sense to try to recommend strategies and tactics for code reuse without talking about open source, open-source practices, open-source licensing, and the open-source community. Even if those issues could be separated elsewhere, they have become inextricably bound together in the Unix world.
In the remainder of this chapter, we'll survey various issues associated with re-using open-source code: evaluation, documentation, and licensing. In Chapter 19 we'll discuss the open-source development model more generally, and examine the conventions you should follow when you are releasing code for others to use.