You may want to avoid hacking your open-source CMS

Seth Gottlieb has an excellent blog on content management called <content here>. Recently, he had a post about The Onion's adventures with Drupal. It's a story that illustrates the issues companies face when highly customizing an open source content management system. According to Gottlieb, when The Onion went with Drupal 4.7, they had to "hack the core" to allow for the high visitor volume they expected to their very funny and popular website. What The Onion couldn't anticipate was that Drupal would eventually solve this problem. The trouble was that by the time they released updated versions, The Onion's hacked version was so different from the original, it could no longer afford to upgrade without sacrificing its substantial customizations. 

And that, in a nutshell, is one of the problems companies could face when customizing open-source tools to this extent. The good news is that you have access to the source code. You can change and shape it to your company's needs--something that would be impossible to do with a proprietary choice like EMC or Open Text. They simply wouldn't allow you to see the source code. The bad news is that once you customize the code to the extent The Onion did, you are on your own. Even the community can't help you, and when inevitable upgrades come along including security fixes, if you've forked from the main build as much as The Onion did, you can no longer take advantage of the changes without substantial pain on your part. But if you stick with the main build and don't divert too much, you have a lot more freedom with the open-source options.

Learn from The Onion's experience

Joe "Zonker"Brockmeier is a freelance writer who has been writing about open-source software since the mid-90s. He's also the former Community Manager for openSUSE, a Linux distribution. He says that The Onion's experience should be a cautionary tale for any publisher. "Don't get out of sync with upstream [the main project] or you will regret it later," he says. He adds, "Customizing the core platform [as The Onion did] is asking for hurt. You're signing up to apply security fixes piecemeal or live without them. You're jumping off the upgrade path and missing out on the features that will come in the next version and the next and the next."

Customize the smart way

Brockmeier says you can avoid The Onion's pain if you plan well and use the tools that the open-source projects offer to make changes. "Drupal, WordPress, Joomla, etc.--most open source CMS solutions offer enough extensibility via plugins that it's really not necessary to deviate from the mainline version. Instead, do your customization via plugins and themes. The mainstream projects are sensitive to breaking themes and plugins, and they tend to avoid changes--or at least broadcast them very loudly when they're coming--that it's fairly safe to invest time and effort into plugins," Brockmeier says.

He says that it's likely that many of the same changes you are doing yourself, in house a la The Onion, are the types of changes that the community is working on. Chances are, if you see a deficiency, so do other people and they are working on it.

In the end, The Onion moved to Django, a tool Brockmeier explains is meant to be hacked and therefore might be a better choice for them. For most publishers, however, sticking with the core build and customizing in the fashion that Brockmeier recommends is probably the best way to go. But, he says, you can't be too critical of the path The Onion took, because it's impossible to know where a project like Drupal (or any other open-source CMS) might end up.

That said, if you are looking at mass customization, do your homework and make sure that what you're trying to do isn't already in the works for a future version. You could save yourself a lot of headaches in the long run if you do. And if you do opt for mass customization, make sure you understand what it means for your organization long term. - Ron