An Argument for Building Your Own CMS
Content Management Systems just don’t work. : This is an excellent post about something we’ve discussed before – is a “boxed” CMS really worth it? For instance, in this excerpt, the author is struggling with the decisions that the vendor or platform makes for you:
See, the problem with a full scale Content Management System is that it has too many opinions. Those opinions were though of by somebody other than you and the needs of your organization. The more developed a content management system (or any piece of software, really) the more “opinions” it has. And the more “opinions” it has, the more likely one of them is going to really tick you off.
I can relate to this. We work with one system in particular that makes an astonishing array of presumptions about how you’re going to use it, and if you try to step outside those presumptions, demons fly out of the abyss and try to suck your eyeballs out.
This goes back to a previous discussion we had about Content Management as an API. In that post, we had a great experience with hand-rolling a CMS. Sadly, in another situation it was the exact opposite – we tried to hand-roll something simple, but the client wanted more and more “CMS-ish” features, and there came a point where we realized we had spent so much time and effort that we could of purchased a commercial system and been better off.
For me, the solution is a boxed system with a great API. In fact, ensure that the system is built from the API out, rather than the interface and publication layer in. For now, Episerver has filled this need for us. eZ publish is good too, and Ektron’s API is getting better and better every release (though they’ve had the distinct disadvantage of backing the API into the product, which makes it so much harder and longer, as they’ve been fleshing out this API for about four years now, and are just now getting close to done with it….)
So, in the end, I don’t agree with the author’s contention that you just need a good Rails/Django developer over a boxed CMS. He says it’s an over-used point, but I still believe you just end up re-writing too much functionality in the end.
Selected Reader Comments
Like many blogs of its era, Gadgetopia allowed reader comments. Below are selected comments that were left on the original post.
I have exactly the same opinion about Drupal, built on the foundations of an excellent API, shipped with a simple core distribution and extendable with contributed or custom modules.
I would say that you should build a custom CMS only if the underlying concepts and architecture of your preferred CMS are really disconnected to the specific needs of the project. In this context it could be more appropriate to design a custom solution than to bend the “boxed CMS” to fulfill customer needs.
The most difficult task, and this is where you need expertise, is to be able to evaluate the limits and actually know when you should stop torturing your CMS ;-)
I’ve been espousing a similar argument among my coworkers and executives for some time now.
I like to say, “Content Management is a process, and the software we use is a manifestation of that process.”
When you take on a “boxed” content management system, you are, by extension, adopting the process that the makers of that system have designed.
By using a boxed solution, your end product is going to be, to a certain extent, just like all the other sites that use that product – you’re going to be just another me-too.
If your site doesn’t follow that process, that’s where you start having problems.
So, following this, if your site/business/idea is truly new and unique then the process by which you manage it will be truly unique, and the software manifestation of that process, the CMS, will also be unique.
But, this fits very well into the “CMS as an API” - because the fundamental building blocks are all going to be very similar – its how you wire them together that changes from process/idea to idea.
So, if you have another cookie-cutter website, might as well use some cookie cutter CMS.
But, if you have a truly novel idea, then to execute that idea, you’re going to need to have a truly novel CMS.
The thing is, 99% of Web sites are “cookie-cutter” as you call it. As much as everyone wants to believe they’re doing something amazing and original, they’re pretty much re-solving the same problems and implementing the same functionality as everyone else.