Why Django and Rails CMS Are So Rare

I’ve been talking to people lately about why there are so few CMS in either Rails (Ruby) or Django (Python). There certainly are a few, but I spend more time looking at content management than most people, and I can think of only four offhand (meaning, without using Google):

• Radiant and Railfrog for Rails

• Ellington and the inventively-named Django CMS for Django

(Update: I totally forgot Plone in this list, but that isn’t Django, and is frankly so it’s own thing, that a more accurate comparison might be Zope to Django. Which raises the question, why aren’t there more CMS built on Zope?)

I’d wager that the number of installs of these systems would be dwarfed by the number of one-off, custom-built CMS implemented in Rails or Django. Put another way, Rails or Django shops are much more likely to roll their own CMS than ever use a “boxed” CMS.

Why is this?

I’m convinced it’s because for many developers, a CMS is seen as little more than a bootstrapper. It’s a system to get you up and running without having to re-implement the major subsystems that a CMS provides. In return for using an existing system, you get:

• A philosophy and methodology for content modeling

• A permissions model

• A versioning system

• A delivery mechanism

• A system to render content through templates

• etc.

These are the major functional blocks of a CMS. Not coincidentally, these are many of the things that Rails and Django also provide. Both those systems are built around sophisticated ORM layers providing what many would consider the ultimate in content modeling – the ability to run wild with your own relational database. Both have deep templating systems complete with philosophies of how templating should work. With various extensions, either can provide versioning and workflow capabilities.

In this sense, Rails and Django provide many of the core building blocks of a CMS, they’re just waiting for someone to bolt them together. A Rail/Django project is a bit of a shapeless mass at first, but if you tell it to be a CMS, it would re-arrange itself pretty easily to turn itself into one.

Shops who use Rails or Django are much likely to simply develop code libraries to provide the functionality necessary to a CMS and them drop those in on a per-project basis. This code may never see the outside of their organization, and it certainly never gets marketed as an installable, usable thing. If it does, it lacks the sexiness of a full-blown CMS, so doesn’t get much traction outside their respective developer communities.

But, you might ask, what about PHP frameworks like CodeIgniter, Symfony, or CakePHP? And .Net frameworks like ASP.Net MVC, Monorail (admittedly not that new), and Entity Framework? They provide the same level of functionality as Rails and Django, but there are still massive CMS communities for those platforms. Right?

But, remember that those frameworks are late to the game. PHP and ASP.Net existed long before any frameworks were ever developed for those platforms. Developers were struggling with basic MVC tasks in PHP for almost a decade before Rails came along in 2003 and raised the bar for everyone. Remember, Drupal and Joomla have been around since 2001 (Joomla was Mambo back then); WordPress since just before Rails came out in 2003.

For both Python and Ruby, they were both “ported” to the web using frameworks that were more or less accepted as the standard for their communities.

On the Ruby side, there has never been any serious competitor to Rails. In fact, “Ruby” and “Rails” are largely synonymous to web developers. The only seriously competing framework – Merb – was absorbed into Rails in 2008. The only other Ruby framework that comes to mind is Sinatra (admittedly, however, I’m not a Ruby hacker, by any stretch).

On the Python side, it’s a little less clear, but, still, the first time I saw Python on the web was in TurboGears – I never knew Python as a “raw” web language. Today, you have some other smaller frameworks like Pyramid (which I hear is wonderful) and CherryPy, but the space is dominated by Django.

So both Python and Ruby have always been known on the web as languages used in the context of some framework which bootstraps the way around many of the problems people turn to CMS to resolve. Thus, these frameworks are often used in place of a CMS.

To take it one step further, I’ll toss this out –

The existence and competence of Rails and Django have prevented a serious, shared CMS ecosystem from developing around either Ruby or Python. Since their respective frameworks provide so much functionality out-of-the-box, developers in those languages have never had to generate critical mass around a CMS. They just keep happily rolling their CMS “from scratch” (in quotes because nothing in Rails in Django is really done from scratch…) and in relative isolation, without having to productize much of anything for use in future projects.

(Conversely, has the advent of competent frameworks for all languages slowed new CMS development? Think about it – what CMS has been released recently that has made a big splash on the industry? Silverstripe has been the new hotness in the LAMP world for a couple of years, and I hear about Concrete5 a little. My own favorite open-source newcomer – ProcessWire – is still way under the radar. The fact is, new entrants are more and more rare.)

Let’s go further –

Do we owe the existence of Drupal to the crappiness of PHP, especially the early versions of PHP? Same on the ASP.Net side – if ASP.Net 1.1 was better, would we even have Ektron? (Of course, the first version of Ektron was built on ColdFusion, but the same principle applies there too. ColdFusion has had a fair amount of frameworks over the years, but I’d wager they’re used in a vast minority of projects.)

At the end of the day, were CMS developed to paper over shortcomings in various programming environments?

Rails and Django have been fantastic frameworks right from the start. They benefited from not being first movers – they were created later in the evolution the web, so they were able to see the problems in other languages and correct them. Because of this, they obviate many of the problems we tried to fix by making CMS, especially a decade ago.

And because of that, we’ll never see a lot of boxed, re-usable CMS made with either of them.

In short, why are Rails and Django CMS so rare? Because those guys have never really needed one.