Home-brewed CMS – lessons for publishers and providers
Being local is one of the key success factors for our partners, though their industry expertise is also relevant for an international audience.
In the Partner Insights series we share their stories.
Recently, a few major publishers have developed their own content management systems to deal with the complex world of publishing today. Naturally, that has attracted attention from both publishers and providers.
Is this a growing trend? Can any publisher develop its own CMS, or is it just for those with wads of cash and resources? We tend to believe the latter, but we asked David Best, a consultant at Kirchner + Robrecht management consultants who focuses on digital media strategy and publishing systems, for his take on this topic. (The views in this article are Best’s, and not necessarily those of WAN-IFRA.)
Ever since Jeff Bezos bought The Washington Post, the media industry has been keen to learn how the founder of the internet giant Amazon would get that news-industry behemoth back on track, and where that track will take it. The natural assumption – that technology would play an ever-greater role at The Washington Post – is proving more and more correct.
In October 2015, the company announced it would offer its Arc Publishing toolset, developed over the previous five years, to external customers. Since then, the company has signed up 11 customers: publishers, plus several universities that are allowed to run the tool for free. The largest customer in the media arena is The Globe and Mail of Canada, which was selected as a development partner in June 2016.
Although only very few newspaper publishers plan to market their self-developed software, there are other prominent players in the publishing industry who have developed their own content management tools and systems.
In March, The Telegraph of the UK implemented its self-developed CMS and the Los Angeles Times introduced a self-developed story editor.
Despite those recent initiatives, the concept of self-developed content management tools is nothing new, as demonstrated by numerous examples.
Back in 2008, The New York Times implemented its digital CMS, named “Scoop.” In Germany, red.web is a well-known example.
It is an editorial system that was initially developed exclusively for the Rhein-Zeitung but has subsequently been marketed to other companies for many years. It is nonetheless worthwhile to examine the latest developments, for they offer some interesting lessons for publishers and system providers.
What drives publishers to develop their own CMS solutions?
A company might want to consolidate its system landscape, improve process quality, drive automation, or foster innovation and the development of new business models – there are many reasons for developing do-it-yourself solutions, all of them interconnected.
Process quality in this context means making the publishing process faster, more efficient and more elegant. In other words, fewer steps, clear user interfaces and simple navigation.
Those reasons prompted The Telegraph, for example, to develop a CMS that allows users to create and publish content very rapidly, in line with the paradigm that “simple navigation takes priority over rich functionality.” This system is used solely on all news desks.
Previously, The Telegraph had used an off-the-shelf system and customized it to the individual requirements of each news desk, with the effect that it ultimately existed in five different versions. The consolidation makes it possible to concentrate all maintenance, service and operation activities in one system.
Process efficiency can be achieved also through automation. Sometimes, self-developed systems can be the method of choice for creating a software solution for applications for which no off-the-shelf packages are available.
As a case in point, Mashable developed its predictive analytics tool Velocity as early as 2011 and has since expanded it into a digital publishing suite with a focus on automation. That allows Mashable’s home page to be configured automatically for all readers coming from social media sites based on a comprehensive analysis of social web data.
In addition, the system supports optimum storytelling for all social media channels and can also be customized to the requirements of emerging channels.
Thus it becomes evident that self-developing software tools can enable publishers to strengthen the innovation capability of their core business.
Take BuzzFeed, for example, which consistently both self-develops key systems such as content management and real-time analysis tools and has its own advertising formats devised by a data science team.
Even publishing products such as apps are developed by BuzzFeed’s own team with a view to achieving better control over such products and a shorter time to market.
The example of The Washington Post shows that self-developed tools can also serve as a new revenue source, through sales of the software to third parties. That is another form of innovation, albeit outside the core business.
Different types of self-development – a look at technical and functional approaches to DIY tools
What does “self-development” actually mean in terms of technical content and which functional scope can it have? The approaches described here are clearly focused on digital publishing. They strive to complement existing off-the-shelf editorial systems with digital publishing solutions developed to meet a newspaper’s specific requirements.
The Telegraph is another example. Here the self-developed Telegraph Authoring tool rides piggy-back on a standard solution, the Adobe Experience Manager. In addition, publishers use open source modules.
The Washington Post, for example, creates the lion’s share, about 70 percent, of its content using WordPress. This content as well as contents from other internal systems and external sources are then output using the self-developed “PageBuilder” rendering engine.
In this way, the production and storage of content that traditionally happens in a CMS is separated from content presentation.
The pages to be put out are broken down by front-end developers into stand-alone, reusable “features” such as video elements. That enables newsroom employees to flexibly configure the “features” of a page and connect them through APIs to specific sources – for example, to replace a video from the company’s own video management system with a YouTube video.
Most of those solutions are focused on the areas of content creation and digital publishing (e.g. The Telegraph, Los Angeles Times).
Arc Publishing is somewhat unusual here since it covers the publishing process to a much greater extent and, for example, also contains content analysis tools and methods to re-engage users of mobile devices.
Other approaches in the open source sector
Open source CMS such as Drupal or WordPress have recently gained in relevance for publishers. An example of this are the web CMS distributions based on Drupal that have been customised to the specific requirements of publishers (e.g. Le Temps in Switzerland with the NP8 Drupal distribution).
This is often called “bi-directional publishing,” meaning that content is initially created in the CMS and then sent to a print layout system, where it is adapted to the print layout and ad spaces and subsequently sent back and stored in the CMS.
The Thunder project initiated by Burda in Germany should also be mentioned when reviewing the open source field. Burda has been developing and distributing a Drupal-based CMS customized to publishers’ requirements, to be expanded and refined in a joint effort with publishers and technology partners participating in the initiative.
In contrast to some advocates of the “DIY” approach, however, this project postulates that publishers should coordinate their development efforts rather than differentiating themselves from one another through the underlying content management systems.
What can publishers learn from these developments?
In our view, the intensity with which companies seek to optimize system support solutions is a boon, since this area still has a lot of potential for innovation and increased efficiency. Developing a comprehensive CMS on one’s own involves a good deal of risk and effort.
In the past, many projects initiated by publishers in this area failed because the effort and know-how required for such development and – just as important – the long-term implications in terms of support, maintenance and continued development had been underestimated.
In other words, while a comprehensive “DIY” strategy may be the right thing for large media brands such as The Washington Post, The New York Times or BuzzFeed, it does not necessarily mean that this is also true for other publishers. And establishing oneself as a professional software provider in order to sell the self-developed solution to the market is not an easy feat, even for The Washington Post.
Nonetheless, a self-developed tool can make sense for specific discrete – and thus manageable – areas. Before embarking on a self-development project, decision-makers at the publishing company should take a look at how such projects were implemented at the case studies mentioned above.
In our experience, it can be very useful to have programmers and IT specialists, product managers and editors – plus existing system providers – jointly analyse, optimize, and, if necessary, re-engineer the processes for publishing, distribution and marketing of content.
In doing so, stakeholders from all those areas should review and understand the processes from beginning to end. That can be done by, for example, conducting a joint analysis of the entire process sequence with the aim of assessing the process performance in terms of time, cost, and quality (considering the amount of work generated by serving all external channels, the error rate for publishing online articles, or the approach to optimising content distribution, to name a few examples).
In addition, the team should also consider optimizing the product portfolio and the business models in use, no matter whether dealing with paid content offerings, digital marketing, or cross-departmental data-driven approaches. Whether that exercise results in a change of system or the self-development of new software ultimately depends on the balancing of achievable improvements versus the costs and risks involved.
What are the lessons for traditional multi-channel publishing system providers?
Many editorial system providers already know and heed the following lessons – yet they may still contain some useful food for thought.
A key driver for publishers is their quest for ways to reduce the complexity of operating their systems and to publish, distribute, and monetize content in a more effective and efficient way. All that can be achieved through simple operation, simple implementation, and a simple pricing model.
In principle, multi-channel publishing system providers have the advantage of being able to offer various solution modules from a single source.
At the same time, they have to take account of the heterogeneity and the growing number of tools used at publishing companies by both offering connectivity to other systems (through APIs) and by expanding their own software functionalities.
The functional capability of a system should not be enhanced to the detriment of simplicity of use; that requirement might be met by providing user front-ends that can be flexibly adapted to customer-specific requirements or “simple” complementary publishing tools.
The ability to provide efficient, cross-media multi-channel publishing combined with a flexible workflow management is still an argument that can be used in sales talks.
Of course, print continues to be the most important revenue pillar for most publishers, making it a vital channel. The strongest driver of innovation, however, is digital publishing. Here, content arrives from a vast range of internal and external sources. The number of sources will continue to grow, as will the number of output channels, which makes flexible intake and output of digital content more relevant than ever.
That confronts system providers with the challenge of covering the entire content life cycle, from planning to re-usage of content, by providing either convincing in-house products or well-integrated third-party solutions.
They must take those solutions rapidly to market in order to keep up with the competition from specialised digital system providers and discourage publishers from embarking on their own development projects.
In our view, multi-channel system providers should explore ways to market their solutions in even more modular fashion going forward – possibly in the form of tools that address individual process steps and can still be used in an integrated manner. That would give system providers a shot at winning new customers in an embattled market.
If a solution is offered in very small, individual modules, new customers can be convinced of a provider’s capability in a step-by-step manner. In addition, it would make it easier for system providers to make inroads into the corporate publishing market, which might have use for some but not all modules offered to newspapers and other mass-market publishing customers.