One of the most important lessons I learned as Vice’s chief technology officer was that while the operational needs of the company might feel unique, fundamentally those needs were no different from any other media company. Put another way, while our content was different from other media companies, our business processes and systems didn’t need to be.

This was applicable to business systems like our ERP and CRM — but equally so to our digital publishing platform.

Given this reality, why had we at Vice — like so many other media companies — built rather than bought our publishing platform? The answer is that, until recently, we didn’t have a viable “buy” option. All-in-one CMS/platforms like Drupal, CQ, and WordPress suffered from design limitations and a perception that they would be slow to adapt to changes in web technology. So most media companies choose to build their own proprietary platforms and content management systems.

Today, though, the commercial market for publishing platforms is maturing, and “buy” is finally becoming a viable option. I don’t suggest “buy” casually, as I spent more than seven years building an international-first platform for Vice that was best in class. It spanned more than 12 brands and was used by offices in 35 countries. But the rationale I used for building rather than buying 10 years ago was predicated on a user experience and platform market that is dramatically different in 2018.

For the media industry as a whole, the stakes are high: If companies can set aside their (considerable) differences and use a single publishing platform, they could collectively mount a winning fight against Facebook.

How we got here

When I first built Viceland.com in 2001, its primary purpose was to reproduce the print version of Vice Magazine and to provide contact details to buy print ads. We optimized the site for dialup modems and 640×480 screens.

By 2005, with broadband penetration and screen sizes growing — and more time being spent online — media companies started to seriously invest in their online properties. But with little understanding of the new KPIs — uniques, pageviews, and time on site — and few reliable ways to compare one site to another, media companies did what they do best: They built out experiences that mirrored their print editions. Branding was key; user experience not so much. As media companies built their own platforms, they in turn grew sizable engineering and product teams focused on their digital lines of business.

By 2011, with the mainstream acceptance of smartphones and the first iPads, the number of screen sizes proliferated and responsive design — the process by which a single page can adapt to different screen-sizes — started gaining traction. Over the next three years, most sites were redesigned to make them mobile optimized. By 2015, most media companies had crossed the 50 percent mark for content consumed on mobile versus desktop.

But with responsive design came an unintended consequence: When reading on mobile, you really couldn’t tell one media property from another. A primary reason for building your own platform — to support a unique brand-focused design — was becoming irrelevant.

This matters a lot. If all sites look the same on mobile, and if mobile is the dominant means of consuming media in 2018, why use a custom platform?

One answer is that the “built” platform is still handling a ton of custom backend operations, from ad tech and third-party platform integrations (Apple News, Google AMP) to powering the CMS. But that means that the development teams are no longer tackling anything unique — they’re just solving the same problems as everyone else. Which just doesn’t make sense. It’s as if every record label had their own dev team building their own version of iTunes or Spotify.

The alternative

Starting in 2014, several media companies began to take their own publishing systems and repurpose them as platforms that could be used by other publishers. Vox Media’s Chorus, The Washington Post’s Arc, New York Media’s Clay, and Hearst’s MediaOS are four such platforms that are now available for licensing.

• Chorus is built by Vox Media, which is run by an executive team with significant technical experience. This is worth calling attention to, as it means they’re well equipped to understand the resources that are required to build and support a platform for licensing. And through their acquisitions of Eater, Racked, Curbed, and Recode, they have experience in bringing new sites onto their platform (and a vested interest in making them as successful as possible). Chorus is SaaS software, meaning that Vox Media hosts the platform themselves, giving publishers a system that addresses all current publishing requirements, while at the same time receiving regular updates for future needs (think Google AMP, GDPR compliance, etc.). Most of the third party services a company currently uses for their sites — Google Analytics, Operative, DFP, Krux — can be used with Chorus after an initial configuration. Chorus also ties directly into Concert, Vox Media’s publisher-focused programmatic marketplace, allowing companies that have been struggling with ad sales the possibility of both higher CPMs and sold-out inventory.
• New York magazine is hoping to get media companies to contribute to a common goal of building out a flexible, scalable platform. They open-sourced a significant portion of their own platform, Clay, and are licensing out a full enterprise version to publishers. Clay is not SaaS and an internal team is still needed to support the basic platform. But then any publisher can contribute additions through GitHub — or simply branch off and create their own add-ons while retaining the basic CMS/platform underneath. For publishers looking to support edge-case content modules (horoscopes, recipes, sports scores), Clay allows not only for their development, but also the sharing of those entities across publishers. Slate has already moved onto the platform and a number of other publishers using the system will be announced soon. Clay would be ideal for a company that wanted the advantages of a common platform but still needed to do significant development work to refine the user experience. (Node/Express and AWS skills are helpful to support development.) And for the procurement-minded, those devops contracts with Fastly, AWS, and Akamai are still needed as Clay is self-hosted.
• The Washington Post’s Arc is another SaaS platform which aims to be a one-stop solution for almost all publisher needs. A company can go all in with Arc and leverage the system for everything from video livestreaming to analytics to hosting to CDN. While there’s no Concert marketplace to tie into (yet), Arc comes with modules supporting A/B content testing, newsletters, subscriptions, and digital asset management. The Washington Post is working to position Arc as the SaaS based media platform and is heavily investing in the service. More than 30 major brands are now using Arc, including the the Los Angeles Times, The Boston Globe, and Le Parisien.
• And finally there’s Hearst’s MediaOS, a relative newcomer in this space, launching in 2016. Like Chorus and Arc, MediaOS is a SaaS solution. What makes it an interesting entry in this space is that MediaOS natively needs to support “old-school” and “new-school” properties, from digital-first (Digital Spy) to magazines (Cosmopolitan, Elle), to TV stations (KSBW) — globally. It was built with unity in mind — consolidating content creation, distribution, ecommerce, video, analytics, ad deployment, and operations within a single system. With some integration help, customers can keep their existing services or for a simpler deploy they can use the services that Hearst has already bundled into MediaOS. Also included is a suite of third-party tools that the Hearst development team carefully vetted and integrated into the greater ecosystem. The majority of the stack is proprietary, comprised of over 40 unique micro-services granting any contributing engineer the opportunity to become platform contributors.

It should be noted that there are a number of modern CMSes that could also be considered, such as Brightspot, Contentful, and even good old WordPress. But because they’re not purpose built for media companies by media companies, they need to be evaluated carefully. There are many use cases for media sites, especially around advanced ad-tech integration, that other industries don’t need to worry about — so buyer beware.

“Buy” is still not for everyone

These platforms aren’t perfect — yet! Using a bought platform will always mean some level of tradeoff.

• Companies that have unique content edge cases — say, a recipes site — may find these platforms to be square pegs in round holes for their content. With that said, each platform does allow for significant front-end customization, so supporting edge cases is possible, and if this is critical for your business, then Clay may be the best choice.
• Localizing content is possible in all four platforms, but none developed their CMS with localization as a core requirement. At Vice, we built out our platform knowing that 20-plus smaller offices would be translating content from larger markets, so it was key that the system be optimized to support that workflow. Media companies with local content needs may want to wait until one of the platforms can demonstrate that they have truly built out support for localization.
• Those media companies which have already invested in homegrown, common platforms to support multiple properties will see less benefits than others as they’re already achieving an economy of scale with their current systems.

And for media companies that do choose to migrate from a custom system, there are several other considerations:

• Staff morale is a big concern. After years of building unique custom software, moving to a common platform may seem like admitting defeat. I’d recommend bringing the engineering and product teams into the decision making process — explain the cost savings and let them have a real say in which platform is chosen. Remember that keeping the current team happy isn’t just something nice to do — they will be critical to migrating existing data and the ultimate success of the new platform.
• Depending on the platform chosen, existing contracts with vendors may no longer be needed. That means that timing of a move should be coordinated with sunsetting long-term, high-cost contracts. For companies considering the purchase of a platform in the next 1 to 2 years, it would be prudent to cap all new IT contracts to no more than 12-month terms or to require a 30-day out.
• For companies that have built out iOS or Android apps and feel that those apps are providing value, it will be important to work with the platform teams to understand how APIs can be connected to continue to push content to your existing apps.

A united future

If media could consolidate around a common publishing platform, it would allow players of all sizes to cut costs as well as better compete against Facebook as a media union, taking action collectively, and once and for all addressing their biggest revenue challenges.

For example, while technology exists to stop ad blockers by preventing those using them from viewing a site, most media companies are afraid that by employing an ad-blocker blocker, their visitors will simply go to their competition. But what if every site blocked ad blockers at the same time? Or concurrently deployed a paywall? Users couldn’t simply go to the competition because everyone would be rolling out the change at the same time. (Side note: See Scroll for how publishers could be doing this right now.)

On the SEO front, when Google rolls out dramatic changes to how they index the Internet, in a united media world, any adverse impact that was not content related would be felt by all companies equally, preventing the unpredictable and brutal way some companies have suffered through recent Google updates.

For developers building services for media sites — especially those that require CMS integration — the need to support hundreds of different custom platforms is a tough barrier to entry and prohibits easy scaling. Imagine having to customize software for several hundred different systems, each requiring hand-holding from the companies’ developers? Big developers can handle this, but smaller innovators struggle. The end result is that many developers steer clear of working on third-party media apps altogether. A common publishing platform would allow for plug-and-play integration, spurring far more third-party development.

At stake is a future where companies that transition to a common platform will be able to focus on what they do best — develop content — and leverage their development teams to optimize the “last mile” of user experience rather than solving problems that have already been solved by others.