Support for both commercial and open source software comes in two varieties: formal and informal. Formal support is usually paid and provided by the vendor or a third party. For some popular commercial software packages, like the Oracle database and Microsoft Exchange, both vendor and paid third-party support is readily available. The same even holds true for popular open source applications, like MySQL and sendmail. While both products are free to obtain, their respective “vendors” sell paid support services, as do other third parties. For other open source products, like postfix, there is no “vendor” per se to provide support, but third-party consulting firms do offer commercial support.
Informal support through online communities generally abounds for most popular products, whether commercial or open source. These valuable resources, found through newsgroups, Web-based message boards, and mailing lists, typically scale with the popularity of the product — regardless of origin. Choosing a product with a small installed base, whether commercial or open source, often has the limitation of having a small user support community.
It’s often said that open source software is infinitely customizable, which is true — so long as someone in the organization knows how to write code.
It’s often said that open source software is infinitely customizable, which is true — so long as someone in the organization knows how to write code. Clearly, one of the strengths of open source software is in providing building blocks for organizations that want to build custom solutions. If, say, you wanted to build a workflow for publishing custom XML data into a variety of highly specialized channels, open source tools provide a great deal of flexibility to create robust, budget friendly solutions.
What you need, however, is knowledge, which may not offset this cost-friendliness if the skills are not already in-house. Turnkey commercial solutions, on the other hand, typically cost more out of the box and can be deployable more quickly, often with a sacrifice in customizability.
In the real world, applications do not live in isolation. As part of a larger framework, issues of interoperability arise. For example, consider Microsoft’s Active Directory, a fundamental and widespread central nexus for user, file, and print services across a network. Not surprisingly, many commercial products for the Microsoft platform are designed to integrate with Active Directory. In the open source world, there is no direct equivalent. True to the open source “way,” a variety of building blocks (e.g., Samba and OpenLDAP) address segments of the Active Directory feature set. With sufficient know-how, open source solutions can incorporate these components to interoperate with Microsoft networks. As a general rule, interoperability between commercial and open source software is achievable and actually becoming easier every year. That said, costs may be incurred, whether in time or support, when products cross the boundary from open source to commercial or vice versa.
Ultimately, when choosing software solutions, whether an app originates from an open source or a commercial background is virtually immaterial. More important is the current infrastructure, both in terms of product and people, and how new acquisitions will be managed in that context.