The State of the Headless CMS Market

Headless CMS is about to “tip.” It’s been gaining steam in the last few years, and 2017 looks to be its big year.

However, the market is vague and prone to definitional bias – in some senses, “headless” is whatever someone says it is. Additionally, systems exist somewhere on a range of purity and allegiance to a mythical “headless ideal.”

This post is an attempt to put some structure on the market, and define the options which (arguably) make it up. I’ve defined both specific headless offerings and “headless-ish” architectures.

For each, I provide some examples, but I clearly don’t know about every CMS in the world. This post is not meant to provide an exhaustive list. The examples are merely illustrative and a source for more research.

I’ve listed the categories in descending order of “purity,” meaning the extent to which the model aspires to be a pure headless system (and, yes, even what composes the ideal is entirely arguable).

What is Headless CMS?

“Headless” is an architecture or – even more loosely – a paradigm or belief. If we consider the “head” of a CMS to be the subsystem by which content is finally presented to the end consumer, a headless CMS is what you have when this subsystem is “lopped off.”

In a headless CMS, you have modeling and editorial tools to help you describe, create, edit, and otherwise manipulate content. But the concept of “publishing” content just means, “make it available via an API.” A headless CMS is a “content-focused datasource,” from which you can build content-based applications.

Headless is not the same as “decoupled.” A decoupled CMS is concerned with presenting content, it simply pushes that content into a delivery environment, separate from the management environment. That separation of delivery and publishing is something that headless and decoupled CMSs share, but the difference is that a decoupled system concerns itself with what happens in the delivery environment – for example, it has some concept of templating – while a headless system doesn’t. A headless CMS assumes developers have content delivery handled via other means.

A decoupled CMS is proactive – it prepares content for presentation and pushes it into a delivery environment. A headless CMS is reactive – it manages content, then just sits and waits for some process to ask for it.

Headless systems tacitly distance themselves from HTML and website-centric implementations. You can absolutely power a website from a headless system, but you can also power mobile apps, display advertising, business applications, etc. (See my prior post: “Use Cases for Headless CMS.”) Headless systems attempt to lay claim to “pure” content that can be repurposed and presented through multiple different mediums.

(Perhaps also read the definition of “coupling models” over at the Web Content Management Glossary.)

With that aside, let’s talk about what this market looks like as of this writing.

1. Pure Headless CMSs

Part of why the headless market is tipping is because “pure” players have entered it and are getting attention. They’ve defined the term and moved it from some improvised to something intentional.

Intentionality is an important point. If you’ve ever spent any time building a CMS, it likely consisted of an enhanced admin system to a relational database. The presentation of content on “the other side” was done through traditional methods (I first wrote about this model 13 years ago – CMS Administration vs. Presentation Languages).

In some senses, we were all building “headless CMSs” back in the day, before we got “more sophisticated” on the delivery side and moved on. This model was really the genesis of the modern CMS market. The difference is that vendors have now sprung up and effectively said, “This is okay. This is no longer a compromise. This is an effective paradigm of CMS, and we’re going to formalize and build on it.”

The leader here is likely Contentful, as it has funding, staff, and momentum. Contentful began as a system to store content for mobile apps (it was once called “Storage Room”), and thus had no web origins at all.

Like Contentful, Prismic is a hosted service, as is Butter CMS (seems to be blog-focused). Directus can be on-premise (it’s open-source, written in PHP) but offers hosted options for those who don’t want to manage it. (And new ones pop-up all the time: I just stumbled on Elemeno while writing this post…)

Also in this category, we have Gather Content. This has traditionally been a pre-implementation content aggregation service (a market it basically invented). However, Gather Content is seeing more and more usage by organizations using it for core content management, since the line between their original market and headless CMS is blurry. If you’ve structured, aggregated, and cleaned all your content in preparation for a CMS move…then you might already have a CMS, accidentally.

Also of interest is Kentico Cloud. You might think this should go below as a traditional/cloud hybrid, but it actually has zero relation to the Kentico CMS. It’s a scratch code, ground-up build of a new product that shares nothing with their existing CMS except the name.

2. CMSs with Specific Headless Subsystems

This is an odd category. What I’m including here is traditional CMSs complete with presentation systems, but that include some specific gesture towards headless usage, and which could be used headlessly by specific design, rather than just re-purposed to a headless use case.

The new release of Evoq (v9) will include the ability to manage content in a local installation and have that content pushed/synced to their cloud environment, where it can be accessed remotely by other processes. This is a unique model which ends up as a hybrid – clearly, serving a website is the primary purpose, but the model concedes that might not be the only purpose and provides a framework for access.

Ingenuix occupies a unique space as perhaps the only decoupled .NET CMS, so it’s accustomed to heavy remote API usage – if something happens a decoupled delivery environment that needs to be pushed “backwards” into the repository, then a remote API is how you do that. As such, Ingeniux has a separate middleware component called Dynamic Site Server (DSS) which you could conceivably use without bothering with decoupled publishing at all.

So, if there are so few vendors here, why include this category? Because I think we’ll see this more and more. I don’t think Evoq and Ingeniux will be alone here for long, and you’re going to see traditional vendors (the next category) adopt headless functionality enough to slip “upwards” into this space.

(A good example: one would expect the core Kentico CMS to connect to their cloud offering at some point, thus making that a hybrid as well. This is such an obvious pairing, that if they didn’t do it, it might feel a little odd.)

3. CMSs with Good APIs and Extensibility

This is where things get blurry and weird…

A lot of traditional CMS vendors are likely looking at the “headless” market with annoyance. Repurposing content out of a web CMS is not new – this is the essence of multi-channel publishing – and customers have been doing this for years now.

While almost all systems have local, language-specific APIs, many (if not most) systems also have remote REST/SOAP APIs to pull content from outside the CMS environment. In that sense, is this not also a “headless CMS”? By our prior definition it:

1. Models and manages content

2. Has no presentation component (for the specific act of pulling content through a remote API)

3. Is reactive, waiting for another process to retrieve content

Using a traditional web CMS through a remote API would look awfully like any pure headless CMS. Blend has done this with Episerver – a client accessed Episerver content via Ajax to power contextual help in their web application. And I’m hearing about “headless Drupal” more and more often.

Some vendors might have such a sophisticated remote API that they could conceivably not change a thing and simply start marketing themselves as “headless” and not be disingenuous at all.

Even if your CMS doesn’t have a remote API, some programming platforms make it easy to add this. My experience is mainly with ASP.NET, and I can attest that it’s absurdly easy (like, 10 minutes easy) to set up an XML or JSON endpoint to deliver content however you like.

Where you might run into problems is in more pedestrian things like licensing. Many commercial CMSs are licensed by website or, more abstractly, by consuming process. If you start scattering content around headlessly, a vendor might claim you’re violating the licensing agreement. It will be interesting to see how licensing adapts to this, either proactively or by customer demand.

Also interesting will be to what extent traditional CMS vendors alter their marketing to address the headless market. Some vendors are already marketing against related search terms. Here’s one such landing page from dotCMS touting the “API at its core.” Here’s another from Hippo taking the opposite tack: explaining why headless CMS is “wrong.”

I’m wondering how antagonistic or conciliatory traditional vendors will be with their marketing. I know of one vendor that refuses to promote their system as “headless” because it “helps the [headless] cause.” As more and more customers go headless, will the existing market align or distance itself?

4. Enterprise CMS

The “old guard” of content management is traditionally enterprise systems (ECM) like Documentum, Alfresco, Nuxeo, and even SharePoint. These systems are primarily concerned with managing content and have very little capacity for content presentation beyond the administrative interface itself. These systems are so management-focused, that most presentation functionality is only to make management and administration easier.

Many also include remote APIs to manipulate content, which raises the question of whether or not they fit the headless model? Content could easily be modeled and managed in something like SharePoint, then accessed externally through a headless layer like Akumina’s Interchange, on-demand and real-time.

The idea of this, however, might make ECM people a little nervous. ECM systems have traditionally been treated as “behind the firewall” systems, and they’re not normally built or secured for high-volume performance like public web serving. Web publishing out of ECM has historically been decoupled.

An argument could be made that you should put a public caching layer in front of this, which would fit the same model as something like Contentful that pushes to a global CDN, or some of the headless Drupal architectures we’ve seen which push content into an intermediate datasource (my experience was with Drupal pushing to Mongo, then that being pulled by a Rails app).

But does this blur the definition even further? If your back-end “headless” system is pushing into an intermediate layer (like you would do with ECM), then are we still headless, or are we really decoupled? Traditional decoupled systems have pushed HTML assets to the delivery environment, but pushing database records is not unheard of. I talked about that in an older article about decoupled CMS (still highly relevant to this subject) and I presented a couple CMS-to-SQL case studies just a few weeks ago.

Conclusion

All of these above might have brought us full-circle: any datasource might be considered as a headless CMS, depending on (1) how much you’re willing to ignore any built-in presentation systems, and (2) to what extent you consider an intermediate caching layer as part of the system itself.

Headless will remain a gray area, I think, defying strict boundaries. Systems will be “headless” to the extent that they fit the barest profile of that paradigm, can be re-purposed or modified to fit it, and the vendor markets them as such.

One traditional CMS vendor I talked to in putting this post together says the market will hinge on whether or not pure headless vendors pursue a blue ocean or red ocean positioning strategy. Will they attempt to fight it out in the same market as traditional CMS (red ocean), or will they attempt to embrace their differentiation and create a new, open market to conquer (blue ocean).

I suspect the latter is probably the wisest choice. But, I also know that a lot of vendors like a good old-fashioned street fight – in the world of technology, it’s a sadly rare vendor who’s willing to admit that anyone else does something better than they do. The history of this industry is littered with vendors wading into markets in which they had no business being. Time will tell whether vendors do the same here.