Here’s the challenge from Jon’s post:

So, here is the deal. I challenge any CMS vendor to rate these in order of priority:

• Editors – A user interface that is a editor or publisher’s wet dream
• Performance – The fastest, most stable and scalable CMS in the world
• Features – The richest set of features any CMS could dream of offering
• Developers – An open, standard, extensible product that makes developers salivate
• Website – A product that can give you a kick-ass website, really really quickly

I recommend that you can read the rest of his post and the comments, as he invites CMS vendors to both naval gaze and offer up which one of these children is their favourite.

My take – I guess it goes without saying that in every R&D project office, of every vendor and for every open source developer – this argument is or should be happening – it was certainly my experience – but the frustration is that with a finite developer resource you end up with a compromise.

Compromise is a bad word and here and on Jon’s blog – we have the luxury of donning our smoking jackets, filling our pipes and pontificating on what’s right and proper and not have to deal with the grubby commercial realities. The truth of course is that a vendor has to prioritize based on return on that R&D investment.

But, let’s not let that stop us!

So, looking at the comments on Jon’s post as I write this – two experienced CMS practitioners, Philipe Parker and Zahoor Hussain both sat firmly on the fence, with a view that is was down to the project.

I think Philippe and Zahoor are right – client engagements vary and of course some clients need more of one thing than another, but I think what Jon is driving at is to look at this issue through a vendors eyes of building a single product.

But – is this a single product for a single market?

If my CMS is aimed squarely at the Mom and Pop store market, it would be wasted R&D effort to focus on performance or features, in fact if I focused my effort on the ‘kick-ass website’ creator requirement – I may not even need to offer much up to developers.

This hints at an issue in our market – bit like the WordPress debate… broad church.. big undefined market.. etc etc.. It’s also worth noting that Jon refers to a website, so you hear a collective sigh as the CMS crowd mutter – ‘a CMS is not just WCM’…  (a respectful nod to you folks, but I digress..).

Anyway, lets try and play the game – prioritize..

I agree with Adrian Mateljan, who in his comment defines performance to include stability and reliability.

I don’t think that every CMS should be efficient enough to run every News International website on a rusty old 486 under Rupert Murdoch’s desk – but having something that is there when the visitor or content author have the good grace to turn up has to be #1.

The problem with performance, for a CMS buyer is it is such a complex intangible, with a variety of factors at play – and for vendors, once you’ve got the basics right, squeezing out the extra horsepower is a difficult internal investment sell vs the sexy stuff that helps the product in a demo.

Also today, ‘throwing tin at it’ seems to be an economically viable scalability option for some – I was talking to someone involved in a serious government website project – using a large rollout of a LAMP stack open source product – who was scaling horizontally quickly and cheaply, cloning extra machines and replicating databases. And it was really, really working for them.

So, yes having a reliable platform is priority #1. After that, it gets hazy for me.

Starting with Developers – would seem to be a stuck on, no brainer #2 – right?

A WCM project is no longer ‘crank the handle and spit out a brochure’ – it’s build me a web engagement or experience platform, it’s integrate to social media, it’s show people my back office, it’s mobile apps, it’s marketing platforms, analytics, lead generation etc etc..

The problem for the buyer is that it’s a blessing and a curse, a good developer platform offers great opportunity, but can mask some of the missing ‘out of the box’ must haves for editors as well as product features.

The good news is if a pretty boy pre-sales hacker can build something that fits your scenario overnight, imagine what your crew can do with it in production? The bad news is the hangover of supporting and maintaining the bespoke work.

It is of course a trade off – in a previous life I saw a straightforward, but large government project turn to a behemoth as a systems integrator cut out the ‘out of the box’ vendor functionality (to the point that the software was a tiny bit of the solution) for something beautifully bespoke – but in the process turned themselves into a software developer with all of that maintenance and support responsibility shared by just one client. Bad news for the client as the budget ballooned.

I’ve also seen a client case study presented at an industry event, where the vendor and implementation partner (and presumably the client) were buoyant about a project that was based clearly on a developer platform CMS, the slides spoke of the thousands of lines of code and man years it took to implement – but, it’s a successful project.
There’s a balance here somewhere, can you build and support what you need more efficiently than taking the out of the box, possibly compromised feature?

Yes ‘possibly compromised’ – it’s hell for vendors to build broad adoption into a feature (rather than offering an API and saying get on with it) it means making decisions for the hypothetical customer. Those decisions are hard, the edge cases you need to build to, the current customers you need to satisfy, the future proofing, the support.. etc. This sometimes means that it might not fit your requirement exactly.

Take the example of Jon’s requirement “kick ass websites, really, really quickly”:

Vendor A has the sexiest website cookie cutter you have ever seen, hell even YOUR marketers could work it (but the geeks suspect some back end ugliness there somewhere) . Vendor B has the API that would allow you to roll-out your websites, your way (eventually). Which do you choose? Do you, take the big red D pill or is it a cocktail of E, F and W?

I also think there is a great discussion point here about the crew you have on-board, a debate Jon has championed himself. You want to be innovative and engaging – it’s not going to just come out of the vendors box, a well marshalled set of great, creative developers could be your projects rock stars – differentiating your business.

With my background, I have to talk about the E – Editors. As I’ve written previously, nothing is going to starve to death your beautiful website like a lack of content. Or shackle your progress to engagement nirvana if people are still emailing you press releases to post. But, without P or possibly D – where are you going to post to?

As I said at the outset, it is a compromise – I’d suggest that vendors really want to please everyone – but they have a certain skill set, inspiration, experience, set of customers or whetever that gives them strengths and weaknesses – and buyers need to match those with their requirements.

It would be nice if we could marshal this unruly market into buyer shaped niches, where short lists pick themselves. But, in the meantime in a procurement (boring old advice I know) it’s important that buyers get advice, look at reference sites, carry out POC’s, talk to an implementation partner that understand and have done this kind of thing  before.

Your choice, your compromise? What do you think?

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.