6 ms·

The CMS Is Broken.

92 points by yahelc 15y ago

deleted 15y ago
[deleted]
ejames 15y ago
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. 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.
- bergie 15y ago
  I think the natural next step of "UNIX pipes and filters" is Flow-Based Programming (http://en.wikipedia.org/wiki/Flow-based_programming http://en.wikipedia.org/wiki/Flow-based_programming). Processes can have multiple named input and output ports, and data flowing between them can be objects and other data formats. In currently building an Open Source FBP tool called "NoFlo" on top of Node.js, and at least the initial results of building websites with it are promising.
  - vertice 15y ago
    This is definitely the direction i see things going. Node.js is also perfectly suited for it, and I recall hearing that it's also on the core team's mind.
    - bergie 15y ago
      Here's my project: https://github.com/bergie/noflo https://github.com/bergie/noflo
crikli 15y ago
"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." 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. 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. Drupal plugin A and Drupal plugin B are 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. 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." 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.
- beck5 15y ago
  "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. " Would you mind expanding on that. Do you offer a plethora of services or focus on one or two things? A friend of mine set up shop building small sites for local business with drupal and is always tell me how great it is.
  - crikli 15y ago
    Sure. Our niche is working with ad/marketing/traditional media agencies, SEO firms, and design groups to provide the technical muscle they don't have to get beyond "five pages and a contact form." So what we do is pretty focused: we don't do design, we don't do marketing, we don't do offer SEO (we build very SE friendly sites, but we're not doing keyword research or running PPC campaigns). We're just engineers/developers (if you can call anyone that works with PHP for a living an engineer). :)
shib71 15y ago
Blog engines are a subset of CMSs. They're supposed 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"
- dorian-graph 15y ago
  That's what I was thinking, especially when I read this part: "The CMS has to be everything to everybody. Wordpress has to optimize for both the cat-picture faithful and the ring-bejewled, hair-fisted mogul. Moveable Type has to work whether you are running a lad mag or poetry journal. This is an impossible proposition." Expecting every (?) CMS to be the end-all solution to every possible content situation is ridiculous. It would be nice/neat but that doesn't seem to be quite how it works—is that idea akin to expecting every vehicle to be able to perform every type of situation available? Expecting your family sedan to also be the workhorse carrying materials and whatnot? What if you only wanted to ride a simple bicycle down the street and not have to worry about a more intricate/heavy one? I use different CMS for different things though admittedly, that makes it harder to master one in particular. http://www.thesecretary.org/ http://www.thesecretary.org/ - For portflio type sites. http://staceyapp.com/ http://staceyapp.com/ - For incredibly simple sites. http://textpattern.net/ http://textpattern.net/ - For most other things. I do feel as if CMS have kind of stagnated for a bit and am a little tired of most so I'm thankful for the author bringing Netsta to my attention—it looks interesting.
mrkurt 15y ago
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.
tedsuo 15y ago
Holy shit people still use Moveable Type?
- vladsanchez 15y ago
  NPR.org still uses it. And it's a great example of MT's potential.
Periodic 15y ago
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. 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. [1] http://en.wikipedia.org/wiki/Separation_of_concerns http://en.wikipedia.org/wiki/Separation_of_concerns
- bergie 15y ago
  Exactly the approach I'm pitching to CMSs in here: http://bergie.iki.fi/blog/decoupling_content_management/ http://bergie.iki.fi/blog/decoupling_content_management/
mikeocool 15y ago
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. 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. [1]http://highscalability.com/blog/2011/6/27/tripadvisor-architecture-40m-visitors-200m-dynamic-page-view.html http://highscalability.com/blog/2011/6/27/tripadvisor-archit...
mikx 15y ago
Blaming technology isn't going to change the fact that journalism is still broken. 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.
- paxswill 15y ago
  I don't know if he still uses it, but Daring Fireball use[s|d] Moveable Type as of at least 2002.
- nougatmachine 15y ago
  You'd be hard-pressed to find an entity less representative of the 'old media being outflanked by the young hotshots' stereotype than TPM.
Tichy 15y ago
"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." 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. The road to hell is plastered with abstractions...
- esmooov 15y ago
  Well there are certainly tradeoffs. We do have more apps that can fail. Then again, when one does start to choke, as will happen, the others don't die. So if Baroque locks up, or starts to churn, or I do the ol rm -rf / all that is impacted it our ability to press frontpages until Chef can mint us another Baroque. Also, there's not, so much, another layer between frontend and backend as there is a multiplication of frontends. It certainly may get us into trouble. Luckily, we already were in trouble and, worse case scenario, we all learn a lot from the experience. The hell-road blacktop is something we are trying to tear us by substituting the abstract relation of CMS to site for a closer isomorphy of app to function. Who knows? Might work.
dools 15y ago
Yep, we here at Working Software definitely think CMS is broken ;) [1] but mostly because of the deployment system and reliance on "designMode" word-style editing. Basically, we hate "plugins". [1] http://decalcms.com/mockups/ http://decalcms.com/mockups/
JoelSutherland 15y ago
Wow -- this really stuck a chord with me. My startup's product is a CMS. Before we build the CMS, we built the API: http://www.gethifi.com/blog/first-we-built-an-api-then-we-built-a-cms http://www.gethifi.com/blog/first-we-built-an-api-then-we-bu... 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. 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.
- noibl 15y ago
  > You can see that his system has its restrictions too as he enters a pixel based headline size in the demo video. The fact that he specifies the size unit actually suggests that the system would accept others. It's basically CSS after all.
  - JoelSutherland 15y ago
    I mean in the sense that he is storing pixel sizes as opposed to some semantic information. This implies either: 1. An elaborate system of decoupling styling information from content via metadata. (i.e. in situation X, this document's headline should be 20px) Their approach would be pretty interesting here. How could this be preserved as their design/layout evolves with time? 2. He was just indicating that headline in position X be 20px, communicating with the layout. 3. He was hard-setting it to 20px. It's probably #1. So if, as he says they switch layouts and output to tumblr, how would that work? Their answer might be a lot of manual work, or it could potentially be something really clever.
    - noibl 15y ago
      The semantic information is already in the selector that pops up, e.g. '.headline'. I don't see why they need to store anything elaborate to make that portable. The scope of the change (document, document type, section, site) isn't shown but presumably it defaults to 'type'. BTW the in-place edit features remind me a lot of this[1] use of Deface[2] in Spree[3] [1] http://www.youtube.com/watch?v=qjgQHzYcxIQ http://www.youtube.com/watch?v=qjgQHzYcxIQ [2] https://github.com/railsdog/deface#readme https://github.com/railsdog/deface#readme [3] http://spreecommerce.com/ http://spreecommerce.com/
Locke1689 15y ago
Wasn't this exactly the problem that Django was originally trying to solve?
- fdb 15y ago
  Indeed, Django was made for news rooms! Certainly the whole "homepage is an app" concept maps perfectly onto Django's ontology of projects and applications. The API, however, is not something that's built in. They might want to take a look at Ellington (http://www.ellingtoncms.com/ http://www.ellingtoncms.com/).
Terretta 15y ago
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.
SoftwareMaven 15y ago
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. I don't think its an intractable problem, but the people issues surrounding it make it a hugely difficult one.
brock790 15y ago
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. 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. 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. 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? 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
minikomi 15y ago
I think this is somewhere that highly adapted mini-frameworks could take hold.. something like Padrino for Sinatra, yet slightly more publishing friendly.
thomasfl 15y ago
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.

92 points by yahelc 15y ago

deleted 15y ago

[deleted]

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. 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.

bergie 15y ago
I think the natural next step of "UNIX pipes and filters" is Flow-Based Programming (http://en.wikipedia.org/wiki/Flow-based_programming http://en.wikipedia.org/wiki/Flow-based_programming). Processes can have multiple named input and output ports, and data flowing between them can be objects and other data formats. In currently building an Open Source FBP tool called "NoFlo" on top of Node.js, and at least the initial results of building websites with it are promising.
- vertice 15y ago
  This is definitely the direction i see things going. Node.js is also perfectly suited for it, and I recall hearing that it's also on the core team's mind.
  - bergie 15y ago
    Here's my project: https://github.com/bergie/noflo https://github.com/bergie/noflo

crikli 15y ago

"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." 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. 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. Drupal plugin A and Drupal plugin B are 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. 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." 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.

beck5 15y ago
"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. " Would you mind expanding on that. Do you offer a plethora of services or focus on one or two things? A friend of mine set up shop building small sites for local business with drupal and is always tell me how great it is.
- crikli 15y ago
  Sure. Our niche is working with ad/marketing/traditional media agencies, SEO firms, and design groups to provide the technical muscle they don't have to get beyond "five pages and a contact form." So what we do is pretty focused: we don't do design, we don't do marketing, we don't do offer SEO (we build very SE friendly sites, but we're not doing keyword research or running PPC campaigns). We're just engineers/developers (if you can call anyone that works with PHP for a living an engineer). :)

shib71 15y ago

Blog engines are a subset of CMSs. They're supposed 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"

dorian-graph 15y ago
That's what I was thinking, especially when I read this part: "The CMS has to be everything to everybody. Wordpress has to optimize for both the cat-picture faithful and the ring-bejewled, hair-fisted mogul. Moveable Type has to work whether you are running a lad mag or poetry journal. This is an impossible proposition." Expecting every (?) CMS to be the end-all solution to every possible content situation is ridiculous. It would be nice/neat but that doesn't seem to be quite how it works—is that idea akin to expecting every vehicle to be able to perform every type of situation available? Expecting your family sedan to also be the workhorse carrying materials and whatnot? What if you only wanted to ride a simple bicycle down the street and not have to worry about a more intricate/heavy one? I use different CMS for different things though admittedly, that makes it harder to master one in particular. http://www.thesecretary.org/ http://www.thesecretary.org/ - For portflio type sites. http://staceyapp.com/ http://staceyapp.com/ - For incredibly simple sites. http://textpattern.net/ http://textpattern.net/ - For most other things. I do feel as if CMS have kind of stagnated for a bit and am a little tired of most so I'm thankful for the author bringing Netsta to my attention—it looks interesting.

mrkurt 15y ago

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.

tedsuo 15y ago

Holy shit people still use Moveable Type?

vladsanchez 15y ago
NPR.org still uses it. And it's a great example of MT's potential.

Periodic 15y ago

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. 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. [1] http://en.wikipedia.org/wiki/Separation_of_concerns http://en.wikipedia.org/wiki/Separation_of_concerns

bergie 15y ago
Exactly the approach I'm pitching to CMSs in here: http://bergie.iki.fi/blog/decoupling_content_management/ http://bergie.iki.fi/blog/decoupling_content_management/

mikeocool 15y ago

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. 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. [1]http://highscalability.com/blog/2011/6/27/tripadvisor-architecture-40m-visitors-200m-dynamic-page-view.html http://highscalability.com/blog/2011/6/27/tripadvisor-archit...

mikx 15y ago

Blaming technology isn't going to change the fact that journalism is still broken. 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.

paxswill 15y ago
I don't know if he still uses it, but Daring Fireball use[s|d] Moveable Type as of at least 2002.
nougatmachine 15y ago
You'd be hard-pressed to find an entity less representative of the 'old media being outflanked by the young hotshots' stereotype than TPM.

Tichy 15y ago

"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." 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. The road to hell is plastered with abstractions...

esmooov 15y ago
Well there are certainly tradeoffs. We do have more apps that can fail. Then again, when one does start to choke, as will happen, the others don't die. So if Baroque locks up, or starts to churn, or I do the ol rm -rf / all that is impacted it our ability to press frontpages until Chef can mint us another Baroque. Also, there's not, so much, another layer between frontend and backend as there is a multiplication of frontends. It certainly may get us into trouble. Luckily, we already were in trouble and, worse case scenario, we all learn a lot from the experience. The hell-road blacktop is something we are trying to tear us by substituting the abstract relation of CMS to site for a closer isomorphy of app to function. Who knows? Might work.

dools 15y ago

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

JoelSutherland 15y ago

Wow -- this really stuck a chord with me. My startup's product is a CMS. Before we build the CMS, we built the API: http://www.gethifi.com/blog/first-we-built-an-api-then-we-built-a-cms http://www.gethifi.com/blog/first-we-built-an-api-then-we-bu... 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. 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.

noibl 15y ago
> You can see that his system has its restrictions too as he enters a pixel based headline size in the demo video. The fact that he specifies the size unit actually suggests that the system would accept others. It's basically CSS after all.
- JoelSutherland 15y ago
  I mean in the sense that he is storing pixel sizes as opposed to some semantic information. This implies either: 1. An elaborate system of decoupling styling information from content via metadata. (i.e. in situation X, this document's headline should be 20px) Their approach would be pretty interesting here. How could this be preserved as their design/layout evolves with time? 2. He was just indicating that headline in position X be 20px, communicating with the layout. 3. He was hard-setting it to 20px. It's probably #1. So if, as he says they switch layouts and output to tumblr, how would that work? Their answer might be a lot of manual work, or it could potentially be something really clever.
  - noibl 15y ago
    The semantic information is already in the selector that pops up, e.g. '.headline'. I don't see why they need to store anything elaborate to make that portable. The scope of the change (document, document type, section, site) isn't shown but presumably it defaults to 'type'. BTW the in-place edit features remind me a lot of this[1] use of Deface[2] in Spree[3] [1] http://www.youtube.com/watch?v=qjgQHzYcxIQ http://www.youtube.com/watch?v=qjgQHzYcxIQ [2] https://github.com/railsdog/deface#readme https://github.com/railsdog/deface#readme [3] http://spreecommerce.com/ http://spreecommerce.com/

Locke1689 15y ago

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

fdb 15y ago
Indeed, Django was made for news rooms! Certainly the whole "homepage is an app" concept maps perfectly onto Django's ontology of projects and applications. The API, however, is not something that's built in. They might want to take a look at Ellington (http://www.ellingtoncms.com/ http://www.ellingtoncms.com/).

Terretta 15y ago

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.

SoftwareMaven 15y ago

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. I don't think its an intractable problem, but the people issues surrounding it make it a hugely difficult one.

brock790 15y ago

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. 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. 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. 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? 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

minikomi 15y ago

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

thomasfl 15y ago

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.