For the past few years here at The Brick Factory, we’ve fully embraced using open source content management systems (CMS) – particularly Drupal and WordPress.  Why?  Put simply: They work.  By using them we don’t have to start from scratch on building a web site and can focus on fine tuning the design and functionality of the site for our clients.  Although they don’t cost money to use like a commercial CMS, they do have costs.

Although we acknowledge these costs, we still believe that Drupal and WordPress are more economical than using a commercial CMS or building something from scratch since these same costs also exist for those options.

Here are some costs associated with Drupal and WordPress:

Creating a design – While there are many themes available for purchase, most organizations and businesses require a design that fully incorporates their existing branding.  This requires the work of graphic designers who can design an interface and then apply it to the CMS.

Configuring functionality – There are plenty of modules for Drupal and plugins for WordPress; they add specific functionality to a CMS.  However, they sometimes malfunction, conflict with other aspects of the site, or are unstable prototype versions.  That’s when it is nice to have some programming know-how on your side, and unless you’re a programmer, you likely have to pay one to help out.

Staying up to date – Open source CMS communities regularly update core CMS code and the associated modules and plugins.  These updates fix bugs, add and enhance functionality, and plug security holes.  Sometimes these updates require minimal effort, but sometimes they break aspects of the site and design.  Thus, programming and design expertise come in very handy sometimes.

Optimizing performance – Depending upon the complexity of a site, it can take some sites longer to load than others.  Sometimes this complexity is not tied to functionality or content, this can involve the configuration of the entire CMS.  There are plenty of caching options for both Drupal and WordPress, but enabling caching can sometimes break functionality on the site.  Thus, it requires attention to fine tune caching.  Further, I have seen plenty of CMS driven sites where the owner – not the developer – piled on modules or plugins but then either didn’t use them or configure them correctly.  An enabled module or plugin doesn’t have to be used, but even if it is not used, it does affect the performance of the site if it is enabled.  Optimizing site performance – through caching and module/plugin management, for instance  – can sometimes take advanced technical knowledge, and unless you have it yourself, you have to pay for that expertise.

Handling the “Oh, Crap!” moments – Recently I made a seemingly very minor configuration change to a module on a client’s Drupal site.  When I hit the save button, I got a blank white screen; the site was down.  It took our systems administrator about 15 minutes researching and working on the database to get the site partially back up.  It took him and a programmer another 45 minutes or so to get the entire back up again.  The process required yanking the module out via ftp and then figuring out how to remove any settings in the database since enabling the module again without clearing the database would take the site down again.