Ask HN: Is Content Management a solved problem?

I share your dislike for Drupal, but I wouldn't go so far as to say it's unimpressive. My gut instinct is that Drupal is about as good a hybrid framework/CMS as you can get. That's not to say other approaches might not hit your or my sweet spots better, but fundamentally I think it's operating at the wrong level of abstraction.

The problem is to give you anything that works out of the box a CMS has to make a ton of assumptions. Drupal goes to great lengths to make everything configurable and hookable. It's hard to come up with a use-case that can't be coded using Drupal hooks. The problem is you face the crushing weight of a system designed to meet the needs of any and all potential websites. Even though deep knowledge of the system allows you to do amazing things with very few lines of code, the system itself is a straitjacket where the cost of seemingly trivial customizations can be crippling. If you find yourself with a scalability problem that can't be solved with naive caching you may well be totally fucked.

Contrast to web frameworks like Rails. The goal here is to give you a set of raw tools to make it easier to handle the trivial yet repetitive tasks that come up over and over again in web development. Unused features in Rails don't introduce cognitive load on the developer. If you've spent any time writing CGI scripts before then you can see the reason for almost every feature and design decision.

It's possible to build a career on top of Drupal. Becoming expert in it will allow you to "solve" a wider range of client problems faster than any other CMS or Framework. The problem is that you have to embrace compromise at all levels. You will never create an amazing design in Drupal. You will never create a successful startup in Drupal. You will never write a lean and scalable site in Drupal. If you are willing to compromise you will find a huge swath of potential clients who think $1000 is a lot to pay for an e-commerce site or want a do-it-yourself solution with a little hand-holding.

Why don't you want the users to join an Organic Group? They don't have to explicitly join: you can have it happen invisibly at signup time. You can write code that intercepts the user as they register (or, better, just after they click an emailed link to confirm their email address), notices that their email is on a list of "users that should be added to group X when they show up", and adds them to the group. Then it's just an, um, "simple" matter of using the permissions system. (Which can, indeed, be a little hairy. But not so hairy that lots of people haven't used it.)

Of course, like so many Drupal problems, this will require some custom code...

A framework is unified set of tools that make it easier to implement repetitive tasks. It’s not intended to be an end-product. Instead, it’s meant to be a foundation upon which you build your application. A framework, by definition, is a generic system. CMS, on the other hand is, an application that is supposed to solve a specific problem: managing the content. The problem with Drupal is that it tries to be the both a framework and a CMS and introduces a maze of abstractions.

The content itself as well as the kind of content management practiced tend to vary from one organization to the other. The whole concept of an ‘definitive CMS’, therefore, is ridiculously delusory.

A CMS, in my opinion, can approach this problem in either of two ways. Since a core set of common features could still be identified in each kind of CMS, a CMS can be generic system which different category of users can build upon to meet their respective requirements. Secondly, a CMS can zero in on a particular niche and provide all content management features applicable to that segment. This, of course, would render it, and rightfully so, unusable for other niches.