I often see comments or even posts saying that Ruby on Rails is a CMS (Content Management System) or can be used as a CMS. In this post, I would like to add some dimensions to the debate.

cms definition

We could argue on CMS definitions forever, trying to decide if a CMS is located closer to programming languages, frameworks or applications:

For now, let’s just say a CMS is “something that helps with information management” (the dot can be anywhere on the line above) and let’s look at the question from another perspective: what is the lifecycle of the “tools that help managing information” ?

application lifecycle

First, a client or employee comes with a fresh idea about a new tool or website. The idea is discussed, clarified and finally, implementation (or prototype) time comes.

At this stage, it is not very clear how this idea will evolve so deciding on the tool to use can be quite hard. You can take the most modular approach and write from scratch or try to use an existing application.

Either route has its drawbacks and this is where we need a new dimension:

In the graph above, we do not consider the license price of an application (can be high). This graph simply shows what we know: to reach the same quality, it takes more efforts to write everything from scratch then to reuse existing code.

Once we have a prototype running, we decide that some things need to be adapted:

Adapting an existing application can be impossible or might prove to be very hard and complex. But we imagine the ideal situation where we have access to the source code in the example above.

lifecycle cost

All this gets really interesting when we plot the global cost (initial development, adaptation, maintenance):

We see that there is a sweet spot around the framework area. Lets call this spot the CMS sweet spot. We also see that if you can live with an application’s feature set, this will prove much lighter initially and in the long run (maintenance).

Undoubtedly, Ruby on Rails is a framework that aims to ease initial development cost and there are many open source plugins to help with things like authentication, upload or file attachments. So rails with its plugin friends looks very much like the ideal tool that provides power without loosing flexibility. We could therefore say that Rails (with its friends) is located at the “CMS sweet spot”.

However, there might be some caveats to writing applications this way.

architecture

Since Rails imposes few rules on how you organize your models together, you are left alone to decide if your page “belongs to” an author or “has many” authors. You have to decide if a Contact “is a” page or “has a” page and all sorts of architectural decisions that will greatly influence how you bind things together. As soon as you start creating models and controllers, you loose flexibility. Of course, you can always rewrite parts of the application and migrate your data accordingly, but that won’t be easy and more often the not, once the application has become complex, there are no more resources for such in depths changes: your customer prefers to live with a sub-optimal architecture then to reinvest in refactoring.

When the maintenance cost becomes prohibitive, the quality of the application degrades.

no free features

If you write from scratch, you only get what you wrote. Maybe you don’t really need image resizing support, but it might become handy; you don’t need a complicated access model but your client will appreciate that some people can write new content and others cannot; you don’t need this api, but someone might use it to import data, etc.

polish

And finally, if you use a framework and code everything from scratch, you might not have time to test and fix all edge situations and you will teach your clients to live with reduced quality expectations because of the cost constraints: the last 5% needed for high quality can take more the 40% of the development cost and you just cannot afford it.

conclusion

From the caveats mentioned above, I don’t think Ruby on Rails (with its friends) is located at the “CMS sweet spot”. It is a very powerful framework that encourages good practice and clear architectures, but the development costs implied by the creation of any simple or complex “content management” based application is too high to make it a good contender to things like djoomla or drupal.

And this is why I have created zena and probably why others have built CMS tools for rails: so that we could build flexible applications as easily and fast as the PHP alternatives while keeping the power of Ruby on Rails accessible when we need it.