Open source software is free. That fundamental precept can be an irresistible lure to using an open source product...
to build a Web or enterprise content management system (ECM). In fact, the promise of reducing or even completely eliminating the costs associated with purchasing and updating software is a valid advantage for open source content management technology.
But depending on an organization’s needs, other hidden factors can increase an open source ECM or Web content management (WCM) project’s total cost of ownership (TCO) over its lifecycle. Among the key potential cost drivers that demand early evaluation are training, custom development and maintenance issues.
Context is critical when determining how much these factors will affect the bottom line. If ignored, they can increase TCO to levels beyond those of off-the-shelf, proprietary software. But with proper planning, many of the associated costs can be mitigated or avoided altogether while still retaining the benefits of using open source software.
Missing, incomplete or outdated documentation can result in significant end-user frustration and time wasted during all stages of any software deployment, including ECM and WCM initiatives. Unfortunately, these documentation issues are often unavoidable within many open source communities and projects. The reasons range from a lack of resources to a rapidly evolving code base.
If you’re already committed to a particular open source content management product, it’s difficult to avoid documentation problems and the extra costs they generate. However, third-party books can be an invaluable substitute for official documentation and are usually affordably priced and available in print, e-book and online subscription formats. If your organization has made a long-term commitment to the technology, it’s wise to hire a consultant or train one or more employees in documentation. The money spent up front on this resource can help save money over the lifetime of a project.
Support and maintenance
Who are you going to call? Users accustomed to having official telephone, email and live-chat support channels are often disappointed to discover that assistance for the community versions of open source software is limited to issue queues, Internet relay chat and online forums. Although these avenues can be effective, people unfamiliar with how to use them are often resistant to even trying. Worse yet, responses via these channels are not returned within any guaranteed time frame, if at all.
And if the software is a key piece of the content management infrastructure for a business, even waiting an extra day for an answer can be unacceptable.
There are two types of fixes for this problem: internal vs. external expertise. Support contracts with an open source vendor or an independent service provider can be affordable depending on the required availability (that is, hours of support per month) and complexities of your needs. Certain Software as a Service and Platform as a Service technologies might even offer the best balance of an open source product with a built-in support contract.
In some cases, creating an in-house support position might be warranted if the time spent on system maintenance justifies the cost of adding another person. Be warned, however, that average salaries and the availability of expertise vary wildly among different open source products.
With many open source technologies, you can download and install the software within minutes or even seconds. Configuration might take a little longer, but it’s generally not so time-consuming that it contributes much in the way of costs.
The same is not always true for customization. If a project’s requirements are not properly managed and customizing code takes it beyond the initial scope, the added overhead can be significant. Most open source providers make it clear up front that the software comes “as is,” with no warranty. And in communities that don’t follow or enforce uniform coding standards, understanding, modifying and extending the software can take a substantial amount of time and effort.
The best way to keep these expenses down is to avoid custom code development whenever possible. That can be accomplished by properly defining project requirements and key features before choosing a product. It’s also wise to consider upgrade paths and future features that might appear on a one- to three-year roadmap. Ultimately, though, some level of customization will be inevitable if your content management requirements are specific or unique to your organization’s business needs.
It’s important to remember that these types of issues affect all software projects, open source and not. But organizations should consider them before blindly jumping into an open source content management implementation thinking that cost isn’t a big deal. The key is to research and address them early to properly plan for the TCO over the lifecycle of your open source ECM or WCM system.
ABOUT THE AUTHOR
Rick Manelius has a doctorate in materials science and engineering and is a freelance Drupal developer and community volunteer for the Drupal Means Business track at DrupalCon Denver. He has worked as a consultant, project manager and developer for media companies creating online communities.