|< Free Open Study >|| |
Let's get serious. We're all geeks here, right? Let's put all this talk of cars and software and freedom aside for a while, and cut to the chase. This section will discuss how open source software development works, and describes its biggest asset: sheer numbers.
It's all about the software. When you sit down in front of your computer, you just want it to do what you need it to do. Sure, you want your computer to do it in the coolest, most elegant way possible, but in general, you're after functionality. That's really what open source software is all about. Free software is our conscience, but in practice, open source is simply about writing quality software.
Ultimately, software is written by people: computer scientists, programmers, software engineers, or whatever they call themselves. The more people you have contributing to a piece of software, the better off that software is. If you have five full-time developers, and each can fix ten bugs per month, you're still not as well off as if you had 100 occasional developers who each fix one bug per month.
In a series of influential articles, Eric Raymond described the benefits that the open source methodology can provide. In "The Cathedral and the Bazaar", he popularized the phrase, "Given enough eyes, all bugs are shallow." This phrase is a concise summary of the actual mechanics of open source development, and is a good jumping-off point to understanding how open source software actually works.
Open source software development succeeds by getting as many people as possible working on a given piece of software. However, since open source development is fundamentally voluntary, an open source project can only attract a large number of volunteers when it is appealing to a large number of users. So, open source works best in two cases: extremely horizontal applications and formal collaborations between organizations pooling their resources.
The arguments on "The Nature of Software" discussed earlier in this chapter included a disclaimer, in that they only apply to horizontal software applications. A horizontal application is one that fills a need shared by many problem domains. (A vertical application fills only a very narrow, specific need, and some of the arguments given earlier don't apply to vertical applications.) These are some common horizontal application domains:
Operating systems (which everyone needs to do anything at all on a computer)
Programming language compilers (which everyone who wants to develop software needs)
Web servers (which anyone who wants to be on the web needs)
Since many people need the application, an open source version has a wide base from which to attract contributors.
The most successful traditional open source applications are therefore generally in horizontal domains: Linux and the GNU system make up an operating system; the Apache web server runs more web sites than any other web server on the face of the planet; the K Desktop Environment (KDE) is a user interface, which is almost as general as an operating system; the GNU Compiler Collection is a staple of software developers, and there are more. Each of these applications is an example of software that "everyone" who meets a particular profile needs; when "everyone" needs something, a lot of them are willing to contribute to its development.
Once you have a lot of developers contributing to a project, it starts to become more than the sum of its code. Joe may not need a particular feature, and so might not care if Andrea does. However, if Andrea goes ahead and implements that feature, she might have to add some architectural changes that Joe may benefit from later. A concrete example of this is Linux's virtual filesystem (VFS) functionality, which defines a common API across all filesystem types. This feature was added to make it easier to write device drivers for filesystems, but it also allowed developers to implement advanced "false" filesystems, such as for device drivers, USB devices, user login terminals, and process information. These useful features would have been more difficult or even impossible to implement, if the developers had not first added the VFS architecture.
The other major way in which the open source model can be successful occurs when organizations pool their resources. In this case, multiple organizations collaborate on some particular piece of software, sharing the source code and results.
Through collaboration, potentially competing companies produce software that benefits all involved. For example, for a rather long time, the Linux kernel lacked good enterprise features, such as support for multiple processors, large amounts of memory, and journaling filesystems. Once major corporations such as SGI, IBM, and Compaq started collaborating with Linus Torvalds and the other core kernel developers, these features began to improve quickly, and in fact, in some cases there are now competing solutions; there are now at least three options for a journaling filesystem for Linux, for example.
The reason that open source provides a benefit to companies is that in the end, all participants are equal. The license for open source code prevents any one entity from dominating the project; each of the participants has essentially equal right to all the source code (along with any other individual or new organization that wishes to participate or use the software). One company can get miffed and go home, but it can't take its ball with it.
So, open source software is making inroads into companies where the software being developed can be used by all the participants. For example, the primary reason that most of the big hardware companies (such as IBM, Compaq, and HP) are backing Linux is because they make most of their profit on their hardware and service offerings; their operating systems are really just there to sell hardware. It's been speculated that some companies even lose money on developing their operating systems.
To such companies, the cost of developing an operating system is actually a liability, and by pooling their resources, they can collectively produce a better operating system than any could individually, allowing them to focus on their core hardware and service offerings. For example, if five companies each spend $5,000,000 per year on operating system development, then with the open source model they could pool their development funds, and collectively produce a system of equal or better quality, with less cost to each participating company.
Meanwhile, of course, individual private users gain the same benefits from the enhancements. It is this synergy that makes the free software model beneficial to individual users, and the open source model so compelling to businesses.
|< Free Open Study >|| |