How to choose an open-source CMS

In this issue of Industry Insider, Seth Gottlieb, content management practice lead at Optaros, explains how one should go about selecting an open-source content management system. Gottlieb is the author of Content Management Problems and Open Source Solutions, a whitepaper which summarises 15 open-source projects and distinguishes between open-source CMS and proprietary software selection.
Written by Seth Gottlieb, Contributor

In this issue of Industry Insider, Seth Gottlieb, content management practice lead at Optaros, explains how one should go about selecting an open-source content management system.

Seth Gottlieb, CMS lead, Optaros

Gottlieb is the author of Content Management Problems and Open Source Solutions, a whitepaper which summarises 15 open-source projects and distinguishes between open-source CMS and proprietary software selection.

The source code is not the only thing that is open about open-source software.

Open source happens out in the open. By subscribing to user mail lists and other communication channels, it is easy to learn about what others are doing with the software, which features are good, and which features need work. Reading a project roadmap or the publicly accessible bug lists will tell you where the project is going, who is driving it, and whether the team is well organised. You can also get a feel for the personalities and the social dynamics of the group.

As you read through the archives, pay attention to questions that do not get answered and who answers the questions that do get answered. Having several people actively posting answers is a sign of a strong community that will survive if one of its principals moves on. Also look at the content of the answers. A reference to a document means that a document exists -- a good sign! A long set of step by step instructions may indicate that there is insufficient documentation and processes for creating documentation. It may also indicate that users need to constantly deal with work-arounds rather than actively maintaining the code base. For example, if you see instructions like -comment out the line that says x and add the following code ..." it could mean no one is patching in those fixes.

Look at (or have your technical staff look at) the development guides and practices. Better-managed projects have functionality roadmaps, a clearly defined release process, coding standards, and use practices like unit tests which automatically verify that additions do not break other parts of the code base. Reading through the developer site should make it clear how the community decides how functionality is assigned to releases and what kind of testing occurs.

Browsing through the bug tracking system will tell you how active the software being tested is and how efficiently issues are being resolved. Do not assume that having lots of issues in the bug tracking system is a bad thing. It means that the software is being used by people that care enough to work with the community to improve it. Look at the content of the issues. Bug tracking systems are also used to record requests for enhancements which indicate how the software is expected to evolve.

Most importantly, you can actually try the software. In many cases, you don't even need to install the software to get a demo. The site www.opensourcecms.com has demo versions of over 70 open-source LAMP based CMS including Drupal, Mambo, and Joomla, as described here. eZ publish, Lenya, and phpBB have demo instances of the software running on their sites. As you experiment with the software, involve prospective users in the process. Have them try the software out, list what they would like to change, and how important those changes would be. Give them ownership in the process. Doing so will help them become invested in the solution and increase adoption.

I should note here that I would apply the same recommendations for evaluating commercial software if I could. However, software companies do not expose who the brain behind the technology is, how helpful the tech support is, and how the organisation tends to respond to turnover.

Where to put the money that you save
The truth is that technology is not the primary reason why content management initiatives succeed or fail. Success in content management depends on activities such as migrating content, improving business processes, and achieving adoption. With the absence of licensing costs and availability of different support options, investments in the solution can be redirected into factors that have the highest impact on the success of a content management initiative.

More time and effort can be spent on prototyping to understand requirements better, managing the project, improving business processes, migrating content, and educating users. In his article -Spending patterns during CMS implementation", James Robertson of Step Two writes that the implementation is just the first of three phases of a CMS project. Implementation is followed by phases of adoption which includes data migration, training, and evangelising the solution, and enhancement which addresses requirements that were either deferred or realised once the solution was deployed. Robertson recommends setting realistic expectations of time end effort for these second two phases, with the adoption phase lasting up to 12 months, and continuous enhancement.

After the solution is deployed, allow it to evolve. If the stakeholders were involved in the earlier phases of the project, chances are they will feel ownership of the application and think of ways to help it improve once they understand how the application fits into their business processes. Impress on these business users that the application has the potential to evolve and they will be less tenacious on the scope of the initial release.

What to do about support
Because open-source software presents more support options (commercial, consulting, and community), some thought should be given to the support needs of the organisation. Many companies, due to policy or habit, always purchase support contracts. In some cases, when tech support is frequently requested, those investments are justified. In other cases, when the software just runs without much need for human intervention, or if the organisation has experienced technical staff that has knowledge of the technology, subscription-style support packages make less sense. Frequently, developers find access to the knowledge base and public search engines more expedient and useful than phone or e-mail-based support.

If commercial software-style support is desired, it may be offered by the company hosting the open-source project or by a third party (such as SpikeSource and SourceLabs). The system integrator that helped deploy the solution may also offer different support models ranging from peruse- to subscription-based.

As you support your implementation, you should also think about what you should be giving back to the community. Contributing back code you developed for your own use is not required but it may be to your advantage to do so. A good rule of thumb is that you should contribute code back when the competitive advantage of sole access is outweighed by the cost of maintaining it. When you contribute back, great things can happen. The code gets reviewed by really good programmers. The code becomes part of the core application so you have less to worry about when you upgrade. The contribution that you make also has the potential to grow into a new feature that would be useful to you. The application gets better and attracts more users which ensures its future.

Open-source content management software presents an attractive option for companies looking for a straightforward solution to a common problem. However, traditional methods of software selection are less helpful in evaluating open source than commercial software. Indeed, the vast selection of open-source content management software, coupled with the broadness of the category, can make the task of sifting through the possibilities tedious and disorienting.

To get your bearings, focus on the business problem and look to see what other companies have used to solve similar problems. Once you do narrow down to a set of viable options, the openness of open source will allow you to learn more about the software than you ever could learn in the commercial world. If you leverage these benefits, open source can reduce the risk of your initiative and provide a solution that can grow with your company.

Seth Gottlieb is the content management practice lead for IT services company Optaros. He has worked on numerous content management projects using a variety of software. Gottlieb is a member of CM Professionals. © 2006 Optaros.

Editorial standards