This would rather generate the following matricial split:

+———————+——-+——–+
| | CPS | PMS |
+———————+——-+——–+
|Content Platforms | D | D P |
+———————+——-+——–+
|Content Products | E F | U W |
‘———————+——-+——–+

U = Users 2.0 but could become E

More you are looking after a High-end offering, clearer the matrix will be declined in different lines of products. On the low-end market segment everything is still heavily-coupled but content platform commoditization is ramping.

P.S: Where is Jahia? Somewhere in transition to a better Platform + Products split-up…

P.S. @pmonks – Do you actually like the editorial interface for the VCM? V7? V8?

* Performance
* Website
* Editors
* Developers
* Features

No expansion required.

Plone is about the people. The community is longevity. All the other factors can be gradually improved when you gather awesome developers with shared goals and collaboration. Software can be written again – but only as long as you have momentum behind it (be that from community strentgh or money).

Cheers,

Ian

1. OTEX/VIGN VCM – EFDPW
2. OTEX/VIGN Dynamic Portal – WDEFP
3. AU.L/IWOV TeamSite – EPFDW
4. Alfresco WCM – DEPFW
5. Drupal – WDFPE (F ranks high due to community contributed modules)
6. WordPress – WEDFP (ditto)
7. Non-Java portal-like WCMSes (PHPNuke, DotNetNuke, and friends) – DWFPE (ditto)
8. JSR-168 portal servers – DWPFE (some minor variation between specific products, but most fit this general pattern. Also interesting to note that JSR-168 failed to produce the plethora of community developed modules / portlets that Drupal et al achieved – evidence in support of the idea that in practice specifications tend to result in lowest common denominators? A topic for another day…)
9. Hosted WCMSes (Clickability et al) – WPEFD (with some flipping of F and D)
10. MVC frameworks (Struts, SpringMVC, Tapestry, Django, Ruby on Rails, Lift etc. etc. ad nauseam) – DPWEF

WordPress – WDEPF
OTEX/Vignette VCM – PFDEW
EPiServer – EWDPF
PHP (yes, the language) – DWPFE

Well the blathering stops here: If the product is a CPS, then the priorities are EDPFW. If the product is a PMS, then the priorities are WPFDE. It’s not entirely surprising to me that those two use cases are (almost) the inverse of each other – I think there are *drastically* different priorities for a production / authoring system vs a presentation / delivery system.

Good to see you back and on fine form – congratulations I think you have created a perpetual motion CMS conversation machine – this deserves to run and run.

I also think this could also be the Myers-Briggs test of the CMS profession, I can see people introducing themselves at events – “Hi, I’m a D|W|P|F|E”

Me, I’m errmm.. P (using Adrian’s definition).. then err.. it goes a bit hazy.

I started to explain, then my comment got way longer than your post and that seemed rude. So I wrote this blog post.

Before you say it, yes, yes I know, I too am a cop out.

Ian

P E D W F

1. Performance – a system’s up-time and the delivery of up to 1 billion PIs per day in a dynamic environment is mission critical to our customers, so naturally we take maintaining this level of performance very seriously.
2. Editors – a website can only be successful if editors can do their jobs well. Power and flexibility to shape and optimize the editorial process is essential.
3. Developers – in an enterprise environment, each web project is a tailor-made solution where a WCMS is a strategic infrastructural decision. For this reason, the WCMS needs to be very flexible, minimize proprietary expertise, while still being sufficiently stable in order to protect initial investment.
4. Website – a quick start is perfect! But only if it does not limit future developments and strategies (see 3.). With the right architecture it’s not an either/or decision.
5. Features – are important, which is self-evident for a comprehensive product suite. However, no set of features will ever be complete and no two customers will ever have the same feature requirements.

1. Performance – this is your foundation, and I include Reliability and Consistency, as well as Authoring and Publishing interfaces in determining this as choice number one. It affects *everything* else. This is not solely about Power. Would you put an underperforming Formula 1 engine in a lawnmower? Or a high performance two stroke? The choice for a CMS vendor here is what size project do they wish to cater for. The choice for the CMS customer is to not choose one below their requirements! Poor performance does not give any confidence that any of the other choices can be delivered to any satisfaction.

2. Developers – Unless your CMS is Perfect, it better cater towards developers. Basically – any flaws, holes, missing features or just the fact that no two set of requirmeents are the same means that there will be bespoke work to be done. Make this painful for developers and prepare to be saddled with few to little choices in everything below. Developers come after Performance only because Developers can’t improve Performance – not without rewriting the CMS anyways…

3. Website – Our end purpose. Remember, we are supposed to be making this *easier* not *harder*

4. Editors – Editors are very important, so why down at #4? Well, if you put them above performance, their editing interface can be impaired – no matter how good the UI is. If you put them above developers, then the supplied interface better be Perfect. Again, a customer may choose a CMS whose editor interface suits (or more likely mostly suits) their needs, but a CMS vendor would have more difficulty creating an interface that is Perfect for one let alone all of their clients’ needs… I did consider putting Editors above Website – but then I had to consider that – we need to create a Website, and, most likely the Editor interface will also be a Website – and therefore anything that restricts our ability to create a killer Website more than likely will restrict our ability to create a killer Editor interface too…

5. Features – the easy one to place! Features are nice, especially standardised ones, but again, the chances of all of your requirements being met and in the way you want them to be met means that you are looking at custom development again, which means we are covered by #2! This really is just a nice to have, perhaps as examples of Developer API

Disclaimer: I’m a developer

It depends on the politics & personalities of the organisation, who is leading the charge for the CMS?

You also have to consider risk and your plans to deal with it, what are the factors that have the highest probability and impact to derail the project?

Performance may not be important if your traffic patterns don’t have peaks of user activity or you don’t have more than a couple of editors using the system.

If much of the content is coming in via automated feeds you wouldn’t really care about the editorial interface. So I would suggest that there is a matrix where a particular context yields different results sets, so nobody is wrong!

Where there is a devolved publishing model, complemented and supported by a small in house of project managers, web and software developers I would suggest the following results:

1. Editors – this is the tool that they will use on daily basis, these are the guys who care about the Content and they usually outnumber and are more vocal than the
2. Developers – looking for interesting problems to solve (opefully elegantly), next comes
3. Website – the reason why you brought the product to support delivery channels,
4. Performance – hardware (servers, cacheing to CDN) is so abundant and ubiquitous today that systems can be designed to scale with relative ease
5. Features – most CMS’s now ship with a comprehensive set of features, and you would be looking at best of breed to cater for the requirements that were not being met.

Of course the most important ingredient is the website visitor, they will drive the KPI’s management are monitoring. Fortunately we can improve their user experience to better cater for their needs. Unfortunately with the CMS you’re stuck with the UX (and content model) that you’ve purchased.

* Do you need to worry about Editors if you’ve got a centralised publishing team?
* Performance isn’t that important if you’ve a small-scale site with relatively little content churn.
* Who cares about Features if you’re not going to use them all?
* Developers aren’t important if you want to off-shore (out of site, out of mind) or don’t need a site that interacts with any other systems.
* Website is of course the ultimate objective and you want to deliver it quickly, but it shouldn’t be at the expense of achieving your other objectives.

Of course, the reverse is also true:

* Editors – if you don’t get this right, what are you buying the software for?
* Performance – absolutely essential and a massive failing for many CMS projects.
* Features – enough to enforce standards and inform new possibilities.
* Developers – if your product isn’t extensible, your strategy will be limited.
* Website – the core objective for your WCM.

Glad I could help to clarify.

Some clients want a tactical solution [ F|W ] score highly. Others want a strategic solution [ D|P ] may well be the order of the day.

I’d choose: [ D|W|P|FE ]

@micycle: I’d go E DWFP – but then I’m not strictly a vendor just now

@CompoSiteC1:- D E P F W – that’s with a capital D.