Open Source is a term that applies to software for which the source code--the inner workings of the program--is freely available for anyone to download, modify, and redistribute. Software covered under the GNU GPL, described in the previous section, fits into the category of Open Source. Not surprisingly, though, so does a lot of other software that uses copyright licenses similar, but not identical, to the GPL. For example, software that can be freely modified but that does not have the same strict requirements for redistribution as the GPL is also considered Open Source.

The so-called "Open Source development model" is a phenomenon that started with the Free Software Foundation and which was popularized with Linux. It's a totally different way of producing software that opens up every aspect of development, debugging, testing, and study to anyone with enough interest in doing so. Rather than relying upon a single corporation to develop and maintain a piece of software, Open Source allows the code to evolve, openly, in a community of developers and users who are motivated by desire to create good software, rather than simply make a profit.

O'Reilly & Associates, Inc., has published a book, Open Sources, which serves as a good introduction to the Open Source development model. It's a collection of essays about the Open Source process by leading developers (including Linus Torvalds and Richard Stallman) and was edited by Chris DiBona, Sam Ockman, and Mark Stone.

Open Source has received a lot of media attention, and some are calling the phenomenon the "next wave" in software development, which will sweep the old way of doing things under the carpet. It still remains to be seen whether that will happen, but there have been some encouraging events that make this outcome seem not so unlikely. For example, Netscape Corporation has released the code for their web browser as an Open Source project called Mozilla, and companies such as Sun Microsystems, IBM, and Apple have announced plans to release certain products as Open Source in the hopes that they will flourish in a community-driven software development effort.

Open Source has received a lot of media attention, and Linux is at the center at all of it. In order to understand where the Linux development mentality is coming from, however, it might make sense to take a look at how commercial Unix systems have traditionally been built.

In all, the process used by commercial Unix developers to maintain and support their code is very complicated, and quite reasonably so. The company must have quantitative proof that the next revision of the operating system is ready to be shipped--hence the gathering and analyzing of statistics about the operating system's performance. It's a big job to develop a commercial Unix system, often large enough to employ hundreds (if not thousands) of programmers, testers, documenters, and administrative personnel. Of course, no two commercial Unix vendors are alike, but you get the general picture.

Linux is primarily developed as a group effort by volunteers on the Internet from all over the world. There is no single organization responsible for developing the system. For the most part, the Linux community communicates via various mailing lists and web sites. A number of conventions have sprung up around the development effort: for example, programmmers wanting to have their code included in the "official" kernel should mail it to Linus Torvalds. He will test the code and include it in the kernel (as long as it doesn't break things or go against the overall design of the system, he will more than likely include it).

The system itself is designed with a very open-ended, feature-rich approach. While recently the number of new features and critical changes to the system has diminished, the general rule is that a new version of the kernel will be released about every few weeks (sometimes even more frequently than this). Of course, this is a very rough figure; it depends on several factors, including the number of bugs to be fixed, the amount of feedback from users testing prerelease versions of the code, and the amount of sleep that Linus has had that week.

Suffice it to say that not every single bug has been fixed and not every problem ironed out between releases. As long as the system appears to be free of critical or oft-manifesting bugs, it's considered "stable" and new revisions are released. The thrust behind Linux development is not an effort to release perfect, bug-free code; it's to develop a free implementation of Unix. Linux is for the developers, more than anyone else.

Keep in mind these are only conventions--not rules. Some people feel so confident with their software that they don't need to release an alpha or test version. It's always up to the developer to make these decisions.

What happened to regression testing and the rigorous quality process? It's been replaced by the modality of "release early and release often." The users are the best testers, because they try out the software in a variety of environments and a host of demanding real-life applications that can't be easily duplicated by any software Quality Assurance group. One of the best features of this development and release model is that bugs (and security flaws) are often found, reported, and fixed within hours--not days or weeks.

You might be amazed that such a nonstructured system of volunteers programming and debugging a complete Unix system could get anything done at all. As it turns out, it's one of the most efficient and motivated development efforts ever employed. The entire Linux kernel was written from scratch, without employing any code from proprietary sources. A great deal of work was put forth by volunteers to port all the free software under the sun to the Linux system. Libraries were written and ported, filesystems developed, and hardware drivers written for many popular devices.