Category: Alfresco

Alfresco open source content management

JBoss Portal and Alfresco

I recently delved into JBoss Portal to put together a demo for a client. I started with JBoss Portal 2.2.1 without Alfresco just to get my feet wet. I was a bit underwhelmed. The documentation was spotty, which I expected. The admin UI was clunky at best and wholely non-functional in some instances (here’s a tip: stick to the XML descriptors and avoid the UI for now).

The bigger problem for my immediate need was that the out-of-the-box CMSPortlet instance couldn’t be easily customized through either XML or the admin interface to show anything but the default content stored in the embedded jackrabbit (JCR/JSR-170) repository. The problem was that the URL was configured as an initialization parameter instead of a portlet preference. To fix that I snagged the updated CMSPortlet from the 2.4.0 Alpha release and deployed it to my 2.2.1 instance which worked great.

My next source of frustration was the JBoss-Alfresco bundle. I didn’t know exactly what was going to be included in the bundled instance of JBoss Portal and Alfresco–in hindsight my expectations were set too high. What I was hoping for was that Alfresco would be configured as the replacement JCR repository for JBoss Portal and that there would be a set of useful portlets that exposed the Alfresco repository to portal users. At a bare minimum I would have expected an Alfresco search portlet and a trimmed down “spaces” portlet.

Instead, what’s included is a single “Alfresco Client” portlet that essentially wraps the entire Alfresco UI in a single portlet. The embedded jackrabbit repository still exists and can be used with the CMSPortlet, but Alfresco isn’t configured out-of-the-box to be used as the content repository for JBoss portal.

These annoyances can obviously be addressed with code. And because JBoss and Alfresco leverage open standards, that code will be easier to write and maintain. I was just hoping that the bundle would have been more tightly integrated. (In the immediate-term I was hoping for a more powerful demo with less sweat equity).

As a side note it makes me wonder: Does Alfresco already have these portlets (and other similar types of value-added code) in-house but not easily accessible (or accessible at all) by the community or do they not exist?

This really illustrates the need for services firms to help clients take open source components the “last mile” by adding glue-code, implementing useful add-ons (portlets, integrations, etc.), and beefing up documentation, all of which could and should be injected back into the community in some form or fashion.

Open source document management white paper

Optaros has followed up their fairly recent open source WCM white paper with an overview of the leading open source document management solutions called, “Unleashing the Power of Open Source in Document Management”.

The paper puts Alfresco in the “magic quadrant” with the highest enterprise readiness and application capabilities. Plone is given a close second but has a much larger and more active community.

People new to document management but not necessarily considering open source might still want to take a look at this. Almost half of the paper is on general document management.

Optaros summarizes 15 open source content management projects

Seth Gottlieb has published an excellent whitepaper summarizing 15 different open source projects. He also includes a summary of how to go about evaluating open source offerings.

Seth offers a short list of offerings for each of the following usage scenarios:

    Brochure Site
    Online Periodical
    Collaborative Workspace
    Wiki as Collaborative Workspace
    Online Community

The format is similar to the presentation he gave at KM World but the format obviously lets him go into much greater detail.

Alfresco announces PHP support

Matt Asay, while commenting on Alfresco’s PHP support, says all systems should be architected in a language chosen by the development team but remain extensible in any other language by third parties.

I think giving clients and other developers the choice about how to extend the core product is a good thing. Hopefully it won’t get too out-of-hand, though. It seems like there might be some loss of efficiency in the community as the number of different implementation choices increase.

For example, if someone finds a great extension they’d like to use but it is only available in [pick your language], they’ll have to port it.

If the number of choices stays reasonable, and if each one develops a decent mass, it’s a win-win for both the customer and Alfresco.

Alfresco and Plone comparison

Seth Gottlieb has posted a good Alfresco overview with a brief comparison to Plone. Seth concludes,

I would use Alfresco for a targeted document management solution that would fit into a larger enterprise content management architecture…I would use Plone to build an all-in-one intranet or extranet where I wanted to mix article, page, and file content and opportunistically deploy new features to improve collaboration and retention.

I agree with Seth’s conclusion and the point he makes in the article that the lack of LDAP integration in the community edition of Alfresco limits it to departmental use. I’m sure they’ll move that feature down at some point–when they do it should boost adoption.