White Elephant Alert! Why A CMS Is A Terrible Reason To Hire A Dev Shop

Posted in Content Management Systems, Web Development

Recently, we sat down with an advertising agency to chat about business possibilities. As CTO at aimClear, my focus of the conversation naturally gravitated toward technology. I was intrigued to hear about a content management system (CMS) that was being deployed by their development shop. Our agency friends expressed much pleasure in the CMS but did not know its name, which led me to dig deeper.

After perusing their site, we were able to quickly confirm that the CMS in question is a repackaged open source-based, LAMP-stack solution. Pretty common in our space. However, still no mention of the specific CMS being deployed – not surprising since their own client didn’t have a strong sense of exactly which solution was being used. The site did note that they don’t hold their clients hostage, and that users are free to take the source code elsewhere, if desired.  Great – thanks! It’s worth noting this is a given with General Public License (GPL) and most other open-source licensing. No special favors here.

The hang-up here is understanding what it would take to execute if a client decided to take the code elsewhere Without disclosure of the actual CMS in use, how is one to prepare for such a change? What expertise would internal staff or another development shop need to take control, move the site to another server, and resume development? All are critical questions to consider prior to diving into a repackaged CMS solution offered by any development firm.

When evaluating an agency’s CMS of choice (or even if choosing one for yourself) there are some key considerations to factor into your decision-making:

Keys to Evaluating a Repackaged CMS

1) Know which solution is being offered. Whether it be WordPress, Drupal, ExpressionEngine, or some other open-source CMS, know what you’re getting into from the start. Resource allocation and contingency planning require intimate knowledge of the platform at hand. Save yourself a headache down the road and do your research upfront.

2) Understand the strengths and weaknesses of the selected CMS. Core functionality and plugin availability are the two primary differentiators when evaluating a CMS. Evaluating the strengths and weaknesses of each against your project requirements provides a clearer view of which solution can meet your needs with minimal customization – now or in the future.

3) Research community engagement. Here is one area where size doesn’t matter. In fact, many bad CMS solutions have very large support communities – often for the wrong reasons! The most important aspects to consider when evaluating the community are:

  • Participation from within the organization: Does the organization itself participate significantly with the community, or is it a pure peer-help-peer environment? Look at some threads around topics that are important to your project.  A look at Magento’s forum shows the community is clearly (and sadly) left to fend for itself, largely devoid of official Magento input. Countless threads are rife with ongoing complaints of lack of direct participation on behalf of the brand.

Forum post indicating low participation from within the organization:

Screen Shot 2013-02-05 at 10.49.09 AM

Forum post indicating healthy support community:

Screen Shot 2013-02-05 at 11.06.09 AM

  • Presence of solutions, not just questions. Reading through community threads is also a great way to determine if the community is solving problems or if they’re left hanging with questions. A look at Drupal’s community forum reveals an encouraging and functional community that is able to resolve issues and collectively move forward with plugin development. Each plugin has it’s own support forum, providing for the community a clear path to communicate with those involved. This surely makes for efficient and effective issue resolution.
  • Willingness to expand development into new areas for the good of the community rather than just for profit. Some CMS solutions perpetuate an open-source approach to plugin development, allowing all members of the community to benefit from free add-on modules. Others don’t. Take one look at Joomla and you’ll quickly see that plugin developers are clearly in the game for profit. While some may look at this as a benefit, our experience tells us that paying for a plugin doesn’t guarantee a better product or more responsive support.

4) Request details outlining the repackaging. This is a critical consideration that is often overlooked. If a CMS is repackaged, it is of the utmost importance to know exactly what the distribution entails. Start by asking the agency if any core code was edited or overridden. Overridden is a key term here, as many CMS solutions allow developers to override core code without actually editing the core files. If core is clean and unobstructed, then it’s time to ask if custom modules or plugins have been installed, and whether those will remain available if the site is taken elsewhere. Finally, verify whether any of the customizations conflict with the extendibility of the CMS going forward. Module conflicts are common when third party plugins are used. Even if the answer here is a resounding “no,” understanding the touch points of the custom plugins will help identify possibly conflict areas in the future.

Final Thoughts
Selecting a CMS is no easy task. Each project has unique requirements and characteristics. Next time your agency tells you, “We have our own CMS,” don’t sit in the dark. Find out what content management system has been repackaged, then dig deeper to understand exactly what the packaging entails and how it may affect your business in the future.

© tiero – Fotolia.com

  • john andrews

    Hmmm… really? For me, stability and security are two important aspects for any CMS (not just “core functionality” and “plugin availability”). I often see that consideration of security and stability is often skewed by availability of seemingly valuable plugins, when in fact said plugins are from unreliable (and unaccountable) third parties.

    A single insecure plugin can breech the security of even the best open source CMS.

    In general, I’d much rather see a qualified tech team produce a secure and stable CMS they can reliably control, manage, and extend, over something like Drupal or WordPress. I’ve seen as many “out of control” Drupal customizations as I have insecure WordPress installations.

    By the same token, I think it’s unreasonable to suggest “Save yourself a headache down the road and do your research upfront” when it comes to open source platforms, tech stuff, and code. That’s precisely why we have so many terrible Joomla websites — clients cannot be expected to “do their own research” and when they do, they make poor choices.

    I have a good idea.. why not find and hire a really good tech team and let them choose (and configure and manage and support) a CMS for you? It’s the smartest way to go in the long run, if you actually are executing a meaningful publishing plan. Of course you cede some control and or assume costs of switching to another tech team down the road (if that were to become necessary), but you took that on in exchange for a good tech team that would work for YOUR interests, not the interests of open source community or plugin publishers or ease of re-selling the work to other clients.

    • Joe Warner

      John you make some excellent points. My SysAdmin is probably ready to slap me for leaving out mention of both stability and security. So often overlooked – yet no technical solution should be considered without. Each can be undermined by a single plugin or bad line of customized code.

      As you mention, many clients can’t begin to evaluate these systems on their own. However, I disagree that clients can’t successfully perform their own research. Part of doing research is reaching out to other resources that can help answer the unknowns. Someone has to be asking the questions. Precisely the point of this article.

      Hiring a stellar tech team and building a stable, secure CMS is a great choice. I wish more clients would go this route. In our experience, the custom CMS projects we’ve been involved with have been some of the most successful we’ve seen to date. While a great tech team can select a CMS and deploy with success, doing so goes beyond the technical. Someone on that team must be able to relate to business needs and opportunities. They must understand the full breadth of business requirements and have the ability to envision future use to truly succeed. Have you ever run into issues allowing a tech team to choose, configure, manage, and support a CMS for you?