Latest posts by MindTheGab (see all)
- Introducing the Symphony Foundation & Community Blog - August 7, 2016
- Building our Community bottom up. Thanks for a great Member Meeting! - May 28, 2016
- The Symphony Software Foundation is Growing – Join the Community! - May 16, 2016
The open standard concept is indeed a very general one, as it embraces top down standards (i.e. when a committee of some form is created and the standard follows a formal approval process) and, especially since the rise of Open Source, bottom up standards (or standard de facto, i.e. recognized as standard because of major adoption of a large community and well known benefits).
For example, in the case of Alfresco, I would consider support for JDBC, JSR-168, JSR-170 and more recently CMIS as falling into the former category, while technologies like Spring or architectural patterns like ReST as part of the latter. Another example I’m familiar with which might fall in the latter, is Apache Maven, which allows to use a standardized process for development, release and documentation of your project, and is used by most J2EE open source projects.
In my opinion, both these classes of standards are equally important to a sustainable development process. They have to be leveraged and balanced, to allow both a potentially very modular growth in features by standard/clear interfaces, while still ensuring wide adoption thanks to the usage well known technologies and enabling tools.
And in my experiences, it’s only in the Open Source ecosystem that open standards can flourish and get stronger, as key building blocks of the backbone of many open and proprietary applications (thus driving also dependent processes, like resource provisioning and maintenance). For this, I’ve always been advocating to leverage open standards (and possibly open source implementations) in ECM integrations/customizations, both for clear architectural advantages and to also provide sustainability to the whole application lifecycle (and thus to the business model at large $$$$).
I’ve been pushing, waiting, trying, educating and contributing to the standard in order to help as much as I could to have this out and kicking in the shortest time-frame. Biggest achievements of this last 2 years have been, on the personal standpoint, my committership for the Apache Chemistry project (which now provides, amongst others, a complete Java CMIS client called OpenCMIS) and, on the career standpoint, the wonderful chance of joining an Open Source ECM Software company like Alfresco.
Even better: participating to an open source open standard implementation, while working for an open source product company…seems a wordgame, but now after 2 years of great efforts, it’s now fair to say, at least for the J2EE world, that:
“CMIS is ready and easily usable”
At this is because of a few amazing things happened in the last months:
- OASIS 1.0 CMIS ratification
- OpeCMIS and Chemistry merged in fully functional open source Java client under Apache
- Alfresco 3.3 (Community and Enterprise) offering a CMIS 1.0 complete and supported repository server
As Dave correctly says, from now on, I think we should more and more try to build on top of this standard approach (and the simplicity offered by OpenCMIS) to achieve simply reusable content oriented applications.
This new open ECM is a bit like moving on from the Tower Of Babel of one off integrations, to open (standard and possibly source) content development aided by CMIS, playing somehow the Babelfish (see image for a detailed architecture) that unlocks your content from the specific repository details…bringing it to an abstract domain model, ready to be introduced in complex, distributed, scalable content processes. Too poetic? 🙂
In other words, this open ECM it’s not just merely about open standards and/or open source products adoption: it’s more like a new way of envisioning content applications based on both the benefits of open standards and of the open source development process, at technical and communication levels.
After all, same as when design patterns were introduced they drastically changed the way we talked and designed software, we should exploit the great momentum of CMIS to start “talking the same content language”.
This is true for product vendors (which are rapidly offering support for the standard), but also for System Integrators and community members which might end up (finally!!!) building once and use (sell) everywhere.
And so (possibly also because I’ve been attending a Rage Against the Machine concert lately, my last quote and public call for action cannot be any different than:
“Content Workers of the World, Unite (under CMIS) !”