Since then, developments have been comparatively slow. It seems DNN Corporation has taken the Alfresco route: focusing on support packages while building various commercial add-ons to the community edition.

Earlier this week, DNN Corporation announced an "Enterprise Edition." This new edition gives you a staging platform to make content and code changes, which you can then push into production. That's standard-issue for higher-end systems, but can still get tricky, and we always encourage customers to test such synchronization services very carefully.

To be sure, DNN's popularity proves there's a place for omnibus CMS products, especially when you need something easy to deploy. Joomla! is another great example, from the PHP world. We call these "simple products:" if you select the right modules and well-tested skins, you can apply a wide range of canned web applications to a single site.

From there, they will both start falling off.  Neither DNN nor Joomla! natively provides effective multi-site management.  Think twice about employing them as serious application development platforms, and if you're looking for technical elegance, I recommend casting your gaze elsewhere.

So it comes down to scenarios and fit. In our Web CMS technology evaluations, we cite DNN as potentially a good fit for two of twelve scenarios, and a plausible fit for three more. DNN's new staging feature is unlikely to change that. Then again, you don't want to invest a system that tries to be all things to all customers.

First, to illustrate: about a year ago, I read Jon Mark's blog post: "when most Twitter users say CMS, they mean WordPress, Drupal or Joomla!. [...] So I panicked a bit. I know WordPress. We very occasionally see Drupal in a vendor selection, and never see Joomla! at all. I've never been involved in an implementation with either. [...] So, are we really that out of touch?"

I'm sure there are many out there that would immediately have thought Jon really was out of touch. Because WordPress, Drupal and Joomla account for millions of implementations. To the general public, if they even know what a CMS is, those three have almost become synonymous with the term. To the point that even a serious newspaper like the Guardian would suggest WordPress as the ideal CMS for the Birmingham City Council, lamenting WP never got a fair chance: "Why wasn't it good enough for Birmingham? It seems that there's a prevailing mindset in some parts of local and central government that thinks that if you (actually, taxpayers) aren't paying through the nose, then you're not getting value for money."

Stop right there.

Yes, millions are using these systems and are perfectly happy with them. (In fact, I've commented a few times how, for instance, WordPress is one of the few systems that casual editors actually like to use.) That's why they rate very well in the "simpler" scenarios we describe in our Web Content Management evaluation research. And most of those millions of implementations fall in one of those categories. On the other hand, there are, for instance, no multinationals running all of their online efforts on simple open source PHP systems. Not because they're against open source, or because they think PHP isn't good enough, or because they're eager to "pay through the nose." But because these systems don't really work in their scenarios. (As a side note, I'm not even generalizing all open source PHP systems here -- some, like Typo3 for instance, are quite complex; and a .NET open source system like DotNetNuke is quite straightforward.)

Saying you could do "anything" with any given CMS is true to an extent. But it's like saying that the bicycle that's so healthy for your daily commute, would also be great for a ride to the South Pole. Sure, you certainly could, but the real question is: would you really want to? And if all you know is bicycles, wouldn't planning a trip to the pole be a great occasion to find out what other transportation would be available?

So what does make a project more "complex" than those "simple" scenarios? Well, we could talk about that for a long time (in fact -- it's what we do on this blog most of the time). But to give just a few examples of what would go beyond a "simple" scenario; some of the things that quickly add up complexity:

• Scale of the CMS deployment: Having hundreds or thousands of contributors, and tens or hundreds of thousands, or sometimes, millions of content items. If a CMS tends to display users or content items simply as lists (newest on top, or alphabetically) you can imagine this becomes rather unmanageable at this scale. You really need a lot more sophisticated controls to deal with it, such as efficient search. It gets quite hard to find out who's doing what, where, and when in your system without repository services, audit trails, integration with directories -- and so on.
• Scale of the published websites: Running a simple PHP CMS on a hosted LAMP server is quick and easy. However, you may find that what works for thousands of visitors doesn't at all scale to millions. Many of the simpler systems we cover are actually much harder to run when you try to use them for high traffic (because they aren't really prepared for it, so you'll have to customize, adapt and use a toolbox of tricks) than complex systems which come with out-of-the-box functionality for massive scaling.
• Content re-use: When you want to use the same content in multiple places in a website, and/or in multiple sites or channels. Especially when this involves placeless content, deployed based on different criteria (automatically and manually). It will quickly build up the complexity of both the core system, but also the interfaces in order to keep it all manageable and intelligible for users.
• Globalization: Just take a look at an airline website. There's not a shocking amount of content, but usually it'll have to be available in at least dozens of languages, in multiple websites targeted at various countries. This means content needs to be translated, but also adapted to nuances of local requirements. Managing this effectively is quite hard, and complexity tends to increase exponentially for each locale added.
• Workflow: In many cases complex workflow is overrated, and straightforward "save - review - publish" would be more than enough. But there are scenarios that won't do at all. If, for instance, content has to be checked by legal, or translated into multiple languages, preferably (to save time) in parallel, you need to be able to design complex branching workflows to deal with this.

Of course, there's a lot more, and if this interests you, I'd suggest you have a look at the introductory chapters of our Web Content Management research. But suffice it to say, when I say "this system is great for simple scenarios, but don't think it'd be just as great for complex scenarios" -- I really do mean complex scenarios. (But that doesn't mean I hate bicycles.)

In the end, what it boils down to is using the right system for the right job. Use something simple and cheap for a simple problem. But don't forget that sometimes, complex problems demand complex solutions. It would be ridiculous to buy a train to get groceries; just as ridiculous as getting a bicycle to haul tons of bricks.

• Folding WordPress MU (multi-user) and regular WordPress into one system means you'll now be able to run multiple blogs from an install. This means WordPress is now more like Movable Type:
• "Custom post types" mean WordPress can now do other content types than just "posts" and "pages" -- this seems trivial for most WCM systems, but it's not something to take for granted. This means WordPress is now more like Drupal (and its CCK, to become part of Drupal 7 core).

Is this great news? I'm sure many would think so. And I like WordPress as blog software (even though I think Movable Type may still be the better choice for running multiple blogs). I can also see its appeal as simple web CMS (it's more user-friendly than Drupal, but can be made to do pretty much the same things). As the WordPress blog says, "Arm your vuvuzelas!" -- to which I'd like to add: "bzzzzzzzz."

Let's face it, the main reason so many have started to use WP as a CMS to power sites other than blogs is simple: because it's easy to use. (For blogs.) Every feature (and every plugin) added to WP threatens that same ease of use. And as soon as you start making it jump hoops to do more complex things than it was designed to do, you completely loose the advantage. Use it for more than dozens of pages, more than two languages, or more than just a handful of sites, and WP will begin to hurt.

I'll keep repeating my mantra: WordPress is great for a blog. But there's a real risk of it being turned into a very mediocre CMS. It really depends on your scenarios, and there are many reasons you'd want to look beyond WP. Don't mistake WordPress for a cheap and simple alternative to just any other system in our Web Content Management research. That would be like using a vuvuzela to play Brahms and Ravel.

The platform has many new features such as:

• Plug-in based architecture allowing you to host multiple portal type applications or add on other components to your Portal infrastructure
• A complete new user interface that is based on the GateIn Portal. The UI is based on Groovy framework and replaces the existing JSF based interface
• It uses a different page model in which each page is stored in a Java Content Repository (based on eXo JCR)
• An in-built gadget container based on Apache's Shindig allowing you to host and run gadgets along with portlets
• Some of the other features are support for Right to Left (RTL) languages, a new identity manager, and a cache implementation

Many of these features above are not just enhancements but completely new development efforts. While it is called EPP 5 and targeted as a next release of their existing EPP 4.x, remember that it is really a new product for all practical purposes. We describe some of the platform's other demerits in our Portals and Content Integration evaluation research.

In addition to this, today we reached something of a milestone with more than 4000 people coming to download the ECM Maturity Model, a truly remarkable figure when you stop to think about it. The decision to make the original model completely open source and free was definitely the right one, as public and private sector alike have been able to simply download the free PDF without charge or obstacle, and they have definitely done in style!

All of us here at Real Story Group have been practitioners in our own right prior to becoming analysts, and our work is centered solely on helping buyers and end users so the maturity model makes perfect sense. ECM is complex and bewildering at times, and we have seen an enormous need for a tool that quickly helps you get a grip on where you are now and where you need to go in the future.

Progressing the model further remains a challenge though. We have not always be great at following up with the community as we would have liked. For those willing to roll up their sleeves and help, we do welcome you. Frankly the model is not going to progress much further by our efforts alone. That being said, it's in a pretty good state at the moment, and compared to others out there we can be fairly bold in stating that we believe it to be the deepest and most comprehensive available, and we plan to keep it that way - and keep it free.

So, with your help, a more comprehensive Version 3.0 update will come in time. But for now we will have a little celebration at the milestone, and look forward to hearing more of your stories and feedback regarding your use of the model with anticipation.

My colleague Adriaan Bloem has produced a short briefing answering two important questions that have emerged around Gardens:

1. Is it oriented more towards simpler use cases like blogging, or more complex services that make up traditional websites and community platforms?

2. Does it target Drupal novices, experts, or neither?

Web CMS and Collaboration & Community stream subscribers can download the Gardens advisory briefing here.

For an open source project, that's a lot of time between two versions. There have also been concerns raised about transparency and governance within Open Source Matters (OSM), the not-for-profit that manages the Joomla! project. However, with a new leadership team and much awaited release of Joomla 1.6, things seem to be back on track for the project.

First, the good things. The new release has made numerous improvements, many of which are subtle - enhancements to extensions manager, new templates out-of-the-box, newly written menu system, general refactoring, and performance improvements, among others.

However, some bigger changes - about which we have detailed in our WCM research before -- and the ones that add some enterprise capabilities to Joomla are:

1. New Access Control System: In Joomla 1.5, you had fixed Groups, fixed access levels, and a fixed relationship between Groups and Access Levels. A user could only be assigned to one Group. Version 1.6 changes all that - you can have any number of Groups, Access Levels and can assign your users to multiple groups. There are also changes to how permissions work and in particular, the way you can inherit permissions and have a hierarchy could be very useful for more advanced scenarios.
2. No more Sections: In Joomla 1.5, the way to categorize content was based on Category and Sections. 1.6 does away with Sections but you can have a category tree - as deep as you want to organize your content. However, the old limitation that one article can only belong to one category still remains.
3. Form API: A new form API allows developers to customize the forms that makeup the back-end. So now you can have your own custom fields in forms such as the content entry form. While this in no way comes close to the ability to define custom content types (such as those in Drupal using CCK), it does make it easy for an extension developer to create an extension that allows you to customize your content entry screens.

And now the not so good things. If you are currently running Joomla 1.5, now is the time to start thinking of implications and things that you need to plan for. Consider the following changes:

• Joomla 1.5 supported a legacy mode that allowed you to run extensions written for older versions. This will no longer be supported and you will need to ensure all your extensions support the new version. So start pushing the individual extension developers to make sure the extensions are upgraded.
• Joomla 1.6 requires considerably higher resources in terms of PHP and MySQL. So make sure your host supports the new requirements
• While having nested categories is a good addition, the fact that there will be no sections means the URLs will have to undergo a change. There might be implications on your SEO initiatives and general content migration issues.
• The new ACL and Security system allows for a very fine grained access control mechanism. But with flexibility comes complexity and you will need to invest significant efforts to plan how you would want to structure who can view what. And if you are an Joomla 1.5 and want to take advantage of the new access control mechanism, you will need to map your existing users/roles to the new ones in Joomla 1.6 and this could again have an impact on your migration planning

So while the new release does add a lot of new features, make sure you plan well in advance, especially if you are dependent on third party developers for extensions or have a lot of content to migrate.

Perhaps more generally, this release takes Joomla! more in the direction of enterprisey use-cases.  However, to the extent that it doesn't quite get there on several fronts -- and yet has become more complicated -- Joomla! risks becoming a kind of uncomfortable middle for you: no longer the simple product its many adherents love, but not quite durable enough for most larger organizational scenarios. 

We cover more details about this as well as about the forthcoming releases of other Open Source products including eXo, JBoss and GateIn in our regular updates to the Portals and WCM evaluation research.

This gets worse when two vendors go head-to-head. For instance, last month, collaboration and community software vendor Jive published a whitepaper called "Jive vs. Open Source." It argues the case for Jive just as I would expect a marketing team to do it. It mostly ignores the pros of open source (saying "there are no licensing costs to deal with," which isn't even necessarily true; it depends on the license.) But it also states open source cons without much effort to actually reason them. I particularly liked the out-of-context quote, "Open source projects focus on developing software that addresses a specific need, ensuring that the need is well met." The whitepaper doesn't really explain how this is supposed to be a bad thing.

On the final page, Jive states its advantages over Drupal. Acquia (the Drupal commercial open source company) took offense, and has now responded with a package called "Drupal Commons" as a specific alternative to Jive SBS. Unfortunately, Acquia is fighting fire with fire, using pretty much the same kind of superfluous argumentation the other way, talking about Jive's million dollar licenses and how they'd "love to show how Drupal can run circles around Jive SBS for a lot less money." Personally, I'm not quite sure I'd like software to run in circles.

This is just a little tiff between vendors, so why should you care? Well, both are making it abundantly clear that a vendor is not a neutral source of information (even if the vendor is marketing open source, like Acquia.) So wouldn't you rather get your information from people that are not trying to argue a case?

Of course, I'm now trying to win you over as much as these vendors do. There's a huge difference, though: it's not in our best interest to confuse you; we only win by providing you with clear analysis of your choices, depending on your specific context. And in this case, that means digging through whitepapers -- and more importantly real customer experiences -- so you don't have to...

Lucid also provides a number of open-source testing and performance monitoring tools for Lucene. Lucid's customers include Nike and Netflix. Launched only in 2009, the company claims revenue in the “millions."

The advent of additional funding should contribute to Lucid's viability, which is welcome news to customers. But you should also understand that for small companies with major VC funding, there's typically an exit for the investors somewhere (perhaps three to five years) out on the horizon.  That typically means the company will eventually sell itself to somebody bigger -- maybe much bigger. So if you go with Lucid Imagination, understand that such a transition may lie in your future, and those always bring risks. (Of course, we'd caution the same thing for other similar ventures as well, such as Alfresco.)

For critical analysis about the pros and cons of Lucene, Solr, and Lucid Imagination, be sure to consult our Search and Information Access Research.

The answer is, we use an open-source platform called "Midgard." We picked it nearly ten years ago, and it has held up fairly well. The leisurely development pace of the Midgard project ultimately led us to drop official research coverage of it within our WCM evaluation stream, in lieu of more vibrant PHP-based systems like Typo3, eZ Publish, Drupal, Joomla!, and the like. But by the same token we've welcomed not having to suffer through multiple upgrades!

Midgard has remained popular mostly in the Baltic region. We are one of the few sites west of Hamburg to use it (another is playbill.com).

One of the things we like about Midgard actually makes it rather unsuitable for many simpler publishing scenarios: it is highly object-oriented. This allows us to run multiple sites off largely a single codebase -- at the cost of quite user-unfriendly administrative and authoring facilities.

Also, Midgard is very much a development platform, and we have had to create a fair amount of custom code, especially to handle structured content. In that regard, our CMS experience probably resemble yours. As an industry we remain very far from plug-and-play content management technology for all but the simplest of websites.

According to IBM's research, while Apache and PHP account for only 0.4 percent and 0.6 percent (respectively) of total reported vulnerabilities, Drupal accounted for 2.7 percent and Joomla! accounted for 2.6 percent. TYPO3 and WordPress fared somewhat better, at 1.5 and 0.4 percent, respectively.

But the more ominous news has to do with patches for security problems involving plug-ins. A whopping 80 percent of the vulnerabilities reported for Joomla! plug-ins (against 13 percent for Drupal plug-ins) had no available security patches by year's end. That compares to 8 percent of Joomla! core system vulnerabilities that had no known patch, and 18 percent of Drupal core vulnerabilities with no patch. If you're a TYPO3 user, you'll find that 51 percent of plug-in vulnerabilities have no patch (versus just 5% of core system gotchas), while with WordPresss the unpatched plug-in flaws come to 57 percent, versus 13 percent for core.

Bottom line: Systems that are heavily reliant on plug-ins are more apt to have security vulnerabilities for which there is no known patch. Why is this?  Even frequently-used plug-ins are not always actively maintained and enhanced by their original developers.  Our Web CMS evaluation research cites some specific examples across several platforms. 

IBM did the worst presentation of all, Microsoft did almost as badly, and the open source vendor wowed the client with by far the most professional and convincing demo and presentation.  The deal was all done...until costs were discussed.  To everyone's surprise when one took into account consulting, integration, and maintenance fees, the open source option was by far the most expensive.  In fact, too expensive.

This is not something that gets discussed often.  Indeed the key selling point for many open source options remains (often quite rightly) the low cost involved. But times are changing, and the commercial open source model sweeping content technology marketplaces is proving to be very profitable for some suppliers. 

I will go as far as to say that I am a fan of open source, and in the right circumstances will recommend it over more traditional licensing options. But I never tell our clients that it will be cheap or cheaper than the competition. Not until all the numbers are on the table will you know that for sure.

Infrastructure Vendors

• IBM: WebSphere Portal Server 6.1.5
• Microsoft: Microsoft Office SharePoint Server 2007 SP2
• Oracle: WebLogic Portal 10gR3
• Oracle: WebCenter Suite 11gR1
• SAP: SAP NetWeaver 7.0 Enhancement Package 1
• RedHat: JBoss Enterprise Portal Platform 4.3

Specialist Portal Products

• Open Text: Vignette Portal 8.0
• Broadvision Portal 8.1
• eXo Portal 2.5
• GateIn 3.0
• Liferay: Liferay Portal 5.2.3
• Plone: Plone 3.3.2
• uPortal 3.1.2

Our annual subscribers and recent customers will receive their updates automatically. You can also download a free sample of any of our evaluations.

By the way, this release marks the end of an era for CMS Watch -- and the beginning of a new one. This will be the last "big-bang" update that CMS Watch releases in the current format. With your feedback, we are embarking on new research delivery model that emphasizes online access to the latest updates, along with more avenues for obtaining practical advice for your specific problems.

Rest assured that buyers of this report and any of our existing research in the weeks to come will automatically receive access to our new services. We're extremely excited about the new model and we think you will be too. In the meantime, I hope you'll join the club by signing on to one of our research streams.

Both Red Hat and eXo will use GateIn in their respective offerings.  Just to clear some confusion, Red Hat's commercially supported Portal product is called JBoss Enterprise Portal Platform (EPP). EPP has many other components like the Portal CMS module, Enterprise Application Platform (EAP), Identity Module, and the JBoss Portal Project. It is this last Portal Project component that will get replaced by a version of GateIn project in the next version of EPP (version 5). EPP 5, which is slated to be released by May 2010, will also use eXo JCR (an implementation of JSR 170 by eXo), and will also later integrate eXo's Web Content Management.

Similarly, eXo Platform will replace eXo Portal with GateIn project and will eventually certify all their other components to work with GateIn (and EPP).  This means that all their applications like eXo Social, eXo Collaboration, and so forth will use GateIn as the Portal runtime instead of the existing eXo Portal.

So what's the big deal?

There are a couple of reasons that make this interesting. GateIn is not just a low-level framework like Struts or even a simple Portlet container, but a complete portal runtime, complete with bells and whistles getting reused across two platforms. The portal is now slowly becoming one component of an overall platform and in that sense getting "commoditized."  The partnership between Sun and Liferay under which Sun was planning to use Liferay's Portal Server for their own version of Portal was another example. With Oracle acquiring Sun though, the future of that initiative is not clear.

If base portal functionality is becoming a commodity, how do vendors differentiate? (That's a question many people ask when talking about standards as well.) Well, one way they differentiate is by building around the common component (or standard in case of discussion around that). In this case, JBoss differentiates by bringing in its middleware expertise and tighter integration with JBoss infrastructure, whereas eXo differentiates by building applications on top of this platform.

Finally, as I mentioned on twitter, this is a rather unique situation that has an impact on both vendors (and hence their customers). Red Hat for its part has committed to support its existing platform for five years (four more to go now) but the fact remains that they will not be doing any new development (apart from upgrading the Portlet Bridge) on JBoss Portal (the project) as Red Hat focuses on GateIn. Remember, GateIn is quite different from JBoss Portal and so for existing JBoss Portal customers its means a migration effort or committing to a legacy platform that will not see any new advancement.

So if you are evaluating Portal platforms, keep this in mind and make sure you understand clearly the respective vendors' road maps and how they align with your requirements. We cover more details in our Portals evaluation research.

From multiple vendors using the same portal as a component to one vendor offering multiple different portals, these are interesting times for the portal marketplace...

And which vendor has perfected the maintenance fee profit engine? You guessed it: Oracle. InformationWeek's Bob Evans explains in an excellent column, "Global CIO: How 22% Annual Fees For You Equals 51% Operating Margins For Oracle."

I think Oracle's success has had a huge influence on the technology marketplace. In the ten years that I've been covering content management, portals, search, et. al., I've seen many other vendors deliberately mimic Oracle's model.

And we're not just talking about commercial vendors here. A new breed of "commercial open source" vendors has also explicitly copied Oracle's approach: if a lion's share of the profits lies in customers paying annual fees, why charge for the software up front at all? Simply invest a little R&D to get started, use consulting projects and whatever the community can muster to drive ongoing innovation, carefully collar tech support costs, grow the company, and then sell it to a larger firm looking to acquire reliable revenue streams...such as Oracle.

These fees would feel less galling if you received great support in return. You've told us over the years that some vendors do indeed excel here. But most do not.

Then there's the thorny issue of supporting the software versus supporting (and upgrading) the implementation. In most sizable projects, someone (either your developers, a consulting firm, or a vendor's professional services arm) has so heavily customized the software that your vendor's tech support can quickly become impotent, save for addressing common bugs or very low-level problems. We've been advising buyers to take a close look at warranties and tech support within any consulting contracts, including those signed with a vendor. Remain particularly alert when buying software via a re-seller -- an increasingly prevalent model in the Web CMS market, as well as several others we cover.

Is there anything to like about maintenance fees? Some observers pointed out on Twitter yesterday that we should at least value the predictability of such expenses, even as we decry the rates (@lehawes). Annual fees help provide a kind of insurance for the customer and enable the vendor to invest in long-term support for the core codebase. And they put less pressure on vendors to front-load their total costs+ profit (@damtrends). Presumably vendors can break-even now, then profit later.

But oh, the profits. As part of our evaluations of publicly-traded vendors, we often listen in on quarterly financial analyst calls, which as Evans notes, can be quite revealing. One of my favorite vendor boasts to equity markets is, "obtaining a higher yield from existing customers." How much should financial performance matter to you the buyer? A little. It's good to know your vendor won't go bankrupt. Nonetheless, I think traditional technology analyst firms do enterprise buyers an injustice by too often conflating a software vendor's financial success with technical acumen or product development skill. (Some analysts also mis-identify vendor marketing and sales acumen with customer value, but that's another story....) I'm quite certain that in the software world, there's no definite correlation between profits and quality. According to Oracle's CFO, there is a correlation between profits and size of maintenance base.

There's some good news, though. We're seeing increasingly better peer-based, community support. This trend is surely more advanced in the open source world, but commercial vendors have been catching on here, too. The availability of peer support has become an important criterion for our evaluations in recent years, and enlightened suppliers are fostering active communication among customers.

Our research reports also instruct technology buyers how to negotiate down annual maintenance rates. In the field, we sometimes receive slack-jawed responses from both the customer ("you mean we can do that?") and the vendor ("you want to carve up our golden calf?"). Yes, on both counts.

It's too soon to know whether Lucene's continued meteoric rise in popularity will eventually spell trouble for establshed information-retrieval players like Autonomy, Endeca, or Open Text. It seems premature -- maybe even preposterous -- to suggest such a possibility. Then again, not so long ago, it seemed preposterous that people would someday carry telephones in their pockets. Funny how things change.

Armed with venture capital, Bluenog seems to have taken the pre-dot-com-bubble-burst path. Invest your money wisely: spend it on marketing. I get frequent emails singing the praise of Bluenog's ICE, which would almost lead me to think that the solution has real market presence. Almost, because in reality, compared to the vendors we cover, they still have a lot of ground to cover. The company recently released a "Higher Education Initiative," presumably sensing an opportunity after three wins in that area. But even if there were to be a "best" solution for a specific vertical, there's some pretty stiff competition there (including Terminalfour, which is gaining its footing in the U.S. on the basis of its expertise in education).

And then there's the tool itself. Bluenog is a mashup of open source -- "ICE leverages several open source CMS, open source collaboration, open source portal and open source BI projects" which are listed in a faraway corner of their site. Bluenog ICE, however, is a commercial closed source product. Having just written a blog post on open source, "it's just a license", I find it ironic that immediately afterwards I was alerted to a small storm brewing on just that topic.

Don't worry: as a solutions buyer, I still don't think you should be overly worried about licensing and Seth Gottlieb seems to agree on that. But like I said in my previous post, there is an exception: if you're a software company, building on open source, you're expected to participate in the community and give back code. Large parts of Bluenog ICE rely on Hippo CMS (in an older version 6), something Bluenog doesn't seem particularly keen on emphasizing.

Understandably, Hippo isn't very happy about it. As you may know, "more people are killed by the hippopotamus than any other wild animal, either by being trampled to death or having their boat capsized." I don't quite see Bluenog being trampled or capsized by Hippo yet, but there's discussion of a possible breach of the Apache license. That would be novel, because usually with open source, it would be the other way round.

Bluenog issued a press release saying it intends to "contribute back to open source projects." I checked, and Bluenog developers don't seem to play much of a role in the development of any of the Apache projects they use. Bluenog promises "extensions to the popular JSPWiki, which adds support for wiki and page level permissions", but as of yet, JSPWiki's wiki doesn't seem to have any contributions from Bluenog developers.

Checking the Hippo mailing lists, I did find quite a few posts by Bluenog developers. But most of these were questions, and some just a cry for help. And, unintentionally funny, Bluenog CTO Suresh Kuppusamy asked the list "Can you please check if I locked the car. I forgot to lock it" (later apologizing that he had sent this to the wrong address).

By contrast, you can criticize Hippo for lacking the ability to execute with the new version 7 of their CMS, or for the fact that the vendor is very developer-centric. As commercial open source, it's not exactly run for altruistic purposes, and the Hippo community mostly revolves around the company itself. But if you want a Hippo, you'll probably want the people that are taking an active lead in the direction the project is going.

Currently, Bluenog is missing not only the transparency of what they're actually selling -- they're also passengers on the journey, rather than drivers. There's nothing wrong with sharing the safari vehicle. But usually, you'd still like to know where it's going.

As a student, I spent some time studying information technology law, and I'm still intrigued by the legal technicalities of Apache, GPL, LGPL, and other open source licenses. I will also, from time to time, read the fine print of commercial licenses. Your legal department will probably want to do the same. But you should ask yourself this: is the license really a decisive factor when picking software?

Oddly enough, with open source, it often is. In many European countries, governments are actively pushing for the use of "open source" and "open standards." On a superficial level, that makes a lot of sense. Who'd want vendor lock-in, or extortion by an integrators' truck system? Think of all the advantages. Who doesn't want global interoperability? How could you possibly resist the ability to shape and mold software to your liking? And best of all, it's free!

Of course, in reality, things aren't quite so black and white. First of all, I have to keep repeating that open source isn't gratis ("think of free as in free speech, not as in free beer"). The "free" refers to a model of development and innovation, not to a matter of cost. Get out your calculator and tell me this: what's more expensive over the course of three years. Software that's $30K up front, with a 15% annual maintenance and support fee; or software that's "free," but with $15K a year in "gold support"? Or, if you're planning on doing it yourself, one FTE? It's just an example, but you get the point -- it's very hard to do an enterprise implementation cheap, whichever way you turn it. Large companies like IBM aren't in open source because they've suddenly become philanthropists.

So maybe the real reason is development. You can take the open source software and change it. That may be true, but "closed source" doesn't mean to say you can't modify the code that's on your servers. It's usually a bad idea -- your changes may be lost with the next update -- but then again, the same could happen with open source software's next release. Sure, often you can't really touch compiled commercial code; but how many actually modify and recompile open source C? If you're a software company, developing on the basis of open source, you may want to actively participate in an open source community and help develop the code. But if you're not, all you may want out of the community is free support: see the previous paragraph.

In reality, not only is there a large gray area between black and white, there are plenty of zebras, as well. There's commercial open source, there's shared source, there's community open source, there's community editions, there's open sourced commercial software. There's open source without much of a community, and commercial closed source with a large and active community. There's a lot of mature and stable open source software, and a lot of new and untested commercial software. It's hard to apply any clichés to such a broad spectrum.

There's only one thing you can generalize: open source is a specific kind of license. And discussions about which license is better are rather academic. What you'd want to decide on is what your software should do, if and how you want to customize it, and how easy it is to get support when you need it. That means doing your homework, and finding out the real story: you'll certainly want to know what's behind the facade. And that's something that applies to software under any license.

As it turns out, Lucid Imagination had exactly that idea. The company, which offers commercial support for Lucene and Solr, is now offering it's own "LucidWorks" versions with the ISYS filters integrated. This means one of the gaps between open source and commercial search products has been bridged: with the filters, Lucene, too, can read over 200 file types.

According to Lucid, this has been one of the favorite doubts commercial vendors would cast over the open source search engine, and the move should level the playing field. However, as a customer, you should be aware that there's a couple of other things you may take for granted that are missing. Connectors to various content repositories, for instance, don't come with Lucene, not even a simple web crawler.

Still, the filters are a welcome addition, and they're certainly an improvement over what's currently available as open source. It's not just in the numbers: ask yourself how you think a converter will read a three-column Word document. You may be surprised to know that some will just go across all the first lines from left to right, then the second lines, etcetera. As always in Search & Information Access, the devil is in the details -- and knowing about these details will pay off.

The added filters aren't for free, but not exactly expensive, either. There's a 14-day trial, and you can get a subset (e.g., Microsoft Office) of the filters for as little as $3.250 for 2 years, or pay $10.000 for all of them (including those pesky legacy formats you'll discover in a distant corner of your fileserver when you least expect it.) That's still a long way off from the hundreds of thousands even a Google Appliance implementation may cost you in licensing. (Though there's no such thing as a free lunch or free beer with open source, either.)

So this is interesting news if you're considering Lucene, but what about ISYS? Aren't they selling the family silver? Well, let me wrap up this post by meandering off into history. As the (perhaps apocryphal) story has it, when the Dutch were at war with the Spanish in the 16th century, they were still selling cannons to their opponents. They figured they might as well make a profit out of it: the outcome would be determined by strategy, anyway.

Open source projects and commercial vendors, on the other hand, don't even have to be at war. And as with a Spanish Rioja or a Dutch Heineken, it's all about picking the right one for the occasion.

ECM platforms are by their nature highly complex systems that revolve around enterprise processes (sometimes working in tandem with business process management software), as well as typically interface with a wide range of other technologies from imaging through rendering to archiving. A high percentage of ECM deployments integrate with legacy business applications such as CRM or ERP solutions. That's very different from most Web CMS deployments -- which are usually more standalone in nature.

Part of the historic challenge for open source ECM has been an allergic reaction to integrating with Microsoft Windows and Office.  Fortunately, that's changing a bit. 

But the real story here may lie in business models.  Commercial -style open source seems to be a better fit for ECM rather than the more common (in the Web CMS world) community-driven open source options. Commercial style open source such as Alfresco may not charge you up front licensing fees, but they do provide centralized support and development services (for a potentially hefty fee) -- in the same manner as their fully commercial/proprietary rivals. It's a model that ECM buyers who are inclined toward open source are comfortable with and for some enterprises, it is a model that can work well.

Many ECM buyers look warily at the CMS world where open source projects have a tendency to come in and out of fashion. Today, they see Joomla, Drupal, and a few others in fashion, but also a fairly large graveyard full of currently unfashionable community driven frameworks. Some of those might be revived at some future point, but many are for all intents and purposes dead. So, for ECM buyers, the commercial models of the likes of Nuxeo and Alfresco can act as a form of insurance for buyers. The buyer feels safe that their acquired software, (as long as they pay the maintenance fees) will be supported and developed in the long term. Clearly it is not a 100% guarantee, but it is something.

I think in time more open source ECM solutions will become available.  We know for sure that a number of fully commercial vendors have investigated the possibility of open sourcing their solutions, and at some point one of them will take the jump and others may well follow. But what is holding them back at the moment is the tiny revenue streams that open source ECM vendors can boast, in comparison to their more proprietary rivals. For no matter how you do the math -- be it seat numbers or revenue -- open source still represents a tiny portion of the ECM market, and despite all the negativity about the economy, multi-million dollar ECM deals still get signed on a regular basis. And as long as that remains the case, there is little real incentive for proprietary vendors to walk away from that money and sell maintenance-only contracts.

I, for one, would like to see a few more open source ECM vendors. Right now, as subscribers to our ECM Suites research know, the four open source ECM players are very regional in their customer bases and don't often compete head-to-head for the same business. There is enough business out there and ample opportunity for enterprising folk to rethink and reinvent the ECM paradigm. And true competition among the open source efforts would undoubtedly bring even more positive product enhancements and value to you the buyer.

According to the Chemistry wiki: "Apache Chemistry is an effort to provide a Java (and possibly others, like JavaScript) implementation of an upcoming CMIS specification, consisting of a high-level API for developers wanting to manipulate documents, a low-level SPI [Service Provider Interface] close to the CMIS protocol for developers wanting to implement a client or a server, and default implementations for all of the above. Chemistry aims to cover both the AtomPub and SOAP bindings defined by the CMIS specifications."

Some months ago, Day Software tried to drum up interest in a CMIS-to-JCR bridge layer as part of Apache Jackrabbit (the well-known JCR reference implementation). But a more generic (non-JCR) open-source CMIS implementation, led by Florent Guillaume and other Nuxeo employees, began to gather momentum before the CMIS-JCR bridge effort had a chance to get very far. Soon enough, the two companies realized that rather than duplicate each other's efforts, it might be better to combine efforts on a larger, joint effort (not tied to JCR) hosted by Apache. The name Chemistry was chosen, in part, because it contains the letters 'CMIS.'

Committers on the project include five developers from Nuxeo, two from Day, and one each from Alfresco and European Open Source systems integrator SourceSense.

We see this as yet another indication (if any was needed) of the broad base of support behind CMIS. What will be interesting to see is whether any of the large commercial vendors who are backing CMIS (such as Microsoft, Open Text, and EMC) will contribute code to the Chemistry project -- and then use it once it's released. The potential exists for commercial vendors to adapt the Chemistry code for their own use. The alternative, of course, is for those vendors to reinvent the wheel in-house. That costs time and ultimately money. And the costs are passed on to (guess who?) you, the consumer.

We'll keep you posted, whichever way it goes.

The short answer is: yes. At the ApacheCon Lucene meetup in Amsterdam, Erik Hatcher gave a demo of LucidFind, which is based on Solr -- one of Lucene's more productized flavors. (Incidentally, this was one of the fastest demos I've ever seen -- it may have lasted for all of two minutes). LucidFind searches most of the public sources for Lucene (including wikis and mailinglists) and related projects (such as Solr, Nutch, and Mahout), and then allows you to drill-down into the results using faceted navigation. You can narrow results down on project, source, and author.

Of course, Erik Hatcher is one of the founders of Lucid Imagination, and LucidFind is a showcase for the company. Other search vendors have done the same before them, notably Vivisimo with its federating/clustering Clusty, and Exalead with its public website search. The clever thing here, of course, is that those are interesting examples, but LucidFind takes it to a new meta-level -- actually indexing search so you can find it.

So certainly in this scenario, Apache's Solr proves more useful than Apache's Google Site Search. If you ever need to find any technical details on Lucene, this is the place to go. Now if only it could find you the answer to the question whether Lucene would work for you, too. But that's another story.

From the release:

By understanding the structure of the Web CMS repository, the search engine can access more relevant data, and deliver richer results, more easily than a 3rd-party solution

To be sure, most Web CMS vendors have always provided sort of embedded repository search for authors and managers, but this is about searching the published website -- a source of perennial frustration that spawned the Google Search Appliance. But it turns out that for many customers, Google just doesn't cut it.

A big driver here is the rise of the broad open source search framework, Lucene, which gives vendors a flexible framework -- if they take the time and effort to integrate it carefully.

By our latest count, the following vendors among those we cover now embed Lucene: Alfresco, Clickability, Day, DotNetNuke, Escenic, eZ publish, Goss, Hannon Hill, Hippo, Magnolia, FatWire, OpenCms, Percussion, Refresh, Telerik, and Vyre. Others are considering it.

As the release says, this trend brings many potential benefits for you the customer, but also some potential pitfalls. We've seen some great Lucene integrations, and some really crappy ones. Consult The Web CMS Report for more details.

While not quite as ambitious as endeavours in other countries, the project, dubbed "Project ONS" (see the announcement in Dutch) is still a major undertaking, replacing the individual sites of 13 ministries and several public information sites (including government.nl). It is estimated to cost €6 milion, of which €250,000 in software (presumably in support and development, since Hippo CMS is open source, licensed under the Apache License 2.0). The first release of the new site is planned for October 2009, and the project should be completed in 2011.

Readers of The Web CMS Report may be surprised that an untested new version of Hippo CMS would get chosen for a project on this scale. While version 6 is still in active use (and is available rebranded as Bluenog CMS as well), version 7 is a complete re-write, which has been on the verge of being released for a year. And even though it's now out officially -- and it seems the underlying platform is pretty stable -- the interface (built on Wicket) still has plenty of annoyances and minor bugs that will need to be fixed.

I've seen a few blogposts mention fancy features in the UI, such as drag & drop linking and image placement, type-ahead-search, and autosave. However, in reality, not all of those have been implemented yet, and many fail to work as users would expect them. It's getting better quickly -- minor releases are now following in rapid succession, with 2.02 in December, 2.03 in January, and 2.04 in February -- but still a work in progress.

Common wisdom has it that a hippo is an animal that lives in denial. However, the director of the project team told me that the selection process was meticulous, and included several months spent on a proof-of-concept. They're aware of the newness of the platform and the work still being done on the interface, but confident that the creases will be ironed out.

While this is reassuring if you're considering going with Hippo CMS 7, you might not want to be quite as courageous in committing to it just yet. We'll be keeping tabs on how the Dutch company lives up to its ambitious roadmap, so watch this space if you want to see how the hippotomi migrate.