Real Story Group/CMSWatch

[theHam]

Real Story Group, the CMS review site previously known as cmswatch,
has put up a blog post on their opinion on the current situation of
the Web Solutions suite http://www.realstorygroup.com/Blog/2185-A-Requiem-for-RedDot.
What's everyone's thoughts on this article? Is it a poorly researched
hack job or bone cutting truth? Do you think they sum up the situation
well?

- Morgan

P.S. I've already aired my opinion on the blog comments if anyone is
interested ;).

[Bagsy]

Hi Morgan,

I followed your lead and instead of duplicating here, you can read my
response in the comments on the article: http://www.realstorygroup.com/Blog/2185-A-Requiem-for-RedDot

Regards,

Dan

On Jul 1, 1:17 am, theHam <morgan.ritchi...@gmail.com> wrote:
> Real Story Group, the CMS review site previously known as cmswatch,
> has put up a blog post on their opinion on the current situation of

> the Web Solutions suitehttp://www.realstorygroup.com/Blog/2185-A-Requiem-for-RedDot.

[Gavin Cope]

The OpenText response: http://blogs.opentext.com/vca/blog/1.11.647/article/1.26.929/2011/7/1

--
You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group.
To post to this group, send email to reddot-c...@googlegroups.com.
To unsubscribe from this group, send email to reddot-cms-use...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/reddot-cms-users?hl=en.

[kimdezen]

At least there was a response from Open Text within 24 hours.. never a
good thing to let these things roll along for a couple days

Was at a social media seminar a while back and one of the speakers had
this to say:
Businesses need to react to issues (bad press, negative feedback etc)
that occur within 15mins of them happening, 1hr at latest. 24hrs is
too late, buy that time it may have already gone viral...

On Jul 4, 10:03 am, Gavin Cope <gavin.c...@gmail.com> wrote:
> The OpenText response:http://blogs.opentext.com/vca/blog/1.11.647/article/1.26.929/2011/7/1
>

[Sud]

May be not all of this blog is correct but ground reality is customer
base is going down and in last one week two big shot customers moved
off Reddot which means the market is less two opportunities for me. I
guess Reddot not being up to date and failing to match the developer
friendliness of products like Sitecore and Sharepoint has blown it
completely off the table. I don't care what some report says or what
has been posted by OTX as reply but trend I see is not good and makes
Reddot look like a sorry dying old product.

Truth is that it takes a lot (good experience with it and technical
understanding) to keep it stable which I don't think is such a bad
thing cause otherwise I would not have a job :).


Sud

[Tim D]

Sud,

I think Danny had offered to speak with you in the past to get feedback, I'd like to extend the offer again to see if you would like to work with us to improve. I'm not sure what region you are located in but I'd be happy to see what I can arrange with your AE, local support, and services if you prefer.

We have legacy code. 3 years ago the roadmap would have forced you to do a migration and full reimplementation. We changed directions. We've evolved the code base of Management Server. First there was a .Net Pagebuilder and v11 will see removal of all COM legacy components and a .Net 4 code base that will be easier to maintain and extend. No reimplementation to upgrade. No plans to stop working after that.

I'm working at getting us more developer friendly. Jian, Manuel, Danny and others participation in the forum and, Solution Exchange to share practices and techniques is a start. Hopefully this is making development more successful if not providing different development interfaces.

WSM's primary focus is to open up content management by serving the content creator. I am a developer of WSM solutions and so are all my friends and colleagues at OpenText so I understand there are improvements possible. I'm happy to be as loud of an advocate as I can be internally as are many others. The other solutions have deficiencies too although they may not be the pain points of users on this group. For instance analysts and observers others have pointed out how CFO unfriendly SharePoint for public sites can be citing via services cost and total cost of ownership.

Part of reality of software is that some customers move to other products. Customers are buying, implementing, and expanding their investment in WSM and other OpenText products and services. Customers are moving from other solutions to WSM. Existing OpenText partners (more than just legacy RedDot partners) have been training resources in WSM. Myself and those at OpenText who work on WSM are committed to improvement. SolutionExchange is just getting started and there are other projects in their early stages that will continue this trend.

Part of the reality is we can offer more complimentary products and services as part of OpenText. Video Services, Social, and several DM and DAM options. As you grow your web we do have solutions that can augment and a product that is flexible and agnostic to move as web technologies shift.

Like Scott said in the blog response, we are here just ask us anytime if you'd like to talk. I hope to hear from you.

@Kim,
I was pretty busy yesterday so it took me more than 24 hrs.

Best,
Tim Davis (tdavis at opentext dot com)

[Dmitry Terner]

Hi Tim thanks for the perspective it's always nice to hear news straight from the source,

Let me add another one though, I have been doing Management Server / Delivery Server development for 5 years. When we started it was a very quick way for us to get up and running with an enterprise level CMS. Since then, we have had continuous serious issues with performance and functionality of both systems. Several System audits and major hardware changes have made the system stable enough for our needs although publishing on our older projects is still flaky. 

But forget about all that, since that is my (the developers) problem. The real issue is that the smartEdit interface is dated, slow and unresponsive. My users know this, they have seen the alternatives and they are not happy about it. We recently went through a project to evaluate other systems and the truly extensible dynamic systems available today simply put Management server to shame. Modern CMS should look and feel like a desktop application not crawl along reloading the page with every click. My users should be able to drag and drop content elements as allowed by the templates, not have to navigate countless grey dialog boxes.  

I as the developer should have access to my content via REST calls on the Delivery server not have to spend time on Apache rewrites. I should not have to dig into Java garbage collection to simply set up my delivery server without it crashing every day.

The truth at this point is that the only reason we continue to use Management Server/Delivery Server is that we are too heavily invested in it and cannot afford to move off. In my opinion that is not a good reason.

- Dmtiry

[Tim D]

Dmtiry,

I'm glad your seeing improvements in stability and performance. If it's ok I'll reach out offline to follow up as well.

With regards to some editorial experience features (Drag and Drop, DirectEdit and Panels). I'm not certain if you are aware of them, but I'm pretty certain you aren't using them. Some have been available for a while many are new to v10 and improved in 10.1.

With respect to REST interfaces does this project look promising to address what you are looking for? http://www.solutionexchange.info/DSaaS-Delivery-Server-as-a-Service.htm

Organizationally I'd say we learned a lot about JVM tuning in the last 12-18 months and support has some general guidance on JVM and GC settings that are leading to stable servers at our largest North American customers. A couple options have gotten rolled into the OpenText\WS\DS\tomcat\webapps\cps\WEB-INF\bin\rdesetenv.cmd with 10.1 SP1 (full installer). I hope you all are better served by that going forward. A good number of memory leaks and race conditions have also been squashed so I generally give guidance to get one of the most recent builds of your major v10.x release.

The product has URL simplification setup options that fit some needs. Install in the root web application, make rde the default servlet, and set XFW3 weblet as default. As many of the customers I have worked with have multi-site needs we often first suggest continuing to use Apache/IIS rewrites to simplify Delivery Server URLs as it a broader set of challenges and allows other web applications to easily sit next to it. Typically if worked out during project definition we see a fairly small amount of rewrites setup to match a URL strategy. If there are challenges you see I'd be happy to continue the dialog in another thread, on Solution Exchange, or offline.

Best,
Tim Davis

[Christoph Straßer]

Hi!

JVM/GC-problems ... we also had to fight with this on the LiveServer/
DeliveryServer-side. Primary it´s a J2EE-problem. But you first buy
the DeliveryServer and do not think much about the infrastructure.
J2EE sound´s good and stable. A established plattform, where everyone
(???) knows how to run software.
This problem is not specific to DeliveryServer. I talked with a co-
worker responsible for our fat IBM WebSphereApplication-Server and
other co-workers responsible for other J2EE based third-party-
software. You need to analyse the applications needs and tune GC
according to this. I have hope, that Java7 with the new default
GarbageCollector "G1" brings a better default-behavior.
Our last problems were frequent Full GC´s on our new DS 10.1 serving
our corporate intranet. During Full GC´s the server stop´s all threads
until GC is finished. Full GC´s on a big JVM can take real long time.
(>10 sec)

The following options help you to find out, what´s going on:
-verbose:gc
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails

In our case we were runnig out of space in the Permanent Generation:
2418057.745: [Full GC [PSYoungGen: 1283008K->504057K(1340544K)]
[PSOldGen: 2796183K->2796183K(2796224K)] 4079191K->3300240K(4136768K)
[PSPermGen: 118736K->118736K(118784K)], 14.8017860 secs] [Times:
user=14.77 sys=0.01, real=14.80 secs]
2418273.758: [Full GC [PSYoungGen: 1283008K->489063K(1340544K)]
[PSOldGen: 2796183K->2796183K(2796224K)] 4079191K->3285246K(4136768K)
[PSPermGen: 118745K->118745K(118784K)], 13.6654052 secs] [Times:
user=13.64 sys=0.02, real=13.67 secs]
2418503.511: [Full GC [PSYoungGen: 1283008K->410719K(1340544K)]
[PSOldGen: 2796183K->2796181K(2796224K)] 4079191K->3206901K(4136768K)
[PSPermGen: 118753K->118721K(118784K)], 16.8217989 secs] [Times:
user=16.78 sys=0.00, real=16.82 secs]
2418872.413: [Full GC [PSYoungGen: 1283008K->464162K(1340544K)]
[PSOldGen: 2796181K->2796181K(2796224K)] 4079189K->3260344K(4136768K)
[PSPermGen: 118732K->118732K(118784K)], 14.3326230 secs] [Times:
user=14.33 sys=0.00, real=14.31 secs]
2419180.272: [Full GC [PSYoungGen: 1283008K->459540K(1340544K)]
[PSOldGen: 2796181K->2796181K(2796224K)] 4079189K->3255721K(4136768K)
[PSPermGen: 118734K->118734K(118784K)], 14.9122777 secs] [Times:
user=14.86 sys=0.00, real=14.91 secs]

We fixed this via increasing the PermGen from 128m to 192m.

Christoph