Ask HN: Is Content Management a solved problem? | Hacker News Reader

Ask HN: Is Content Management a solved problem?

30 pointsteej38 comments

As part of one of my hacking for fun projects, I decided to take on the task of building a lightweight CMS for Ruby on Rails. It's more of an exercise to stretch myself beyond my current experience than anything else.

As I started doing research and building it out, I realized how many CMSs exist out in the wild today[1]. I also determined that this is a project that doesn't scratch my own itch, which makes me nervous about making design decisions.

None of these things will deter me from finishing my project, but some of them may deter me from publicly releasing it.

What does Hacker News think about content management? Is it a flawed system needing radical rethinking, or is it merely a landscape littered with half-baked options? Any reflections on having non-technical people update dynamic content would be appreciated.

[1] -- http://en.wikipedia.org/wiki/List_of_content_management_systems

View on HN

I make a CMS and sell it for a living (we also have an open source version). I'll be the first to say we're nowhere near 100% there, and won't be for a long time.

CMS is a bit vague because it encompasses so many areas that overlap, so one product is inherently not going to excel at all of them. These areas include:

- Traditional content management - Document management - Workflow/notifications - Revision control - Access control/restrictions - Website editing - Website layouts - Website features (forum, search, blog, events, member registration, ad infinitum) - Website building framework for custom development

The core of a web CMS is just a framework (or in traditional CMS-speak, a content server...), then come the apps that each handle different components of the site (blog, events, etc), followed by one of those apps which handles the actual content management itself which tends to encompass the rest of the above points.

As you can see, this is a lot for a single app to do and do well. Some of these aren't needed for smaller sites, but the same CMS that works well for those then won't work well for larger ones. And the more features a CMS has, the less it retains of the simplicity that made it appeal to the smaller sites.

Personally, these days I use our CMS as the framework that underlies the SaaS software I'm building for my other startup, so that's where my focus has been. So for at least the next while, the biggest changes in our CMS are likely simply to be framework-level things to save development time or improve performance and things like that. But again, those only benefit me and those users using it as a framework, not those who just need a simple web page editor.

In short, CMS fails because it tries to be everything to everyone. Blogging software overtook it in popularity because it did exactly the opposite. Now most blogging software is following the same path and becoming bloated CMSes... Kinda funny to watch actually :)

Content management is very definitely NOT a solved problem.

Even if you restrict the domain to just blogging software, there are a ton of unsatisfied people (myself included). Blogging software is still bad enough that a bunch of people are still writing their own.

A possible solution is something that's more than a framework but less than a fully functioning software package. I think that's the general idea behind drupal, but during the limited time I spent with it I wasn't very impressed.

I agree. There are also constant give/take issues attacking it: Simplicity vs This feature, Power vs Eas of Use, Good tools for non technical people vs Fexibility etc etc.

None seem to have gotten it down yet.

Basically I agree. Content management is a lot less solved then spreadsheets or word processing.

"Good tools for non technical people vs Flexibility"

Depending on the group of people using the installation I think this is huge. For user groups that include a big slice of non-technical people web interfaces still have a ways to go.

Lots of businesses have spent big rolls on CMS deployments only to continue farming out the maintenance of content to web techs because the interface "wasn't enough like Word."

Whichever companies develop platforms that Mom and Dad can use reliably will make a mint.

There are also constant give/take issues attacking it: Simplicity vs This feature,

The obvious solution is to divide the software in two parts: a "framework" that takes care of storage, authentication, etc. and modules that implement features using the other part's API.

I've used Drupal for a few projects as well as having written more than a few CMS solutions from scratch in PHP and Rails.

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.

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

Can you substantiate these claims? It sounds a bit as if you're generalizing based on a bad experience in trying to use Drupal. And to be fair, Drupal does take a while to get used to -- you won't build an awesome site in the first week after untarring the package on your server.

However, all of the following sites were built on Drupal -- and there is nothing intrinsically fixed about their designs or their ability to scale, etc.:

-The Onion: http://www.theonion.com/

-MTV UK: http://mtv.co.uk

-Yahoo Research: http://research.yahoo.com/

-Ozzy Osbourne: http://www.ozzy.com/

-Moby: http://moby.com/

I was a professional PHP developer for 4 years before picking up Drupal. I studied it. I read books on it. I built a half dozen sites with it. I participated in the forums. I submitted a couple patches. One thing I never did is "untar the package on the server" because I'm a real developer and of course I have my dev environment set up locally. Deployments are pulled from source control.

My closing statements were definitely hyperbole, but I fundamentally stand by them, both as a web designer and a developer. My opinion comes from experience, which I believe is more informed than looking at a bunch of sites without knowing what went in to each one.

The thing with Drupal is that it caters to generic needs very well. It will get you 95% of the way on any project with moderately standard functionality. However the last 5% includes fine design and usability touches that I take as a point of professional pride.

I had one project where I built the whole thing in Drupal in about 20 hours. After crossing the finish line, the client was unhappy with the checkout flow from the e-commerce section. I wasn't happy with it either, but it was just the way the module worked. Although there was no reason we couldn't re-work the e-commerce module, there was no modularity or unit tests to help with this kind of refactoring. I estimated the rewrite to be somewhere in the 20-80 hour range given the potential for massive breakage. In the end we decided to cut our losses and spend 40 hours rewriting in Rails. We fixed a lot of other design details along the way, and we have a lean 2000-line code base that we could extend in any reasonable fashion. Sure we couldn't drop in a forum/gallery/blog/library at the drop of a hat, but is it more important to have a million pieces of generic functionality at the tip of your fingers or to get the core user experience correct? It's bad enough when you have to fight with the client to get the UI right, but what I find truly unbearable is when everyone's on the same page, the ideal UI is clear, the logic is simple, yet you're encumbered by technology that's designed to solve 1000 extra problems you don't have at all.

Well, I think we're using the term design in a couple of senses. The sites you provide (and dozens of others, really there are a lot of awesome sites running on Drupal) are solid, clear, high quality websites. They have good visual designs and layouts, and they have managed to scale well. This is true.

They aren't groundbreaking websites, however. They do their job well and all of those sites are successful because their owners/content was successful before their current drupal incarnations were developed. I'm also aware that there are some sites that have launched their 1.0's as drupal sites, I think it's pretty safe to say that these sites are familiar conceptually (like digg, like slashdot, like etc.) In that sense they don't have "amazing" designs.

Perhaps we should rephrase this as "you will never create an innovative desgin in Drupal." I'm generally in favor of Drupal, but I think this is probably the truth.

It's also not a bad thing. Websites need to excel at presenting information above all else, and drupal sites provide a lot of power to make this happen. Most websites are adjuncts to other things that organizations and individuals are doing, and they don't need to "shift the paradigm of web design and architecture." Lots of people need websites like this, and drupal's ideal for these cases.

---

I think the "you'll never create a successful startup in Drupal," statement requires a bit of a clarification, but it's probably mostly true: given the constraints and assumptions of the platform, you're unlikely to create a new kind of website in Drupal that will succeed on the Internet. The next boom of new websites (like blogs in 2000, or social networking sites in 2004, or webapps in 2008) isn't going to be built in in Drupal first.

But it will be built in drupal second (maybe,) Drupal is great for making custom instances of websites that are targeted at niche/specific audiences. And that's a huge chunk of websites. It doesn't make a lot of sense to build highly local sites like "digg-chicago" and "digg-Sao.Paulo" all in custom-built perl or ruby based sites, when something like Drupal promises to make development and maintenance much more simple in the long run. These kinds of sites have a great deal of worth and potential.

---

As for lean and scalable.

Totally the truth. Drupal can scale, but it's a pain in the ass. Which means, a sliver of the huge gains made in development times and maintenance times is absorbed by increased architecting costs. Lots of memcache and hardware can fix this problem. But if you get to the point where you get to that level of demand, presumably you'd have to have a sysadmin on staff anyway, so I'll concede the point, but I think it may really be a draw.

Previous commenters have demonstrated a recurrent theme, that the CMS problem is "huge" and "far from solved".

But what you must understand is that almost every use case you come across is a niche market. It's a huge number of medium-to-small problems with medium-to-small user sets. A medical school has different needs than a law school and a law firm has different needs yet again, as do hospitals, corporations, the GAO, the White House, etc, etc.

One huge value someone could add would be to develop bridges between the user databases. Right now we use Joomla, Wordpress, and MediaWiki. We are fortunate (sort of) in that we have a university's LDAP server to provide user authentication, we just fetch roles out of there, and we really only need logins for the Joomla app. But it would be great if someone could come up with an uber-site authentication system with plugins for the different CMS systems and authentication systems.

LDAP-----\......................../----Wordpress

gmail------\...................../-----Joomla

openID----->uber-auth>-------mediawiki

yahoo-----/.....................\-----generic for your-new-app

Joomla---/.........................\----.htaccess

one bridge, lots of plugins for both sides of the bridge.

I think the first point to realise is that there's a huge scope as far as potential CMS functionality is concerned.

At one end of the market are the big enterprise level CMSs complete with workflow, permission groups, asset management, etc.

At our end we've created a hosted solution (http://www.cushycms.com) that takes 2 minutes to install and no training, etc.

Personally it always amaze me how difficult most CMSs are to use. The fundamental point of them is to allow non-technical people to edit content.

The other problem we've tried to tackle is that it can often take days for a developer to implement/customize a CMS.

Sure we've sacrificed some functionality (editors can't add pages) but we felt it made sense to start with base of easy/fast and build from there.

I think there are enough specific end-user needs to justify tons of specific CMS instances. It's funny to me how much wordpress is hacked up in order to try and accommodate more business oriented clients. I think tons of freelancers sell their clients hacked wordpress sites because it gives their clients CMS access, even if all they are doing is "updating a blog post".

A CMS is just a tool, not a solution. So rather than asking if CMS is a solved problem I think a better approach would be asking what problems need which kind of CMS and building from there.

If there's a 100 different systems out there that's a pretty amazing sign that CMS is not a solved problem. I think part of the problem is there is no way to build a one-size fits all solution. Any solution will need to be customized by a technical person.

Content management is definately the way forward for any website that contains a significant mass of editorial content.

The challenge in choosing a content managment system (CMS) is that it is typical example of 'enterprise software' (in my head I am saying 'enterprise' in a silly voice and rolling my eyes), and therefore attracts a high proportion of expensive, yet functionally unimpressive offerings.

As somebody who has been around the block a bit with several CMSs, from high priced bespoke packages, to completely homegrown, to big name MeToo clones, I can tell you that in terms of functionalty there are 4 systems which lead the pack, and these are all open source. They are: Drupal, Joomla, Plone and Mediawiki.

However, (and this is where it gets interesting) the solutions named above are often ruled out in the early stages of procurement precisely because they are open source. Want to actually pay for a CMS system? The field for proprietary CMSs is wide open, and there is no reason why another competitor cannot break through.

There's certainly a lot of half-bakery out there in CMS land, but as others have said you can't "solve" content management any more than you can come up with a single standard size for books and publish all books that way. All content is different, and the way it's produced is different.

I think there is a market for componentized solutions to CMS -- solve one portion of the problem, but solve it really well. This is basically what drupal is trying to do but I would sooner eat my foot than configure drupal.

So, hey, get cracking on that awesome new CMS of yours! :-)

Maybe the best approach is to do as Ruby on Rails did -- do something real, and then create your tool/infrastructure around/in reaction to that (in Rails' case, it was Basecamp and subsequent applications, as well as contributions by other working practitioners -- not stuffy people sitting on committees writing specs instead of applications that people use).

So, in order to make a CMS, you ought to have some content to manage. Make your CMS really, really good at managing that particular collection of bits you care about so dearly without making things complicated. That seems like a good strategy to me. Yes? No?

To answer your question directly, if you think you can create some useful software that scratches your itch in a novel way (slightly novel is more than sufficient), by all means work on it, and post a follow up here so we can try it out! :)

Thanks for the advice on focus. I will definitely post my finished product.

Ruby on Rails is not a CMS. It’s a framework. While it’s true that the line of demarcation between a framework and a CMS continues to blur, it’s still important to be able to tell one from the other. Conceptually, the two are discrete entities.

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.

Before I was overcome with a hell-bent desire to actually learn how to program, ExpressionEngine (EE) let me build relatively powerful custom database-driven applications without using any code except its template tags in addition to the obligatory HTML/CSS/Javascript. If that's the definition of what a CMS is supposed to do, then I think EE nails it.

I haven't used it since 2005, but it looks like they've been steadily improving (their dev team was really responsive) and I believe EE was used to run Change.gov.

It has a powerful templating engine. My inner designer is obsessive about fine-grained control over the end result of any project I do, and I don't remember a time when EE prevented me from achieving the design I wanted.

I also liked its custom fields and 'weblogs'. EE 'weblogs' can be thought of as custom database tables, which are easily created and modified by the EE graphical interface. You can then create as many custom fields as you want, and relationships between fields, and then insert your data however you want into your website using simple template tags.

So, for example, I made a personal website in which I could keep track of books I'd read, the authors, quotes that I liked, and my book reviews. Each kind of item was stored in its own table and I could insert all the relevant information for any book into a blog post by using a custom tag.

"Content management" is too broad to be "solved". For certain types of content it might be, but the types of content you can have is endless, even for the web.

My personal experience is that there is a lot half-baked shit out there for CMS systems and few, if any, really deliver on the dream.

Part of the problem (IMO) is that they're trying to allow very non-technical users to do pixel-precise web layouts and the technology just isn't there yet.

I'm not sure how you define a "solved problem." Do you have an example? When it comes to end-user software applications, I can't think of any problem that has been solved categorically (contact management, calendaring, browsers, word processing, spreadhseets).

That's why I would take the other comments in this thread with a grain of salt. True, nobody has solved content management -- BUT, the leading solutions have put in a ton of work to solve vast swaths of the problem space even if they haven't nailed the whole thing.

Wordpress, for example, while not the most architecturally elegant piece of software in the world, is an incredibly rich, powerful, and useable content management system. The plugin system enables a developer to extend the application in any number of directions, while the administrative toolset is sleek and sophisticated yet easy enough for hundreds of thousands of bloggers to use.

Okay, I didn't mean to turn this is into an ad for Wordpress (which I've used as a CMS on several projects, btw). My point is simply that your CMS would have to get very far advanced before it even reached the terrain where the problems that Wordpress has not solved lie.

I don't mean to discourage you in your project, but simply to point out the road might be more difficult than others make it appear. As a consolation here are a few areas that I haven't (in my own limited experience anyway) seen many CMSs nail effectively:

* Content versioning

* User commenting features (threaded commenting, ratings, user management/ownership of comments -- basically disqus's whole business is built on this lacking)

* Snippet management (tools to manage little copy snippets etc., not just pages/posts)

I'd be curious if anyone else had any specific features they felt were part of the "unsolved" problem set.

What's missing are CMS's with well-designed user interfaces. From what I've seen, Wordpress has one, and that's it (at least of the open-source options). There's room for a CMS that focuses on non-blog content but provides good and separate interfaces for configuration by a programmer and content management by an end-user.

My experience with CMS has been that of doing the initial configuration / development / programming of a CMS which someone else (usually non-technical) will enter content into. My requirements are two: the system needs to be flexible enough for me (a developer) to configure the way I want, and easy for the other person to use without my help.

I would focus on making a great interface for the end-user, and a flexible API / plugin system for developers. This is more-or-less what Wordpress does. Most CMS's seem to take the middle route of trying to make the system easy for an end-user (non-programmer) to configure. This is extremely difficult and unnecessary. Better to make it easy for someone to hire a programmer to set up the system and for them to maintain it themselves. Even Wordpress does a poor job of documenting its API, making plugin development more difficult than it should be.

But really, the key is a great user-interface. Do that, and you should do well.

I did some looking around a while ago and couldn't find anything that gracefully gives users ACL-like, fine-grained control over who can see which of their postings. This seems like a clear hole in the space, too me.

I'd like to be able to create a group of users -- let's say by email address, so they wouldn't even have to be registered with the site at the time I created the content -- and then be able to post specifically to that group.

Drupal Organic Groups gets close, but sort of misses the mark -- I don't want people to have join a group, I just want them to see content I've targeted to them when they come to my page on this hypothetical site. Also Drupal's permissions system seems sort of disjointed -- various plugins can too easily collide with each other's customized permissions schemes. (Caveat: this based on reading, not implementation, so maybe it can be done.)

Also -- I want this to be something I can run on a server I own. I don't want to put content I care about in the cloud.

This idea has been kicking around in my head for a long time now. If anyone knows of a CMS that lets you do this, I'd be interested. Someday (like when I've finished with grad school?) maybe I'll scratch this itch...

It just so happens that I just finished building a Drupal system that stores content until a user with a particular email address logs into a site, then shows it to them.

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

"I just finished building a Drupal system that stores content until a user with a particular email address logs into a site, then shows it to them."

Interesting -- public code?

"like so many Drupal problems, this will require some custom code"

Yep -- that's what I mean, it's an itch to scratch, not a tool I can deploy today. I wish I could deploy such a tool; it would be useful w/ my graduate work, which involves lots of collaboration w/ different groups.

It sounds like you're a heavy Drupal developer, and so your comment gives me some hope that if I were to try to implement this with Drupal, I wouldn't end up in a stinking morass. (At least not one I didn't make myself.)

your comment gives me some hope that if I were to try to implement this with Drupal, I wouldn't end up in a stinking morass.

Oh, no, Drupal pregenerates the stinking morass for you. ;)

Well, it's not really as bad as that. But the person in this thread who pointed out that Drupal development is the art of compromise was on the money. And the learning curve for Drupal 5 can be rather like scaling a sheer cliff. It all depends on what you're trying to do, though. If you're willing to compromise your goals to fit the scope of things that you can convince Drupal to do right out of the box... it works out of the box!

Get a book or two. The Lullabot.com folks seem to be good teachers. In particular, if you find yourself wanting to write PHP for Drupal, get a copy of Pro Drupal Development and sleep with it under your pillow.

As it happens, my email thing is not public code. But perhaps it could be. I seem to have already identified one potential user! But the stuff I wrote would have to be factored out and turned into a plugin for Organic Groups, or perhaps interfaced with the Actions Module.

I dusted off my previous experiments with Drupal and started messing around. I pretty quickly ran into barriers with the 'out of the box' snap together model, but I see what you mean, the infrastructure could work with some customization.

But, the 'stinking morass' thing gets to me -- maybe better to start closer to scratch w/ e.g. Rails or Django? Why did you decide to go the 'customize Drupal' route?

(for my own notekeeping: brought this idea up again, here: http://news.ycombinator.com/item?id=466673)

I'll consider CMS solved when end users can create most any basic site -- to the pixel, with absolutely no XHTML or CSS written by hand coupled with a robust management and analytics framework. It's a ridiculously difficult problem to both create a system that is developer AND end user friendly that satisfies this requirement.

I think it's through the development of some new UI paradigms that this sort of problem will eventually feel more "solved". That said -- have you guys looked at Squarespace - http://www.squarespace.com/ (Disclaimer: My company.)? We have a pretty unique take on the problem -- with separate editing modes (content, structure) + an expansive module base + an excellent visual CSS designer + an extremely robust hosting core (think: S3 for pages). 5 years in business.

Definitely don't feel we've completely solved it, as evidenced by our system constant upgrades, but it's a great shot. If anyone on this thread is interested some facet the CMS problem, feel free to add a question.

Broadly defined, NO I don't think it is solved by a long shot. In the narrow Hey-look-I-made-a-multi-user-blog sense, then sure. But beyond that think there is still a lot of room for innovation. For instance, I've been looking for a CMS that would let multiple authors submit articles directly to a digg-style rank-based page, but none of the solutions work without a real mishmash of code. Also, it seems as if a lot of systems out lack good out-of-the-box rich media support. It would be nice, given that it is 2009 if you could record right from your microphone/webcam/still camera and publish to your site without needing some third party tool.

You generally can't throw a rock in a crowded room of programming nerds and not hit someone who has built their own CMS these days. I've basically built my freelance career out of building and selling a set of CMS software and I'm sure others here could say the same.

For a simple term like Content Management System, it seems like everyone has a different interpretation of what that means. I think that alone answers you question about whether or not this is a solved problem. There's always going to be some target market with a need that can't be solved with current CMS software.

Cms is a feature of a wider business organizational tool in the same way GTD is a feature. It is the wider business context that makes these features truly useful.

Even if it was, why wouldn't you release?

I'd rather publicly release need-driven, thought-out, polished projects. If I can't really find direction, I'd rather just finish it and catalogue it silently.

That's fine, someone might think it's great even if you don't.

has anyone on HN tried Alfresco? Usually I just roll my own PHP CMS or battle with Wordpress, but if I was to go with an enterprise ready open source solution this would likely be it. Anyone have testimonials?

CMS is definitely an NP-hard kind of problem... no matter how many features a CMS has, end users will always find something lacking...

One of the other issues I have found with CMS is that the software does not evolve as fast as the business requirements... so good luck!!!

AFAIK a good CMS for e-Governance domain is not solved.

Reply on news.ycombinator.com