Why the NYT is Building Their Own CMS
##And Why You Probably Shouldn't
If you’re above average interested in publishing or content management, you noticed the blog post from the New York Times a couple of weeks ago about their custom-built CMS “Scoop”. It gave us some amazing insights into how the world’s leading publishing house manages their content and probably made a lot of editors go “gimme, gimme, GIMME!”. The astounding platform raises an interesting question for companies that manage a lot of content:
How do we determine if we should build our own CMS, or buy an existing one?
##CMS as a Strategic Advantage
In the business of journalism, technology has become a competitive advantage on multiple levels. Not only does it allow your team to work together in a more efficient way, but it also impacts the kind of story you can put in front of your readers and even the talent you are able to attract! Vox Media seems to have the upper technology hand in the world or journalism, with their highly secret CMS making senior journalists ready to change jobs for it!
These media houses have extremely sophisticated needs and see their CMS as a core competency. Considering that the NYT publishes more than 700 articles and 50 hours of video per day, that’s not so hard to understand. Their needs around planning and budgeting, collaboration and workflows, and tracking changes are highly sophisticated and would mean extensive customization of any CMS that’s available on the market. But doesn’t every publisher have unique needs? Why shouldn’t everyone just build their own CMS then?
##When Nothing Else Cuts It
Even though Scoop is a quite impressive piece of software from what they showcased, it’s far from without shortcomings. The aforementioned blog post came just a shy month after their Innovation Report was leaked on Buzzfeed, which states how their CMS is lagging behind the ones of Huffington Post, Buzzfeed and Vox in terms of speed and ease of use. (Yes, the report stated some other minor issues beyond what their CMS is concerned, like facing irrelevance and being unfamiliar with the web, but that’s less interesting to us). The report clearly states that Scoop’s 20+ person team(!) is spending too much time on fixing bugs and doing minor improvements for individual desks instead of focusing on editorial innovation. You don’t have to be a visionary to understand that this isn’t the recipe for long-term success.
Building a CMS is no joke. We know that and so does the New York Times. They’ve been working on this thing since 2008. That’s six years and counting! And they’re still not all that happy with the system. Building a CMS requires a big vision. Not just in order to envision something that will be better for your editors than anything that’s already on the market, but also to attract technical talent required to build it. Imagine, all of a sudden you’re not just competing with the Washington or Huffington Post for talent, you’re competing with Adobe, Google and Microsoft. Those are real tech companies building products for millions of people to use, not just your 100-or-so editors. That means something to good developers. They want to make an impact!
##So why do they do it?
“Unlike many commercial systems, Scoop does not render our website or provide community tools to our readers. ...This separation of functions gives development teams at The Times the freedom to build solutions on top of that data independently, allowing us to move faster than if Scoop was one monolithic system”
LUKE VNENCHAK the New York Times
I’m not criticizing the NYT for building their own CMS here. I’m positive that this was the best decision they could make back in 2008. They needed a decoupled architecture and a completely API-driven CMS in a time where monolithic and page-centric systems ruled. The open-source systems like Joomla, Wordpress and Drupal, as well as almost all commercial enterprise solutions fail here. In the modern orgy of devices, screens and platforms, API’s and structured content rule. The New York Times understood this early on and decided to build their own. The founders of Contentful understood it a bit later and built something that everyone can use.
Still, if you put Contentful next to Scoop, or the CMS of Vox Media, it would still look… let’s call it simplistic. Our focus so far has been on developing a scalable cloud-based platform for high volume content delivery, but we’re now slowly getting to implementing many of the more complicated enterprise requirements. There are many boxes of the RFP that we couldn’t tick off as a standalone platform today, but that’s the beauty of a modern API-first platform: you can easily extend it with the add-ons you need. When you start digging into Content Management API, you can get a feel for all the cool stuff you can do with it, like creating your own editing interfaces. Because we also deliver all your content via our Content Delivery API you can really create once and publish anywhere.
If your needs are anywhere near to the level of sophistication needed by the NYT, Vox, etc. buying an out-of the-box solution is simply not an option. You simply won’t find it. Here are three questions to ask your team when evaluating to build your own CMS:
Is content management a core competency for our company?
Do we have the capabilities and resources to recruit a team that can build and maintain a CMS that meets our needs?
If the answer to these two questions are “yes”, then do some more market research and try to answer the more difficult third question:
Are our needs so unique that no existing platform can be extended to fit them?
If your answer to question 3 is also “yes”, dig up the budget for a 20+ CMS developer team and start building something from the ground up. Hopefully, you won’t look back in 6 years time and see a lot of glaring holes in your system (in addition to your budget!). If the answer to any one of these three questions are “no”, find an API-driven CMS platform that you can use as your foundation (like Contentful! We’re happy to help :)
