Skip to main content

CMS vendors now and then

CMS analyst Janus Boye has just published a post on CMS vendors that discontinue their products (because they get bought out or similar)
During the past 10 years, a number of software products used by online professionals have been discontinued
That sentence reminded me that I had given a talk almost 10 years ago (it was in 2001 exactly) that contained a slide on the CMS market at that time:



The circles denote vendors that were part of CMS market overview articles by popular German IT magazines in that year (I wanted to show how differently the market place could be perceived). A vendor placed in any of the circles had enough attention to be part of at least one evaluation. The vendors outside of the circles were not part of any of these overview articles, but somehow present in the market place - at least I knew their names back then.

It is interesting to look at the landscape from that time. Of course there are a number of well-known vendors that got bought (Vignette, Obtree, Gauss), but the majority still seems to linger on - at least, a web site still exists, for example iRacer, Schema Text, or Contens.

On the other hand, one can ask how many vendors that were important enough to make it into a (German) market overview are still relevant in the market place today. I have used Janus Boye's spreadsheet of relevant European CMS vendors as a benchmark and checked which vendor's of today's list were already in 2001's presentation: Day, Coremedia and Open Text were "in the circles". Tridion was there, but outside of the circles. The rest of the vendors that Janus considers relevant today were not on my radar in 2001.

The end of my presentation involved a couple of CMS-related predictions. Let's see how I did. I predicted:
  • product borders between CMS, DMS and app servers will blur further - my take now: wrong. I do not think that these border are more blurry than they were in 2001
  • more standards and standards-based software (Java, JSP/ASP, XML, XSL) - true. The underlying technologies of CMSs are more homogeneous than they were at that time. Remember TCL?
  • But no true compatibility. True. Nothing more to say.
  • Improved Personalization. Improved Multi-Channel support. Both not really true, but rather fads of those days.
  • Improved DMS features and Office integration. Don't ask me why I said that.
  • No quick market consolidation in sight. Right on the money here.
Mostly correct on general market considerations, mostly wrong on features.

Comments

Markus Giesen said…
Absolute great post. Looking at your predictions I can see how you mixed those with customer desire & wishes for new innovation & features. But the vendors seem to prefer following buzzword and marketing trends instead in-depth analysis and real end-user requirement which would lead to a better return on invest.

Better DMS and Office integration, so easy and yet so far away from becoming a standardized portable solution across bigger enterprises.

Also nice to see Open Text on your slide and InfoOffice which became RedDot CMS and now is called 'Open Text Management Server' (seems like a horrible attempt to destroy a great brand name).

If you have some spare minutes I would like to get your opinion on the article about the acquisition of RedDot CMS:
Why the acquisition by Open Text was bad for RedDot CMS
- Markus
7:03 PM
Stefan Lotties said…
> The rest of the vendors that Janus
> considers relevant today were not
> on my radar in 2001.

Oh, not even Pironet/Imperia with pirobase CMS 7+? How comes? Actually I thought we're "known" and have quiet a good software. Perhaps it's just because we're not listed in Boye's sheet, because our development team was drastically reduced and does not hit the 'minimum dev team size' anymore. It's sad to be ignored by just that tiny fact :/

Anyway, interesting post!
3:44 AM
Post a Comment

Popular posts from this blog

Python script to set genre in iTunes with Last.fm tags

Now that I have started to seriously use iTunes I figured it might be nice to have the genre tag set in a meaningful way. Since I have a reasonably large collection of mp3s doing that manually was out of question - I wrote me a Python script to do that. There seems to be a large demand for such a functionality (at least I found a lot of questions on how to automatically set the genre tag) so maybe someone else finds the script useful. It is pasted below. General Strategy The basic idea is to use Last.fm's tags for genre tagging. In iTunes the genre tag is IMO best used when it only contains one single genre, i.e. something like "Electronica", not something like "Electronica / Dance". On the other hand dropping all but one tag would lose a lot of information, so I decided to use the groupings tag for additional information that is contained in the list of tags that an artist has on Last.fm. In the example above that would be something like "Electronica, Dan
15 comments
Read more

The misuse of the term "RESTful" in the Rails community

Today I went to a talk at the local Ruby on Rails group. The speaker was quite clueful. He had even implemented his own DSL to describe his business problem. Obviously, the guy was not a noobie in Ruby. However, what really turned me off was his usage of the word "RESTful". For him, it seemed to be a way to describe the inner workings of his application, like, say, "separation of concerns". RoR guys are generally not the most clueless people, but nobody in the audience challenged him about this. It seemed to be the generally accepted usage of the term in the Rails community. This made me think that DHH and Rails have done two things to REST: First, they greatly help to evangelize the term "RESTful" Second, they hijacked the meaning of the term and changed it from "architectural style" to "application architecture" As it happens I listened to a podcast from the Pragmatic Programmers on my way home. It was about the .Net Ruby implementati
2 comments
Read more

What is Multi-Tenancy? A closer look

Lately, I had a lot of conversations about multi-tenancy (MT). So I finally wrote up my thoughts on that term. In this post I will argue that MT is a value that depends on a continuous variable. Therefore, any statement about a system being “MT” can only be made in the context of the given requirements. It is not a property of the system itself . I will also show that perfect multi-tenancy is indistinguishable from single-tenancy (ST). MT is a value that depends on a continuous variable Imagine a step-function "ST-MT" (values are either 0 or 1) that determines if a given system is MT (1) or ST (0). That function will look like this: ST-MT = function (system, business requirements) Look at  the function’s arguments: the first one is obvious – the result will depend on the system itself. The second one is more interesting: it is the cumulative set of business requirements . Typically, these requirements will include: Resource sharing: systems typically declare
2 comments
Read more