Inspired by a blog post by Ron Miller, where he comments on an article by Clay Johnson, that states that Content Management Systems just don’t work and you should seriously consider building one yourself. Really? Clearly with my background this got my attention…
Wow.. I was astonished by the original Clay article. In 2009 folks are still advocating self building a CMS? Not for some specialist task, but just for managing web content! I then started hacking together a comment for Ron’s blog and it started turning into this, full blown post.
OK, so previous generations CMS products were pretty close to being IT development frameworks and if this were still the case – I could have some sympathy for Clay’s point of view. If your CMS vendor (or open source project) of choice is handing you a bag of bolts and suggesting you get on with it, then as a developer I would agree that development frameworks have moved on and could be a better bag of bolts.
In those days we’d propose that an organisation build a contribition user interface (or Content Management Application as we used to call them) and a website (or a Content Delivery Application) based on a bunch of API’s – which was what the customer purchased. In those days we recognised that the CMA was 70% of the effort.
A hand rolled ‘CMA’ was nothing like the business user focused tools of today. Today a CMS, and you can pick one from a wide selection of commercial and open source developers, is a sophisticated business user’s tool. We are way past the “here’s a fancy database and a bunch of API’s – now go build” formative years of this market.
If we imagine that development frameworks, like Ruby on Rails, put you at that same starting point we were at in the late 90’s (which is a very poor assumption) – does anyone still want to direct 70% of their development on the management application – before you even start delighting your site visitors?
Clay is of the opinion (and seems this is his view on all developed software) 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.
That’s quite a position to take.
I’d prefer to take that statement and replace ‘opinions’ with ‘experience’. Opinions come for free, experience is hard earned. I can be less sure about all open source projects, but the good ones and all recognised commercial products have years and years of experience equity (and R&D dollars) being applied to each release.
The bright people on a software project agonize over design, architectural decisions, best ways to make it scalable – they do this through personal experience, innovative ideas, customer feedback – a host of experience based scenarios.
There is such a broad range of products in this CMS market – you are going to need to have something pretty special to compete or to render obsolete that ocean of existing IP.
The CMS market is being described increasingly as commodotized and certainly the basics are; WYSIWYG editorial, create pages, change navigation, add images, add meta-data etc etc.. are all there. Why would I want to build all that stuff again?
Do I want to spend 70% of my budget competing with all of that? Will it stretch to the cost of learning all those lessons as I overcome my inexperience? Will my project delight my content contributors as much as my visitors?
And that last point is important, back to todays CMS being a business user tool – I have said in this blog before a CMS projects success hinges on that contributor adoption – for fresh content – the life blood of your website.
I would also guess that a user interface that suits Clay, a developer, is not necessarily going to be right for the marketing team that will have to feed this thing.
Plus of course if, or maybe when, things get sticky, you’ve got a community, support or a warranty to fall back on and a bunch of people who know how your stuff works.
Clay singles out Drupal and implies a frustration in working with it – my suggestion would be to get involved with that community – apply his development cajonas to becoming the change he wishes to see. (Apologies Gandhi). The world of CMS is a broad church and if the Drupal community won’t embrace his ideas, there are plenty of others.
Of note of course, is that Clay published these ideas using a blogging tool… a focused kind of CMS.
I’ve already gone on too long – this is the classic ‘build vs buy’ argument, covered in detail elsewhere – and exposes the gulf between writing code and developing software.
Fancy more of this?
Subscribe to my Rockstar CMO Newsletter
I’m a 3xCMO, now a marketing strategy advisor and podcast host at Rockstar CMO. Although, I’m not a rock star, but a marketing leader, strategist, content marketer, columnist, speaker, industry watcher, and creator of ART (Awareness, Revenue, and Trust) for the companies I work with. But most of all, I am an enthusiastic tea drinker.
You can find me on LinkedIn, Twitter, or now Threads! – or listen to my weekly podcast at Rockstarcmo.com
The half-baked thoughts shared on this blog may not reflect those of my employer or clients, and if the topic of this article is interesting or you just want to say hello please get in touch.
Good post Ian. I think you’re right that the original poster is largely lamenting a poor experience in working with an Open Source solution/s. Having spent a fair few years working with proprietary CMS solutions I have be using an Open Source solution a lot in the last year. On the whole that has been a very satisfying experience and I’ve often been surprised how good some of capabilities are but when you do get issues it can be an extremely frustrating experience wrestling with limited or poor documentation and navigating the communities to find answers. In some instances you do get the sense that it would be easier to pull together your own solution as at least you’d have a better understanding of what’s under the covers. However, I think this is a reflection of these solutions being less mature than many of the proprietary ones that have histories dating back into the 90s and that the emphasis is often very much on the coding rather than the documentation that would help make the solutions more understandable for less technical people and therefore easier to use.