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:
Forum post indicating healthy support community:
- 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
