How to choose a content management system



Softare quality

All software today is built upon other people’s work. When assessing a CMS product, the key criterion is not whether it is open source, but rather the quality of its components.

The day 11 lines of code nearly broke the internet

In March 2016, thousands of software projects were knocked offline due to a conflict between a developer of a critical yet obscure component; a messaging app company, which had a trademark on the software component’s name; and npm, a widely used package manager for javascript projects. You can read more about the conflagration here or here or here, but what interests me here is not the case itself, but what it shows about software development today, especially content management systems. 

How, when evaluating CMS software, should we assess quality? 

It’s turtles all the way down

Component-based engineering is a critical paradigm for software development. All kinds of services, resources, functions and more are available to the modern developer. Developers universally use components in well-defined tasks, like charging a credit card or answering a request for a web page.

Component design is seen in CMSes, too, through plugins, modules, and templates. Drupal calls them modules, WordPress calls them plugins, Joomla calls them extensions. They all extend the CMS to handle new kinds of content, features, and business logic. The linked libraries show each product has thousands, if not tens of thousands of components. 

CMS components vary in quality

If it’s turtles all the way down, it’s the turtles below that we’re counting on to hold everything up. But components come in all shapes, sizes, and levels of quality. Some are so excellent and well maintained, they become part of the product itself. Others were developed for a specific purpose and then abandoned. How can you evaluate component quality? 

Assess documentation

Code without documentation is like a forest without trees. Developers wonder, how does this work? Why doesn’t this work now? CMS component libraries are littered with undocumented code, or documentation that is promised as something to do in the future when everything is done. 

Consider support

Plugin libraries suggest a community of support. Yet I’ve often found their forums littered with questions about bugs, usage, or installation, with no response at all or only other complaints. Contrast this to a well-supported project: Homebrew manages software packages on MacOS. The vitality of the open source project is apparent on the contributors page, which shows a large community of contributions and sustained development over many years. 

Determine fit

Why are there dozens, if not hundreds, of WordPress calendars plugins? Because components are developed for specific purposes, and those purposes vary immensely. We often encounter CMS projects where plugins do not fit. For example, a calendar doesn’t handle repeating events. Or an event list doesn’t handle upcoming, past, or soon to close events in the right way. Or content archives that must be handled manually. In all these cases, a component that might have been a perfect fit for a different case gets shoehorned into a project that’s just different enough to cause pain. 

Evaluate development method

“Django projects are built up to fit the organization, whereas Drupal developers often talk about having to remove or work around the things they don’t need.” — scot hackerDrupal or Django? A Guide for Decision Makers

Quality software is built to fit, and that starts with understanding the data models — the Articles, Programs, and Events; or Classes, Schedules, Students, and Registrations — that an organization creates or provides value to. Data models have interdependent relationships, attributes, and business rules. Great fitting software is built up, from models, as opposed to built down, from components that “mostly do the job” but need features removed. 

So what is software quality? 

Wikipedia has a great article on software quality, but for the purposes of evaluating a CMS, I define quality as: 

  1. maintainable: tested, well structured, documented and clear; 
  2. transferrable: can be given to another team for ongoing development; 
  3. adaptable: can be changed to fit new problem variations and not tied to a specific solution; 
  4. secure: is written to reduce vulnerability risk due to poor practices or architecture; 
  5. fit: well designed to solve the problem at hand. 

Conclusion

Since it’s components all the way down, CMS assessment should not be on the basis of open or closed source products. Instead, assessments should be performed on the needed components. To be successful, a software team must carefully select components based on only on solving a problem, but also quality. 


The Neoteric CMS is built on the open source Ruby on Rails framework, with highly reliable open source components and extensively tested, modular custom code. It is cloud-hosted at Heroku, the best platform for building software with modern architectures, with 99.996% uptime. Interested to learn more? Contact us today.