A few weeks ago, I was having drinks with a friend of mine who'd recently separated from her husband. She hadn't told many people the news as of a week before we met up, but then she changed her relationship status on Facebook. A broken heart icon declaring that she was no longer married appeared on her profile, and immediately she was bombarded with phone calls and emails from concerned friends. She was mortified, as she didn't realize that changing this piece of information in her profile would go out via her news feed.

I saw this as an isolated incident, until it happened again today to another friend of mine who's apparently separating from his wife. In fact, unlike the previous occasion, I found out from Facebook. It was a lousy way to find out that a couple may be on the road to divorce -- as it would have been a lousy way to find out any other piece of "serious" or "sensitive" information. But there it was in my Facebook friends news feed. I learned from a mutual friend that the dissemination of the news was unintentional.

And what about enterprises that use Facebook as a corporate intranet? Could it be that employees are also unaware of such automatic information distribution? As readers of The Enterprise Social Software Report know, it's difficult to separate professional from personal information on Facebook, which has also had a history of privacy and security breaches. Though you can now categorize friends and decide who gets to see what information, I admit, I find it crazy that in this day and age, people still think that things published on a social networking site will go unnoticed, or not be disseminated. Unless you specify otherwise, you should assume it will not only appear on your page but distributed to every close, personal Facebook friend you have. All 347.

If you mix work and play on Facebook, don't be naive. If you're going to sip wine while naked in a hot tub in California, don't write about it on your wall unless you're comfortable with everyone knowing, including your boss, your ex, your clients, and anyone else you may have thought it was a good idea to "friend."

In this blog, I once linked to a colleague's Facebook page, and then was contacted by his company's PR firm, insisting I switch the link to the person's profile on LinkedIn. I accommodated, but was also perplexed. What I'd said about the person was nothing but complimentary. It was clearly an issue of not wishing to mix work and personal information. But really, it's too late. We're already there, thanks to Facebook, thanks to the legions of social networking sites on the web. Social software doesn't let you control the dissemination of every piece of information about you out there -- yet. If you don't want people to know, just don't publish it. Anywhere.

While Web CMS vendor Sitecore has been busy promoting the new user interface in its recently released Version 6, the company has attracted quite a bit of criticism from existing customers for the new version's lack of an easy upgrade path.

In a recent blog posting by Sitecore's VP of Technical Marketing, Lars Nielsen, he discusses their upgrade strategy and explains the company's choice between delaying the release of Sitecore 6 or let the database conversion tool follow afterwards. Similar to many other vendors in this situation, e.g., Microsoft, Sitecore decided to get the new product out the door and worry about upgrades later.

The definition of immediately afterwards may extend beyond the 2 months that have transpired since V6 came out, but I see that Sitecore themselves have still not upgraded their very own website. According to Sitecore, an alpha release of the upgrade tool is expected this week, but there is no news on when customers can expect a final release.

Regardless of vendor, upgrades are never straightforward, and you typically want to wait until the vendor has gone through the pain itself before teaching them the ropes. In this case, though, it is telling that Sitecore -- a vendor with a support model that we have previously questioned -- has focused more on pleasing new prospective customers and less critical analysts alike with exciting new demos rather than supporting its faithful customers. If the past is any guide, do remember to budget and plan any upgrade carefully.

A new season brings an updated vendor map:

We added a Yellow Line -- for XML & Component Content Management vendors, and reflected some other station changes.

And now, if you like what you see, you and your wall can wear it. Our new store at Cafe Press offers t-shirt and posters of various sizes, along with other CMS Watch tchotchkes.

Regarding the latter, perhaps you already own your fill of mugs and mousepads, but can you ever have enough beer steins? Bring it to the next event where we're speaking and we'll fill it up with the closest available brew. ;-)

In a thoughtful post at JavaLobby, developer Ali Loghmani poses a simple but important question: Why is Web UI development so slow?

Here, Loghmani is not just talking about the creation and placement of AJAX widgets on web pages. He is talking about full-cycle development and testing of web and portlet interfaces that integrate with popular MVC webapp frameworks such as Grails, Django, Tapestry, or any of a slew of others.

The reason this is an important question, of course, is that people write custom web and intranet apps against their DAM, WCM, ECM, and Portal systems all the time, whether for public-facing B2C apps or just to create a CMS front-end that content contributors will actually use. And it is invariably a resource-intensive process. Gobs of time, money, and engineering talent go into the creation of web interfaces (and the code that binds those interfaces to back-end business logic).

Loghmani laments the protracted program-test-debug time in development frameworks that require (as many do) redeployment of files to an appserver before changes can be previewed. This is certainly a problem. It's one thing to do an eye-pleasing mockup of an AJAX webform in a browser; quite another to wire it into JSF and do full-cycle debugging in WebSphere, say, or JBoss (or whatever).

There's also the perennial cross-browser compatibility bugaboo. Web UIs tend (still) to perform differently in different browsers, necessitating ugly "browser-check" code with parallel logic branches to handle the various browser types and their legacy quirks. Writing and testing this kind of code takes time.

Of course, to some degree UI development is an inherently hard problem. The mapping of widget states to program states is not always straightforward. To the contrary, the possible permutations are more often than not incalculable, and the potential side-effects legion. You can't expect this kind of programming to go quickly.

In the end, Loghmani argues that the sheer complexity of popular MVC frameworks is a major (perhaps the major) contributor to long UI development times. As much as I value simplicity, I have to disagree here. In my experience, complexity is not a bad thing per se if you can properly hide it. Twenty years ago, three-person crews were the norm on airliners. Today it's almost entirely two-person crews. Ironically, the airplanes have gotten much more complex, but the human interface has been refined to the point where you no longer need a "flight engineer." This is an example of how complexity can be hidden, to good effect.

I think one could argue that the main reason Web UI development is slow is because insufficient tooling exists to make it quick and easy. Things like Tapestry and JSF (and appservers) are complex, with many moving parts. Developers are constantly having to open the hood and make hand adjustments to rather intricate machinery, using only basic hand-tools.

In the post-2.0 world, that won't do. Time is too precious. We're going to need better tools -- or perhaps an entirely new development paradigm. Old-school MVC development, à la Struts and all the rest, is just not cost-effective any more. If indeed it ever was.

Via numerous acquisitions, Oracle has built up a formidable collection of products that they sell for Portals, Content Management, Web 2.0, and other content technologies. As a result, customers find considerable overlap in functionality and often there are multiple options for doing same things. Consider blog services:

Oracle WebCenter page lists "...services such as wikis, blogs, discussions..." as one of the benefits

BEA AquaLogic Pages (now part of Oracle) touts "Drag-and-drop simplicity for creating wikis, blogs and basic Web applications"

Stellent had a blog module even before it got acquired by Oracle

So its perhaps a bit surprising that when it came to their own blogs, Oracle chose to migrate to Six Apart's Movable Type.

We had cautioned about lack of a decent blog functionality in Oracle stack in our recently released Enterprise Social Software Report 2008. Well to be fair to Oracle, they are not the only ones -- many other product vendors use 3rd-party blog and wiki products for specific functionality. Blog migrations are never easy, but Oracle seems to have pulled it off successfully.

So if you are a buyer of similar technologies, remember that:

1. If a product vendor is selling you a suite that claims to do everything, be very cautious and ask for real life examples and demos
2. A product suite might not be the best option; keep your options open and consider point solutions for specific requirements

It's quite possible that Oracle uses one of its own blog packages behind its firewall. But when ECM vendors put their trust in best-of-breed tools for high-profile, publicly-facing sites, perhaps there's a lesson there.

Nobody likes content migrations. But they're inevitable. Like trips to the dentist.

You can perhaps reduce your pain by reading this nifty little white paper, "Content migration: options and strategies," by James Robertson of StepTwo Designs. It's a wonderfully concise survey of your likely toothaches and options for dealing with them.

James is not optimistic about outsourcing the migration project, but as others have pointed out, staffing depends on how you organize the effort, and there is potentially a role for temporary help.

You'll also want to pay close attention to the question of metadata. Oftentimes enterprises implement a new system in order to employ tag intelligence for publishing and navigation. Someone knowledgeable needs to add all those tags -- at least as part of the final migration QA process. Like transforming the content itself, you'll find automated classification tools a mixed bag at best.

Everyone can agree though, that the more attention you pay to regularly cleaning up your content beforehand, the more likely this particular dentist visit will prove less painful.

Flying below the radar for most North American analysts, French-based commercial open source portal vendor eXo has been very busy recently. Earlier this month marked the release of new versions of their key products, including eXo Portal, which we cover in the Enterprise Portals Report 2008.

Then last week eXo announced a new branch in Tunisia covering the emerging (but also largely underresearched) marketplace in Northern Africa.

When we started covering eXo back in 2006 the firm had a 27 employees and had just opened a US office. Today they have 70 developers have joined the growing ranks of open source projects trying to offer an alternative to Microsoft SharePoint.

eXo has also been an early adopter of Adobe Flex, which is actively used in several of the eXo products, including the beta version of the new "Liveroom" video conferencing component.

I don't pick favorites and am not saying that eXo is the "best" or "leading" enterprise portal, but in these times where the portal market is increasingly dominated by large vendors (IBM, Microsoft, Oracle) it is important to remember that the open source portal market may indeed offer you viable alternatives. Beyond eXo we also cover Apache Jetspeed, JBoss, Liferay, and Plone.

In talking to wiki users, we find a wide range of sophistication. Some are quite content with the simplistic "edit this page" features you can now find in most Web CMS and Social Software suites, while other customers seek more advanced features (such as topical refactoring and advanced aggregation and print services) that constitute for them a "real" wiki.

And then there are those who cut their teeth editing Wikipedia pages or learned about wikis by using the earliest tools. They come with a particular set of expectations -- especially around using good old fashioned "Wikitext" mark-up -- that today are met largely through the MediaWiki platform, the same tool that powers Wikipedia.

As Enterprise Social Software Report readers know, MediaWiki tends to find favor among wiki purists, but is often perceived as too arcane by novice users. Here's a nice summary of some relevant issues by consultant Dan Katz. (Thanks to Janus for the link.)

I'm more sanguine about open source wiki options and less enthusiastic about Socialtext than Katz, but he makes some very good points regardless of the tool you select. The key for you the customer is, as always, to test with "real" users before you deploy...

I recently had a long and wide-ranging interview with IT Business Edge on the topic of Social Software technologies.

The intrepid reporter, Ann All, transcribed nearly the whole discussion verbatim -- a rarity these days! -- and something any analyst (well, at least this analyst) welcomes only with some trepidation, because you're never (I'm not) as articulate in a stream-of-consciousness chat than a well-considered article. For example, I was more harsh on SharePoint in the end than I intended to be. Anyway, the key points come through and I'm not complaining.

Ann also offers some interesting commentary here.

Look for more from us over the coming months on the topic of Social Software, in these pages and others...

Through the SharePoint product team's MSDN blog, Microsoft announced that it had released a significant infrastructure update for SharePoint (and related technologies like Project Server that leverages SharePoint components). The update seems to primarily address three areas:

Search functionality and search-related performance (like index performance).

Content Deployment bug fixes (which hopefully will correct a series of irritating bugs related to deploying content from one SharePoint environment to another in web content management scenarios). These are include the hotfix packs Microsoft released for content deployment back in May of this year.

General interface and performance improvements. In reading the three or four pages in Microsoft's site that aimed to describe what was actually included, it was difficult to pinpoint what these "improvements" actual mean to SharePoint administrators. However, Microsoft describes them as "...fixes and product performance updates driven by customer feedback which have resulted in significant platform performance improvements..." Again, I was unable to nail what precisely has changed or how significant the improvements were.

What's interesting, at least with regard to search, is that it seems the "ancillary" search products like Search Server 2008 (and it's "free" sibling Search Server Express 2008) are driving updates to SharePoint's search technology. As mentioned in the SharePoint Report 2008, Microsoft has invested heavily in improving SharePoint search. In fact, historically, it seemed as if SharePoint Search was the the parent of these independent search tools, but it now appears as if "the student [has become] the master" as Darth Vader said to Obi Wan.

In particular, SharePoint is getting Search Server's federated search capabilities and "a unified search dashboard." From what I saw at the last SharePoint conference, both of these search products borrowed very heavily from the SharePoint interface construct, but improved the visibility of certain configuration settings. In particular, I liked the ease with which you could configure the federated search.

However, these changes call into question how this will all play out within the Shared Services provider and whether administrators who are struggling to figure out where to go to change search settings -- at the site, site collection, Central Administration (in the Application or Operation tab) or in Shared Services. While most key search settings reside in Shared Services, SharePoint has search-relate configuration in spread over virtually every administrative interface. My hope is that this "unified search dashboard" brings some order to search within SharePoint.

In the end, these changes (along with the FAST search integration) also add more evidence to the theory that Microsoft is going to decouple search from SharePoint entirely (and potentially the Office team) -- making SharePoint a client technology. As I blogged about in a post on the completion of the FAST acquisition, Microsoft seems to be leaning very heavily towards and independent search product team. And just to add fuel to the conspiratorial fire, this type of organizational structure might make sense if, say, Microsoft were to acquire a large Internet-centric search company (although it begs the question what they'd do with all of this overlapping technology).

I recently wrote an article for DOCUMENT Magazine summarizing the state of the digital asset management industry. Readers of our DAM Report 2008 will recognize these as excerpts from the Report's executive summary, but if you're looking for something to put in front of your boss or CEO to give a quick overview of the state of DAM, here's the place to look. It's in a downloadable, print-friendly, magazine-spread format, too.

In "Why Most Online Communities Fail," the Wall Street Journal cites some very useful Deloitte research on businesses who launch their own online communities -- what we and others call "White-label Social Networks."

The Deloitte study found a low success rate, owing the usual culprits: over-emphasis on technology, lack of leadership and experience, and poor or inadequate metrics.

In our own research for the Enterprise Social Software Report, we found some other, likely related trends:

• That technology companies with technically-oriented customers generally fared better at generating online communities, and pre-dominate among vendor case studies
• That non-technology companies seem to have to prime the pump with a lot of their own content
• That the purpose of the community matters a lot (e.g., peer tech support vs. collaboration vs. commentary) and -- here's the kicker -- most vendor offerings specialize in one at the expense of others (consult the report for details)
• That vendors are struggling with analytics in step with their customers

We also found that there are several different ways to build, foster, and take advantage of communities, but (as Deloitte observes), each approach takes active care and feeding. Budget your schedule and resources accordingly.

Today Quark Inc. announced that it is acquiring the assets of In.vision Research Corporation. In.vision is best known for its XML add-in for Microsoft Word ("Xpress Author for Word"). Quark is best known for QuarkXPress, a design and desktop publishing tool. The In.vision team will continue to be located in Florida, but the former In.Vision module will become "Quark XML Author for Microsoft Word."

In recent years Quark has lost ground to Adobe InDesign. There are many reasons for that, but from our perspective (XML & Component Content Management), Quark simply did not handle XML very well, and InDesign was more capable in that area. Quark began to signal an interest in XML when they announced the hiring of their new President and CEO, Ray Schiavone, formerly President and CEO of Arbortext, one of the frontrunners in XML-based authoring and publishing products. Schiavone brought a considerable amount of knowledge about XML to Quark and quietly hired a number of former employees of Arbortext that had left after its acquisition by PTC.

Quark more strongly positioned themselves in the XML multichannel publishing world with the launch of their Quark Dynamic Publishing Solution (DPS) in March of this year. DPS uses Quark Transformation Engine, essentially an XML rules-based engine, to convert content coming in from many sources to XML then renders it to multiple channels.

The acquisition of In.vision now takes the XML publishing process back to the content contributor -- Word of course being a ubiquitous authoring tool. While some would argue that QuarkXPress is an authoring tool, it is really oriented towards designers - few content contributors would ever want to work in Quark directly.

What does Quark gets out of the acquisition?

• Integrated XML-based content contributor software, making dynamic multichannel publishing accessible to broader areas of the enterprise
• Expertise and functionality in SPL (Pharmaceutical XML standard) and DITA (fastest growing XML standard)

What does In.vision get out of the acquisition?

• Global sales force
• Access to broader opportunities for the use of its products

But what does the customer get out of this? Well, In.vision and Quark have been working together as partners for a number of months, with some hand-offs to show for it. But the integration is not complete. For example, you can't just say "publish to DPS" from Xpress Author. DPS is treated much like a call to the DITA Open Toolkit. Round-tripping from XML to design to XML is possible, but not productized yet.

In the long run, customers may see some benefits:

• Access to XML-based publishing software that allows not just simple layout, but full camera-ready layout
• More DITA-based publishing for the enterprise

This acquisition moves In.vision from a small XML solutions company into a much larger realm, and this allows Quark to move closer to XML-based enterprise dynamic publishing. But full integration will take time. We'll keep watching...

While working with a client in the U.S. state of Rhode Island, I discovered an interesting approach to providing directions: don't give directions by using landmarks that still exist, but rely on someone's historical knowledge of what landmarks used to exist. Directions in Rhode Island, as a result, sound something like this: "Oh you need to find the airport? Just travel down Kilvert and turn left where the old AlMacs used to be." This line of thinking is so pervasive, that's it difficult for a "foreigner" to actually figure out how to get anywhere. However, most locals, who've been around while, tend to instantly understand -- and can more fully comprehend the directions, as well as the geo-context.

As an analyst and a technologist that's been working with SharePoint technologies since before the official release of SharePoint 2001, I too am guilty of using these historical references. In fact, I find them almost invaluable in understanding how to solve problems or understand why certain functions in SharePoint operate the way they do.

In many cases, Microsoft builds on previous approaches to construct improved functions -- sometimes to the detriment and sometimes to the benefit of the end user. For example, when Microsoft integrated "the old Content Management Server (MCMS)" functionality into SharePoint, the result wasn't quite like MCMS and not quite like SharePoint (although certainly more SharePoint than MCMS). What Microsoft actually did was to inject basic MCMS concepts into the existing SharePoint architecture (e.g., created a "pages" library in SharePoint to explicitly hold HTML pages) and extend implicit SharePoint concepts with MCMS-like flexibility (introduced field types and controls that existed before, but weren't explicitly extendable).

This approach yields statements like: "How do you write a custom SharePoint field control? It's like writing and old MCMS placeholder."

In our SharePoint Report 2008, we use this instruction-through-historical-context to improve overall understanding of the current product. While we don't spend a lot of time reviewing history, the report provides some valuable historical context for SharePoint's approach. As we point out, this is sometimes to the detriment of SharePoint (trying to fit all MCMS constructs inside the existing SharePoint architecture), but it does occasionally work to its benefit -- for example, with the list construct.

As I continue to travel back and forth to Rhode Island, I always have to smile when I hear statements like "you're sitting in the PMO's old office." However, I believe I've gained an appreciation for the context that accompanies the language

Last week I wrote about Open Text's acquisition of eMotion, and may have added to the confusion over the alphabet soup of DAM, MAM, and MOM. Allow me to clarify how we use the acronyms, and then how they may be used differently by others.

1. DAM = Digital Asset Management
2. MAM = Media Asset Management
3. MOM = Marketing Operations Management

First, as with ECM, we must make the distinction between disciplines and technologies/tools. As my colleague Alan often points out, ECM is really a strategy or an approach that requires many different technologies coming together. I'd argue the same for Marketing Asset Management (sometimes also shortened to MAM) and MOM. Marketing Asset or Operations Management isn't a technology, it's a strategy, set of workflows, and often a suite of tools working together to achieve marketing goals. That might include a DAM system, a web analytics tool, and even a WCM system or a portal capable of personalization. All those technologies might manage marketing assets: brand materials, customer information, or the messages you want to target.

Now, we'll insist that tools alone don't make for a true ECM or Marketing Asset Management solution any more than a set of hammers, wood, and nails makes a house, so we're more specific about the MAM acronym and use it to describe technologies that specialize in certain scenarios. In our parlance, and in the lingo of many of the companies themselves occupied with the management of time-based assets, such as video and audio, MAM specifically describes the management of audio and video assets.

Corbis' (now Open Text's) eMotion is a hosted platform for general Digital Asset Management, largely used by marketers (and thus is called a MAM in the Marketing Asset Management sense, as Open Text is pitching it). Open Text's other DAM platform, Artesia, offers both traditional DAM (management of digital photos and other marketing materials), as well as MAM (Media Asset Management) for time-based assets, one of the few vendors in our report that does both. In our universal DAM and MAM scenarios, we group ones related to marketing collateral and print production into one group, and the ones for video and audio production into a completely different group, given how vastly different the vendors are in their capabilities. Open Text's new combination of eMotion and Artesia means they're covering more of the whole range, in both hosted and licensed offerings.

Press releases are a funny thing, I thought as I saw the announcement from JupiterResearch that the "majority of web analytics customers [are] content with service, forcing providers to compete with price and flexibility," and that "despite some small skirmishes over capabilities like video and audio measurement, the Web analytics feature race is largely over."

It's not as simple as that.

On one hand, as I noted when we released the Web Analytics Report 2008, the top 5 reasons that managers like their vendors has nothing to do with features...it's about service, value and relationships.

On the other hand, I wouldn't trivialize the importance of tracking audio and video -- two areas of content that are becoming increasingly important to all web content managers -- and have been historically difficult to track completely and easily, hence the rise of independent vendors.

Interestingly, the release mentions that "the new frontier for Web analytics is data integration and the ability to stitch together a holistic view of customers' experience across multiple touch points." Web Analytics Report readers know that we highlighted this trend in our first report in May, 2007. Perhaps it's semantics, but this certainly seems to be a feature issue.

In early June, I was on a panel on mobile analytics at the Internet Marketing Conference. Much of the conversation focus was about the tools...how did current online analytics tools compare to the new ones; what could be tracked; what couldn't be tracked; and so forth. As I've described in a few recent posts, mobile analytics is a new area for online analytics vendors, and this is certainly where we'll see a new round in the features race. The mobile web is too big to ignore.

Finally, software vendors must always evolve their tools to keep investor money flowing. Vendors must come up with twice/year releases to show the marketplace and investors that they are market leaders.

So, while I might be tempted to join in declaring the end of features -- if only so we can all focus on simply doing analytics more effectively -- I don't think it will happen.

And if you care deeply about measuring mobile and multimedia usage, well, then: long live the feature wars, because that's the only way you're going to get the functionality you need.

We're tough on SharePoint. That's because we frequently see enterprises wandering into the platform (thinking it's "easy" or "free") without always realizing the complexity of what they're about to get into.

Still, SharePoint has its merits, and it's worth re-iterating them from time to time to help you get the most value from your investment. One area where we think most customers underestimate the platform is with forms creation and processing (especially in the "MOSS" edition). There's some problems there, but also some good stuff, that's easy to use.

You can read more about it in today's release, "Enterprises Can Benefit from SharePoint's Underrated Electronic Forms Services," based on research from our SharePoint Report 2008.

CMS Watch is looking for someone who suffers from a variant of our particular obsessive disorder: a passionate interest in how content technologies really work.

Specifically, we're seeking a WCM technology analyst, who could think of no better job than to debrief Web CMS customers and integrators and share (in print and in person) what they learned about the tools with the rest of the world.

In our Enterprise Portals Report evaluations, we point out that vendors who tightly couple their portal offerings to other pieces of their underlying platforms can't call themselves truly Services Oriented Architecture (SOA) -ready. This has been a problem for the MOI (Microsoft, Oracle, IBM) portal offerings in particular, which have historically seen dependencies at multiple tiers: appserver (all three), database (Oracle Portal -- now deprecated), and even operating system (SharePoint).

As you might expect, MOI portal product managers sent us testy responses. Suggesting a portal product is less than "fully SOA-enabled" evidently touches a raw nerve with vendors. We replied in turn that savvy customers believe SOA is more about the flexibility and opportunities that loose coupling affords, and less about, say, available WSDL files.

Thankfully, now we can just point them to this handy posting by ZDNet blogger Joe McKendrick, "Ten ways to tell it's not SOA." (Hat-tip to Dion Hinchcliffe.) In particular, check out #8, and this commenter's useful extension of the notion of "platform."

Portals can indeed play an important role in your SOA strategy, but only when they don't make you lock in to other proprietary platforms.

We're pleased that CMS Watch now covers ten different technologies, but I suspect that many of you take an interest in only one or two families of tools. If that's you, here's a list of technology-specific RSS feeds that will just send relevant postings to your reader or aggregator.

Digital Asset Management: http://www.cmswatch.com/RSS/cmswatch.channel.xml/DAM

ECM Suites: http://www.cmswatch.com/RSS/cmswatch.channel.xml/ECM

E-mail Archiving & Management: http://www.cmswatch.com/RSS/cmswatch.channel.xml/E-mail

Enterprise Portals: http://www.cmswatch.com/RSS/cmswatch.channel.xml/Portal

Enterprise Search: http://www.cmswatch.com/RSS/cmswatch.channel.xml/Search

SharePoint: http://www.cmswatch.com/RSS/cmswatch.channel.xml/SharePoint

Social Software: http://www.cmswatch.com/RSS/cmswatch.channel.xml/Social

Web Analytics: http://www.cmswatch.com/RSS/cmswatch.channel.xml/Analytics

Web CMS / WCM: http://www.cmswatch.com/RSS/cmswatch.channel.xml/CMS

XML & Component Content Management: http://www.cmswatch.com/RSS/cmswatch.channel.xml/CCM