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.
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.
Leave a comment