Craig, what do I want to see? Whole offering. As you know, too often engineering efforts stop at the product following the “Field of Dreams” approach. But in order to make this successful you need backing. You need executives at EMC that will own this. Someone needs to make sure that it not only gets the engineering resources to develop it but the marketing and field support to make sure that clients and partners understand it’s value. If not it will be just another engineer sitting on yet another standards body.

Apps, everything. Collaboration, WCM, DAM, Case Management, BPM, and just about everything under the sun.

Also, I agree with the installation. There are too many things that are “separate”. Licensing is also another issue, but that is best left for another day.

I totally get the J vs Common argument and I agree with it completely. I’ve never been a strong proponent of 170/283 for precisely this reason – What is Day’s position on CMIS? I should look that up.

What do I want to see? Simplicity – had a meeting today with a client and discussed an SAP integration. It’s been my experience that the SAP / Documentum interfaces are some of the more stable, straight forward and simple that the catalog offers. The simplicity however did not originate with EMC- it is ultimately driven by the adherence to the ArchiveLink API. There is a weak comparison here but I definitely believe there are lessons to be learned.

Types of apps? Discovery and RM come to mind but I suspect there are more than a few well entrenched architectural positions to overcome with existing offerings. I suspect the first applications will be those that deal with immutable content (images, archived materials) because it avoids much of the potential complexity.

I will say this – If you add one more install to the basic process I’ll lose my mind. C/S, DA, FAST, ACS , Messaging Server, TNail Server, CTS, SCS,DFS, WebTop,DAM,WP, CSS, AARRGGHH!!! WhatEVER you do – put it in the core or DFS and don’t charge another license fee just to support the standard.

What do you want to see product-wise, etc. from ECM vendors where CMIS support is concerned (e.g. kinds interoperable content applications)? As you offer professional services and products into the ECM marketplace, how does CMIS fit into the picture (or how do you ideally see it fitting)?

As you’ve likely noticed, a fair bit of commentary today talked about CMIS “versus” JCR. The ‘J’ in JCR (for Java) creates a bit of a interop problem if you operate in something other than Java. But that doesn’t necessarily mean that JCR “competes” with CMIS. It depends on your interoperability requirements.

I believe that the same can be said of JSR-168, or for that matter ASP.NET Web Parts.

If you portal supports one language–this is just for sake of discussion as most support WSRP, too–then the current language-oriented standard (or de facto “standard” in the case of Web Parts) may have sufficiently broken down silos (e.g. the narrower standard accomplishes the goal of taking plumbing off top of mind for the solution developer). Are they universal? No; still silos at-large may still exist.

ODMA’s failure wasn’t really its fault. It required a desktop component to work. The Web interface killed it. It is hard to have your productivity app work with an ECM system without some client.

CMIS is different and the ODBC comparison is a great one. As I’ve said before, it is what we need.

DAMN! I’m excited.

At the time the idea of document management was still new to most and the idea of developing ones talents with a single vendor seemed the smart thing to do. But over time the platforms that were so very different became very similar in functionality. This is why CMIS will have a much better chance, but only if people developing solutions on top of ECMS look to use it. The opportunity becomes even larger as we look at CEVAs.

In fact CMIS could not come at a better time for those developing CEVAs. By developing your CEVAs against CMIS, solutions will be able to support multiple platforms. This will eliminate the need to put all the focus on a single vendor.

But this will only be successful if the development community jumps on board.