There are significant objections to overcome before open-source software can be broadly adopted across an enterprise. These issues aren’t insurmountable, but they need to be adequately addressed before open-source can go head to head with proprietary software. Let’s explore the major objections:
- Support Availability
- Functional Limitations
- Software License Terms
- Rapid Software Release Cycles
- Package Roadmaps or Future Plans
These concerns have merit but are often overblown by the commercial vendors. Any major software rollout incurs risks. You need to understand the risks and plan for dealing with them. In the end, open-source involves no more risk than proprietary software.
Support availability, or lack of it, is the most often cited objection to adopting open-source, yet the number of support options is large. Hewlett-Packard, IBM, Novell, Oracle, Red Hat, and many others actively promote and support open-source software. Round-the-clock response is available from these vendors and others.
When you’re selecting an open-source package, look for a history of stable releases, multiple books published about the software, availability of foreign-language versions, active online forums and the existence of support options through a variety of vendors. These characteristics indicate that the software is well-known and widely used.
Functional limitations come into play whenever a company migrates from one software package to another. Many open-source packages 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. The key is to stay focused on core business objectives and not get sidetracked by useless bells and whistles. Such features result in needless complexity, generate support problems and introduce vulnerabilities.
Software License Terms
Software license 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 do to. The most common licenses are the Apache License, the BSD License, the GNU General Public License and the Mozilla License. These are widely known and respected. Many open-source communities adopt one of these licenses.
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 jeopardize your intellectual property. Read the fine print and seek legal advice in these cases.
Rapid Software Release Cycles
Rapid software release cycles concern many IT departments. It’s tough enough to deal with daily antivirus updates, weekly security updates and monthly Windows updates. Some open-source communities release feature updates on an irregular but frequent basis.
While it’s impossible to control software update frequency, not every update has to be installed. 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.
Package Roadmaps or Future Plans
Package roadmaps or future plans are important to most companies. Major vendors tend to heavily promote their roadmaps, even to the extent of publicizing future capabilities years in advance. Of course, there is no promise that any advertised feature will ever see the light of your computer display.
Some open-source groups publish roadmaps too. 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 roadmap 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.