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:

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:

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:

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:

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:

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:

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:

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:

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:

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.

Footnote #1

Or for another reason no one talks about: implementing expensive software is often seen as a mark of significance among industry peers. People like being taken seriously at conferences, and system name-dropping happens more than anyone will admit.
Footnote #2

For an examination of the philosophy of open source software, I highly recommend link to The Cathedral & the Bazaar by Eric Raymond (O’Reilly).
Footnote #3

In reality, however, open source enhancements are rarely released, and most organizations simply keep their source code private in quiet violation of the open source license and philosophy. Therefore, this option is usually only attractive for companies with strict policies governing the release of open source changes.
Footnote #4

This raises the question of whether these companies are open source or commercial entities. eZ distributes eZ Platform, which is an open source content management framework. It also sells eZ Studio, which is a commercial interface and editorial management system – an add-on that makes eZ Platform work better. Does this make eZ a commercial or open source company?
Footnote #5

Actually advertised as “The really little CMS.”
Footnote #6

With the exception of “decoupled SaaS” models. In these architectures (which are not common), the management portion of the CMS is owned and hosted by the vendor, but it publishes content remotely into a delivery environment owned by the customer, via FTP, rsync, web services, or other methods.

This is item #4 in a sequence of 18 items.

You can use your left/right arrow keys to navigate