The latest in the “Battle for Enterprise Collaboration” comes courtesy of Barb Mosher of CMS Wire [1] and Adriaan Bloem of CMS Watch [2] in their reviews of the Sites API release that now enables migration of content out of SharePoint and into Google Sites. What both accounts fail to mention is that SharePoint SaaS has a long way to go to match the capabilities of on-premise SharePoint. Success in SaaS form, arguably more relevant than anything that’s happened in the server market over the last decade, will ultimately be predicated on PaaS (Windows Azure vs. Google App Engine) strengths and not the current feature sets around collaboration.
Vendor Lock-in Concerns
In addressing one of the chief concerns with nascent SaaS platforms like Sites, an engineering team at Google responsible for The Data Liberation Front has extended support to allow data the free flow of data in and out of their coloration platform [2]:
The Data Liberation Front is an engineering team at Google whose singular goal is to make it easier for users to move their data in and out of Google products. We do this because we believe that you should be able to export any data that you create in (or import into) a product. We help and consult other engineering teams within Google on how to "liberate" their products. This is our mission statement:
Users should be able to control the data they store in
any of Google's products. Our team's goal is to
make it easier for them to move data in and out.
(Note that the lack of API was one on the barriers cited with the Sites in our first review this summer.)
Meanwhile, Adriaan Bloem, of CMS Watch commented yesterday [3]:
And lastly, who uses Sites, anyway? After Google acquired JotSpot, it was closed for business for a year, and then Sites emerged: a stripped-down version of JotSpot. And after the initial hubbub, there was a roar of silence. @GoogleAtWork occasionally tweets about a corporate site done entirely in Sites, but those are always the sites of Google Enterprise partners. And they're the select few where I could see using Sites for an external site would make any sense (since they're selling it, of course.) Other than that, I read about enterprises switching to Apps -- and they get Sites in the deal, but while everyone uses the (g)mail, and many will use the docs (which have some nice collaborative features), few seem to venture into Sites.
To slightly offset all of this, yes, of course there are scenarios where Sites could be useful. These mainly revolve around small companies, with maybe up to 10 or 20 staff (so governance is less of an issue), who aren't in the business of running fileservers, mailservers, webservers, and social software -- Apps, with Sites, is a viable alternative. Running the infrastructure required for SharePoint (and going through the pains of implementing it to do useful things) would make little sense in that case. And for a lot of organizations, maybe especially the larger enterprises, Gmail is a very cost-effective replacement for maintaining in-house mail servers.
Google, however, hints at examples like "your sales team's Google Sites pages can update automatically when new leads are added to your CRM system"; but you'd have to develop the code to do so, first. And right now, there are too many reasons why you wouldn't really want to do that. Likewise, a migration from Notes to Gmail, I could understand. But from custom-built Domino applications to Sites... that's a completely different story.
Sites as a SharePoint killer? No, definitely not. This assassin has to go through ninja school first.
Google Sites isn’t ready for the enterprise spotlight yet, agreed; but I’m not sure the “reasons why you wouldn’t really want to do that” are clear to me. Comparing on-premise SharePoint to Sites is no apples-to-apples; Sites to SharePoint Online, on the other hand, is a little more realistic and a better question to ask is how and when the on-premise SharePoint that we’ve come to know and love will shine in SaaS form?
We still haven’t seen much on how future generations of non-dedicated SharePoint Online will support code-level customizations – all we know is that today’s version carries very limited support for functional extensions; the most you can do comes in the form of WebParts like Twitter Search that rely on existing HTTP interfaces and the built-in Data View and Data Form WebParts [4]:
(Whether even basic customizations like this would run in SharePoint Online needs to be validated.)
Fundamentally, customizations on either Sites or SharePoint online would look the same at this stage – and exactly why loosely coupled designs like this would be bad investment is unclear to me.
Both products are fairly premature for enterprise adoption; but there is arguably more momentum and a more active ecosystem around Sites at the moment [5] than there is around the wait-and-see SharePoint Online camp.
For a fair comparison of the two SaaS offerings, a detailed review is provided here.
Update (Oct 10, 2009):
Google has just announced a few upgrades to Sites:
Picasa Web Albums integration, site feeds, and page templates in Google Sites
References:
[1] – Google Goes After SharePoint with New Sites API
http://www.cmswire.com/cms/enterprise-cms/google-goes-after-sharepoint-with-new-sites-api-005620.php
[2] – The Data Liberation Front
http://www.dataliberation.org/
[3] – Google Sites with API: Still No SharePoint Killer
http://www.cmswatch.com/Trends/1702-Google-Sites-versus-SharePoint
[4] – Code-Free SharePoint Twitter Search Web Part
http://woodywindy.spaces.live.com/Blog/cns!773832677F575173!558.entry
[5] – Google Site Samples
http://www.steegle.com/websites
http://siteshelp.kccloudsolutions.com/
http://sites.google.com/site/wgpconsulting/Home/links-to-google-sites-examples
http://www.sacvolvoclub.org/google-sites#GSHL
0 comments:
Post a Comment