Most WCMS don’t provide a defined structure for interacting with external systems in a way that can be used as a pattern for further integrations, meaning that the integration becomes a highly custom piece of functionality that works specifically against an external system. We’re trying to address this in SilverStripe by providing a base ‘External Content’ framework that provides the basis for integrations, while Matrix has always had the concept of ’shadow assets’ which offers similar capabilities in a more general kind of way. To build once off integrations for various systems without something to build on top of can be risky and difficult to maintain, and the investment involved can’t always be justified unless that cost is shared… by someone needing the functionality, leading to a chicken/egg scenario.

On the other had, the APIs available for integrating with ECM/RMS systems haven’t always been pleasant or even that open. Various systems behave in different ways under different circumstances, and have different nuances that you can only understand by having some level of experience with the product. Spending the time and effort to learn one ECM/RMS well enough to integrate with it needs to be weighed up against the number of users of that ECM/RMS who are also looking for a WCMS. Again it comes back to the point of being able to justify that cost to do the initial work.

It’s one area I think that CMIS is going to really help third party integrations, as it widens the number of systems that a development can target… all three of the requirements you mentioned can be developed against the CMIS API, and theoretically speaking that means a write once, connect anywhere approach when integrating to any CMIS provider. Theoretically of course .