The Generation Gap

Use of open-source software is mushrooming with the use of Linux. The benefits of open source are becoming more widely known—software quality is improved from peer-review, and future risk is reduced if the source is available.

Open-source projects depend on contributions by motivated, talented developers. Big, important projects like Linux attract many contributors; a project for a software development tool may interest a variety of software developers; UNIX systems gurus contribute to projects for Internet tools. However, a project for software that identifies butterflies may not attract much interest, and the only people who are going to contribute to a project for a company's accounts receivable system are those who are paid to do so. Not all software benefits equally from being open source.

The development of closed-source software will continue. As Eric Raymond observes in “The Magic Cauldron”, some applications (as opposed to operating systems and utilities) can be good candidates for being closed-source. The owner of an application may find more benefit in the software being secret and/or rentable than being open source, at least for a while.

It may be undesirable for the source of a homegrown business system to be open, because it reveals so much about the business's procedures and capabilities. A company may want to keep the source of its business systems confidential.

The owner of an application may want to keep the source closed so that the software can be rented (i.e., licensed for money). Many applications are developed only when someone believes they can make money renting them.

While the benefits of open source are becoming more widely appreciated, closed-source software will continue to be developed.

Closed-source applications can benefit from using open-source components.

Applications generally make use of pre-existing software components. Almost all programs use general-purpose function libraries that come with compilers. Many applications provide a front end using a GUI framework that comes with the compiler or a third party. Some software uses special-purpose libraries to do things like statistical analysis or mapping projections. Many applications include, or know where to find, a self-contained “component” that provides sophisticated functionality, such as a database engine or a map-drawing system.

There is less risk in using a third-party component if it is open source. This is particularly true of components developed by small companies and individual developers. It's very difficult to develop software components and make money renting them. People think, “I don't know these guys. Who knows what they've done in there? My application depends on this functionality.” They also think, “What if these guys disappear? Or find something else to do? Or change the component so I can no longer use it? Or not fix what I need fixed?” They may also think, “This component does what I need to do now. What about next year? What if I want some enhancements? Are these guys going to care what I want?” Being open source addresses these concerns. Developers can see what an open-source component does and how it does it. They always have the option of making improvements themselves (or paying someone to do it).

If a component is open source, its owner cannot rent it. However, money can be made in support services, and the people best poised to do so are developers. A tiny outfit without the credibility to rent a component may find that the best way to make money is to make it open source.

It might be easier to attract contributors to an open-source project for a component than to a project for a narrow application. The users of a component are programmers, and they make up a natural pool of potential contributors whereas the users of a narrow application might be, for example, dentists.

Developers may be motivated to improve the component if an improvement is all that is necessary for the component to be used. Companies using the component may be motivated to spend money to improve it.

Concerns arise over using open-source components in closed-source applications. The most commonly used open-source license is the General Public License (GPL). It grants users the freedom to modify the software and distribute this derived work only if, among other restrictions, the derived work is also licensed under the terms of the GPL. This license ensures that all users of a piece of software, even users of modified versions, have the freedom to see and modify the source code. The Free Software Foundation promotes the use of the GPL.

A component licensed under the terms of the GPL cannot be used in a closed-source application, but some developers of open-source components would like to see them used in any application, open-source or not. The Library General Public License (LGPL, also known as the Lesser General Public License) was developed for this situation. A component licensed under the LGPL may be included in a closed-source application as long as users can get the source for the component, modify it and rebuild the application.

In many cases, however, developers of closed-source applications cannot (or will not) make use of components licensed under the LGPL. Developers of commercial products and companies writing software for their own use frequently don't want any given component badly enough to submit to the restrictions of this license.

There are less restrictive open-source licenses. A component licensed under the terms of the MIT License can be used by anybody for anything. Such licensing makes a component practical to use in closed-source development. Many people in the Open Source community find this license to be subversive, precisely because it makes it practical to bring open-source software into closed-source applications.