![[ t ]](/images/structural/icon_twitter.gif){kind=icon}
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.
What This Links To
Content Management as an API
Here's what I want: a CMS that was truly developed from the API out. If an interface comes with it, great. I might use it, I might not. I've talked about this before. Last year, I said this: When building a new piece of software, you really…
Comments
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.
So, if you have another cookie-cutter website, might as well use some cookie cutter 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.
Another great CMS that's popped up on my radar recently is Sitefinity - www.sitefinity.com - which is another extend-able and flexible ASP.NET based solution.
Has anyone played with both these CMS's and which do they prefer?
Looking at the EPiServer site it doesn't seem to mention anything about localisation which Sitefinity handles very well. Anyone have experience with this?
EPiServer localizes like a mofo. Most CMS coming out of Europe do that quite well.
Add Comment
- Right-Click Command Prompt Hack by realist, 4 hours, 10 minutes ago
- LightKeeper Pro by Don, 13 hours, 11 minutes ago
- Why Windows Sucks by Jethro, 17 hours, 37 minutes ago
- elgooG by shopping, 2 days, 6 hours ago
- Halo 2 vs. Tribes 2 by jingle balls, 2 days, 9 hours ago
- Show 5 more »
- Crowbar Hijinks at CERN by Deane in 2008
- Colleges still offer email? by Deane in 2008
- Busted By The Wii by Deane in 2007
- Turning Classics into Hybrids by Deane in 2007
- Macs Crash Too by Deane in 2007
- Show 8 more »