"Drupal is supposed to be the best CMS ever! So why doesn't it come with a simple news or event system?"

We hear that line in one form or another from clients all the time. We also hear it from fellow collaborators within the Drupal community. It's a fair criticism, too. Shouldn't a content management system include some definition of, well, what content to manage? It should.

The disconnect is that Drupal is not a Content Management System (CMS), nor has it been one for some time. Drupal is a Content Management Framework (CMF), from which you can build a CMS tailored specifically for your needs.

Drupal has had a long and winding history. It began life as a piece of forum software, in effect; yet another Slashdot knock-off. "The Drop", as it is often affectionately known thanks to its aqueous mascot, quickly evolved into a reasonably flexible content management system, centered around chunks of content called "nodes". That's all well and good, but then it kept on evolving. Soon Drupal was so flexible that some people started to think of it as a framework, not as an application for managing pages on a web site. That Application vs. Framework tug-of-war has persisted for a long time, and has been discussed often.

Around Drupal 4.6 or so, one could still speak of Drupal as a system for managing content. The core system was all about nodes. The contributed module world produced modules that added "news nodes" or "event nodes" or "recipe nodes", along with some canned related functionality like "recent news items", "upcoming events", and so forth. That is where most content management systems stop.

The Drop didn't stop. Starting around Drupal 4.7, key developments such as the Form API, Content Construction Kit (CCK), and Views changed the way Drupal worked; not Drupal core, but Drupal the meta-project. "News nodes", "event nodes", and "recipe nodes" got replaced by "text fields", "date fields", and "image fields", which you could now use to build your own news, events, and recipes to exactly your specification. The "recent news items" block got replaced by "build your own news list however you want," tailored to exactly your specification.

That process accelerated, and by Drupal 7 is almost entirely complete. No one writes recipe modules anymore. They simply don't exist. The assumption of Drupal today is that you will build your own recipe out of the smaller, more atomic pieces that Drupal provides, and then use those same atomic pieces to also build your news and event content.

That's great if you want your own recipe site. It's not so hot if you're expecting to just download a recipe module and call it a day. That is, for better or worse, not what Drupal is, nor will it ever be again. Sorry.

What Drupal is today is a tool for building a content management system for a variety of different needs. That's an important distinction for someone looking to build a Drupal site to understand. Drupal is not a CMS. It is the framework with which you build your own CMS, to your specifications, to suit your needs. It is a Content Management Framework.

In many cases, the CMS you need has already been built. Drupal calls these "distributions", and they are ready-made content management systems built with Drupal. Open Atrium (a project case tracker) was one of the first, but recently there has been an explosion in Drupal distributions (such as Managing News, Drupal Commons, and Open Academy to name a few well-known examples). Not all are fully baked at any given time, but many are quite powerful if they fit your use case.

But what if none of those Drupal-based content management systems suit your need? Then you have the option of building your own. The flexibility of Drupal is in building your own content management system by, mostly, pushing buttons. You define your own data model using Content Types and Fields; you define your own displays using Views and Panels. You define your own administrative workflows using Workbench. You define your own site hierarchy and structure using menus, Workbench Access, Organic Groups, Domain Access, or various other tools.

And when you're done, you have your own Drupal-based CMS, as tailored and honed to your specific needs as you care to make it. But even though it's your own specific CMS, you are still able to get the benefit of sharing the same platform as others because all of the building blocks are the same. That means access to the open source support network, ready availability of Drupal-savvy talent, freely available documentation, and the ability to collaborate with others to push the Drupal platform itself forward. A custom Drupal-based CMS is not an proprietary custom CMS, provided it's built using established best practices. It's the best of both worlds.

Of course, building your own CMS, even with Drupal, is not always a weekend task. For some cases it is, but for most institutions it's a bit more work, and requires careful planning and forethought. That's where Drupal consulting firms like Palantir are helpful. We've built Drupal-based content management systems for dozens of clients, and depending on what you need we can build one to your specifications, help you figure out your specifications, or help teach you to build it yourself.

But whatever your approach, whatever your needs, it's important to understand that Drupal is not a CMS. It is a Content Management Framework: A tool for building your own dream CMS, to your specification, for your organization. Just don't forget that step.