Acquiring a CMS

Before we discuss features and get into the specifics of CMS architecture, let’s take a brief detour into the software business. In order to start working with a CMS, you need to get your hands on one.

Your search will usually begin from one of three starting points:

• Software: If you begin your search by looking for CMS software first, vendors will likely introduce you to one of their “partners” to assist in scoping the implementation, or they might offer their own professional services group for that (assuming they have one).

• Integrator: If you begin your search by looking for a CMS integrator (a developer or firm that installs and configures CMSs), they will usually specialize in one or more CMSs and will invariably attempt to steer you toward those systems. They would obviously like to implement a system with which they’re comfortable, and/or for which they’ll receive a markup, discount, or kickback from the vendor.

• Selection consultant: If you begin your search by using an independent CMS selection consultant, they will help you select a system based on your requirements and desired features, presumably free from influence or bias. The drawback is additional expense and likely additional time, but as a participant in many formal CMS selection processes, I can validate that it’s money and time well spent.

Those three types of searches should identify one or more CMS vendors, each representing one of the following paradigms of acquisition:

• Open source – you download and install
• Commercial – you license (purchase) and install
• Software-as-a-Service (SaaS) – you “rent” and use
• Build your own – you develop from scratch, within your organization

Any of these will provide you with a working CMS with which to begin implementation. However, lurking within each these seemingly straightforward options are countless variations, idiosyncrasies, and paradigms.

Open Source CMSs

There are likely more open source options available in CMSs than in any other genre of software. The most commonly used platforms in the world – systems like WordPress, Drupal, and Joomla! – are all open source. (In fact, almost all LAMP-stack systems are open source, demonstrating the close relationship between that technology stack and the open source philosophy.)

An examination of the intricacies of open source is beyond the scope of this book ,but a key point is that open source CMSs are typically free to use without paying a license fee. These systems all have a website where you can download the software, and you can then install it in your own environment and use it.

That said, remember that the license cost is not the sum total of your expenses. You will still need to:

• Host the software
• Integrate the software

Some open source CMSs are very easy to host on commodity shared hosting accounts costing less than $20/month. Other systems require more libraries, computational power, and permissions than the average hosting account offers, and therefore require a self-hosted environment with complete control.

When it comes to ease of integration, open source software also varies greatly. Some projects are mature enough to have significant documentation and bootstrapping installers to get you up and running quickly. But these features are often developed late in the lifecycle of open source software, so many younger systems fall quite short in these areas. Additionally, there’s often a clear developer bias in open source software (“written by developers, for developers,” as mentioned in Points of Comparison), and a general feeling that since no one is paying for it, users can just figure it out.

Given the lack of a license fee, open source systems are used quite often in smaller projects that don’t have the budgets to pay for a license. This means that applicability to much larger projects might be questionable. For every Drupal, there are a hundred other systems that have never been asked to scale much larger than a small to mid-sized marketing site or blog.

Ubiquitous use does present enormous advantages in community support. Many open source systems have thriving user communities that are available to answer questions quickly and accurately. However, this can be offset by the lack of professional support (which is sometimes available at cost – see the next section), and the lack of a community’s ability or willingness to solve more intricate questions.

And, as mentioned previously, open source CMSs are tilted heavily by platform. LAMP systems are almost always open source, while there are comparatively fewer .NET and Java systems.

Business Models of Open Source Companies

Many open source CMS products have full-fledged companies behind them, which either actively develop the software internally (for example, eZ and its eZ Platform CMS), or guide and manage the community development (for example, the Drupal Association). Additionally, many open source systems have commercial companies lurking around the edges of the community to provide paid services for those systems (for example, Acquia, which was founded by Dries Buytaert, the creator of Drupal itself).

To pay the bills, companies behind open source software operate on one or more of the following models:

• Consulting and integration: No one knows the CMS better than the company that built it, and it’s quite common for vendors to integrate their own software from start to finish, or to at least provide some higher-level consulting services with which to assist customers in integrating it themselves.
• Freemium: The basic software is free, but a paid option exists that allows access to more functionality, a larger volume of managed content, or scaling options, such as the ability to load-balance. Sometimes the free product is quite capable, and sometimes it’s just a watered-down trial version meant to steer users toward paying for the full product .
• Hosting: Many vendors offer “managed hosting” platforms for the open source systems they develop. The purported benefit is a hosting environment designed specifically for that system, and/or system experts standing by in the event of hosting problems. Note that the actual value here is a bit questionable, as there’s rarely secret information known only to the vendor that allows them to tailor a hosting platform to one CMS over another. Any available performance enhancements or configuration tweaks could just as easily be implemented by a savvy customer. The value is often just peace of mind that an “expert” is in charge.
• Training and documentation: Open source software often lacks in documentation, and developer bias can lead to idiosyncratic, API-heavy systems. For these reasons, professional training can be helpful. Many vendors will offer paid training options, either remote or in-person. Less commonly, some offer paid access to higher-quality documentation.
• Commercial licensing: Depending on the exact license, changes to open source software might have to be publicly released back to the community . Some vendors will offer paid commercial licenses for their open source systems to allow organizations to ignore this requirement, close the source, and keep their changes to themselves.
• Support: When community support falls short, professional support can be helpful, and some vendors will provide a paid support option, either on an annual subscription or a per-incident basis.
• Additional testing and QA: Some vendors offer a paid version of the software that is subjected to a higher “enterprise” level of testing and QA. In these cases, the free or “community” version is presented as lightly tested and nonsupported, while the enterprise (paid) version is marketed as the only one suitable for more demanding implementations.

Many of the paid advantages offered by open source vendors are an attempt to address the largest fear companies traditionally have of open source: lack of accountability. Companies want a “neck to choke” if something goes wrong. A CIO wants a phone number to call, product documentation to download, a trainer to fly on-site, and a single point to hold accountable for any problems.

Many open source companies have entire business models built around addressing this need. In most cases, these advantages are never actually invoked or acted upon, but exist to provide informal peace of mind, or to meet formal audit or regulatory requirements.

Commercial CMSs

Like with any other genre of software, numerous commercial CMS vendors are available and eager to sell you a license to use their systems.

After our discussion of open source, you may be wondering why anyone bothers purchasing when so many options are available for free. First, a commercial company presents itself as a more formal business entity than an open source community, which is important to some organizations (we’ll discuss this further shortly). Second, commercial vendors generally adhere to a higher standard of quality and functionality, as they have to keep paying customers happy and they have incoming revenue from license fees to fund professional development.

Like any generalization, this is not always true, as some open source systems are mature and well-used enough to compete against any commercial offering. Conversely, some commercial vendors are terrible at QA and sell products riddled with bugs. But as a general rule, it holds.

Additionally, in the last five years, there has been a distinct separation between open source and commercial CMSs along the lines of marketing features. While the open source development community is obsessed with solving problems of content management, the commercial world has moved on to content marketing, which are the tools and features that help enhance your content once it’s published.

It’s been said that open source CMSs are made for the CIO (chief information officer), while commercial CMSs are made for the CMO (chief marketing officer). This largely holds true in how the systems are marketed, with the commercial sector concentrating their selling solely on the marketing departments of their customers, while open source providers are more interested in trying to capture the hearts and minds of the IT staff.

Like with the open source offerings, platform distinctions are clear. Very few LAMP systems are commercial, while many of the .NET and Java systems come with price tags.

Finally, remember that the numbers under discussion in this section apply only to the license costs. Buying a commercial CMS doesn’t liberate you from the costs of implementing it – you will still need to find (and pay) someone to install, configure, and template your system. In some cases, the commercial vendors provide an option for this (so-called “professional services”), and in other cases they have a “partner network” of integration firms who are experts in their systems and willing to integrate for a fee.

Licensing Models

Commercial systems rarely come with a single, simple price tag. Vendors usually have a byzantine system of formulas and tables to determine your final price, with the overall goal of forcing well-heeled customers to pay more, while not losing smaller sales to customers with more modest budgets.

At this writing, the “mid-market” is roughly defined as systems with a list price (the stated “official” price) between $20,000 and $80,000, and most everything is valued in relation to this – vendors are categorized as being either above or below the mid-market.

The range of commercial pricing is vast – Perch sells for $79, while Adobe CQ can’t be had for less than $250,000 and large installations will easily cross into the seven figures.

Here are the more common ways of determining pricing:

• By editor/user The system is priced by the number of editing users, either per seat or concurrent. More rarely, the system is priced by the number of registered public users, but this usually only applies to community or intranet/extranet systems where it’s expected that visitors will be registered.
• By server The system is priced by the number of servers on which it runs (or, less commonly, on the number of CPU cores). This is quite common as larger installations will require more servers, thus extracting a higher price tag. With decoupled systems where the delivery environment is separated from the repository environment, this can get confusing: Do you pay for repository servers or delivery servers? Or both?
• By site The system is priced by the number of distinct websites running on it. This can be blurred by the vagueness of what constitutes a “website.” If we move our content from “microsite.domain.com” to “domain.com/microsite,” are we still under the same website and license fee? What about websites with different domain names that serve the same content (branded affinity sites, for instance)? What about alternate domains for different languages (“en.domain.com” for English and “de.domain.com” for German)?
• By feature The system is priced by add-on packages installed in addition to the core. Almost every commercial vendor has multiple features or packages that can be added on to the base system in order to increase value and price. These range from ecommerce subsystems to marketing tools. Note that each one of these features might also be licensed by user, server, or site, making their prices variable as well.
• By content volume The system is priced by the amount of content under management. This is less common than other models, as the number of content objects managed is highly dependent on the implementation. For example, should you manage your blog comments? Or can you move them to a companion database (or external service, like Disqus) and reduce content volume by 80% or more?

Most systems are priced on multiple axes – for instance, by a combination of editors, servers, and sites. Final pricing can often be impossible to determine without considerable consultation with the vendor’s sales department.

Vendors attempt to price for the value provided and the customer’s ability to pay. The methods listed here are essentially all proxy models for what a vendor might really prefer: to have inside information on how much a customer is able to pay, and price their product at that number. Since no customer would ever allow that, vendors use metrics like number of editors or sites to provide some rough estimation.

Software Subscription

One thing you can always count on with commercial vendors is the need to pay for software subscription, which is a continuing annual fee based on the purchase price. This is not at all unique to CMSs – almost all enterprise software is priced similarly.

Subscription is usually a percentage of the purchase price – typically 18% to 22%. The first year is often built into the purchase, but the customer will be invoiced on the purchase anniversary date every year after.

At an average of 20% per year, this adds up quickly. Simple math will tell you that you will effectively “rebuy” your CMS every 4 – 6 years.

Whether or not you have to pay this fee varies by vendor. With most, you can simply stop paying the subscription at any time and continue to use the product, but you will lose all the value-added benefits that your subscription fee grants. With most vendors, those benefits are some combination of the following:

• On-demand support
• Upgrades and patches as they are released
• Free licenses for development or test servers
• License management, in the event you need to license new servers or sites

The fear that keeps customers paying subscription fees is that they might be stranded in some situation with a problem they can’t solve or a critical security bug they can’t patch. Vendors play on this fear by forcing customers to “catch up” on their subscriptions if they stop paying and then want to restart, in order to prevent customers from only paying for subscription when they need it.

For example, if a customer stops paying the subscription fee after year 1, and has a problem in year 3, the vendor will require retroactive payment for years 2 and 3 in order to restart the subscription (and sometimes with an added penalty). In some cases, vendors will force customers to repurchase the entire system from scratch.

Software subscription has become so ingrained in the enterprise software industry that few customers question it. Vendors simply require it in the sale of their systems, and customers expect to pay it.

Subscription revenue is the engine that keeps many vendors in business. If their new license sales ever slow down or stop completely, they still have a large cushion of subscription-paying customers to keep the lights on. This continuing revenue is critical to their viability and valuation, and subscription is sometimes more important to them than the initial license sale itself.

Software-as-a-Service

Software-as-a-Service (SaaS; pronounced “sass”) used to be quite a clear and simple proposition: rather than purchase and install a CMS, you simply paid a monthly fee and ran your website inside a larger system managed by the vendor. You became one of many customers running their websites inside this same system.

This is known as “multitenant” software. Whereas purchased and installed software is “single tenant” – you are the sole occupant, much like in a single-family home you built yourself – multitenant software is like an apartment building in which many people live.

The purported benefits are quick ramp-up time and no hosting issues. Indeed, the system is already running and just waiting for you, and since it runs on the vendor’s servers, you don’t need to worry about any of the headaches that go along with infrastructure management . SaaS was “cloud” before that term became common.

Another claimed benefit is to always be on the leading edge of versions. Since the vendor runs the hosting environment, when they release a new version, the customer gets it right away. Indeed, “releasing a new version” is synonymous with upgrading their customers, since that’s what has to happen to constitute a “release.”

CMS companies were early entrants into the cloud paradigm, and when vendors like Clickability and CrownPeak came on the scene in about 2000, this model was new and original and provided clear benefits for customers who didn’t want to install and manage the software themselves. What happened in the intervening years is that the market changed, and the difference between true multitenant SaaS and everything else has gotten very blurry.

Today, “purchase and install” (often referred to as “on-premise” or “on-prem” when comparing to SaaS) is just one way of getting open source or commercial (non-SaaS) software. If you want either of those options but don’t want to host yourself, there is a large ecosystem of vendors willing to install and host anything for you. In effect, many vendors will become SaaS vendors if that’s what you want.

The “instant on” feature of SaaS was further marginalized with the advent of server virtualization and computing grids like Amazon’s EC2 and Microsoft Azure. You can now get an installation of almost any CMS in less than an hour. These systems aren’t multitenant, but offer the same benefits of minimal ramp-up time and third-party hosting.

This raises the question: just what is SaaS? Is SaaS defined simply as when a vendor can give you an instance immediately and also provide the hosting environment? If so, then almost any CMS can be purchased and managed in such a way that it fulfills these criteria.

Or does SaaS refer only to the true multitenant systems we discussed previously? If so, then these systems are becoming less common at the higher edges of the market (in terms of price, capabilities, and complexity of integration), and more common at the lower edges. Vendors like WordPress.com, Drupal Gardens, and Squarespace offer “unattended” multitenant CMSs where you can get a fully content-managed platform in minutes with nothing but a credit card and without any human interaction. If you can live within the functional restrictions and don’t need much customization, these systems might be exactly what you need.

However, at the enterprise level, where customers require significant customization, SaaS CMS vendors are struggling. Some still exist, but their value proposition has dwindled precipitously. Many enterprise SaaS vendors are offering a lower monthly fee and comparing that to the six- and seven-figure licensing costs of purchased systems. Traditional commercial vendors have responded by offering to “rent” licenses, where customers pay a monthly fee for the license and lose it when they stop paying. (This is also valuable for customers who might need to bring up extra sites or servers for a limited time, in response to temporary load.)

If you’re considering multitenant SaaS, several questions become important:

• Is it appropriate for your industry? SaaS systems tend to group by the vertical in which they serve. For instance, OmniUpdate traditionally services higher education and HubSpot specializes in smaller, marketing-heavy websites. This enables these vendors to develop features common to those industries that will be used by multiple tenants of their systems.
• How much control do you have over the system? To what extent can you integrate with other systems or inject your own business logic? Since these systems are multitenant, vendors are leery of allowing significant customization, lest this destabilize the larger system for other clients. Some vendors will offer a dedicated, “sandboxed” environment in which you have more control, but this raises the question of how you’re now any better off than you would be if you installed a CMS yourself.
• Who can develop the website? Some vendors might require that template development or other integration be performed by their own professional services groups. This is common in SaaS systems that grew out of the in-house CMS of a development shop. In some cases, the subscription fee to use the system is simply a minimal gateway to enable the vendor to generate professional services income.
• If you part ways with the vendor, what happens to your content? Can you export it? In what format? What about your templates, which contain all of your presentation logic? Can you get that information out? Vendors in all software genres are notorious for lock-in, in order to prevent customers from leaving. Wise customers will evaluate the process for leaving a vendor as a system feature like any other.
• Are you considering the CMS on its merits, or just because it’s SaaS? Don’t engage with a SaaS vendor solely because they offer their software as a service, especially if you’re not particularly fond of the software itself. If SaaS if what you want, there are numerous options to get a SaaS-like experience from software you might like much more.

In the end, what once was a clear market for SaaS vendors has now been muddied considerably through changes in technology and business models. If the idea and benefits of SaaS are attractive to you, understand that almost any CMS vendor is now willing to engage in a model that effectively emulates the SaaS model that used to be unique to a handful of vendors.

Build Your Own

Like any other software, a CMS can be built inside your organization by your own development team. In some senses, a CMS resembles any other data-driven application, and it’s not difficult to build a simple CMS fairly quickly.

There are several common justifications for this, including:

• An in-house CMS doesn’t require a license fee (clearly, this is rendered moot by open source options, but it’s still quite common in project justifications).
• You’ll be experts in the usage of the resulting system and will not have to suffer the learning curve for an existing system.
• You will only build the needed functionality, avoiding software bloat and unnecessary complication.

On deeper analysis, few of these reasons withstand scrutiny. Often, the project is justified based on a very superficial understanding of the needs of the organization or the overall discipline of content management. While it’s possible to generate quick wins, the initial thrill of progress wears off too quickly, and the organization eventually finds itself rebuilding large pieces of core CMS functionality that other systems have long since solved.

From the outside, a CMS looks like a simple exercise in editing and publishing content. But get deeper into the project, and editors begin asking for features like versioning, multiple languages, workflow, multisite management, etc. These functions can be deceptively complex to develop – even more so when they have to be backported into a running system.

CMS development tends to “hockey stick” over time. It starts very quickly and development teams make huge strides early, often having a simple, workable proof of concept in a matter of weeks or even days. Simple CRUD operations (CReate, Update, Delete) are very quick to implement, especially with modern development frameworks.

Other features, however, such as content aggregation, editorial usability, and especially advanced marketing features, will cause development time to shoot skyward and forward progress to drop to a snail’s pace. It wouldn’t be surprising to spend as much time implementing a minor marketing feature as you did building the entire content editing interface.

A subtlety is that many of the problems involved with building a CMS are logical and behavioral, rather than technical. Vendors working in this space have the benefit of years of experience with editors and how they work with content. There’s often an “entry fee” of implementing a feature wrong two or three times before finally getting it right. If you build something from scratch, you’re often going to pay this fee every time you expand the system.

Over years of work, the developers of existing CMSs have learned how editors think and what things they want to do. This is critical, because knowing how to accomplish something technically is often not the real problem. Rather, the problem is knowing why the editor wants to do it. The underlying reasons for this can drive development decisions in ways that only experience will reveal.

Additionally, in-house CMS efforts are often developer-led, and developers tend to treat content as data, not as a business asset. To a developer, a page of content is simply a database record like any other, not a marketing asset designed to generate revenue. As such, marketing, optimization, and enhancement features often take a backseat to developer-centric features like data management.

Eventually, developing the CMS itself begins to take more time than solving the organization’s core content problems, which the CMS was originally needed to remedy. Additionally, the organization realizes it has invested far more time developing the CMS than it would have ever spent becoming an expert in an existing CMS.

The resulting software can be idiosyncratic and unstable. It’s also unknown outside the organization, resulting in an inability to find outside contractors and creating a significant training curve for new hires.

Finally, the system is “locked in,” meaning it has been developed to service the stated requirements and nothing more. While this sounds like a sound development practice, some additional features beyond what the editors immediately need are often helpful for experimentation and understanding the scope of what’s possible.

Typically, most organizations cross a “line of regret” where they’d like to rewind and choose a pre-built option. It’s not common to see a positive result from an in-house effort over the long term.

However, there are situations where it might be the right choice:

• When the content model – more on that in@link:content-modeling – is very specific to the organization. (If all you publish is cat videos, building a management platform might not be difficult.)
• When the management needs are very simple and future development plans are absolutely known to be limited
• When the CMS is built by heavily leveraging existing frameworks to avoid as much rework as possible (e.g., Symfony for PHP, Django for Python, Entity Framework and MVC for ASP.NET)

If your organization is pushing for an in-house CMS, don’t begin until you’ve carefully reviewed the open source options available. Ask yourself this critical question: if we spent as much time developing expertise in Platform X as we would building a CMS from scratch, would we be better or worse off?

There are very few situations where an honest answer to that question would indicate that you should build your own CMS.

Questions to Ask

When considering the acquisition of a CMS, the combination of variables make your options almost limitless. The following questions might help give you some perspective:

• Where will the final CMS reside? Are we hosting it ourselves, or having someone else host it?
• If we’re hosting it ourselves, does our IT department have platform limitations we must abide by?
• What is our capacity for a license fee? How much of the project budget can we carve out for this? Do we need to consider a lower fee, payable over time rather than all at once?
• Have we budgeted for continuing subscription costs in the years after launch?
• Are we going to integrate the CMS in-house, or do we need to find a partner firm to do this?
• Do we have the skill and capacity to build a CMS in-house? Can we manage maintenance and feature upgrades along with our other workload?

Finally, it’s important to note that none of these questions is perhaps the most important of all: will the system under consideration meet the functional needs of our organization?

Do not invest in a system just because the method of acquisition seems easy. An open source system that’s free but doesn’t offer marketers the tools they want isn’t good value – you will save on a license fee, but invest money in an implementation that will not provide the result you want. Along the same lines, a commercial vendor offering a good deal on tools you will never use is simply helping you throw money away.

The method by which you acquire a CMS is but one aspect of a much larger question of matching need to platform. This is the topic we’ll discuss in cms-feature-analysis.