Last year, Builder.com columnist Shelly Doll wrote an article titled, "Will open source finally kill off the $1.2 million CMS money pit?" The article prodded me to learn more about open source CMSs and to see what options they offer and what level of support is available.
Don't get off on the wrong foot
I began my open source CMS exploration the wrong way, with insufficient preparation. Before downloading, installing, configuring, and testing an open source CMS, it's important to have a roadmap of the features you need, including the license, level of support, and security features.
OSCOM lists 11 content management frameworks and 27 content management systems. Cmsinfo lists at least 64 CMS systems.
Open source doesn’t always mean free. Some licenses allow noncommercial use of software for free; others (such as GPL) are free but require you to list the original copyright; otherwise, you must buy a license. Think about your application and then choose the option that's most cost-effective for your needs.
When evaluating which tool makes sense, also consider how the CMS will be used and who the end users will be. The way the CMS is used will be the key to how you are allowed to use it according to the base license.
Open source products feature a wide variety of support mechanisms. For instance, PHPNuke and its derivatives have no commercial support, but the user and developer communities are so large that community support is pretty solid. However, the nature of the project and your installation may require more traditional support, such as incident-based trouble tickets.
I recommend that you take a look at the support mechanisms and make sure that you’re comfortable with them. No matter which CMS you choose, you’ll most likely run into some kind of trouble. Unless you feel like debugging the code from scratch yourself, support is critical to the success of your implementation.
Customization features are a huge issue with open source CMS systems, whether you need to customize the theme (graphics, layout, style sheets, etc.) or the functionality of the system itself. Is your application out-of-the-box or is it specialized?
PHPNuke, for instance, has a relatively rigid layout, which makes it easy for a rapid install. Changing the layout isn't easy, but a number of good resources are dedicated to that issue.
When looking at the customizability of the various CMS offerings, think about how you want your end product to look and function. Can you easily modify layout, modules, and functionality? Look at how you would go about making customizations to the CMS and include the process in your testing methodology.
As with any software system, security is an issue. Some of the open source content management systems (PostNuke, for example) have active developer segments that concentrate on security alone. Others seem oblivious to it. Make sure that whatever CMS implementation you use conforms to your overall security framework and does not compromise the rest of your efforts.
PostNuke was the only open source CMS (GPL) I tried that had a dedicated security team looking at security issues without requiring me to shell out for commercial support. Most likely, commercial support for the other solutions includes regular security updates and patches.
Table A outlines the platform and languages for some popular open source CMSs.
Size Them Up
Table B summarizes the support, customizability, and security features of various open source content management systems.
Try Them Out
Once you’ve narrowed down the field and decided which CMS solutions may be appropriate for your requirements, try them out for yourself. When I started to test various systems, I did it the hard way: I downloaded them to my test box running the same environment as I expected to have on the live server.
Since then, I’ve found a simpler method to test drive some of the CMS systems. Opensourcecms lets you try out 41 CMS implementations from its respective Admin screens. (I found a separate WebGUI demo at demo.Plainblack.com.)
Of course, there's no substitute for testing in your own environment. If you’re going to use it, you have to abuse it and see how it holds up. If you don’t, you can bet that your users will.
TechRepublic originally published this article on 9 June 2003