An Argument for Building Your Own CMS

By Deane Barker • September 7, 2009 •

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…

The document discusses the pros and cons of building your own Content Management System (CMS) versus using a boxed one. The author argues that full-scale CMS often have too many opinions and can be difficult to manage, and recommends building the system from the API out rather than the interface and publication layer in. However, the author disagrees with the author’s assertion that a good Rails/Django developer is needed over a boxed CMS, as it may result in re-writing too much functionality.

Generated by Azure AI on June 24, 2024

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.