Originally published: December 12, 2007.  Updated: March 25, 2008

Based on a recent conversation I wanted to brief everyone on the communication strengths and weaknesses of a Hub.  These arise from (a) the intended market for the Hub and (b) our position on the Product Roadmap (aka "what we've managed to build so far"). 

My hope is that after reading this you'll have a good idea when to communicate via a Hub vs. some other technology.  Please feel free to let me know your thoughts.

Strengths 

• External communication. Hub's treat all participants uniformly with no requirements on external parties for installed software or network user accounts. You communicate with your partners, customers, project members, teammates, and everyone else in the same manner using the same tools.  In addition, the Listener, Aggregation, and Broadcast Response Hub features help locate and connect users regardless of their web location. 
• Back-n-forth discussions.  Hub threaded discussions enable an easy-to-follow point/counter-point style of conversation.  Note:  in the future, this will improve further with our new "Conversation Distiller"; a feature that will distill conversation threads into their key elements with references to the original discussion.
• Thought Leadership or Opinion Sharing. A Hub's blog-style entries and tagging make "position paper" or "Op-Ed" discussions easy to create and organize.  Further, full-featured commenting promotes open and interactive debate on opinion pieces.
• Knowledge sharing and accumulation.  All Hub conversations are fully taggable, searchable, and SEO optimized.  This makes all conversations automatically "wisdom of the firm" entries.      
• Multi-Party / Broadcast Announcements.  Hub's are multi-writer, multi-reader communities and, therefore, facilitate broadcast communication.  In addition, Hub's offer extensive support (including alerts, widgets, and RSS feeds) for delivering content outside of the browser directly to user's desktops.  Lastly, using a Hub's social features, speakers can segment their audience and target messages directly at relevant or interested parties.

Poor Fit 

• Highly sensitive content.  Hub's were intended for open, broad communication.  Over time, private or segmented communication use cases were included.  While the Hub supports many of these use cases, it does so imperfectly, often putting too great a behavioral burden on the user (aka it's too easy to make a mistake).
• Collaboration on a single piece of content.  Hub's were not designed for multiple, simultaneous authoring of a single piece of content.  This usage relies heavily on versioning and synchronization that Hub's do not currently possess.  Wikis, however, are ideal for such use.  Note:  Apps Team will deliver wiki integration in Q1 2008 (or SteveD will explode!). 
• Time Critical Notifications.  The Hub's publishing model does not guarantee rapid distribution of content.  Use of "Tell a Friend" alerts can minimize latency, as can subscriber RSS feeds, but these techniques lack the targeted distribution found with e-mail (particularly group mailing lists).  
• Rapid fire communication.  While creating a Hub conversation is fairly easy, quick comments or questions will feel cumbersome in a Hub.  Instead, we recommend IM, e-mail, or any of the common groupware packages.
• Transient communication. Hub's archive and promote searchability of conversation; however, plenty of discussion has no long lasting value.  We suggest avoiding information pollution by IM'ing or e-mailing transient conversations. 
• Targeted or Individual communication.  Person to Person communication has never been a Hub design requirement.  While some security setups (e.g. small, private interest groups) may simulate targeted or personal communication, this is really a side effect of the normal Hub "broadcast communication" model.  When speaking directly to an individual we recommend IM, SMS/Text, e-mail, or in some limited cases Social Networks.