India recently finalized its 3G policy and although we are way behind many countries, it is expected that 3G subscribers will cross the 100 million mark - that's more than the total population of many countries - within 5 years. With one of the lowest rates in the world (20 paise a minute or about 0.5 cents for a 3G video call) and innovations such as the $35 tablet, I don't doubt that estimate at all.  3G will reach where wired broadband could not.

What concerns me though are some of the other challenges that remain largely unaddressed:

1. I don't think the content providers and app developers have understood local pricing yet.  Many of them have their global pricing strucutures applicable here. In fact, many of them have actually priced their offerings higher in India. I am no economist but I also understand that the incremental cost of producing a digital product is miniscule as compared to that of a physical product. A small blog post is not enough to discuss all the intricacies of pricing but the content providers (and also the vendors) should keep their options open for differential pricing as well as pricing which is in line with cost of other things. After all, a customer who pays 0.5 Cents for a 3G video call is hardly likely to pay $20 for a social networking client
2. It is just not sufficient to have iPhone or Blackberry versions of your site if you want your content to be consumed more broadly. You need to be able to have much more fine-grained support for different types of handsets, and not just a few types of smart-phones. We detail why this is important and how this can be implemented in an advisory paper, "Adapting Your Content Management Platform for Mobile Delivery"  for our subscribers.
3. Localization is very important. There are 22 official languages and many more dialects as well as unofficial languages spoken in India. So your content systems should make it easier for users to interact in local languages.  Having a Unicode compliant WCM system is not enough; you also need to have local language interfaces to enter content in users' language of choice. I'm not suggesting that there should be a version of TweetDeck in all 22 languages, but you get the idea.
4. Apart from the language, there are many other unique aspects that these systems should support or enable. As an example, if some of the vendors were to come up with an out-of-the-box accelerator for building Matrimony or Astrology sites -- the two most popular type of web content in India -- I am sure they would have a big customer base
5. And finally, for  app developers, there is a serious lack of support in terms of SDKs, APIs, policies, and documentation for them to be able to create language-specific, localized applications.  As an example, some app stores do not allow you to submit applications that are ad supported. So you can only submit apps that are either free or paid but not that are supported by any alternative business model. If someone wants to develop a highly unique application such as the one that allows tobacco farmers in rural India to participate in tobacco auctions, the only way to make money would be by way of ads (example courtesy @pranshuj)

In one of the conference keynotes, a speaker explained how mobile apps are going to be big. He gave his own example of how he starts his day by checking his Facebook account, prepares for a music concert, books movie tickets, and does a lot of other stuff all using his "smart" handset. While I don't subscribe to this hype - in this case, our friend probably doesn't have a laptop or life - I do believe that there is a huge opportunity waiting to be tapped, and  some of these challenges will need to get addressed sooner than later.

On a related note, I will be speaking about how to manage content for the mobile world in my session at the J. Boye conference in Aarhus. Please feel free to leave a comment or send me an e-mail if you'd like me to cover anything specific.

Though I'm an analyst, not a fortune teller, my best guess is that Adobe will turn Day's DAM into another "boxed" solution, much like the products of their Creative Suite. Under Adobe, Day's DAM will more likely compete with Extensis, Canto, and Xinet for mid-market, lower-priced, and departmental DAM needs, than grow into an enterprise player. As Apoorv pointed out in our first take on the acquisition, Adobe doesn't have deep experience selling server-side software.

Otherwise, Adobe has a lot of work to do on their new DAM product before it can compete with the major players in the DAM space. As a buyer with creative specialists employing Adobe tools on the desktop every day, don't assume that buying Adobe's DAM is necessarily the right choice for you.

Products like Adobe LiveCycle help the automatic generation and dynamic delivery of personalized documents, usually for customer communications such as insurance quotes or e-bills sent by your telco. 

Adobe's LiveCycle's customers who wanted ECM capabilities had an option of using an embedded Alfresco repository. But now they will also be able to use Day's CRX as well as have tighter integration with Day's Digital Asset Management and Social Collaboration offerings. The announcement does not say anything about whether Alfresco will be replaced by CRX in LiveCycle, so if you are an existing customer of this offering, you'll need to wait and see what the implications may be. 

Existing Day customers may better benefit from the acquisition as they will likely be able to use some of Adobe's personalization capabilities (such as clickstream cloud) in conjunction with LiveCycle as well as have a tighter integration with Adobe's Flash, Flex and other technologies.

The deal will conclude in December 2010 and the FAQ mentions that the current management of Day will continue through 2011. But we recommend you ask for a detailed roadmap from your rep.

The deal also has a significance in terms of the general marketplace. For many organizations, the content lifecycle includes much more than what is "typically" considered part of ECM. In many cases, the end document (e.g., policy or bill) consists of some standard elements such as salutation and greetings along with elements that are specific to you. In the case of a policy, the specific elements could be based on your risk profile or legal terms based on your state or country of residence. In the case of a bill, these specific elements could be new tariff plans or campaigns based on your past history. In these examples, the organization needs to collect information (such as demographics), take it through a business process and then based on some rules, dynamically generate and publish the end result. 

We believe that all of these should be part of content lifecycle and that is the reason why in our ECM & Document Management Marketplace 2010, we've argued that features such as document assembly and dynamic publishing will get increased attention from mainstream ECM vendors in the future. Many other vendors that we cover in our ECM research, such as EMC (with Document Sciences),  HP (with Exstream), Oracle (with Documaker) already have offerings that strive to bring together these two aspects. We plan to include a separate section on Dynamic Publishing and review many such products in our next version of the ECM Report.

As for Adobe and Day, the question that nobody can answer at present is whether Adobe can really sell enterprise-grade customizable software. Their history of selling shrink-wrapped, lower-priced, high-volume software has built the firm into a Silicon Valley giant, but their ability to sell small-scale but very high-value enterprise software deals remains untested. The biggest danger for current Day customers may be that Adobe will want to take the technology, and over time commoditize it into shrink wrapped low-cost functionality bundles. But again, at this stage we can only speculate. And you as a buyer and user of the technology can do no more than act with extreme caution and ensure that any promises made by the Day and Adobe are solid and verifiable.

I'm not going to get into the details of how to add the button -- there are plenty of tutorials on that. Suffice it to say you can either use a simple iFrame, or go all the way using FBML and a Facebook application. The end result will look something like this: click the button below to "Like" the Real Story Group website.

You can do a lot more with the button:

• The "Like" buttons we now append to each blog post will actually like the individual post, not the entire website
• You could make these part of an application; you'd be able to get stats on how well-liked your articles, products, or posts are
• You could also, then, start pushing similar content to Facebook users that liked your content

However, as my colleague Tony Byrne observed, "just because you can, doesn't mean you should." Certainly, when visitors like your content, that means more exposure. But it also means more exposure outside of the context of your website.

In a sense, this is a natural progression from RSS syndication. On this blog, we're well aware that many of our readers don't necessarily visit our site -- they get the content in their feed readers, without our carefully crafted design. (We publish the whole posts in the RSS, not just the abstracts.) That's fine, since we don't make money on advertising around our content -- instead, we're advertising our content.

But obviously, not everybody is pleased with this new reality. Rupert Murdoch is waging a battle with Google "taking his news for nothing." And yesterday, the NYT demanded the Pulse application be pulled from Apple's App Store, since it pulled in NYT content and published it in a different context (the Pulse app).

But even if you're fine with everyone indexing, liking, and retweeting your content, you may not like what happens around it. You might want to see what people are saying about your content, wherever it is they're saying it. You may want to enforce strict rules on how your content looks when it is presented. You may want to add context to it.

To Facebook, of course, it's not so much your content that has value, but the relationships between people and their likes. This becomes part of their Social Graph (which has little to do with graphs, but is all about mapping social networks). There are a couple of sites that make use of Facebook's API to show you what your friends like (such as Like Button). This gives some sense of what kind of information Facebook is gathering. If there's anything Facebook itself likes, it's becoming the central hub of all of these relationships. And of course, so would Google, Twitter, Yahoo, LinkedIn, and many others.

In effect, this means your carefully crafted online publication is under your control, but not your content. As soon as you publish it, it rides off into the sunset, and it may, or may not, live happily ever after. Be careful not to imagine your websites as some sort of non-linear books, nicely bound in leather and sent to known subscribers. If you still want to use paper as an analogy, imagine it as a stack of sheets blowing away in the wind on a busy street. It's going to be difficult to manage that experience.

Of course, these aren't physical pages, and there are many ways to trace them, regroup, and stack them. But it's important to think about the mechanics of content flows across the internet, instead of just pushing out your publication.

Facebook's "Likes" might be a good place to start finding out what that's going to mean for your Web CMS, and perhaps more importantly, for the content you're managing. Traditional content management concepts like "placeless" content, canonical templates, and the separation of content and presentation now take on a much broader meaning. Our tools and our content will need to adapt.

On the surface, this is a run-of-the-mill strategic acquisition. Dassault has built a business around its 3D technology, and now has a software suite to accommodate the whole conceive, design, realize, and service PLM process. It's become one of the most major vendors in that business (with revenues of €1,251m in 2009) and has enough cash to move from a recently announced OEM partnership to a full-blown acquisition in less than a month. Exalead has been pushing "SBAs" ("search based applications") built on top of its CloudView search infrastructure. There should be plenty of opportunities to integrate that search technology into the PLM cycle.

But there's a little bit more to it than that. The press release struggles to pithily convey it, quoting Yvan Proteau of Yellow Pages: "The combination of these entities will help organizations like ours create better user experiences based on the delivery of information and data in an innovative manner that leverages the latest in 3D technology that consumers have long demanded."

Wait... what? Are we going to see a Yellow Pages iPhone app that uses Exalead to understand what mood you're in, and then uses Dassault technology to display suggested restaurants in 3D?

Actually, they're already halfway there. Yellow Pages recently launched the Urbanizer app, which uses Exalead to recommend places based on your mood. And Dassault has created 3dvia, where users can build 3D environments on-line.

Both companies have a history of generating revenue out of their core technology, and then branching out in all directions from that. For Dassault, the bread-and-butter is 3D and PLM; but it also created 3dvia, and invested in community & collaboration vendor blueKiwi. Exalead's main business is enterprise search; a few years ago, mostly indexing Lotus repositories, and more recently, building larger (and more custom) enterprise integrations. But Exalead also built a large public web search engine, indexed the French President's speeches, and powered an iPhone app.

Normally, with an acquisition like this, I would caution any current or potential customer to think carefully whether the priorities of new owners will still be with their scenarios. However, both Dassault and Exalead have shown they're strongly engineering-driven, and unafraid to trod off the beaten path. With a new wealthy parent, Exalead is not likely to shut down its more exotic projects as irrelevant extravagances. There will be plenty of search applications for Dassault's PLM, and I'm fairly certain Exalead will hold on to its current customers. But don't be surprised to also see an animated, 3d, mood-sensing Yellow Pages search on an iPhone 4 next year.

Both these applications run on FatWire's Content Server platform that we cover in our Web Content Management research. Although FatWire claims you can deploy these products independently, I am skeptical of the value proposition of running them independently even if it were possible. Both these products tie into Content Server via FatWire's "WEM" -- not the marketing acronym that is getting popular these days -- but an integration framework the company released sometime back. This framework essentially allows you to create applications on top of Content Server and provides features like single sign-on, unified interface, and a single administration window. Just like Drupal, FatWire wants to target those social use cases that are driven largely by content.

However, don't assume that adding a new product such as Community Server onto your Content Server installation will in itself convert your existing application to a community platform. Technical and functional considerations might require you redesign your application. In our WCM evaluation research we lay out some important architectural options and considerations for managing user-generated content (hint: neither FatWire nor Drupal's approach is ideal).

FatWire's Gadget Server is based on Apache's Shindig project. It allows you to create gadgets based on Google's Open Social standard. Your site visitors then can pick and choose the gadgets they want and personalize their interface. As of now, there are only a few gadgets available out-of-the-box, and the percentage of visitors who will actively modify page functionality or layout tends to be very low.

Perhaps more usefully, the new module now provides an additional delivery channel to FatWire content because you can embed an Open Social gadget on any web page, including those not driven by FatWire, and therefore more easily distribute content.

Nevertheless, you may be disappointed to learn that these gadgets are only for site visitor related functionality and not for editorial functionality, at a time when many competitors are employing gadgets to offer different content contributors the exact functionality they need, in lieu of struggling with one complex interface that everyone uses.

In any case, just like with Community Server, consider architectural implications carefully before deciding whether you want a completely gadget-based front end or a hybrid front end where only some functionality gets driven by gadgets.

Frankly speaking, the new features offered by these products are not very complex to implement. You could always create a new asset type, such as "comment," and associate it with another asset type such as "news" to achieve the desired functionality. In fact, FatWire has been offering a separate Blog module, free of cost, for some time. What's more important in my view is the the new administrative and configuration capabilities to manage these modules from a familiar interface. You can also take advantage of some of Content Server's scalability and integration services with these new products.

Overall, both the new products provide a useful set of features. With Community Server, FatWire is probably playing catch-up, since this functionality has been offered by many other products for some time. With Gadget Server, FatWire becomes one of the very few vendors to offer in-built gadget services that allow you to run third-party Open Social Gadgets on your infrastructure.

We're working on a deeper critique of these two new modules for our regular Web CMS updates to our subscribers.

As such, I thought I'd take the time to explain.

1) The "core" application is the interface (usually web-based, but sometimes a desktop client) that employees within an organization use to upload and manage assets. It often has a wide breadth of functionality, some of which is visible (or not) to those end-users based on their rights.

2) The external or "self-service" application is usually a pared-down version of the core application. It is only accessible via the web and tends to be leveraged by users external to the organization. The functions tend to be limited to download, upload, and other simple transformation functions that allow agencies, partners, or customers to easily and securely access digital assets in their desired format. 

3) The administrative application is for the system administrator to configure, manage, and specify how people will access #1 and #2, review analytics of how the system is being used, and so on.

Where the confusion often starts is when, as is often the case with DAM products, #2 looks completely different from #1. This is where it's important to note that most DAM products are a platform: that is to say, highly malleable and open to customization. That includes the interfaces. So when a vendor is showing the core application and then switches over to the external or as they sometimes call it (to further confusion) "portal" application, chaos ensues.

"Wait, what am I looking at now?" says the brand manager. I often then find myself drawing boxes and arrows illustrating what's behind and in front of the firewall, and having to say, "you can make the interface look however you want it to." Internal brand managers sometimes feel their external suppliers should have the same user experience they do, while others could care less -- as long as the task is accomplished.

If you're looking at DAM systems, it's important to examine and test the core/internal, external, and administrative applications. If you don't want to perform a lot of customization, be sure to get clear information on what the default configurations are, and test those default UIs with your use-case scenarios. Some vendors neglect their admin interfaces as if admins don't care about usability. Sometimes external applications are overly complicated, or over-simplified, depending on how much functionality you may want to offer to external agencies and partners. 

And, since that external application often comes at an additional cost, be sure to determine if you really need it. I've seen some brand managers recoil in horror, saying some "fancy" external application isn't necessary.  For them, putting the completed assets on an FTP server for external partners to access would be just fine. 

We review the differences among these applications, and how they affect overall DAM pricing, in our DAM research stream. 

• Autonomy/Interwoven TeamSite: Do the actual improvements in V7 match the hype?
• EMC|Documentum Web Publisher: Into the long good night...
• CoreMedia: Various minor improvements
• Escenic: Still just for media companies?
• WordPress: When does it work (and not work) as a CMS?

If you are a subscriber, you can read or download all the updated evaluations here.

BT Mosaic boasts extensive rich media services, in that their (SaaS-based) offering stretches beyond Digital Asset Management to production facilities, and most importantly digital distribution.  BT Mosaic's customers are able to make use of BT's (British Telecom's) network expertise to link and push content throughout global broadcast networks.

BT Mosaic was an interesting spin off from BT, one that had done fairly well commercially while building up it's network reach and services. Most likely Tata will continue to support BT Mosaic's focus on media companies, but I would expect Tata to absorb elements of the Mosaic services  and start to offer this into broader enterprise IT offerings.

There will always be a market for standalone DAM software, meeting the needs of marketing departments for example. Rich digital media is making up an increasing percentage of enterprise content, and it's only going to grow.  Not only is it easier to create digital media these days, but the demand and expectation is growing exponentially.  Digital media is becoming pervasive and needs to be managed alongside and in lock step with all our enterprise content, not as an exotic exception.

The next couple of years for DAM will be fascinating to watch, as one way or another Digital Media is going to continue to grow in importance far beyond its traditional uses and constituents, and become a key element of any Enterprise Information strategy.

Here's an example that's been tried around the world with varying success.  Say you're running the web presence of some medical organization. As such, you have information on how to deal with various diseases, both on a general level (hygiene and disease prevention) and very specific (what to do when a flu breaks out).

Suddenly there is an outbreak of a new disease; let's say the elephant flu. You could prepare a news bulletin, which would automatically appear on information portals for medical professionals, consumers, etc. -- all the sites targeted to specific audiences for which this news might be of interest.

Better still, since you've already built up a large repository of information, it would be easy to launch an elephant flu theme site: just define the kind of content you'd want in there, and hey presto, with one click you've got an entire site with all the information (http://www.allaboutelephantflu.org). Content specifically on the elephant flu, but also the more generic topics on how to deal with a disease or whom to contact.

You can imagine why this is a compelling concept. Which is probably why I've seen attempts in many different areas, ranging from media companies, governments, product marketing companies, and insurance companies.

But, I said, elusive dream. Many have tried (I count myself among them), and many have failed (unfortunately, I can't really discount myself entirely from that group, either). That's because there are three major problems when you've actually implemented the infrastructure to do it. Since this is only a blog post, I'll pick the most obvious one for now.

The content needs metadata for this to work. Many will tell you that "people won't tag." No, seriously, they won't tag content with the right labels, add the right metadata, or correctly categorize, "even if threatened with being fired." And even if they do tag, it will be haphazard and inconsistent.

This is a very real problem. But at the same time it's complete nonsense. Because if this were the case, why would people meticulously tag and file their holiday snapshots on Flickr and Facebook? Somehow, in their spare time, they do identify the people in a picture, add keywords to a shot, give it a meaningful title, and actually describe it. Without having to be threatened with being fired, or even having to be beaten with a stick.

Partly this is because they get the feedback that makes it worth their while to do so. If you identify your friends in a picture on Facebook, they (and then their friends) will immediately find it and start commenting, which creates a positive feedback loop to tag some more. More importantly though, it's really easy.

If you get back to work the next day, and have to laboriously click ten times, scroll, add, categorize, while thinking what the right category within the taxonomy would be, it all feels like an insubordinate amount of trouble to go through. In most WCM systems and implementations (and dare I say it -- most ECM implementations are much, much worse) it's just too much trouble.

Fortunately, I'm beginning to see some change. There are now quite a few ways in which CMSs can make it easier on your editors to identify the content they're producing:

• Using a "free-for-all" folksonomy, where you can just quickly type in a few keywords. The problem of course, is that the tags will often be wildly inconsistent and ambiguous. Check a tag cloud near you for tags like "New York," "NY," "newyork," and of course, the typo that got away, "new yok." This can be made easier by type-ahead auto-completion of tags. Some systems will start listing suggestions as you type, and helpfully, with some, what you type doesn't have to be the beginning of the tag ("york" will also suggest "New York.") The auto-complete effectively normalizes the tags (i.e., at least all of them will be "New York.") It may still be ambiguous and inconsistent, but at least for many purposes, it'll be workable.
• Using suggestions. Usually with the help of an embedded search engine such as Lucene, the system comes up with tags and related links for your content (based on similar content it finds.) At first, this will need quite a bit of training, but the great thing is that the more content is accurately identified, the better the system gets. The suggestions can be used to completely automate the process, but since you'll still have the original author at hand in the editing screen, you can take advantage of this and ask them to validate the suggestions as they are saving the content. That's a lot easier than having to think them up themselves.

It's still more common to see any folksonomy functionality smoothly integrated into Social Software, and auto-categorization or auto-classification is an area where Search & Information Access systems are usually way ahead. But a few web CMSs are making headway into this territory, as well. For GOSS, which has mostly customers in the UK government, its ability to suggest related content, and categorize it in the IPSV (the Integrated Public Sector Vocabulary) is a unique selling point, and the company has been honing this for the past few years. Hippo (who, incidentally, recently won a large Dutch government account, so there may be a pattern there) is working on releasing similar functionality this fall.

There are others with such capabilities; but at the same time, many are lagging. A system that hides keywords and categories on the fourth tab, three items down under "metadata," and then makes users jump hoops to enter the information isn't likely to help. And some products are so thin on metadata, no amount of customization is ever going to make it work for your users. Carefully check before you buy.

But the good news is that if you share this dream of at least partly automating a metadata- driven architecture, the metadata part of that dream can be realized. Of course, that means there are at least two other major hurdles to take -- but that's enough for now.  I'll return to this topic again...

At some point, techonology should remove the need for taxonomy projects, even if it hasn't -- yet.

Help is on the way, though -- assuming you have, say, $150K (plus or minus a Toyota) to spend. Today, San Francisco-based Recommind, Inc. (one of the vendors we cover in our Search & Information Access Report) is introducing MindServer Categorization, a software system that does just what its name implies: It analyzes content, discovers logical categories within the content, and auto-tags each content item according to category relatedness.

Although it's being introduced today as a standalone product, MindServer Categorization -- technically speaking -- is not new. The product has been sold in Germany for years, where major media companies have used it to auto-categorize news feeds. Today's release represents the first time MindServer Categorization has been localized into English and productized for a general market (i.e., not just media firms).

Recommind is not the only company with auto-categorization technology, of course. (Autonomy, often seen on shortlists next to Recommind, is a familiar source of such technology.) But unlike others, Recommind uses PLSA (Probabilistic Latent Semantic Analysis) as a basis for category discovery, which means, among other things, that Recommind's software requires no training: It doesn't need to be exposed to a "training set" (or sets), have access to a preexisting taxonomy, nor know about keywords. In fact, MindServer Categorization is not only self-training but language-agnostic. In theory, the underlying algorithms can discriminate categories in any corpus, regardless of what language the corpus is in.

Exactly how efficient the system is, you'll have to determine yourself by testing it against a corpus or two of your own. The rate of false positives and false negatives will vary according to the characteristics of the corpus and the tuning parameters you specify. (You can relax or tighten the system's "strictness" through config settings and a C++ API.) Don't expect this -- or any other -- auto-categorization system to be perfect, or anything close to it.

Notably, although Recommind does a lot of business with law firms and legal departments, who use Recommind's search software to categorize e-mail (as well as do more sophisticated kinds of things, such as divining who the domain experts are, in an organization, based on correspondence), some customers are content just to have Recommind's software separate content into two categories: garbage, and content that clearly should be saved.

If it's true, as some research indicates, that 1 GB of data can cost up to $20,000 to collect, process, review, and retain, then the $150K entry fee for MindServer Categorization would seem quite reasonable. (Bear in mind, maintenance is another ~$30K per year on top of that.) But one wonders how long it will be before entity-extraction software, auto-taggers, RDF extractors, and the like become commoditized through Open Source. Also, Recommind and Autonomy face a different sort of competition from the likes of Thomson Reuters, whose Calais project provides what amounts to semantic analysis as a service. (While it's true you might not want to send your entire corporate e-mail archive over the wire to the Calais service, nevertheless you might very well want to stream select RSS or Atom feeds through it -- and many people already do, apparently.) 

At the moment, the company with the greatest exposure (and therefore the most to lose) in this field is Autonomy, whose IDOL technology has cemented the company's reputation for intelligent information retrieval. It will be interesting to see whether upstart Recommind can put a dent in Autonomy's semantic suit of armor -- or whether the two companies are, in fact, destined to remain in separate categories forever.

Now SDL has acquired Component Content Management (CCM) vendor XyEnterprise. Time will tell how this acquisition plays out, but it does illustrate how the CCM marketplace could be consolidating into larger players

At first glance it appears to be an odd acquisition, since, as our CCM research subscribers know, XyEnterprise Contenta and SDL Trisoft compete head to head in the marketplace. On closer look however, there is some logic in the acquisition. SDL Trisoft provides pretty strong DITA capabilities and reuse in a multilingual environment. Though not a large vendor, XyEnterprise brings a range of products:

• Contenta, a DITA and S1000D CCM
• XML Professional Publisher (XPP), an XML-rendering engine
• LiveContent, a dynamic delivery engine

SDL says that XPP and LiveContent will be integrated almost immediately. SDL has also indicated that Contenta's S1000D version will continue to exist as a separate product and the strengths of the DITA version (e.g., workflow, authoring bridges) will get integrated into SDL Trisoft. That will not be an easy task, and we anticipate it will take years to complete.

So there are some additions with XPP and LiveContent, and some gap filling (e.g., S1000D), but SDL has a long way to go to make this a truly integrated product. And while XPP is a good rendering engine with a long track record relative to its nearest competitors, it has also grown a little long in the tooth now, and has not kept up to date with all of the newer standards (like XSL-FO).

As in all acquisitions there will inevitably be fall-out and change, and just how well a small New England-based firm like XYEnterprise will operate as a part of a European roll-up remains an open question. How nicely they will play with the Trisoft team is also something to watch closely. So.... (you could see this line coming), tread with caution if you are considering buying either Trisoft or Contenta, as it will be quite some time before things truly settle down.

Let's first consider the positive implications: eXo will gain an audience outside of Europe.  And the JBoss Portal will have some nice new applications (content management, collaboration etc) to add to what was a fairly sparse framework.

As with any merger, the details could become inconvenient for existing licensees.

However, I have bigger doubts that Red Hat will really make the most of the opportunity, and I wonder if the likely outcome of the merger is really what buyers and implementers are even looking for in 2009. It is a merger that makes sense for eXo but maybe not so much for those in need of an enterprise portal.

If we exclude MySQL from the discussion, JBoss (acquired by Red Hat in 2006) and Red Hat, are by far the two biggest vendor names in the open source world. They are the names that come up most often in enterprise procurement discussions as alternatives to the likes of IBM and Oracle. Be it the Application Server, BPM, Directory Services, or indeed their own longstanding version of the Linux operating system -- RedHat and JBoss are synonymous with open source for the enterprise.

But the JBoss Portal has never really figured in that equation. What should have been a direct competitor to IBM WebSphere and the Oracle WebSuite and WebLogic portals, was seldom seen in action. And adding some functionality to the product is unlikely to really change that situation.

I am not favoring commercial systems such as those from Oracle or IBM over commercial open source systems such as Red Hat.  In fact, buyers deserve a truly level playing field from which to chose from, but currently that is not the case.

In fairness to the open source community, it's not for lack of trying. Just in the past year the Liferay open source project hooked up with an enterprise-level vendor (Sun Microsystems), only to see what looked like a very promising and competitive product emerge (GlassFish), and be then thrown into doubt after Sun's agreement to be acquired by Oracle.  Who knows how that one may resolve itself.

Red Hat now has an opportunity to fill that gap, and to give enterprise buyers a more competitive open source option. But the only way to do that is to build a truly enterprise-level portal framework, not by adding new widgets. The problem before wasn't a lack of functional bells and whistles. it was a lack of direction and depth.  Merging with eXo doesn't in itself fix that.

Of course, it's not my job to advise vendors, it is to advise buyers.  My current advice to buyers has to be to tread with extreme caution in the world of enterprise portals. As subscribers to our Enterprise Portal research well know, with Oracle now effectively owning 5 of the 12 major portal offerings and somehow attempting to make sense of them, IBM on the verge of a major upgrade, Vignette acquired by Open Text, SAP losing almost complete interest in the space, and open source alternatives either falling short or themselves going through a period of upheaval, it is a market that is full of treacherous waters to navigate.

Within that service we cover XML authoring tools: the software for creating and editing highly complex documentation, be it DITA structured technical documentation, complex translation work, or product information designed for multiple re-use. But our research goes beyond the editing and authoring options at the front end, and evaluates all the leading CCM (Component Content Management) tools that have been designed to manage the publishing and workflow of these complex XML document components throughout their lifecycle.

On other occasions we separate technologies into different categories, where others may have bundled them together. An obvious case here is our Web Content Management research and our Enterprise Content Management Suites research. Just in the past fortnight I have been asked by more than one person why we have two subscription services for the same technology. Well the simple answer is that it is not the same technology: the technology to manage outward (web) facing content and sites, versus the technology to manage inward-facing (documents and files) content and filing systems is quite different. But nevertheless it is a very fair question to ask, because to someone outside the industry (and even some insiders) that distinction is not always obvious.

Confusion can come about due to vendor branding strategies or a plethora of nebulous acronyms used within the industry. For example Interwoven (recently acquired by Autonomy) did a good job of branding their WorkSite (document & files) offering quite separately from their TeamSite (web content) offering. Other vendors such as EMC Documentum or Open Text use a single brand moniker (such as "digital media") to cover all their content-focused software offerings regardless of each component's specific purpose, while in other instances product names can even be synoymous with the firm's brand, as with ADAM and Sitecore.

Then there is the issue of acronyms. We use the term ECM as it is the most commonly used term for document-based technologies, however in different regions and industry segments ECM is referred to as EDMS, EDM, EDRM, Document Control, IM, IDM even KM. As an advisory firm we have to call our research and services something, and we are faced with picking and choosing amongst a myriad of terms, typically choosing the most well-known term currently in use.

Our job at CMS Watch is to make sense of the complexity of the technology offerings out there for you, the buyer - and that can be a challenge at the best of times. We believe it's safe to say that we have more research available to our subscribers on content technologies than all of our competitors combined. But volume, depth and breadth is not all that separates us from our competitors, we are in addition avowedly a firm that follows the market rather than "makes" it. Thus, we don't try and come up with new acronyms, terminology or market segments, we don't cheerlead for the industry or get involved in market sizing, we stick to the basics of evaluating current release products side by side and evaluating the importance of current trends.

So here is my challenge to you. We evaluate over 200 products and sub-divide those into 10 subscription services, which in turn are sub-divided into about 5-8 sub-categories each. We try to use common terminology so that you the buyer can relate to and locate the research that meets your needs, but that does not always work as well as it could. So if you find the product evaluation(s) you need, but locate them in a place - or grouped in a way you find 'surprising' or 'interesting', let us know. Tell us how you and your colleagues perceive these technologies, what you call them, how you would categorize them differently, how you explain them to your internal clients or project teams. Truly we would love to hear from you as this industry remains a dynamic and very moveable feast at times....

You can read about it here, with some additional analysis here. Note that the main enterprise AARP.org site -- which is driven by Day Software's Communiqué Web CMS -- was not compromised.

An ex-AARP developer tells me that this community application was custom code developed by a (now defunct) consulting firm. In retrospect, that choice appears a mistake. There are numerous established "white label" suppliers of these services, as well as social software "suites" that you can extend for external scenarios. As Enterprise Social Software Report readers know, none of these solutions are ideal, but all of them have had to emplace and update some fairly tough protection schemes.

Still, don't harp on AARP. They fixed the problem quickly, and their community site continues to function and attract new members. This could happen to any of us; AARP's site was a big target because of the Google link-juice it confers. Just remember that when you want to extend social computing services beyond the firewall, you have to prepare to encounter the three horsemen of any website apocalypse: performance, cost, and ...security.

Not surprisingly, then, comes this blog entry, "Drupal considered dangerous for startups?" As both the author and numerous commenters point out, the problem isn't really Drupal -- it's the idea that generic technology alone can create a real business. At the same time, developers at those would-be "next youtubes" were probably a bit surprised at Drupal's complexity, lack of real configuration management, and its project leaders' famed reluctance to make usability improvements. You can read more about Drupal in the most recent Web CMS Report.