Having worked with web CMSs (WCMS) for more than 15 years, I’ve seen a wide range of CMS products—including bespoke solutions built by digital agencies to suit the needs of their existing customers, open source platforms developed and supported by large communities, and proprietary commercial products developed by software houses serving a wide range of industries and use cases. I’ve worked with market-leading CMSs, as well as average, “good enough” CMS platforms. I’ve worked on selection and procurement to replace end-of-life, officially dead CMSs too.
Some of these WCMSs were better than others, but most of them proved frustrating to the developers as well as the editors using the system. There was always a feeling that something wasn’t quite right. If the platform was flexible, it required exorbitant amounts of configuration and developers’ time. If the platform was simple enough to run out of the box, it was lacking in some business-critical features. Almost universally, content editors had to suffer in silence, doing their jobs in counterintuitive, inefficient ways that were dictated by the quirks of the system.
The frustration with the system was at its worst for projects in which the implementation team—either the company’s in-house team or an external supplier—was not experienced enough with the chosen CMS (or sometimes just incompetent). No matter how good or bad the actual system was, it was the quality of the implementation that made the biggest difference.
When Does a Homegrown CMS Make Sense?
Building a homegrown CMS solution to address this frustration is tempting. A bespoke solution removes the gap between the vendor (or the open source community) and the customer—the product development team and the implementation team are the same people. Development of a bespoke CMS presents an opportunity to own a platform that not only meets customer needs and business requirements fully, but also suits developers and content editors within the organization.
What’s the problem with the bespoke approach? Well, there’s two. First, keeping a team of developers in-house is expensive. Second, more often than not, 80% of the requirements can be met with an off-the-shelf CMS product, in which case, the bespoke solution amounts to nothing more than reinventing the wheel.
“Writing your own CMS is like keeping your own elephant — for most people, it’s just easier to visit a zoo,” argues Petr Palas, founder and CEO of Kentico, in his article “How I Built a CMS, and Why You Shouldn’t.” Keeping an elephant and running a zoo, however exciting, are not feasible for most organizations. Regardless, there is one industry in which the bespoke CMS approach is actually justified: media. For a publisher whose entire business depends on its CMS, having full control over how it’s done can bring competitive advantage. It’s a capital investment in its core offering.
In addition, there are a number of idiosyncratic requirements, specific to the media industry, which cannot be easily met by an off-the-shelf “horizontal” CMS, such as Adobe Experience Manager, Sitecore, or WordPress. For example, these:
• Digital advertising management
• Management of soft and hard subscriptions and a paywall
• Management of multiple drafts of the same article
• A track changes feature to allow a journalist and an editor to easily see each other’s corrections
• Automatic, intelligent inclusion of links, tags, and metadata
• A light, mobile-friendly version of the CMS for reporters on-the-go
• Extensive cards and card stacks for easy newspaper-like responsive layouts at low cost
• Social media integration: social sharing, plus customizable social media descriptions and images
• Advanced personalization
• Scalability, ability to cope with high traffic
Developing and supporting a homegrown CMS is a huge commitment. It requires a dedicated team of developers, supported by testers, user experience specialists, business analysts, and project managers. Even then, getting it right and staying at the top of the game are a challenge. But in the media industry, in the absence of a common publishing platform that’s fit for purpose, this continues to be the strategic choice.
When Publishers Become CMS Developers
The Guardian runs on the homegrown, open source CMS Composer. The BBC uses a bespoke system called iSite. Some media companies went as far as licensing their systems as software products for other businesses to use. Notably, Vox Media launched the Chorus CMS in 2008, and The Washington Post launched the Arc publishing platform in 2014.
There is an opportunity for the right CMS vendor to establish a leading platform tailored for the media industry. The reason this hasn’t happened yet is that digital journalism itself is still evolving. The relentless publishing of articles written in an inverted pyramid style works to a point, but this is more of a product of a legacy format than customer preference. The BBC is exploring new formats by mixing evergreen and ephemeral content, as well as offering swiping options and scrollable videos to update how we deliver and consume news.
The business model of digital journalism is also changing. Despite the initial pushback, paid subscriptions and paywalls are finally getting traction, so the goal of reducing or eliminating traditional advertising from the paid services is more achievable than ever. Technology needs to catch up with this trend and allow content editors to price the content, impose paywalls, and apply discounts as required without having to contact IT.
The whole of the media industry is on the verge of a digital transformation. Netflix, Uber, and Spotify transformed the way we watch movies, get around town, and listen to music. The future of media is about to change too, and the technology behind it will play a central role in this transformation.
