- What Is Open Source?
- The Motivation for Open Source
- Who Gets Paid?
- Security, Bugs, and Features
- Off the Shelf?
- Not Sustainable?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.