With the recent announcement that the Documentum Developer Edition is being discontinued – Bidding Farewell to Developer Edition, we thought it would be a good time to update our previous post from 2010 in regards to development differences between Documentum and Alfresco. This post will compare and contrast development environments and philosophy with both Alfresco and Documentum.
Documentum Development Roots
When originally founded in the 1990’s by John Newton (current Alfresco CEO) and Howard Shao, Documentum was really just an object orientated layer on top of a database. When we would discuss it with clients, the “database for documents” was a common description of how a layer for security and object model abstraction would lay on top of the database (usually Oracle back then although Sybase was supported as well). Documentum had an API layer (C Code), DMAPI that was the only way to access the repository along with the still popular query language, the Documentum Query Language (DQL) to access and manipulate the repository. Originally the DMAPI had both a client and server component with an embedded remote procedure call (RPC) since Documentum was developed pre-web.
Original developers were encouraged to use the API or, as of Documentum 4i, the DFC to enhance or extend Documentum (Workspace, RightSite, Webtop/WDK, xCP and others). Pricing options originally not only included CPU-based but also concurrent users (something that quickly faded) so development wasn’t limited to single interfaces. Documentum has evolved to a web services API access with DFS although it did take some time as pointed out in one of our old posts. The developer edition was announced in 2009:
From the press release:
“This expanded investment in developer resources demonstrates our continued commitment in making Documentum the premier platform on which developers can build their content-enabled applications rapidly while keeping their costs of implementation and support low,” said Whitney Tidmarsh, Chief Marketing Officer, Content Management and Archiving Division at EMC. “Through our various online communities, developers can take full advantage of free tools and content as well as work together and foster the growth of the Documentum community.”
Contrasting that with the farewell post:
“With the latest releases of xCP and D2, we now have best of breed products for building ECM solutions with a minimum of code. We continue to support the classical development tools and APIs (and will for some time), but most new applications are being built with these new techniques that are faster to deploy and much cheaper to maintain. Developers are now much more interested in learning these products than the tools available in the Developer Edition……Finally, we’ve shifted our strategy to be more focused on delivering solutions, rather than just a platform for building them. In the past couple of years we’ve greatly expanded the number of solutions available from ourselves and our partners.”
As Documentum has evolved, a number of changes have occurred that have affected the Documentum development philosophy including:
- Pricing – We would argue that the biggest impact to pricing has been the pricing construct of named user and per application pricing. While it has evolved in the last two years to include one server side price and a small per application price per named user, the pricing of a custom application costing more than $400 per named user discouraged custom development or access from other environments.
- Anti-Customization Movement – As Documentum gained more success, some of the competitors would attack it as “too expensive” because it “required customization”. As pointed out in a previous post, not all customizations are bad. Most of the issues regarding customization came not because the customizations were bad but that Documentum didn’t support them during an upgrade, particularly on Webtop, and would require a rewrite to the new proprietary interface for the upgrade. OpenText, in competing against Documentum, even had a campaign as the “consultantless solution”. This philosophy can be seen with the recent D2 and Mobile environments and the quote above where “you can’t customize it”, almost to prevent users from doing what Documentum perceives they shouldn’t be doing.
- Professional Services from EMC – A couple of clients have pointed out that D2 and other environments can be customized but “only by EMC”. We see this as a dangerous trend in that development environments exist (SharePoint Development Framework for example) but are only available to internal professional services from EMC.
As demonstrated by the discontinuing of the developer edition, the overall trend from Documentum is moving away from development options for clients in favor of configurable but proprietary only environments.
Alfresco Development Roots
Alfresco, a company founded after the internet bubble, was built as a web/Java open source evolution of a content management system. While many of the same principles exist (API access to back-end layer on top of a database), Alfresco choose to implement with a web-based API focus from the beginning, focusing on open standards geared for developers. Alfresco promotes open development in a number of ways:
- The Community Edition of Alfresco is available free of charge.
- Alfresco is setup to be easily customizable. There are many integration points for adding customizations, and you can even wire in code with Spring to access lower level APIs.
- Alfresco has a well-documented API that is geared for developers wishing to customize and add on to Alfresco.
- As you would expect with open source software, you can access all of the source code for Alfresco. This is very helpful since developers can load the code into an IDE and see exactly what Alfresco code is doing, and can even step through it in a debugger.
- Alfresco actively promotes CMIS as a standard for accessing the repository.
- Alfresco’s main interface, Share, is written using the Spring Surf framework. Alfresco developed Surf and then donated it to the SpringSource community.
To contrast Alfresco with the issues discussed above with Documentum:
- Pricing – Alfresco only has a CPU level maintenance/support that is lower than Documentum’s maintenance pricing (see related post – add link). For Developers, CPU pricing gives them the flexibility to develop small, focused applications for any type of user without worrying about licensing impacts.
- Customization – Alfresco has never had the perception of being “over customized” due to their client base. Also, the focus on the developer has made the bulk of the customizations easily upgradable.
- Professional Services – Consistent with a partner focus versus a consulting solution, Alfresco doesn’t offer professional services and releases all updates to the entire installation base rather than positioning additional technology as a solution or consulting only solution.
Summary – Sales Culture versus Engineering Culture
With all of the posts around Alfresco and Documentum, the development philosophy clearly illustrates the cultural differences and contrasts between the two companies.
As pointed out in an earlier post, EMC has a sales driven culture. By understanding how sales goals drive decisions, you can see how the movement to add internal solutions and products while moving away from open development tools benefits Documentum sales. Readers should also understand that Documentum has been unfairly characterized as “requiring customizations” and has reacted by releasing products that can’t be customized.
Alfresco has an engineering driven culture. With the community edition, pricing and a variety of development approaches, Alfresco embraces the power and innovation of the open source movement and standards to create solutions and other approaches. Every piece of Alfresco is available to developers to create innovative and cost-effective solutions.
For further insight in the cultures, as pointed out in our earlier post, Documentum’s user conference is called Momentum and features suits/ties and non-technical presentations about solutions. Alfresco’s user conference is called DevCon and is focused on engineers and developers.
If you have any thoughts, please add below.