The CMS Is Broken.

"Drupal, Wordpress and Joomla use PHP. — the plugin model aches at scale: popular plugins become abandoned plugins, energies move elsewhere. Plugin A works great, plugin B too. However, they weren’t designed to know about each other, thus leading you down a rabbit hole of forking and mending. A few years of use later, you are left with an unmaintainable tangle of ad hoc code written by an all-but-unknown cast of programmers."<p>This is true of Joomla, and to some extent Wordpress, but as someone who makes his living using Drupal, this statement is patently false and indicates that the author isn't truly familiar with the systems he's criticizing.<p>The cast of characters behind most Drupal plugins (modules, in Drupal parlance) is well known and most have been iterating their plugins for four to six years (or more). Drupal.org serves as the sole repository for plugins, providing usages statistics, notifying users of upgrades and patches to modules, serving issue queues, and generally keeping the Drupalverse running quite smoothly.<p>Drupal plugin A and Drupal plugin B <i>are</i> designed to know about each other, at least indirectly, because they use the same fundamental elements (the menu system, the hook system, common APIs) to manage data.<p>I'm not going to claim that Drupal is "Wordpress easy" to install, or that you'll just sit down in a day and master the system as it's as much a RAD framework as it is a CMS. It's big, powerful, and flexible, and these traits are the natural enemies of "easy."<p>FWIW, I'm not a core contributor or anything like that, I'm just a guy who's made a hell of a nice living using Drupal.

I find this interesting because TPM's solutions reminds me of the classic UNIX "pipes and filters" strategy - a series of small components with well-defined inputs and outputs that can be strung together to produce a sophisticated result. (Of course, "small", "well-defined", and "sophisticated" could be relative terms.) The pipes and filters "API" was plain text transmitted through stdout.<p>It also strikes me as an example of software development becoming more deeply embedded in media companies. It's not an accident or a coincidence that most content management systems work on the framework-with-plugins model. Dedicated software developers build the framework, and it's expected that organizations who use it only have the technical chops to deal with plugins. TPM's architectural change is also a change in the amount of development work they plan to do - they're saying that they can afford to rewrite/develop/debug/etc. 10% or 20% (percentages are arbitrary) of a CMS-size framework and string those components together, rather than work with the 2% of a plugin and sprinkle it on top of the main 98%. They've moved up the food chain in the size of their internal development.

Blog engines are a subset of CMSs. They're <i>supposed</i> to be restrictive - that simplicity is part of their value. If they wanted a CMS that would allow them to add their own types of content, they should have gone with a CMS that was more "framework" than "application"

It sounds like Separation of Concerns[1] applied on a larger scale. Software is easier to manage and more flexible if each piece does one thing and does it well, with as little overlap with other components as possible. This is what makes OOP a good system for designing large programs. I helps people separate out the various components so that maintenance is of many small pieces with clearly defined boundaries instead of one large piece with none.<p>Separating out these services into their own "apps" is like splitting up classes. It's a natural and good way to increase maintainability and flexibility.<p>[1] <a href="http://en.wikipedia.org/wiki/Separation_of_concerns" rel="nofollow">http://en.wikipedia.org/wiki/Separation_of_concerns</a>

This is roughly what Ars Technica was doing before I left, I think moreso now. The Movable Type "post" interface was relegated to "the box people write text in", which was then pushed into the app that handled rendering a site.

The world of Content Management Systems is definitely an awkward place to be in, However, I don't think that the notion "The CMS Is Broken" is really justified.<p>I think the first major problem with CMS' is that people expect them to be the end all be-all solution to their site and content needs. Clients expect them to be an intuitive cheap publishing platform that will magically format, organize and display an endless array of content and content types, while developers expect them to be fast, easy to extend, scaleable, lightweight and fit a theoretical "goldilocks zone" of adhering to conventions but still being flexible.<p>To fix the client problem, clients need to understand software does not create good content for you. Content needs to be curated and software is there to help with the heavy lifting. Instead of forking out X amount of money on software, spend half that and spend the remaining half on writers, photographers and people to make your content great.<p>As for the software/development problem, each specific case can require a different platform. Just like one specific programming language is only one tool in the box, one CMS follows the same pattern. Educate yourself about all your tools and explain the pros/cons to the client before making a decision, but in the end, isn't that what were being paid to do?<p>Sorry if my comment is a little more about the business side of things and not necessarily about the CMS itself, but I feel its a pretty important point on this issue

Definitely an interesting perspective from the media industry. Although the pattern described is a relatively common pattern across a lot of "webapps-at-scale." For example, the CTO of Trip Advisor recently talked about how Trip Advisor is a series of distinct services exposing APIs that all run separately and are pulled together for a page render[1]. At some point most growing web apps simply outgrow the ability to be a single monolithic PHP/Rails/Python/whatever app and need start breaking things up.<p>Although, it seems like TPM is seeing benefits from this that go outside the typical reasons folks start to go this route, like outgrowing a single relational database or wanting teams working on different components to be able to work and deploy independently of each other.<p>[1]<a href="http://highscalability.com/blog/2011/6/27/tripadvisor-architecture-40m-visitors-200m-dynamic-page-view.html" rel="nofollow">http://highscalability.com/blog/2011/6/27/tripadvisor-archit...</a>

Wow -- this really stuck a chord with me. My startup's product is a CMS. Before we build the CMS, we built the API:<p><a href="http://www.gethifi.com/blog/first-we-built-an-api-then-we-built-a-cms" rel="nofollow">http://www.gethifi.com/blog/first-we-built-an-api-then-we-bu...</a><p>That said, I didn't buy everything he said. We've built a farily agnostic API, very much like he described. That said, it's not Mongo, it's not MySQL and it's not CouchDB. It's impossible to build something that is 100% free from constraint and trade-offs.<p>Blog Engine CMSs are restrictive because they are Blog Engines! You can see that his system has its restrictions too as he enters a pixel based headline size in the demo video.

"Our new system will simply wrap the MT database in a cached layer and incorporate its content. Our new gallery app — currently active on the site — creates slideshows, writing its changes to central datastore as well."<p>Also known as "now they've got two problems", or in this case, four. Or I don't understand it - it sounds as if they have introduced another layer between frontend and backend, which probably increases complexity.<p>The road to hell is plastered with abstractions...

Wasn't this exactly the problem that Django was originally trying to solve?

I like the feature-as-app paradigm, but the article says nothing about the underlying API. I have used a CMS the last couple of years at work, where documents are stored as JSON files on the server using WebDAV protocol, which off course is totally REST based. Access control is done using the PROPPATCH verb. The CMS is named Vortex, developed at the University of Oslo and has an open sourced license. Too mee this API seems to function better than the usual custom made REST based API.

The most complex piece of software I've worked on was a CMS. I spent a lot of time doing competitor evaluations, and, without fail, the only successful implementations were using small products in small workgroups. Trying to solve the "enterprise" problem always failed, both because the software became stupid complex and the processes became even worse.<p>I don't think its an intractable problem, but the people issues surrounding it make it a hugely difficult one.

Blaming technology isn't going to change the fact that journalism is still broken.<p>Folks like John Gruber and Matt Drudge make a ton of revenue by serving their readers. They have simpler technology than everything stated in this article.

His discussion of editors' thought process about CMS tools and making site parts from apps sounds suspiciously like the reasoning over at the Lawrence Journal-World newspaper. I'm curious why their solution wasn't mentioned.

I think this is somewhere that highly adapted mini-frameworks could take hold.. something like Padrino for Sinatra, yet slightly more publishing friendly.

Yep, we here at Working Software <i>definitely</i> think CMS is broken ;) [1] but mostly because of the deployment system and reliance on "designMode" word-style editing. Basically, we hate "plugins".<p>[1] <a href="http://decalcms.com/mockups/" rel="nofollow">http://decalcms.com/mockups/</a>

Holy shit people still use Moveable Type?