Eric built custom systems for the Walker and in my discussions with museums around Australia a common question is “hey, why doesn’t the Powerhouse Museum use a content management system?”. I always answer this by saying we do have content management systems (plural), but that for the collection content it made more sense to use our collection management system for that area of content and blogging engines in other parts. This gives us flexibility and a sense of ‘fit for purpose’ that, from our experience with other large scale projects, a proprietary content management system never can give. Just think if all those ‘installation and customisation’ fees were spent in-house on building in-house development, programming and support skills?
Now, as Keith Robinson points out, developers now can call upon powerful but easy to use developlment frameworks to build customised solutions rather than try for the impossible catch-all out-of-the-box solution.
. . . the case could be made for always building a custom solution (not necessarily a CMS) to suit the needs of the particular content, people and processes your working with.
It sounds daunting, but this is where I think the true promise of a technical content management solution lies. With frameworks like Django, CakePHP, Ruby on Rails and the like we can create custom solutions and construct custom systems that are extendable and much more flexible than most of what’s available today.
I don’t want to trivialize the development of these solutions. Building a custom CMS from scratch, for example, would be very difficult. However, it’s important to note the current costs and effort involved with most pre-built CMSs out there. They’re usually really expensive and already requires tons of work to implement in most cases. It’s going to cost you regardless. Doesn’t it make sense to put that money, time and effort into a true custom solution?
I think so. I mean, yes, you’d need specialized resources for development, but it seems as if you need those most times anyway. I know I’d rather offer my clients resources working toward a custom solution than learning yet another proprietary system.
So you could look at a development framework, as opposed to a canned system. That way instead of “hacking” you could “develop.”
Also with a framework, you can extend beyond Web publishing and build specific tools to help the process. An interactive editorial calendar comes to mind, or brainstorming tools. Of course, if you avoid the “one CMS as as a product” mentality, you could probably find lots of smaller, more specific, products that when pulled together are much more enabling than any bloated, proprietary CMS full of features your people will never actually use.