My response to Pie’s Quality of Documentum Over the Years bears repeating, even if I am beating a dead dmHorse:
I started with version 2, back when I was just a newly-minted UNIX geek. One thing you missed with the transition to 4i was the introduction of the DFC. DMCL had a very UNIX feel; a simple, open API designed to be glued into any programming language. DFC was just Java then, with a COM layer growing over it later. That was also the point where EMC became more marketing-driven and started chasing the Internet bubble at the expense of their existing clients.
Both were attempts to capitalize on hot topics of the time, Java and the Web. I never bought that the DFC would make a whole pool of talent available; Documentum’s about the model, not the means. However, the marketroids successfully reframed it. Hiring managers now believe they can take Java people and mold them into Documentum people, and I hear gasps of disbelief when I say Java or Visual Studio aren’t requirements to do Documentum–a good Java programmer is not necessarily a good Documentum developer.
This Java mentality did increase the number of people with Documentum on their resumes, but the talent didn’t increase as much as the volume. It just diluted (maybe also tainted) the pool. It became harder to find good people in the now-mirky waters.
The lack of focus then is what brings us to the lack of quality now. Innovation at the model and server level is rare, and frankly I don’t give Documentum much geek cred anymore because of it. Great ideas like BOF and Aspects are stapled into an API rather than made an inherent part of the product. Too much work up the stack (and on vertical solutions) has made the product top-heavy and tottery. EMC continues to chase markets (i.e., case management) rather than concentrate on making a solid core product.