When CMS Genes Won’t Splice
Oh God said to Abraham, “Kill me a son”
Abe says, “Man, you must be puttin’ me on”
God say, “No.” Abe say, “What?”
God say, “You can do what you want Abe, but
The next time you see me comin’ you better run”
Well Abe says, “Where do you want this killin’ done?”
God says, “Out on Highway 61.”
- HIGHWAY 61 REVISITED
People are talking about Open Text’s CMS roadmap again. There were some interesting statements made in the latest Earnings Call, the most notable of which is quoted below:
Paul Steep – Scotia Capital
What sort of the timing for the integrated platform, and I guess, would the plan be to migrate that Vignette product over to RedDot that [number] there. I think they are on a different architectures as I would recall?
Actually, it probably be the other way, Paul, where we would migrate the RedDot to the Vignette platform. We will be showing a detailed road map at the conference in October, so I think you’ll get a good clear. But it looks pretty interesting, the way that things are shaping up.
Ho hum. Another migration in a box. I really liked the post from Markus Giesen on the Unofficial RedDot blog. He asks many of the questions that customers, implementors and investors should be asking. He also has good inside knowledge, and so I’m not going to repeat what he’s already explained so nicely. Read his post. Instead, I’m going to outline the options as I see them.
Option 1: Sophie’s Choice
This one is easy to explain – a tragic choice between two unbearable options. Kill either RedDot or Vignette, one bullet for the CMS product (VCM or LiveServer) and one for the Delivery product (Vignette Application Portal or Delivery Server). This is most likely to mean bye-bye RedDot unless, of course, the people at Open Text pay more attention to the Gartner Magic Quadrant than me, in which case it’s goodbye Vignette. However, there is no chance at all that VAP will die so I think Vignette is safe. Option 1 isn’t going to happen.
Option 2: The Quick PurpleDot Brundlefly
So, next option. Merge the two products together into some kind of new hybrid product. Now this simply isn’t going to work. I’m not going to waste anyone’s time by listing the numerous reasons why this is insane. Instead, I’ll let the good children of South Park explain this for me:
Kyle: Well, what about our pot-bellied elephant?
Mephesto: Oh. Well I’m sorry children, but, pig and elephant DNA just won’t splice … Although, maybe I could help you add a few asses to that swine of yours.
Cartman: You can keep your hands off of Fluffy’s ass!
‘Nuff said. I’m not sure if you’ve ever tried to implement a site on a CMS with four asses. It isn’t pretty. Trust me.
Option 3: The Long Winded PurpleDot Brundlefly
Okay, so we’re not killing a product, and we’re not merging them either. The next option that is being discussed is the creation of a brand new product using the best engineering ideas and lessons from both products. Realistically, however, it’ll take far too long to build a brand new product from the ground up. In reality this will either end in the euthanasia of a product or a slower route to market for a PurpleDot Brundlefly. I see this option as a marketing spin on the infeasible Options 1 and 2. Not going to happen.
Option 4: The Alterian Gambit
Here is a viable option. Keep them both, keep supporting them both, and keep both products separate. Re-assure existing customers and implementers that nothing is really changing. This approach would keep existing customers happiest, but might make new sales more difficult. However, I think there are many ways they could differentiate the products, as I explained in this post. They could split by technology (Java/.NET), by industry vertical, or by dramatically reducing Red Dot’s license fees to compete lower down the food chain.
Option 5: The SKU Jedi Mind Trick
Keep them both and make the sheeple believe they’re part of the same integrated product suite. It’s amazing what new product name and a CSS change can give to a marketing manager. So in reality this is similar to Option 4, with a bit of confusion thrown on top. This is a fairly likely outcome.
Option 6: The Maintenance Milking Machine
Now this isn’t really a separate option, but a given. Open Text would be insane to rock the boat and potentially scare of the maintenance paying existing customers. The MMM could work in conjunction with either Options 5 or 6. The Shareholders will demand it. Expect to see both products being supported for many years to come, although don’t hold your breath for too much innovation.
While I can’t predict what’s going to happen, maybe history can teach us something. In the spirit of ignoring copyright rules, I’ve attached a screenshot from the CMS Watch CMS Report from 2004.
We all know what happened last time. Let’s see if history repeats itself.