Software company vs Apache License

A month ago I got impressed how software company manages knowledge: as all we know when Documentum was under EMC wing there were two public forums: Documentum Support Forum and Documentum Developer Forum – both are inaccessible for now because OpenText had partially moved their content to OpenText community forum and restricted access to customers only – here I have now idea why do they think that ECN forums weren’t public:

At ECD, the two forums you mentioned were separated because one was an open forum and the other (Dev) was closed and available to developers only. Here, we do not have the distinction of open and closed forums within our product membership.

Today I got another interesting case: it seems that OpenText decided to rebrand Documentum products but doing it in extremely weird manner, for example:


Are changes coming?

On last week something weird had happened – a couple of researches disclosed information about vulnerabilities in Documentum xPression and Documentum WDK applications:

and these disclosures are qualitatively different from what EMC was publishing previosely – these disclosures had been coordinated. Let’s explain this point. When Documentum was under EMC wing EMC was never published correct/true information about security flaws: they were always underestimating security impact and were never noticing that exploit/PoC were available in the wild, and such behaviour, obviously, had negative impact on customers: customers see that vulnerability impact is medium and prefer do not install security fixes – that is a kind of expected behaviour, because in most cases Documentum updates tend to break a lot of things which previosely work smoothly. But last disclosures are different – they are full and everybody can independently estimate a security impact, so I do see positive changes for Documentum customers after acquisition. On the other hand it is not clear whether acquisition took effect on talented team, because my communication with both EMC and OpenText was not so good – please check my story below.

Long time ago (I believe it was 2012 or 2013) I filed a plenty (more than 20) of security reports related to Webtop and Content Server via EMC customer support channel, they confirmed the existence of vulnerabilities and after a while I was notified that my vulnerabilities were remediated, but there were a couple of things which shocked me:

  • EMC refused to disclose those vulnerabilities, that time I considered such decision as scorn of customers
  • some of vulnerabilities weren’t actually remediated – EMC didn’t even try to find a root cause of vulnerability
  • some of fixes were breaking a lot of thing – check out D2 story for example

So, I realised that EMC customer support channel didn’t work and opened my cool blog. During next three years I was contacted by EMC reps twicely:

  • First time that was Jeron Van Rotterdam (CTO) – he asked to share all my finding for free, though on that time EMC knew about 15 unfixed vulnerabilities in Documentum and I was unable to understand why they requested more, by the way I let him know that if he wanted to collaborate on this topic ECD had to provide contact(s) of qualified SW engineer(s) on EMC side
  • Second time that was John O’Melia (SVP) – he had attempted to hire me, and I that time I failed to understand what I was supposed to do there – it was clear they failed to find competent contact and I had no intention of teaching their talented team.

Dialog with OpenText had more promising beginning: 7 months ago I have contacted Muhi S. Majzoub (CTO) regarding security issues in Documentum (like I discovered more than 30 security flaws and I would like to help) and on the same day (technically that was next morning in Australia) I received following from David Goldberg (VP):

Hi Andrey,

Thanks for accepting my LinkedIn request. Mark Barrenechea forwarded the note you sent him to the head of Engineering at OpenText who asked me to reach out to you. We are interested in better understanding the issues you mentioned in your message. Is there more you can tell me?

We got a shot conversation (actually, I didn’t provide information about all security vulnerabilities – it would take a lot my time, I just picked up two most important (CVE-2017-5585 and CVE-2017-5586), in my opinion that was enough to evaluate whether talented team is capable to fix security flaws or not), and the result of that conversation was (un)expected:

Thank you, Andrey

I will pass this on to our Engineering team and we will consider what follow-up is required.

And as you can see, CEO, two VPs and 2000 talented persons are not enough to replace two vulnerable jar files.

As regards to last vulnerability disclosures: the second part of CVE-2017-14524 looks very similar to I perceive the world: response.sendRedirect(String location) and it is XSRF, but the first part is not a XSRF but XSS – if I understood properly the following piece of code in webtop/help/en/default.js is vulnerable:

if ( != null && != "")
if (,9) == "?startat=")
startPage =,;
if(startPage.indexOf("://") != -1 || startPage.indexOf("\\") != -1 || startPage.toLowerCase().indexOf("javascript:") != -1)
startPage = null;

so I have no idea why two different security vulnerabilities were combined into single CVE, moreover I doubt that XSS was actually remediated – both disclosed test case and description (“open redirect”) are confusing:

So, I think it is clear that OpenText management seems to be much better than EMC was, but, unfortunately, talented team remains the same.

Documentum innovations

A week ago OpenText have announced another one Documentum roadmap (here I recalled following quote:

“I’ve been watching this process with OpenText for more than a decade, and I think, in 2009, I called them ‘The Roadmap Company,'” said Tony Byrne, founder of Real Story Group, a research and advisory firm in Olney, Md. “Every time [OpenText] acquires a company, they always have this story around innovation and synergy and a roadmap. It’s a very nice story for the customer and perhaps OpenText believes it, but it very rarely executes on it.”

), this roadmap contains more “technical details” than the previous one, so we may discuss it more thoroughly.

Brava! & Blazon

Actually, here I didn’t understand what innovations they were talking about, because both innovations are already available:

More probably they were talking about new challenges for Documentum customers: in D7 EMC have switched CTS primary rendering engine from Adlib to Aspose, now it seems that they are going to switch from Aspose to Blazeon.

S3, Hybrid services and Independent JMS

And again, I did find nothing innovative there – all these three innovations were part of “EMC’s vision” in 2016:

Moreover, all these three points seem to be doubful:

Application access control in D2

If my memory serves me right similar feature was implemented in Documentum xCP 1.x 🙂

Improved content contribution in D2

Very innovative, if forget that the similar behaviour was present in, at least, webtop 5.3 🙂

Expand with homophones

From business perspective this slide looks funny, the problem is that Atenolol and Timolol are two different drugs, so this slide literally means following: in version 16.4 our search engine will return irrelevant results 🙂 From technical perspective, again, I do see nothing innovative here: the similar behaviour could be implemented via

Why you should stay clear of REST. Part II

Actually, as a continuation of previous blogpost I wanted to write about DDD and my own experience with DFS, CMIS and REST, but today I have found another gem on LinkedIn: Performance Anti-Pattern For RESTful API – batch updating (saved copy), actually that blogpost hides package names:

but all we do know what is hidden there:

As far as I know, batch updates were introduced in 7.2 and they are dead slow 🙂

Another LinkedIn gem: Potential Permanent Generation Leakage In Your JVM

Why you should stay clear of REST

Once again I get inspired by to write this blogpost by Alvaro de Andres Documentum 16.3 delayed until Feb 2018 blogpost – there is some “interesting discussion” about REST where you can find following opinion from another member of talented team:

Is DFS a personal target for your projects? Baseline REST is a mature offering and it has active Engineering working on it. The planet seems to be focused on a RESTful interface and the DCTM platform is meeting that focus with a set of platform APIs. As I’m sure you are aware Captiva, xCP and D2 can be access through REST interfaces.

Actually, it is not clear what Tomas meant under the word “REST” because my observations about REST are following:

  • when most people talk about REST they typically mean JSON, which is obviously wrong: it is true that in the most cases (especially when REST client is a web-browser) REST is used together with JSON, but if we want to get faster data processing or put validation rules on data nothing prevents us from using XML or protocol buffers. Moreover the idea to use JSON in most cases sounds ridiculous: we spend a lot of time on designing data structures, but once we chose to use JSON as serialisation technique we throw all our efforts out of window.
  • Documentum’s REST API is actually not REST-compliant, so when talking about Documentum under the REST we should mean “something that looks like REST”, so, yes, REST seems to be a standard of providing interoperability between computer systems on the Internet,
    but how it relates to Documentum?

Let’s discuss the second point: why is Documentum REST not REST-compliant? The base idea is following: when we work with our data through REST API we consider two types of resources: elements and collections of elements, which could be queried/modified using GET, PUT, POST, PATCH and DELETE methods, the behaviour of these methods is following:

Method Resource type Contract
Collection Element
GET List the URIs and perhaps other details of the collection’s members Retrieve a representation of the addressed member of the collection, expressed in an appropriate Internet media type readonly
PUT Replace the entire collection with another collection Replace the addressed member of the collection, or if it does not exist, create it idempotent
PATCH Not generally used Update the addressed member of the collection
POST Create a new entry in the collection. The new entry’s URI is assigned automatically and is usually returned by the operation Not generally used. Treat the addressed member as a collection in its own right and create a new entry within it
DELETE Delete the entire collection Delete the addressed member of the collection idempotent

Below are some explanations of the table provided above:

  • Documentum REST API should not allow to do something like:
    GET /dctm-rest/repositories/DOCBASE?dql=delete%20dm_user%20objects

    because GET method is readonly

  • PUT method against element must completely replace element’s data, i.e. if you are doing something like:
    PUT /dctm-rest/repositories/REPO/DOCBASE/dm_user/11bc614180000522
    Content-Type: application/vnd.emc.documentum+json;charset=UTF-8  
    properties: {
      "user_address": "user@domain.tld"

    the request above should set user_address to user@domain.tld and clean other properties, if your objective is to update user’s email you should do something like:

    PATCH /dctm-rest/repositories/REPO/DOCBASE/dm_user/11bc614180000522
    Content-Type: application/vnd.emc.documentum+json;charset=UTF-8  
    properties: {
      "user_address": "user@domain.tld"
  • example of POST method usage against element should look like:
    POST /dctm-rest/repositories/REPO/DOCBASE/dm_workflow/4dbc6141801aa1e1/attachments
    Content-Type: application/vnd.emc.documentum+json;charset=UTF-8  
    properties: {
      "object_name": "new attachment"

Now, how it does look from Documentum perspective:

  • updating object:
    POST http://localhost:8080/acme-rest/repositories/REPO/alias-sets/6600000580000515 HTTP/1.1  
    Authorization: Basic ZG1hZG1pbjpwYXNzd29yZA==  
    Accept: application/vnd.emc.documentum+json  
    Content-Type: application/vnd.emc.documentum+json  
        "alias_name":["RestASX ", "Everyone_Write"],  
        "alias_value":["/Resources/Registry/Presets", "dce_world_write"],  
        "alias_category":[5, 6],  
        "alias_usr_category":[1, 1],  
        "alias_description":["A test alias set", "A second alias set"]  
    HTTP/1.1 200 OK  
    Content-Type: application/vnd.emc.documentum+json;charset=UTF-8  
    Content-Length: 725     
        "object_description":"A test alias set",  
        "alias_name":["RestASX ", "Everyone_Write"],  
        "alias_value":["/Resources/Registry/Presets", "dce_world_write"],  
        "alias_category":[5, 6],  
        "alias_usr_category":[1, 1],  
        "alias_description":["A test alias set", "A second alias set"]  

    and inconsistencies are:

    • improper usage of POST method
    • PATCH method is not implemented at all
    • if under POST they actually mean PUT they should clean values of owner_name, object_name and object_description attributes – I believe talented team actually uses POST as a replacement of PATCH, though PATCH method was introduced in 2010 (7 years ago)
  • dealing with workflow tasks:
    PUT /rest-app-name/processes/process-system-name/process-id/task-name/task-id/status
    Content-Type: application/vnd.emc.documentum+json  

    that is a total mess, the correct implementation should be:

    PATCH /rest-app-name/processes/process-system-name/process-id/task-name/task-id
    Content-Type: application/vnd.emc.documentum+json  
    properties: {
      "r_runtime_state": 1

As you can see REST implementation in Documentum is actually not REST-compliant, so, I have no idea what talented team was doing last 8 years. On the other hand it is not a big issue in comparison with the next one. At current moment ECD/OT provides following options to work with Content Server:

and the problem is that all those options do not provide you an out of the box robust integration with Documentum: while the planet seems to be focused on ORM, DDD and scaffolding, Documentum developers write tons of boilerplate code.

Hardware company mantra. Part III

When I was writing the previous blogpost I had a feeling that I was missing to write something important (i.e. due to experience I suppose that some things are obvious, but readers may not even know such things), so let’s start from the “beginning”.

Below is a history of names of EMC Documentum division:

What was the reason to rename CMA division in 2010? Well, until 2009 EMC was offering only two ECM solutions:

  • Documentum Webtop and it’s derivatives
  • Documentum Desktop

Moreover, somewhere until 2007 EMC was considered as leader of ECM market, take a look at Gartner MQ for ECM in 2006:

Unfortunately (unfortunately for EMC, but competition is always a good for end-users) the release of MS SharePoint 2007 has changed a lot on ECM market – below is Gartner MQ for ECM in 2007:

and in 2009:

So, EMC was forced to compete with new ECM players and their strategy in 2009 was the following:

  • Improve content management discipline, i.e.:
    • add Web 2.0 and Social Networking capabilities (CenterStage – Webtop replacement and MS SharePoint competitor)
    • improve Desktop integration (MDD, MDO, FSS, DCO)
  • Introduce new discipline – Transactional Content Management (a.k.a Case Management with TaskSpace as a flagman product)

You can find some Momentum 2009 “materials” here: Momentum 2009 – EMC’s vision. Also it is worth to note that “configuration over coding” and “lower TCO” slogans have first appeared in 2009 too (it seems that somebody is little behind a schedule):

So, the renaming in 2010 was required to demonstrate both customers and competitors that EMC was doing much more than just content management. However, somewhen in 2011 EMC realised (for me it was always clear) that CenterStage didn’t take off, but they already wasted a lot of time on it (for example first rumours about D7 have appeared in 2009, but D7 was released in 2012, though from my perspective there is no difference between D6.5 and D7, moreover, I have no idea why they decided to create new product instead of evolving WDK – adding Web 2.0 capabilities into WDK is not a big deal), and in 2012 EMC has started reselling C6 D2 and in 2013 EMC announced a new UI for D2 client (the original UI was based on ActiveX). Interesting thing here is a fact that CenterStage, D2 and xCP2 UIs were designed by the same person:

Well, I think it is clear that during last 8 years talented team was trying to do their best to kill webtop, but it is still alive. Why?