Originally published in Intranet Journal (07-Sep-2008)
In Part 1 of this series, I painted a very rosy picture of open source intranet software. But open source isn't for everyone or every situation. For all the advantages open source software can give you, it's not always the easiest to set up if you're not technically inclined. And it can be difficult to sell the open source idea to senior management. Sometimes it's just easier to go with one of the "Big Guys" to make your intranet life easier.
Free, open source software is available to everyone, but you still need to have the technical know-how to put all the pieces together—installing and configuring the intranet software; installing and configuring its associated database; and most importantly, setting up the appropriate application and content security for users and content managers. Drupal, for instance, is extremely powerful and customizable, but there's a very steep learning curve to overcome before you can take full advantage of the software's true power.
Although open source intranet tools are getting easier to install and set up, it's still a do-it-yourself process. Most of these open source suites are optimized on an open source solution stack, using databases such as PostgreSQL or MySQL and Web servers like Apache. But what are the chances that you'll already have these components running in a production environment within your organization? Choosing an open source intranet solution, therefore, means that you'll have to not only overcome the learning curve associated with the tool itself, but also all the other open source components in the solution stack.
If you're not up to this challenge or you don't have the time to overcome the learning curve, you can save a lot of hair-pulling aggravation by choosing a proprietary, commercial intranet suite that's ready to use out-of-the-box. Developers of proprietary, commercial intranet suites go to great lengths to hide the nuts-and-bolts from customers. They try to make their software as quick and easy to install and set up as possible—even by those with limited technical ability—by encapsulating many of the tool's components into its installation package.
Open source software is usually built and managed by a seemingly ethereal body of developers known only as "the community". But these open source developers join and leave the community all the time, and the community as a whole might decide one day that it no longer wishes to continue with the project. Some software adopters will find this lack of stability in community-based development a bit risky.
It's not uncommon for an open source project to reach an apex and then begin a steady decline as the project community loses both interest and developers. If an open source project is abandoned by its community of developers, and you don't have any in-house expertise, you might find yourself running an obsolete tool with very few avenues of support. Large, established commercial software firms have huge market shares and customer bases. Adopters of proprietary software from established companies such as IBM or Microsoft like the feeling of security that comes from knowing these companies are not likely to disappear overnight.
Despite the advances of open source software, many non-IT people still view open source as "not serious". They still have a misperceived notion that open source software is developed and maintained by an unorganized group of misanthropic technoweenies hiding in some damp basement. Unfortunately, many of these non-IT people are the same people who sign the checks for large-scale projects such as intranets.
Senior management loves the status quo and hates to rock the boat. Senior managers—especially those in larger enterprises—have a tendency to choose established commercial software makers such as Microsoft, IBM, and Oracle. Getting them to agree to do away with these so-called traditional software makers in favor of an open source solution developed by what they perceive to be a community of "faceless" programmers will take them too far out of their comfort zone. They might even consider open source a Mickey Mouse solution when compared to tools from well-known and established commercial software makers.
No one will bat an eyelash if you propose a Microsoft-centric solution stack... OK, maybe if you work for Apple, but in most cases convincing management to back an established software maker will be much easier than convincing them to back an open source solution developed by a community of relative "unknowns."
Let's face it, we live in a litigious society. When something goes wrong, we always want someone to blame. So if a CMS mysteriously gobbles up an organization's data, senior management will want heads to roll. They will want to hold someone responsible—and possibly to take legal action against. It's tough to do that with open source software.
The very nature of open source is to allow developers to modify and adapt the core software to their organization's own needs. But the open source software's original development team can't be held responsible for what others do to the core software—especially when those making the changes aren't too technically adept and modify the source code with a "let's see what happens when I do this" approach.
Since open source is more of a DIY solution when compared to proprietary software, the open source development community can't offer guarantees for code changes it had nothing to do with. Open source software is provided as-is, and the development community often explicitly states that it's not liable for anything that can occur with the use or modification of the core software.
Open source software makers have no formal technical support department. Troubleshooting, like development and implementation, is a DIY process. Informal support comes in the form of community-based Web sites, knowledge bases, and discussion forums. If you have a problem or question, you have to hope that someone in the community will have an answer or solution for you. You also have to have the technical know-how to put that solution into play.
These DIY, community-based support structures can help organizations with IT expertise avoid costly technical support contracts, but it does little for those companies that don't have the time and resources to go digging through online knowledge bases and user forums. Proprietary, commercial software makers tend to offer more personalized, one-on-one technical support. They can walk you through different troubleshooting procedures regardless of your technical skill level.
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.