The Lure of Open Source Software: Why Consider It for Your Business?
Date: Oct 14, 2005
For more information on Linux and open source software, visit our Linux Reference Guide or sign up for our Linux Newsletter
What Is Open Source?
The open source movement began as an offshoot of the free software movement, aimed at making free software more appealing to commercial interests. The problem is that the English language overloads the term free with two very different meanings, referring to freedom and to cost. Members of the free software movement commonly distinguish between these two meanings by referring to free software as "free as in speech," and not "free as in beer."
The general perception of free and open source software (FOSS) comes from a few high-profile projects, such as Linux. They are perceived as being written by hobbyists working for free, and to cost nothing. But neither of these perceptions is either required or implied by either the free software or open source definition.
For software to be classed as free software, the user must be able to do all of the following:
- Run the software. This right is obviously a necessity for any software to be useful.
- Modify the software. Less obvious, but equally essential. Much commercial software grants this right to a limited extent; for example, Microsoft Office can be extended by using VBA. The difference with FOSS is that the customer, not the supplier, determines the permitted extent of the modifications.
- Redistribute the software and modifications to the software. Important from a cost perspective. If you can't distribute your modifications, other people can't benefit from them. More importantly, you can't benefit from their modifications. If two customers need the same feature, they have two choices: both can add the feature (duplicating effort), or both can wait for the supplier to add the feature, and then both can pay to upgrade.
Open source software grants similar although less concisely defined rights. (The difference is the motivation for the software, rather than the rights themselves. In general, the terms open source software and free software can be used interchangeably.)
Note that these rights apply only to the customer, not to the world at large. If a company commissions custom software and has all of these rights assigned to that software, it's qualified as FOSS, even though the software may not be distributed.
The Motivation for Open Source
If "there's no such thing as a free lunch," why is there free software? Anyone who has lived in shared accommodation as a student will understand the FOSS principle—if one person cooks more than he can eat, he can either give the excess food to someone else or throw it away. If he gives the leftovers to a housemate, he hopes that the housemate will eventually reciprocate; in this situation, both individuals get a "free lunch" because the cost of the second serving is negligible each time.
Most FOSS is written by developers "scratching an itch"—solving a problem that they personally encounter. For example, Andy Tanenbaum found the UNIX source code license too restrictive, so he wrote MINIX, a simple POSIX-compliant operating system that he could use for teaching students. To keep the system simple and elegant enough for undergraduates to understand, he didn't allow complex features to be added. Linus Torvalds found this restriction too confining; he hacked together the simpler Linux kernel, allowing anyone to submit features, which allowed Linux to grow in ability faster.
Linus' motivation was not to create something for the community; it was to create a system he could use. By distributing his code as free software, he received other people's code in return. The Linux kernel now is far more complex than it would have been if Linus had been developing it himself.
Of course, a kernel is not much use by itself, and Linus was fortunate in that the Free Software Foundation had already been developing a free UNIX-like userland for seven years when he released his kernel. Once both pieces—kernel and userland—were available, anyone could build and use a free system.
Not all projects are started by a single individual. Sun Microsystems is a good example of a FOSS sponsor. Sun makes money selling hardware and support. In the past, they developed Solaris completely in-house—an entire commercial UNIX system and a software stack built on top of it. A few years ago, Sun realized that they needed an office suite running on top of their operating system for it to be attractive to the corporate market. Rather than write one, they bought the German company Star Division, whose StarOffice suite already ran on Solaris. They then took the somewhat unorthodox step of releasing as much of StarOffice as they were able as FOSS.
Sun still employs the lead developers on OpenOffice.org, the FOSS version of StarOffice. They also benefit from patches from the community. In return, the community benefits from a usable office suite. Ports of OpenOffice.org to FreeBSD and Mac OS X have been accomplished entirely by community efforts. If a company needs specific functionality added to OpenOffice.org, they're most likely to pay Sun to add that functionality, generating a new potential income source for Sun.
Who Gets Paid?
One criticism often leveled at the free software community is that the programmers—those responsible for creating the product—are not the ones being paid. In some cases, this may be true. Some open source developers work for motivations other than money; for example, they want to use the code that they're writing and feel that they gain more by allowing other people to modify their code than they would by trying to sell it. Linux started like this—Linus could possibly have developed Linux by himself and sold it. If he had done so, Linux would have been much simpler (because only one person was working on it) and would not have been worth very much. After the code was opened, large numbers of people started contributing; the result is that Linus gets to run a kernel that's far more complex than one he could have written by himself.
Companies such as Red Hat are sometimes cited as "parasites" on the open source movement—they take Linux and sell support for it. They didn't create Linux, and so it may seem unfair that they should be getting money from it.
The first obvious response to this complaint is to point to all of the companies that sell third-party support for proprietary software. They don't even have the source code, much less the right to modify it, so all they can do is help people use it. (Apparently this doesn't count as parasitism.)
The next important thing to note is who is employed by Red Hat. They maintain their own branch of the kernel for their enterprise version of Linux, employing a number of kernel hackers to work on it—including Alan Cox, who has written significant chunks of the kernel.
Another example is Digium, the company that produces the Asterisk PBX, which is highly regarded as a VoIP solution. The Asterisk code is released as FOSS, and Digium exists to sell support and custom installations of the software. They seem to have a profitable business model developing FOSS. Since they authored the software, they're the logical choice as a consultant for any company that wants to deploy their product. And because the code is free, anyone can download it and evaluate it for free, increasing Digium's potential customer base.
Security, Bugs, and Features
The motivations of developers of open software and proprietary software are quite different. In general, a developer of open software is writing software to use, while a developer of closed software is writing software to sell. This difference doesn't disappear when a FOSS developer is employed by a company; in this case, the developer is writing software that the employer will use or will bundle as part of a solution.
In either case, the company is interested in making reliable software that fits their customers' needs as closely as possible. But once developers of off-the-shelf commercial software have sold a program to a customer, they have no easy way of gaining additional revenue from that customer. Fixing bugs in the software won't gain them more income; if you charge for a bug fix, customers start wondering how much you'll charge for the next fix, and you may also fall foul of consumer protection laws.
As a concrete example, consider Apple Computer's application for displaying PDF files, called Preview. In OS X 10.3 and earlier, this application determined the size of the window before determining whether it needed scroll bars. The result was that if you opened a multi-page PDF, it would always display a horizontal scroll bar, even if you had enough screen space to display the entire width of the document. In July, 2004, I filed a bug reporting this behavior. This is a trivial error, and could be fixed with about five minutes of programming time. If Preview were FOSS, I could have fixed it easily myself. The bug has now been marked as closed, because it doesn't appear in OS X 10.4—but if you want it fixed you have to pay $129 to upgrade to the latest version of the OS.
This example is fairly trivial. Now consider a hypothetical example in which the bug were critical to use of the software in my business. I would have no way of fixing the bug, and it could cost my company money every time I encountered it.
One common mechanism for increasing the priority of bug fixes and feature enhancements is to offer a bounty for their implementation—a specified sum awarded to the person who provides the fix. If a company encounters a significant bug in FOSS, they can offer a bounty for the repair. If another company has problems with the same bug, they can add a sum to the bounty.
Exactly the same principle applies to security fixes. Let's consider an example. OpenBSD is a UNIX-like OS with a focus on code correctness. This FOSS system is based in Canada and developed by around 60 people (although it does incorporate some code from other sources). The system is used by the OpenBSD developers, supports multiple CPU families, and includes basic server functionality out of the box. In the last eight years, OpenBSD has experienced only one security hole that has allowed an attacker to compromise the system. By comparison, over three years ago, Microsoft announced a security initiative—they would focus on security above all else. When I tried setting up a Windows XP system a year ago, I found that it was compromised even before I had finished running Windows Update.
The reason for this difference is, to a large degree, the development model. Microsoft developers have a constant incentive to add large numbers of features to encourage customers to upgrade. If Microsoft produced a version of Microsoft Office and a version of Microsoft Windows that fulfilled the needs of their customers, that would spell the end of the company; once they had sold a copy to everyone who owned a computer, they would have no income.
If a FOSS project reaches the same state, it enters maintenance mode. The developers fix any bugs that appear, but beyond that they move on to other, more challenging projects.
Off the Shelf?
The off-the-shelf software market is a very small part of the overall software market; the vast majority of software sold is custom software. Even if off-the-shelf software were to disappear completely, the software market would still be huge.
There's no reason why all custom software can't be free software. Custom software is paid for once, and then usually completely owned by the customer. Since all rights are assigned to the customer, it fits the Free Software Foundation's definition.
The availability of a FOSS stack benefits customers and software companies implementing custom software. They can take a FOSS operating system, database, web server, and so on and modify them without having to pay for that privilege. This saves the software company from duplicating effort and saves the customer from paying for duplicated effort. It also drives down the per-seat costs; because the software is free, the customer, not the supplier, decides how many people can use it.
This doesn't mean that the developers aren't paid; they're paid for doing work of value to a customer, not for working to create a product whose value derives solely from an artificial scarcity.
Not Sustainable?
Criticisms of the open source development model come from misunderstanding the nature of the model. FOSS is not about doing work for free; it's about doing work for which there's a real market. FOSS is developed by paid developers to add value to their employer's products, or for their employer to use.
A FOSS customer is free from vendor lock-in; they can buy a solution from one company and then switch to a second source with no problems.
The value of a second source is well-known even outside the software industry. It's considered commercial suicide to depend solely on a single supplier for something core to your business needs—by doing so, you grant the supplier control over your business. The historical term for this practice is hydraulic despotism—rule through the control of a single, necessary resource. In ancient Egypt, the government controlled the supply of water. Subjects who didn't obey the whims of the rulers would find that their crops were not irrigated and so would die. Today, companies that build businesses based on closed solutions find themselves in a similar position. They must accede to the demands of their supplier, usually in regard to forced upgrades and price increases, or go out of business.
For more information on Linux and open source software, visit our Linux Reference Guide or sign up for our Linux Newsletter