So far we've talked only about reasons to make one of your proprietary products into an open-source project. There is also the question of when it makes sense for a company to use an existing open-source product. We conclude this chapter by discussing some of the issues that arise from using open-source products in a company setting.
The first question is pretty much the same for any software under consideration--how do the features of the software match up with your needs? Open-source software is often less polished than commercial products, so you need to decide if extra polish is worth paying more for.
Choosing software also involves looking at what other needs you have that might be met in future releases. Here the transparency of the open-source process makes it easier to get a handle on what new features are planned and when they might be ready--all of the planning happens on public mailing lists and is displayed in the project's roadmap--you can even send an email to the main developers. Most companies are much more guarded about planned release dates of proprietary products and what features will be in future releases.
If a feature you need is missing, open source has an advantage in that you can work with the project to add it. You can lobby with the community about adding the feature, have your own developers write the needed code, or hire consultants to do so.
When you buy a product from a company, you expect that the company will stand behind its product by providing both a warranty and product support. If you have a problem, you believe that you can go to the company and legally it is required to fix that problem. Although this may be true for physical products such as automobiles, by far the majority of commercial software products come with very limited warranties and minimal support. If you've ever read the End-User License Agreement (EULA) for a piece of commercial software, then you know that the warranty is basically just a refund of your purchase price. And if you've ever tried to get basic, no-cost support from a large software company, then you know how difficult and frustrating it can be--although some do have lots of good information available through the company's website that more sophisticated users can take advantage of. Most companies do have support plans that you can purchase. Support may also be available from third-party companies.
With open source, there is often no company to deal with. However, there is usually a community and that community exists in large part to support its members in the use of the software. This support takes two forms: online documents and discussion forums. When evaluating an open-source application you need to check both. Go to the project's website and see how much documentation is available, whether a good FAQ for it exists, and whether there are active mailing lists or newsgroups devoted to user questions. Check if the main developers participate in the user forums--tough questions that might stump a customer support person for a commercial product are often answered by the actual developers of an open-source project. Although getting support through a public mailing list may seem very informal, many who have tried it find it gets the job done, often more quickly and better than previous experiences with support for commercial products.
For the more successful open-source applications, there are companies that sell support. For example, rather than downloading a free copy of the Linux operating system, many people choose to buy it from Red Hat because support is included. Other companies, such as Caldera, Linuxcare, and IBM, also offer support for Linux, as do many consultants. Some open-source projects have commercial versions that are supported--StarOffice is a supported commercial product sold by Sun that is based on OpenOffice.
Training is related to support, and, indeed, for popular widespread open-source products it is easy to find training classes and books, both introductory texts and advanced reference material. Some publishers, such as O'Reilly, specialize in providing high-quality books on how to use open-source applications.
Open-source software is not always free--sometimes you may have to pay for it, as you do for the basic Red Hat Linux distribution--but what you are paying for usually is the convenience and quality assurance that went into packaging the software. Of course, once you have the software you can install it on as many computers as you wish (although the other installations might not be covered by the support agreement). So, instead of needing to purchase multiple licenses, one for each computer you wish to run the software on, open source immediately saves you money, possibly quite a lot of money. However, keep in mind that your total cost also includes the cost of deployment, training, and support, plus indirect operating costs due to ease of use (or, more appropriately, how difficult it is for your employees to do their jobs using it) and interoperability with other software you use. According to some studies, software and hardware costs account for less than 20% of the total cost.
Considering the expense involved in switching from one software application to another, you want to evaluate the future prospects of any software you choose: Will it continue to be a supported product, or will it be discontinued? If the company making it goes out of business, what happens?
For open source it is important to assess the health of the project in order to be confident that the software will continue to be developed. To do so, look at the size of the community, check how much documentation is available, see whether a good FAQ for it exists, and browse through the various mailing lists and newsgroups associated with it to determine how active the community is. Also check to see how often there has been a new release of the software. Look at the project's road map to understand the overall vision.
Even a small project with just a few developers may have advantages over a proprietary product. A single developer may be more willing to fix bugs and add features. Also, there is always the possibility of hiring the main developer as a consultant to make the changes you need. Finally, with an open-source project of any size your risk is always reduced because the source code is available to you.
As with any company, an open-source project can disappear, and with it perhaps its source code and community. You may be able to retain rights to use, maintain, and further develop the source code if the license gives you those rights. By judging the health and importance of the project, you can decide whether this is a risk you wish to accept.
There is another way that open source lets you choose the level of risk you are comfortable with. You can minimize your risk by using only the major releases that have undergone thorough testing. Or you can accept more risk if you want access to new features as soon as they have been added to a development build. Or you can choose to be somewhere in the middle by using the stable builds that are known to at least basically work and may have received some testing. Better yet, do your own testing if you have the resources.
One last risk deserves mention if you wish to distribute an open-source application, possibly along with some of your own products, for use by your customers. By definition, open source can be redistributed, but you need to check the license that the software uses to determine if there are additional conditions that you must meet. If you have not made any changes to the software, but are merely redistributing binaries that you got directly from the project, then there should be no problems, although the license may require that you acknowledge the open-source project in your advertising materials or restrict your use of the project's name in product endorsements. If you have made changes to the software, then you may need to make the source code for those changes publicly available, depending on the license. Because open-source software does not include any warranty or support, your customers may expect you to provide both. Finally, some companies have tried to scare others away from using open source by falsely claiming that, if you merely bundle one of your proprietary programs on a CD with an open-source program, you then need to make your proprietary source code public--it's just not true: Your code stays yours.