Collaboration and Content Strategies Blog

Google Goes After IBM Lotus Notes

Blogger: Bill Pray

After shedding the beta label last week, Google announced today a migration tool – Google Apps Migration for Lotus Notes. In order to win e-mail market share, a vendor needs migration tools. This addition to Google’s growing enterprise feature set for Google Apps demonstrates Google’s intent to seriously compete for enterprise market share. This kind of competition is good for the enterprise and will help mature SaaS e-mail offerings more rapidly.

However, having a migration tool and winning market share are two different things. Google will be hard pressed to win seats from the IBM Lotus Notes faithful – just ask Microsoft. Even Lotus Notes accounts that migrate to another vendor’s e-mail solution tend to keep Lotus Notes for the custom applications. Furthermore, if IBM can get customers to their latest versions of Notes (8 or better), these customers are not likely to be shopping for another solution. IBM is aggressively working to move their customers to the latest version (8.5). Google has a small window of opportunity for those customers who haven’t upgraded yet.

Google also has to reassure the IBM enterprise customers they are targeting that Google is in the best position to solve some of the challenges of software-as-a-service e-mail – e.g. security, compliance, regulatory requirements, discovery, storage, bandwidth, management, and provisioning. IBM’s LotusLive gives IBM the inside track with IBM’s customer base on providing e-mail from the cloud – particularly if they can perfect a flexible, hybrid model of SaaS and on-premise delivery of the e-mail services.

Free Google Apps Comes Back: Why This Is Bad for Enterprises

Blogger: Guy Creese

Um, that was another Google oopsie on July 7. After all the brouhaha about Google Apps Standard Edition going away, it turns out it isn't. The TechCrunch article has an update stating, "A Google spokesperson says, 'In experimenting with a number of different landing page layouts, the link to Standard Edition was inadvertently dropped from one of the variations. We are in the process of restoring it and you should see it soon. We have no intention of eliminating Google Apps Standard Edition, and are sorry for the confusion.'"

So take yesterday's post and turn it upside down. The Enterprise Division continues to be a hobby at Google: it's subsidized by ad revenue rather than standing on its own two feet. Bummer. I thought Google had finally seen the way to serving enterprises. Oopsie on my part. 

Google on Privacy, Coming out of Beta, and (Possibly) Rethinking Free Google Apps

Blogger: Craig Roth

A bunch of quick news hits from Google:

Google's CEO Eric Schmidt was interviewed on NPR yesterday where he was asked about privacy.

Mr. Schmidt said:

our company makes a commitment to people to respect people's privacy and their personal information because it's central to the trust that we have with end users ... I don't think anyone wants everything revealed. That's why we have doors and shades and so forth.

But Google didn't seem to care too much about privacy last year when it latched onto a common legal chiche to claim full license (just to promote its services) to anything people submit or even display on Google's sites. Or when it added an "incognito mode" to Chrome to protect your privacy, but also added a unique id buried in each browser as described in Google's privacy notice for Chrome.

And Google's belief in security-through-obscurity hampers its principled standpoint on privacy.  When people granted access to a shared doc in Google Apps can find older versions of the doc's attachments just by knowing the URL, that's not protecting privacy. Presciently, a commenter on the TechCrunch blog said “Doesn’t beta imply 'This thing is buggy. Use it at your own risk?"  That leads to the next bit of news ...

Google finally took the "beta" tag off some of their most popular webware, such as Gmail, according to the Google OS blog.

As the commenter I mention above demonstrates, many (most?) people assume beta = buggy.  Or, from the vendor's point of view, the right to dismiss bugs by saying "well, it's beta!"  As a former commercial software developer, I can attest that my publisher considered beta to be more about the number of bugs in the system, not features.  The GA version of software was about the same as the beta, but it reliably worked. 

In the Gmail blog, Keith Coleman, Gmail's Product Director, performs the artful dodge.  He asks the correct question "why Google keeps its products in beta for so long".  He then evades answering it with a bunch of "some say", "some people thought", "others said that" statements, then jumps to "The end result (many visible and invisible changes later) is that today, beta is a thing of the past. Not just for Gmail, but for all of Google Apps — Gmail, Calendar, Docs, and Talk."  Thanks, Keith, for telling me how people not in charge of Gmail would answer the question, but "some say" your answer is the one we're looking for. 

Mr. Coleman points to a set of great features they've added, as if to say "we must have awfully high standards if all these features are needed to get past beta".  But a product generally comes out of beta when it has the basic administrative features needed to make it usable and a high level of reliability. 

I think Mr. Coleman's real answer that others said for him is that "over the last five years, a beta culture has grown around web apps, such that the very meaning of 'beta' is debatable."  If the term beta is now useless, that seems to be an argument not to use it rather than to throw it on everything for years.  Just standing behind your product is better than trying to redefine a term to make it meaningless.

Free version of Google Apps gets buried, then emerges

The Google OS blog jokes (?) that "the free edition, ... is still available, despite Google's efforts to make it more difficult to find".  After TechCrunch reported on Google Apps Standard Edition (GASE) being buried, it partially resurfaced.  There's now a link to GASE, but without the key word "free" or a comparison of features.  So it's there, but a bit obscured. This fuels speculation that there's a split inside Google regarding whether the free version of Google Apps should be pushed, hidden, or hobbled.  I suspect wiser minds will prevail and the free version will emerge into the full daylight again. 

Google launches an operating system

I'm saving the best for last here.  This is the most interesting of the recent spurt of news hits from Google.  As many suspected (and Google openly acknowledged) when the Chrome browser was released, their intent was to create a platform for web applications to run on more than a place to browse web pages. 

Now Google has announced the Google Chrome Operating System, targeted at lightweight devices like netbooks.  Indeed, targeting heftier PCs would ruin the point of the venture, which is to say you don't need local storage and processing when the cloud is there to serve you. 

The OS won't be ready until 2010 (does that mean beta in 2010, which means GA in 2017?).  I'm interested to see it.  The lesson Microsoft has learned about operating systems on small devices is that you can't start with a full-scale OS and start trimming - you have to start fresh and build the OS for light weight from the ground up.  There's a lot of room for improvement in lightweight OS and Google is in a good position to rethink the problem with web apps in mind.  But please - don't make it advertising funded!  Sidebars and popups with ads on some web sites I can live with, but not on my desktop.  And the issues behind the news items above - beta (buggy) software, privacy, pricing model consistency - become even more important with an operating system.  Google will have to form a companywide consensus to these 3 issues before plowing into the OS biz.

Free Google Apps Goes Away: Why This Is Good for Enterprises

Blogger: Guy Creese

Google made a splash yesterday by burying the sign-up hyperlink to Google Apps Standard Edition (free) and pointing people instead to the $50/user/year version: Google Apps Premier Edition. The title of TechCrunch's article about the move ("What The Hell Happened to the Free Version of Google Apps?") hints at the general reaction. Several commenters said they felt that Google was violating its "Don't be evil" mantra with this move.

At a superficial level, this is about Google's plowing ahead with a different pricing strategy, leaving some miffed users and prospects in its wake. However, at a deeper level, this announcement signals a major organizational change at Google.

Think about it. Google has been following this dual pricing strategy for 2.5 years--it could have easily kept on a steady course. Why did it change? My guess is that upper management told the Enterprise Division that it would have to start paying its own way--it could no longer live off of ad subsidies.

In other words, this is Google saying, "Let's figure out if we have a viable business here: let's stop treating Google Apps like a lark and get serious." (A hint of the "get serious" attitude is that yesterday Google also removed the beta status from Google Apps.) If the supposition that the Enterprise Division is being told it has to stand on its own two feet is correct, that implies something else: that the Enterprise Division will be able to call its own shots. With its own money coming in, it will be able to develop the apps it needs, rather than making do with hand-me-downs (such as Google Apps) from the consumer side of the house.

In my view, the Enterprise Division has been sort of hamstrung by being a hobby at Google. (Not completely hamstrung--the Google Search Appliance, derived from Google's web search expertise, has been a big hit and a money-maker. However, Google Apps hasn't taken off with enterprises because Google hasn't made the necessary feature changes that enterprises need.) Living or dying based on paying customers will concentrate the mind of the Enterprise Division wonderfully, and that will be good for enterprises. 

The $64,000 Question: Google Docs, Acrobat.com, or Other?

Blogger: Guy Creese

A week ago, ReadWriteWeb published an interesting poll, entitled, "Poll: Which Web Office Suite Would You Pay For? Adobe or Google?" At the moment, out of 519 votes cast, 22% (114 votes) were for Adobe, 38% (199 votes) were for Google, and the greatest percentage, 40% (206 votes) were for neither. A number of commenters took the article to task for failing to point out ThinkFree and Zoho, two startups that offer productivity suites. ReadWriteWeb replied, "...we intentionally left them out so as not to dilute the vote between the two companies that are arguably industry giants as opposed to (awesome!) startups."

The problem with such open polls is you never really know the survey universe--it could include some Adobe or Google employees, hoping to tilt the results; it could include many respondents from SMBs, rather than large enterprises; and so on. Probably the more interesting part of the article is the comments, as they highlight many of the viewpoints I hear from clients. Here is a sampling:

Blogger: Guy Creese

A week ago, ReadWriteWeb published an interesting poll, entitled, "Poll: Which Web Office Suite Would You Pay For? Adobe or Google?" At the moment, out of 519 votes cast, 22% (114 votes) were for Adobe, 38% (199 votes) were for Google, and the greatest percentage, 40% (206 votes) were for neither. A number of commenters took the article to task for failing to point out ThinkFree and Zoho, two startups that offer productivity suites. ReadWriteWeb replied, "...we intentionally left them out so as not to dilute the vote between the two companies that are arguably industry giants as opposed to (awesome!) startups."

The problem with such open polls is you never really know the survey universe--it could include some Adobe or Google employees, hoping to tilt the results; it could include many respondents from SMBs, rather than large enterprises; and so on. Probably the more interesting part of the article is the comments, as they highlight many of the viewpoints I hear from clients. Here is a sampling:

Google’s Outlook Connector – First Bug of Many

Blogger: Bill Pray

Both Microsoft and Google released blogs this week concerning an issue with Google’s Outlook Connector whereby “Programs that interact directly with the Outlook data file, including Windows Desktop Search and PGP.com's encryption plugin, don't currently work well with Google Apps Sync for Microsoft Outlook” (Google’s take) or “The installation of the Google Apps Sync plugin disables Outlook’s ability to search any and all of your Outlook data” (Microsoft’s take). This illustrates my point in my previous blog that, from my experience, building an Outlook connector is difficult and fraught with problems.

In fact, the list of things that do not work (go to the section entitled “What’s Different from Exchange”) – provided by Google – is rather daunting if you are an enterprise looking to use the connector and want to replace Exchange on the backend. For example, it is a rare enterprise executive who doesn’t have a need to delegate her calendar to an assistant – a feature not available with Google's connector. I expect that this week’s issue with the connector will be the first of many for Google.

Google's Approach May Doom the Effort

Blogger: Bill Pray

Google announced Google Apps Sync for Outlook recently, which as Guy points out in his blog, allows enterprises to keep the Outlook client on the front end while replacing Microsoft Exchange on the backend. However, having been part of a team that built a connector for Outlook, it is not as simple as it sounds. Google’s approach may doom the effort.

Connectors to the Outlook are not new. For example, IBM and Novell have developed and supported an Outlook connector for years for their e-mail solutions. However, both of these vendors have dropped development of their connectors within the last year. Neither vendor has had wild success with their connectors and, I suspect, both found the engineering effort to be costly. I think a reason why is that these vendors were approaching it as an effort to make their product, each with more than a decade development, work like their product (not Exchange) in Outlook. This is a difficult task and one that requires constant vigilance to insure the connector keeps working as intended with each new patch, service pack, and release of Outlook .

Other vendors have used a different approach with their connectors. For example, Zimbra, PostPath, and Scalix entered the game with the deliberate strategy that they would emulate or work like Exchange – i.e. be an Exchange replacement. Their products were built from the start with the idea that Outlook could be the primary client. This approach seems to have been somewhat more successful, but even these vendors would like to see customers embrace their web clients over Outlook for a better experience.

As Microsoft alters Outlook in releases, service packs, and patches, it becomes very difficult to maintain this kind of integration. A lot of the heavy lifting happens client side in Outlook, so even small tweaks can create engineering nightmares for an integration. Microsoft definitely isn’t incented to be helpful to these kinds of integrations like they are with partner application integrations to Outlook. The result is that customers trying to use the connectors become frustrated with frequent “breaks” and loss of functionality as their vendor tries to catch up to the latest changes in the Outlook client.

Google seems to be approaching it like IBM and Novell have… building a connector to make Gmail work in Outlook. It will be interesting to see if they can really make it successful.  As Guy pointed out, the initial release will be missing features – such as task management, rules, and delegation. This makes it questionable as to whether or not the connector can really permit enterprises to replace their Exchange servers on the backend. Having experienced it first hand, I believe users will be frustrated by the missing functionality. I expect the success of the connector for Google will be as limited as it has been for IBM and Novell. I agree with Larry that more competition would be healthy for this market, but I believe Google’s Outlook connector may struggle.

Google Turns Up the Heat With Google Apps Sync

Blogger: Larry Cannell

In less than two weeks I will be talking about the enterprise SaaS e-mail market at the Enterprise 2.0 Conference in a presentation entitled “Is Email the Next Killer SaaS App?” This is based on a report we wrote last year, shortly after Microsoft detailed plans for Exchange Online and the Business Productivity Online Suite.

At that time it looked like a competitive enterprise SaaS e-mail market was forming with the promise of Yahoo marketing a Zimbra-based offering and, of course, Google’s low-priced Gmail getting the attention of many IT managers. Also, when Cisco acquired Postpath last year they announced the software would not longer be available for purchase and become part of a SaaS offering (Postpath is a near drop-in replacement for an Exchange Server). So these moves by Cisco, as well as Google and Yahoo, appeared to be significant attempts to disrupt the enterprise e-mail market.

However, until today Google seemed reluctant to get too cozy with Outlook, always keeping their relationship at arms-length. It also looks like Yahoo is no longer interested in selling Zimbra as a SaaS offering (however, it is still available from one of their hosting partners). In addition, Oracle is now in the enterprise SaaS e-mail market through their Beehive On Demand offering. However, e-mail is only a feature bundled in with the entire Beehive offering, competing with Microsoft’s Business Productivity Online Suite.

So, in thinking about my E2.0 presentation recently I was feeling somewhat dismayed that more competition hadn’t emerged. I’m also a little concerned that Cisco might come to market with a higher-end suite and, like the others, go after the higher margins. It looked like much of the enterprise SaaS e-mail market was being left to the traditional IT vendors (Microsoft, Cisco, Oracle) marketing more expensive offerings, since support for Outlook is critical for many CIOs to accept a new e-mail system.

Well, the Google Apps team just gave a big ‘ole bear hug to Microsoft Outlook with the release of Google Apps Sync for Microsoft Outlook. As I wrote here in the past, Outlook is the most flexible enterprise SaaS e-mail client due to is prevailing use, Microsoft’s publication of Exchange and SharePoint protocols, and the MAPI interface. Google Apps Sync leverages the MAPI interface so Outlook essentially thinks it is talking with an Exchange Server (this isn’t new, Zimbra also offers this, as does Oracle, and others). There are some functions which Google’s MAPI code doesn’t support at this time but these may not be show-stoppers for many companies. Switching an enterprise from Exchange to Gmail does not necessarily require users changing their e-mail habits and giving up Outlook, like they had to yesterday.

However, I think there are still some shortcomings with Google’s current offering. But, you’ll have to come to the Enterprise 2.0 Conference to hear about these :-)

Google Apps: Syncing Outlook with Gmail

Blogger: Guy Creese

Yesterday, Google announced Google Apps Sync for Outlook, which allows enterprises to keep the Outlook client on the front end while replacing Microsoft Exchange on the backend. From an organizational point-of-view, this allows IT to save money (usually) on e-mail administration without disrupting end-user life (since most companies use Outlook on the desktop).

Some comments, stories on the announcement:

• Google Blog: "Use Microsoft Outlook with Google Apps for email, contacts, and calendar"
• CNet: "Google plots Exchange escape with Outlook plug-in"
• TechCrunch: "Google Takes Another Swipe at Microsoft. Enterprise Apps Now Sync with Outlook."
• VentureBeat: "Google Apps syncs with Outlook--a cure for cloud computing angst"

For those paying attention to this market (or reading Burton Group reports), this announcement is not a huge surprise. Actually, the surprise is more that it took Google this long--2.3 years since announcing Google Apps--to figure out that it needed to offer this functionality. (Cisco's recognition that it needed to support Outlook as a client for SaaS e-mail was the driver behind its acquisition of PostPath last year.) In short, this software frontend/SaaS-backend architecture is required to penetrate this market. As we noted last year in the Software as a Service Enterprise E-Mail: Get Ready to Go Beyond the Grind report:

If the SaaS e-mail solution forces users to learn a new user interface, it can be a huge disruption to the majority of employees and the change will be visible to the entire corporation. However, if only the mail server is replaced and business users can continue to work as they have in the past, then a SaaS e-mail solution is effectively just a back end swap out. This makes it similar to installing a new blade server; thus, only the chief financial officer (CFO), rather than the large user population, needs to be convinced of the need for the change.

This solution will undoubtedly help Google sign up more enterprises for Google Apps than it has in the past. However, enterprises that do their homework will still find some gotchas. For example:

• Outlook Tasks and Notes aren't supported: According to the Google blog post, it looks like Outlook functionality is still not fully supported--e-mail, calendar, and contacts will sync, but Tasks and Notes aren't mentioned. For workers wedded to using every feature in Outlook, the Google solution is still insufficient. (Of course, for many workers, supporting only e-mail, calendar, and contacts is just fine).
• The cost of SaaS e-mail varies widely, depending on requirements: Based on some consulting work Burton Group has done, while straight vanilla SaaS e-mail implementations are price competitive, the prices start to skyrocket if the enterprise has customized its e-mail solution. For example, if it uses content filtering to intercept pornography or company secrets, uses special e-mail templates, or has built applications that use e-mail for workflow, then the costs of integrating those capabilities with SaaS e-mail often make the SaaS solution more expensive than the current cost of running e-mail in-house.

To sum up, the availability of Google Apps Sync for Outlook is good for enterprises--it gives them yet another option to consider when looking to decrease the burden of running enterprise e-mail. Depending on an enterprise's needs, it may fit the bill--or it may not.

Note: Cross-posted on Pattern Finder

Google Wave and its Audacity of Scope

Blogger: Larry Cannell

As impressive as the recent Google Wave demonstration was, the most sensational part for me was the breadth of aspirations Google says it has for the platform and protocol. Sure, the product demonstrated has some very cool features, such as the blending of synchronous and asynchronous collaboration (for example, a user can see what others are changing within a page in realtime). But, when Lars Rasumussen says “Wave is what email would look like if it were invented today” and we are told Google is open sourcing the protocol and software, then this starts looking like a grand plan indeed.

Call it the Audacity of Scope. This is not simply about a snazzy HTML 5-based application, Google is telling us it aspires to make Google Wave as pervasive as e-mail. However, realizing these aspirations is a long-shot. To have any hope of making it happen Google needs a strong extended-release dose of determination, flexibility, credibility, and lots of luck.

Determination: Google will certainly use its muscle on the Internet to make the Wave platform available and in the hands of as many people as possible. But fostering a federated system as pervasive as e-mail will take time. Ultimately, Google is a business and may not have the patience to see something like this all the way through.

Flexibility (and openness): E-mail wasn’t invented by a single company, but evolved as an idea over time. Although ARPA can be credited with creating and moving forward key e-mail standards. there were many more innovations that built on these simple protocols. If Google maintains sole control over the federation protocols then Wave will remain a Google-based service that many will integrate with, but will fall short of the pervasiveness of e-mail. Google needs to take steps to make Wave a truly open protocol.

Credibility: Getting vendors to agree to a standard is difficult, almost impossible when there is enough at stake (which is the case here). Don’t expect traditional IT vendors like Microsoft, IBM, or Oracle to be lining up behind this effort anytime soon.

Besides Internet-based services, open source is the only other method which has been successful in bypassing or breaking traditional IT-vendor lock-in within most large enterprises. So, another aspect to watch is how involved open source developers, and other open source projects, get with the Wave effort. If Google loses the open source crowd it loses its critical mass.

The key here will be what and how much of Google’s code will be open sourced. Rasumussen said “We intend to open source the lion share of the code we use to build our system.” This is a good start but what does this really mean in terms of code? To some, “lion share” sounds like Google is hedging its bet.

Luck: Google can do all of the right things for years and Google Wave may still not catch on. This is a long-term undertaking and many things can happen in the meantime to derail it (for example, management loses interest, an open source community doesn’t form, better alternatives emerge, or a million other things could go wrong).

But, regardless of all the hurdles Google faces with Wave I am still glad to they are attempting this. It’s great to see new ideas get this level of attention (and Google certainly can draw a crowd). If nothing else, the demonstration starts breaking down preconceived assumptions about how the Internet can support collaboration.