Confluence and Alfresco integration … am I seeing double? :)


Funny little story about open source business models and trends: this story goes about the long time discussed and awaited Alfresco Confluence integration, and goes back of almost one year. Confluence is the Enterprise wiki solution from Atlassian, while Alfresco…well I guess it does not need introductions on this blog 🙂

Short preamble:

This project started  in June 2009 hosted in Google code as joint open source initiative by Alfresco and an Alfresco pan-european partner,  Sourcesense: originally hosted on Google Code under the name “Confluence Alfresco Plugin“.  The project was originally meant to provide access to Alfresco documents from Confluence macros, and was based on the Alfresco proprietary webscripts ReST API. After a promising initial implementation was drafted, the project has not seen any commits as of Jun 2009: the reason behind this sudden stop was  that this implementation was based on very specific Alfresco APIs, and the rise of an Open Standard like CMIS would have made such an approach an early obsolete product.

Where one seem to stop, another rises from its ashes: as natural continuation of the Confluence Alfresco project, in the very same mid 2009 in Google Code a new project is opened under the, more generic, name of Confluence CMIS Plugin. As the name suggests, the scope of this set of Confluence macros was, not just to integrate Alfresco, but to provide Confluence a more generic support for any CMIS compliant repository: this open source & open standard approach was based on the initial versions of Apache Chemistry Java client, still under heavy development at that time, but already attracted some buzz in the Confluence community.

Present times:

Almost one year has passed since then, and I keep on receiving requests (almost on a weekly basis) from Alfresco partners and customers interested in an Enterprise solution for Alfresco Confluence integration.

What happened with Confluence Alfresco (and its successor Confluence CMIS plugin)?

Looking a bit deeper at the project’s mailing lists you can find some hint of what’s going on:

Sounds a bit like the ant vs grasshopper battle, doesn’t it?  🙂
My view:

First of all, I must say I really do hope the two efforts will soon be consolidated into one, both from an open source contributor and also Alfresco business perspective.  Still for now, we’ll have to stick and choose one.

Those who know me already might already be guessing this: at the moment, I quite like the approach of the Confluence CMIS plugin, and not only because you can actually check out the code from Google Code / get snapshot releases NOW and have macros in your Confluence to work against any CMIS repository.

Ah, and also not just because I’m a committer in the Apache project (Chemistry) developing OpenCMIS, which is now used by this plugin 🙂

The reason is instead that I really do prefer an open approach to ECM, especially about building integrations, and that comes out of the my very personal idea of software development.

IMHO, being software development a process, there’s more to it than just a good mix of high quality code and good sales/marketing skills: to build a successful (and scalable) solution, you need to have a sustainable and lean process backing up the development of your solution, a process where systems and people can interact on standards basis and clear information flows, like the ones a controlled open source process can offer.


The Confluence Alfresco CMIS integration story, is just one example of how the very same solution can be approached in multiple ways: with no doubt, from my perspective, the CMIS based approach is bound to be superior in terms of longevity and maintainability (thus reliability of the business model).

Also, in order to achieve a much broader target, it might be beneficial to keep it in the open source arena: this way, it might get the resonance and the broader adoption that the Confluence community is waiting to actually start consolidating content in more advanced ECM platforms like Alfresco (or any other CMIS compliant server), based on top notch libraries like OpenCMIS (BTW, we’re working toward a first release out soon).

And don’t get me wrong, I’m not just a Stallmann style fundamentalist: it’s still perfectly possible to develop proprietary (and maybe enterprise specific) extensions which might use a different licensing and business model, and maybe Alfresco specific capabilities. I just believe that for core ECM functionalities and product integration, it’s just always better to stick to the standard (especially after all the work put into the CMIS process).

And that sounds especially reasonable,  if you think that both Alfresco (LGPL licensed) and Confluence (offering free hosting for Open Source projects) have important stakes in the Open Source community and potentially customer/prospects which value the extended benefits of an Open (source + standard) approach.

And if you not convinced yet, I have few more thoughts on what I mean by Open (source and standard) ECM

Unlock ECM with CMIS

Part of my daily job at Alfresco is to suggest our customers and partners the best way to integrate and customize the extensible and open standards based Alfresco Content Platform.

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 $$$$).

So when, almost couple of years ago, Alfresco strongly shifted to CMIS, I basically was a “happy camper”, as Nancy would say 🙂

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:

Douglas Adams' Babelisfish

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) !”