Commercial and open source software may originate from different cultures but, like Ford trucks and Volkswagen sedans, both get you from Point A to Point B. Sometimes, they even share the same roads. In the real world, choosing one over the other for a particular application should be less about their respective origins and more about the goals ahead.
Choosing between commercial and open source software options often presents a chicken-and-egg scenario. If an organization has already invested in an application infrastructure, that alone may provide the necessary inertia favoring one direction or another when choosing future products. Although a Ford or a Volkswagen will get you where you need to go, one might ride more comfortably or be more reliable. But, if you have the option of riding with a Ford mechanic in the passenger seat, which car would you choose? An old proverb in software development states that the best programming language for a job is the one you already know. This doesn't mean that you must always choose the Ford, but it does mean you need a strong reason not to.
On the other hand, if you are creating a new infrastructure, it is akin to building a new house. Like a builder, you are afforded the opportunity to choose building materials that provide the best long-term benefits. From this vantage point, it is important to gauge the organization's tolerance for vendor lock-in. For precisely the reasons described in the previous paragraph, commercial software choices put practical limitations on future choices. On the other hand, some organizations find locking in with the right vendor offers a kind of efficiency, and having a single shoulder to cry on brings solace to some.
Commercial and Open Source Management and Interoperability
|Configuration||Typically (somewhat) user friendly; may store config data in proprietary formats.||Can involve steeper learning curve; config data may be obtuse but is also open and accessible.|
|Customization||Can range from very limited to very flexible, depending on the vendor.||By its nature, extremely open to modification and customization.|
|Interoperability||Strong compatibility with vendor-supported products, possibly little to none with others.||Typically has reasonable to strong interoperability with both open and commercial products but may require customization or patchwork to complete.|
|Support||Formal support nearly always available for a fee; community support may be available, particularly with popular products.||Formal support may be available at a price for major products; community support typically available but is most comprehensive for popular products.|
One of the top considerations in choosing a software product is how it will be managed over time and how it interoperates with other, related products. Managing a Web server, for example, involves aspects of configuration, support, and customization.
Because open source software tends to stem from a "do it yourself" mindset, even an out-of-the-box configuration may require more upfront knowledge. The ever-popular, open source Apache Web server powers nearly 70 percent of the Web (as of July 2005). The basic Apache distribution, available for many platforms, including Linux and Windows, is basically configured with a text file. This configuration file relies on a syntax specific to Apache. A variety of visual front ends, which superimpose a graphic interface onto Apache, are available for different platforms. Webmin is one well-known example. While these can improve productivity in an Apache configuration, there is no single standard interface. The common denominator across all Apache installations is the text file configuration.
Microsoft's IIS (Internet Information Services) Web server also has a strong following, accounting for nearly 21 percent of all Web servers. It is the Web server of choice for the majority of Fortune 1000 sites. As part of a larger family of centrally developed Microsoft products, IIS configuration has a familiar feel for administrators already comfortable with Microsoft platforms.