Where Content Management Is Going

Web content management is constantly in a state of flux. As a discipline, it rides on the back of the Internet itself, and as the Internet landscape changes, content management changes with it.

In writing this book, I’ve had to navigate the blurry line between what aspects of content management are foundational and unlikely to change (content modeling, for example) and what aspects are still being defined by the marketplace (marketing automation and personalization, to name but two). In five years, parts of this book will still be wholly relevant, other parts will be showing their age, and a half-dozen new chapters will need to be added.

As a preemptive strike, I’d like to look forward a bit and consider where content management might be headed in the future. This is a practical exercise in that I’d like you to be ready for what might be around the corner, but it’s also an exercise in perspective, as I want you to understand the axes and inflection points along which this industry might expand, to give you some sense of the elasticity of content management – the industry, the software, and the discipline.

Chapters like this are difficult to write because they’re always a combination of legitimate prediction, documenting the obvious, and unavoidably spinning the conversation in the direction the author would like something to go. While I think evidence exists for all of the following predictions, only time will tell how accurate they are. In five years, I’m quite prepared for someone to find me at a conference and mock me for how wrong some of them turned out to be.

Additionally, predictions like these inevitably involve looking back at history and making interpretations of what has happened in the industry. My preferences and opinions will show through here. If you have a long history in this industry, you will no doubt disagree with my perspective on some of what has gone before. All that said, let’s take a look…

Fewer Open Source CMSs Will Get Traction

The open source CMS market is already crowded. I’ve long maintained that developers like to architect new CMS platforms more than any other type of software. This is due largely to a quick ramp-up time (a lot can get done in a short period of time, before development inevitably hockey sticks upward), but it’s also due to the Lure of the Framework.

Developers simply love writing frameworks. We love solving problems that stay theoretical. And that’s basically what a CMS does: it solves a problem that doesn’t exist yet. Someday, the CMS we build will solve an actual problem, certainly. But initially, it’s just a framework for a website, and the developer receives all the joy and endorphin rush of “solving” that problem, while the associated problems remain safely hypothetical. It’s all of the fun with none of the accountability.

Ten years ago, there was a dizzying array of open source projects launching seemingly every week, each one claiming some new angle on the content problem. Every once in a while, one would get a toehold in the collective attention span of CMS developers and claw its way toward some user base of note. All the others would fall away.

But even getting that initial toehold is becoming harder and harder. So many products are available in the marketplace that developers are seemingly retreating into what’s well known as a defensive mechanism. Existing open source systems are exerting something of a gravitational pull, drawing in more and more developers while slowly getting larger and larger, which allows them to draw in even more developers.

Very few new open source platforms have gotten traction in the last five years, especially compared to the five years before that. Systems like Concrete5 and ProcessWire are still young, but have managed to knit together vibrant and dedicated communities.

In contrast, Microsoft’s open source CMS offering, Orchard, has been unable to gain much traction or mindshare, even with a gigantic community of ASP.NET MVC developers to draw from and relatively few open source options in that space. And there are dozens of other new entrants that will simply never reach critical mass.

The thing that sustains and grows an open source project is the ability to attract developers, and the excitement of a new system is quickly tempered by the lack of a community and installed base in which the system might grow and be tested.

What will give birth to new systems is the adoption of new web frameworks. Every time a new language or programming paradigm gets traction, a handful of open source projects will spin off of early projects written for those platforms.

At the time of writing, the new darling of web developers is Node.js. We will no doubt see a handful of CMS options for that framework in the coming years, and those frameworks will have the benefit of few competitors. They will sink or swim based on the adoption of the underlying platform – if it withers, so will they.

In no way am I predicting that the development of open source CMSs will completely dry up, but there is simply less and less reason to roll the dice on a new system. While some developers enjoy being contrarian and iconoclastic as a rule, most others will simply be seduced by the array of plug-ins and support available for the larger platforms.

Decoupling Will Make a Comeback

Decoupled CMSs built the Web. When I first entered this industry, we didn’t even have the term “CMS.” We barely had the term “content.” As I noted in the preface, we just had a bunch of files sitting around and were forced to manage them by raw necessity.

Some of the first CMSs, in fact, were simply collections of Perl scripts that templated data and made aggregations easier to manage. Movable Type – one of the earliest blogging platforms, launched in 2001 – was a Perl-based scripting system that generated static HTML .

But decoupled CMSs suffered from a need for active delivery environments. The need for real-time interactivity (message boards, commenting, rating) never lent itself well to static files. As websites became more variable, immediate access to the repository was required and the concept of a clearly defined “moment of publication” got blurrier and blurrier. Small changes in the delivery environment (a comment, a rating, etc.) were forcing full republishing, which became problematic.

Over time, more and more functionality was pushed into the delivery environment, until it became obvious to new developers that content should be managed there as well. With this, decoupled architectures began to decline.

At the same time, managed websites got smaller and smaller. While CMSs were used on larger sites, many smaller websites were still managed with client-side editors like Microsoft FrontPage and Adobe Dreamweaver. As CMSs began to filter downward, a generation of sites came online that couldn’t suffer through the complexities of decoupling and required the latest delivery-side interactivity. This further spurred the adoption of coupled CMS platforms.

But the tide is slowly turning back. What seems to have happened is that the interactivity needed in the delivery environment has become detached from the CMS – it’s now serviceable by systems that might not need interaction with the CMS at all. Adding commenting to a website now is as simple as using a pluggable system like Disqus, IntenseDebate, or even Facebook. Client-side technologies have advanced to the point where integration with social networking platforms is simply done with a JavaScript include. Marketing automation vendors can integrate solely on the client side, and even A/B testing is available with virtually no templating changes.

This means that rich, variable user experiences can now ride “on top” of static HTML files. The HTML files containing the content simply play host for a dizzying array of interactivity provided by other services. Most client-side technologies neither know nor care whether their HTML hosts exist in files written to disk 10 years ago or generated on the fly a millisecond ago.

Even further down this road, the relationship between server-generated content and client technologies may be on the verge of flipping entirely. Full-stack JavaScript frameworks like AngularJS, React, and Dojo are giving rise to “single-page apps,” where what’s delivered to the client is not content at all, but an application that runs in the browser and might retrieve content based on user behavior. In these situations, instead of content delivering the client functionality, we now have the opposite – the client functionality is delivering the content. In effect, we’re installing a templating and output engine in the browser every time a visitor comes to the website.

All of these changes are eliminating some significant benefits of coupled CMSs. Removing post-publication functionality, and sometimes even templating, leaves an editorial core that can survive just as well as a decoupled system and might be the better for it.

As noted in Output and Publication Management, decoupled publishing brings unique advantages in terms of scalability, stability, and security. And delivery environments are becoming simpler and simpler to create and maintain. Amazon Web Services allows the hosting of static content from the Amazon S3 storage framework, and with a couple of mouse clicks this can be integrated into CloudFront, its content delivery network. Combine this with a decoupled CMS and you can literally have an almost endlessly scalable environment to stage content for optimized worldwide delivery in five minutes. (For developers who have been working in this space since the mid-'90s, the mind boggles.)

We may very well see the CMS withdrawing back into its core, which has traditionally been the modeling, management, and aggregation of content. When and if this happens, decoupling is poised to play an enormous role in the landscape that results.

Focus on Marketing Tools and Integration Will Increase

Two years ago, I attended a networking event for CMS professionals on the East Coast. One of the speakers was the web marketing manager for a services company, who came in to explain how they handled their content. For an hour, he detailed the remarkable process and techniques they used to monitor, personalize, deliver, and optimize their content. It was obvious that his team was the focus of an enormous amount of attention and budget at this organization.

I was interested to know what CMS they were using that supported this level of marketing optimization. When I asked, he mentioned the name of a marketing automation vendor. I knew this particular vendor wasn’t a CMS provider, so I pressed him on what content management platform they were using.

He simply didn’t know. He explained that he was notified by the editorial team of what the content calendar looked like so his team could prepare, and then given a URL just before that content was published. He had no idea how the content was managed or generated. He and his team didn’t need to know.

I’ve already made the point that many organizations aren’t looking for a content management system as much as they’re looking for a content marketing system. The fact is, most corporate websites don’t turn over that much – their content velocity is extremely low, and content might change monthly, at most .

However, even though the content might not be new, most user interactions with it are new. That page explaining the features of the product might have been unchanged on the website for two years, but Bob is looking at it for the first time, and this scenario repeats itself a hundred times a day.

Every combination of visitor + content is a brand new experience, which needs to be managed. We might not change the content, but we need to optimize this visitor’s interaction with it through an arsenal of marketing and optimization tools such as personalization, A/B testing, and predictive analytics.

How the industry reacts to this need over time remains to be seen. There are two camps:

• Do it internally, by developing large marketing automation and customer experience suites inside the system itself
• Integrate externally with existing marketing automation vendors

The open source community is generally concentrated on the latter option. They’re content to leave marketing automation to specialized vendors, and keep their systems centered around management.

The commercial vendors are hedging their bets on both. Many are building marketing suites inside their systems. While some claim this is to provide high levels of integration between management and marketing, one has to assume that they simply see another market and source of revenue to capture. At the same time, most commercial vendors are also offering integrations to popular marketing automation vendors

What we may see is commercial vendors pushing further and further into this market until it becomes obvious that they’re going to be outdone by dedicated marketing automation vendors that don’t need to worry about core management features. When this happens, some management vendors will likely acquire marketing platforms, others will spend less on their own systems and more on integrations, and a select few might break off their marketing platforms into separate products and recenter their efforts around core management.

Entry-Level SaaS Will Eat Away the Lower End of the Market

In Acquiring a CMS, I expressed skepticism about pure multitenant SaaS offerings at the higher end of the market where customers require heavy customization. However, the entry-level SaaS market appears to be thriving and will continue to shake up that end of the CMS spectrum.

By “entry-level,” I’m referring to SaaS products that can generally be set up with nothing but a credit card and some personal information. Services like Squarespace and Wix have been popular in this space for years – and this is to say nothing of the blogging platforms like WordPress that can be repurposed into basic, limited CMSs without much trouble.

These systems will chew up the lower fringes of the CMS market, as organizations decide this level of management is good enough and concentrate their budget and staffing on marketing optimization using many of the platforms, tools, and methodologies discussed previously.

Yes, the functionality of these systems is undeniably limited, but they will still exceed the need of many organizations, or the organizations’ more demanding requirements will be abandoned or delayed in the face of the immediate availability and low cost of the platforms.

With these entry-level options, with nothing more than a credit card, a couple of hours, and some knowledge of the marketplace, an organization can come away with a simple website platform and an extensive marketing suite (which, admittedly still needs to visually themed and populated with content, but this is a task that needs to be done no matter how the website is actually acquired).

What will be key to the success of these platforms is the ability to balance the needs of a massive range of users. There will be the aforementioned organizations that “just need a website,” but there will inevitably also be a group that requires more and more customization. As these systems evolve, the ability to balance these groups – providing the latter with more and more ability to customize while not making the platform too expensive for the former – will drive or destroy adoption.

Beyond pure user adoption, these platforms are redefining functionality. Previously, we talked about “the Google Effect” which drives our expectation of how search platforms work. Perhaps “the WordPress Effect” is that which drives our expectations of how CMSs should work.

I envision vendor salespeople having to reorganize their sales decks as entry-level platforms develop. When WordPress finally began offering versioning, for example, that was no longer a competitive advantage for systems costing tens of thousands of dollars. This will begin to happen throughout the entry-level SaaS market. Vendors will have to reorient their systems and sales processes around what they offer beyond these platforms.

A system that costs $15/month today is quite similar to a system you might have paid $30,000 for a decade ago. This is healthy. Not only do customers with modest budgets get more functionality, but it pushes the industry forward. Lack of a vibrant entry-level market allows the higher-end vendors to stagnate.

Multichannel Distribution Will Increase

For years, vendors paid lip service to multichannel publishing. They claimed their systems would publish content into many distribution channels (wink, wink), but they knew the average user would never build more than a single website with them.

However, the rise of social networking has forced the multichannel issue. Massive amounts of content are being created that will never see the inside of an organization’s website. This content will spend its entire lifecycle in third-party, hosted distribution platforms. Facebook, Twitter, and Pinterest are enormous marketing and communication channels, and some organizations could simply forgo a formal website entirely and market solely through those channels . But this content still needs to be managed

What we’re seeing is the rise of the “social networking CMS” in the form of management platforms for social media updates. Platforms like Hootsuite, Buffer, and TweetDeck abstract content creators away from the actual platforms, allowing authoring and management in centralized applications. The line between these and more traditional CMSs is getting blurrier.

What we’ll likely see in the future is more vendors encouraging social media management from their core CMS products. Some have done this through add-ons and subsystems, but others will pursue a more “pure” approach, where a social media update is treated as a content object like any other, subject to workflow, permissions, auditing, etc. When content is published, it doesn’t appear on the website; it’s simply injected to the various social networking platforms through various APIs.

Social networking is just one channel among many. Marketing departments have been quick to embrace microsites, where a multitude of smaller websites are created to support ad campaigns. While these sites can often be managed out of the same CMS, the complication and overhead (not to mention the potential licensing costs) might encourage organizations to create static websites or use smaller SaaS platforms and push selected content to them from their core CMSs.

And while mainstream usage of RSS continues to (sadly) wane, RSS is still a valuable content distribution mechanism. Many platforms and systems consume RSS feeds, and one might envision a CMS that “publishes” content simply by including it in an RSS feed, where it’s devoured to be repurposed by dozens of other systems.

Electronic book formats continue to evolve, but repurposing content in a format like PDF, EPUB, or MOBI might be a preferred way for visitors to consume it, especially for long-form, reference content.

Finally, how about offline channels? Video billboards are becoming more and more popular (and distracting). As different as this application may seem, it’s still content that needs to be managed. I look forward to the day when my publication target menu includes options for “10th Street at 63rd” and “I-90, west of Sioux Falls.”

Distributed Content Intake Will Start to Grow

Services are starting to appear that are targeted directly at the editorial and content creation process. Platforms like GatherContent and Divvy are centered around managing editorial calendars, task creation, and collaboration. They have effectively broken off that set of functionality from the CMS, and are concentrating on it specifically.

Some organizations will turn to these services as editorial process tools inside their CMSs run short. Teams will begin working on the sometimes laborious process of content creation, with an API call that actually creates or updates the content in the CMS at the last moment.

Additionally, organizations will begin demanding more and more distributed content intake. I don’t think it’ll be long before we see a CMS offering content editing and collaboration directly from Google Docs, for instance. Other systems, like Beegit and O’Reilly’s own Atlas platform, provide high-end document collaboration based on traditional source control and Markdown-like syntax.

Organizations might likewise begin to distribute their content management, having multiple systems internally but one external CMS that delivers all content. Internal blog authors, for example, might write their posts on a private WordPress installation that then pushes content into a more robust marketing CMS for delivery.

To date, the default assumption of a CMS vendor is that all content will begin life in the CMS itself. This will start to change, as vendors begin to realize and adapt to the fact that other platforms are handling the editorial process with more focus and functionality.