There are significant objections to overcome before open-source software can be broadly adopted across enterprises. These issues aren't insurmountable, but they need to be adequately addressed before open-source can go head to head with the major proprietary software vendors. Objections centre around the following areas:
• Support availability
• Functional limitations of the software
• Software license terms
• Rapid software release cycles
• Package road maps or future plans
These concerns have merit but are often overblown by commercial vendors. Any major software rollout incurs risks. It's important to understand those risks and have plans for dealing with them. In the end, open-source involves no more risk than any proprietary software package.
Support availability, or lack of it, is the most often cited objection to adopting open-source, yet the number of support options is large and growing. HP, IBM, JBoss, Novell, Oracle, Red Hat, Sun and many others actively promote and support open-source software. Round-the-clock response is available from these vendors and others.
When selecting an open-source package, look for a history of stable releases, multiple books published about the software, availability of foreign-language versions, very active online forums and the existence of multiple support options through a variety of vendors. These characteristics indicate that the software is well-known and widely used, thus making it more likely to have a vibrant future.
Functional limitations come into play whenever a company migrates from one software package to another. Because many open-source packages are relatively young, they often don't have the full suite of functionality offered by commercial equivalents. These deficiencies are being erased over time, but in the short run, they may present a challenge. Users are reluctant to give up features, even those they never use but might need someday.
Software migrations are never easy but occur every day. The key is to stay focused on core business objectives and not get sidetracked by useless bells and whistles that are tossed in "at no extra charge". Such features result in needless complexity, generate support problems and introduce vulnerabilities.
Software licence terms have undergone close scrutiny since SCO sued IBM in a last-ditch attempt to avoid insignificance. Just as every software vendor has unique licensing terms, open-source packages have varying terms. The most common licences are from the The Apache Software Foundation, the Open Source Initiative's BSD project, the GNU General Public License and the Mozilla communities. These are widely known and respected. Many open-source communities adopt one of these licenses or produce a variation.
There are two minefields to be aware of when it comes to licensing. First, when incorporating an open-source package into a commercial product, restrictions on how the product is distributed may apply. Second, when using or modifying portions of the open-source code, certain requirements may have to be met that could jeopardise intellectual property. Read the fine print in these cases and discuss it with an attorney who specialises in intellectual property law.
Rapid software release cycles concern many IT professionals. It's tough enough to deal with daily anti-virus updates, weekly security updates and monthly Windows updates. Some open-source communities release feature updates on an irregular but frequent basis. This is a symptom of the immaturity of many of these packages. The update frequencies will diminish over time.
While it's impossible to control software update frequency, not every update has to be installed and distributed. Review the changes in each release and decide what 's critical or valuable. Only perform an upgrade when enough value is present in a release to make it worth your while. The advantage in this approach is that you retain control. There are no forced upgrades.
Package road maps or future plans are important to most companies. Major vendors tend to heavily promote their road maps, even to the extent of publicising future capabilities years in advance. Of course, there is no promise that any advertised feature will ever see the light of your computer display. Not all vendors publish such road maps, and some share them only with strategic accounts under nondisclosure agreements.
Some open-source groups publish road maps, and some do not. At times, the stated goal is to mimic the functionality of a commercial package, though when any particular feature will appear is anyone's guess. The best advice is to make decisions based on what you can see and touch. If a feature doesn't exist, assume it never will, even if it shows up on a road map or vendor presentation.
With all these potential drawbacks and pitfalls, why would anyone consider using an open-source package versus buying a proprietary product? Ultimately, it's not about cost, so forget all those total cost of ownership arguments. It's about value and free-market choices. With any software acquisition, evaluate needs, explore options and select the best fit. Think of open-source as buying software from a small supplier. There may be additional risks, but the rewards can make it worthwhile.