Since the birth of SharePoint, Microsoft has marketed it as an internal collaboration platform, during a period when Intranet managers increasingly see collaboration as a high-priority service. Now, players such as Google and HyperOffice are trying to repeat SharePoint's success, using an on-again, off-again "SharePoint Killer" marketing tactic combined with the idea of creating a kind of Intranet-in-a-box alternative. However, technology buyers inevitably discover with any technology -- from Redmond or any competitor -- there's usually a wide gulf between the marketing hype and the implementation reality.

Google's announcement today that it will allow Docs users to store other files inspired a fresh round of speculation in twittersphere about competition with SharePoint. File-sharing is essential to the modern enterprise, but storage alone doth not a collaboration application make.

Before that, Google made a big media push to promote their Sites application. The resulting coverage brought another round of "SharePoint Killer" claims. Most of these claims have been effectively critiqued. As my colleague Alan Pelz-Sharpe points out, Sites is hardly a SharePoint killer and Adriaan Bloem gets deeper in discussing the broader application of Sites.

But let's back up for a moment. The real issue at hand is not whether Sites or Docs or Wave or HyperOffice can kill SharePoint, but rather can these tools (SharePoint included) stand up to the demands for which software makers market them?

If you ask any three consultants, you'll get five answers regarding the definition of an intranet. Most average folks in medium and large organizations could probably give you a quick definition that goes something like this: "an intranet is a place where employees go to get information and resources necessary to do their jobs." While this broad definition could be applied to many applications, you'll typically see the following in a basic Intranet: forms for various benefits, links to key services (and applications), and places to store simpler organizational content (e.g., holiday schedules, policies and procedures, and so on). For these basic services, SharePoint Services/Foundation, Google Sites, and HyperOffice can meet many needs, especially among smaller enterprises. However, if this is all organizations needed for intranets, Microsoft, IBM and OpenText would not have spent billions on developing more enterprise-centric products.

To better understand the very broad and deep needs organizations have for employee productivity, look at Jane McConnell’s Global Intranet Trends Report and Nielson/Norman’s Intranet Design Report. Through the lens of both reports (and others), we begin to see what organizations are not only doing today, but will do in the next couple of years -- and the vastness of that marketing/reality gulf becomes very apparent.

Some of the functionality available within SharePoint Server (forthcoming successor to MOSS), IBM WebSphere, and other large-scale portal offerings are unavailable in more basic solutions like SharePoint Foundation (free successor to WSS) or Google Sites. For example:

• Personal Sites/Spaces
  Some enterprises want to provide each employee with an individual space in an intranet. These spaces are usually controlled exclusively or semi-exclusively by the employee and mimic the personalization features we might see on the internet (think iGoogle).
• Business/Social Networking
  One key aspect of many intranets today is the ability to connect employees from across the organization together. IBM, Microsoft and others have invested in developing solutions that connect one employee to another. In SharePoint, there’s a feature that helps you connect with people within your own team (common manager), within the same distribution list (through Exchange) and through other contacts (like LinkedIn).
• Enterprisewide Search
  No one is happy with their Intranet search engine, but Google's hosted services are no closer to solving this problem than the on-premise search tools of its enterprisey competitors.
• Composite Application Frameworks
  Beyond the ability to create "simple" sites that collect content and allow employees to share data, many vendors are investing in the ability to create composite applications. Composite applications are a collection of features or functions for more than one application in the enterprise, brought together in a singular interface. In Web 2.0 speak, you’d call them a “mashup,” but composite applications are becoming increasing important in organizations that want to give portions of enterprise applications to a much broad audience. For example, combining a product lookup from SAP with sales lead data from SaleForce.com.

Subscribers to our SharePoint Research will know that it's only at the fee-based level (MOSS and Server 2010) where SharePoint can begin to satisfy broader organization needs. And even then, the results can be uneven. At the same time, products like Sites and HyperOffice, as well as SharePoint Services/Foundation, only touch a small percentage of an organization's needs, let alone address concepts like governance, security, and collaboration. Small businesses can cobble together lightweight hosted services effectively. Larger enterprises need to take a more holistic view. Do you need an apple or an orange?