Open Source vs. Proprietary Intranet Software, Part 3

By Paul Chin

Originally published in Intranet Journal (06-Oct-2008)

back back to portfolio

An organization's choice of either an open source or proprietary intranet software solution must be based on its own specific needs and resources—not on what others are doing or saying. What worked for one company might not necessarily work for yours—IT infrastructures are different, employees' technical skill levels are different, and budgets are different. You should never base your decision on the success or failure of another company's experiences.

In Part 1 and Part 2 of this series, I outlined the advantages of each solution. In this third and final part, I'll provide some hints and tips to help you make your own decision.

Consider a DIY open source solution if:

  1. You can't afford commercial intranet suites that are often sold at huge markups. Open source intranet software, user documentation, and community-based technical support are all provided free of charge.
  2. Your company has very unique and business-specific requirements that can't be readily fulfilled with packaged, off-the-shelf software that usually only contains the most common and widely used features.
  3. You have (preferably long-term) technical expertise—either in-house or on contract—in all the technologies used in your chosen open source solution stack.
  4. Many of the technologies in your chosen open source solution stack are already in place in a production environment (or can be easily integrated into your production environment).
  5. You want total freedom and control over every aspect of intranet development, end product use, and system ownership without being held within the confines and rules of a proprietary software's capabilities and terms of use.
  6. You want to free yourself from vendor dependency and want to avoid tying yourself into any one particular software vendor's proprietary technologies.
  7. You want to avoid constrictive, and often costly, commercial licensing agreements—and possibly software bloat (ie, you'll end up paying for features you don't even need or want).
  8. You want to control your own software upgrade cycle rather than have to wait for new releases—that may or may not come—from a proprietary software vendor.
  9. You want to minimize total cost of ownership by avoiding the rolling costs often associated with proprietary, commercial software.
  10. You want to avoid expensive technical support contracts or pay-per-call charges.

Consider a proprietary off-the-shelf solution if:

  1. You have little-to-no technical expertise or software development experience to take on a DIY intranet solution stack.
  2. Your deadline is tight and you can't afford to spend weeks trying to overcome the learning curve associated with DIY open source software.
  3. A robust and highly customizable open source tool is overkill. You might have very basic requirements—where customization isn't an issue—that an off-the-shelf, ready-to-use intranet suite can easily fulfill.
  4. You feel that the time and effort required to learn and implement a DIY open source solution greatly outweighs the payoff and purpose of your intranet.
  5. Your existing IT infrastructure can't accommodate an open source solution stack, and you don't have the time to implement and learn the various components.
  6. You want to be up-and-running as quickly as possible with little to no development required. Most off-the-shelf, proprietary software suites are ready-to-use right out of the box.
  7. You feel uncomfortable with the "instability" of community-developed open source software and prefer the security of adopting a solution from an established commercial software vendor with a huge market share such as Microsoft or IBM.
  8. Your senior level managers aren't likely to approve of "unconventional" solutions. Adopting an open source intranet solution might be perceived by management as untested. Justifying an open source model might prove to be difficult.
  9. You prefer more the formal, one-on-one technical support provided by commercial software vendors rather than the DIY, community-based support provided by open source software. Formal technical support is also more immediate, unlike community-based support where you have to wait and hope that someone in the community has an answer for you.
  10. You don't have the time or expertise to keep up with all the activity in the open source software's community and tool, preferring to let others do the work of creating software upgrades and patches.

Closing thoughts

Open source software, for all it's flexibility and customization, is going to be a difficult sell to senior management—especially in larger organizations where establishment and toeing the line is the norm. And despite all the advances in open source software, many still perceive it as being "not serious" and used exclusively by small groups of freewheeling techies who have no business sense. Free or not, management is much more likely to pour money into an established tool from one of the "Big Guys."

Proprietary, off-the-shelf software is the established and accepted norm in the big business world. But huge software markups can exclude small businesses or not-for-profit organizations with very limited IT budgets. Once you do invest in a commercial software tool—tying your organization to the vendor and tool—you'll be subjected to the rolling costs associated with owning proprietary, commercial software.

Proponents of the open source and proprietary software camps will go to great lengths to prove their case in order to win you over. But you might end up having to chose one over the other by consequence rather than by choice. When you boil down all the rhetoric, marketing, and promotion, it really depends on your needs and resources. All the reviews and arguments are useless if the software's not a right solution for you, or you're unable to implement it within your organization. A perfect tool amounts to nothing in the wrong hands.

Copyright © 2008 Paul Chin. All rights reserved.
Reproduction of this article in whole or part in any form without prior written permission of Paul Chin is prohibited.