A little over a year ago, frustrated with Microsoft Exchange for a variety of reasons, we departed for the sunnier shores of Zimbra as hosted by Maccius. While there were a few bumps in the road – calendar migration was problematic – all three of us would agree, I think, that Zimbra was an immediate improvement.
Most obviously, the web client was considerably more sophisticated – doubly so for Cote and I, who had access only to the non-IE Outlook Web Access client, which is primitive compared to its IE counterpart. Underneath the covers, the application was a better fit for some of our rich clients, speaking as it did web standards like iCal and IMAP natively. And some of the dire predictions and claims with regard to performance – proved unfounded. Well, mostly. As long as you keep the web client up and running, the performance is excellent. If you’re one of those people who open and close their mail client regularly, however, you’ll have issues, because the initial load is time consuming.
Nor was the application static. Over the year we were on Zimbra, we gained new skins (very welcome over the, uh, classic brushed metal heavy interface), the Zimbra Assistant (a little Yubnub-like shortcut box), and the big one as far as we were concerned: full REST APIs. All good.
What we didn’t get, however, were little things like SMS notification, free/busy calendar support, and mobile interfaces for average mobile devices. Hence, our – or mostly mine and Cote’s – interest in Google Apps.
As seen on Twitter, following a somewhat contentious internal debate, we decided as of last Friday to proceed with a trial of Google Apps as a collaboration platform. Herewith are some thoughts on the migration process, and initial reactions to Apps.
Setup (Google)
The setup for Google Apps really couldn’t be much simpler. You fill out a form, pick a domain, and – if you choose Apps Premium as we did – provide a credit card number that can be docked at the end of the 30 day trial period. The whole thing took maybe five minutes.
What was slightly more complex was making the changes to the domain records to repoint our mail from Zimbra to Google Apps, and to activate shortcuts like calendar.redmonk.com or docs.redmonk.com. Fortunately, Google provided step by step instructions for this, so all that was involved on my end was a couple of quick mails to Johncompanies and we were up and running.
The point has been made before, but it’s worth making again: the lower barriers to entry for online applications are an immense advantage for certain types of customers. Customers like us, that have no interest in hosting our own infrastructure. In addition to this, Google benefits from its direct path to the customer. If, as a small business, I want Exchange, Notes, Scalix, or Zimbra on a hosted basis, even if I can get it I’m probably going to have to evaluate and pick from hosting providers that I’m totally unfamiliar with. Google’s lack of choice, then, is an advantage as long as pricing remains acceptable.
Migration (Export)
We could not be happier with Zimbra in this regard. While it’s counterintuitive to argue that Zimbra’s decision to give us the freedom to leave their platform is a selling point, it’s true. Their decision to expose all application data via REST APIs makes it far more likely that we’ll come back in future, should we choose to leave Apps, and protects new customers investments. You will not be putting anything into Zimbra that you cannot extract easily, to the applications credit. Calendar, Contacts, and Messages are all available via a simple URI, in easily consumable formats (more on that here).
When the import of James’ calendar failed, for example, I simply pulled down an iCal and imported it into Google Apps. Took two minutes, and only that long because James’ calendar was immense (near a thousand events, and pushing 1 MB in size).
In short, credit Zimbra for a very customer (developer too, of course) friendly decision with regard to its APIs.
Migration (Import)
Because Google Apps speaks in the same formats and protocols as Zimbra, the import process was just as trivial as the export. In its latest iteration, Google introduced a migration tool to assist in the import of IMAP type accounts. Although it only officially supports Courier, Cyrus, Dovecot, and Exchange 2003 – with Exchange 2007 and Lotus Domino amongst the unsupported options – I had no issues setting up our Zimbra server under the “other” designation.
After inputing the user account credentials, you turn the web based migration tool loose to do its thing, with the ability to check progress. Our accounts varied in total size and number of messages; I was the run away winner in message volume, with some 33,000 messages to migrate, while Cote took the prize in the account size category with 5% of his 10 GB space used up out of the gate.
Although the process took several hours to complete in my case, thus far I haven’t seen anything missing or misfiled. Nor have, to the best of my knowledge, Cote or James. I say “misfiled” because Google Apps still does not speak IMAP natively, only POP, and as a result there are no folders available to place messages in. The import tool accounts for this by mapping IMAP folders to Gmail labels. Simple, and not entirely desirable, but reasonably effective.
What was something of a surprise to me was the fact that Google’s import tool didn’t stop with mail, but pulled and inserted our calendar entries as well – except in James’ case. I hadn’t known it was going to do that, but it was a very nice touch.
Usage
With only a week’s usage under our belt, it’s far too early to render a full verdict on Google Apps, but thus far I’m impressed.
The positives:
- Community:
Whether it’s because the software is only partially open source, or because the focus seems to be more towards the OEM lines of business, Zimbra doesn’t enjoy the community support one might expect from the openness of the platform itself. Google suffers no such problem, despite not being open source at all, due mostly to the fact that it’s Google. The community around Calendar, Gmail and the rest of the applications is sizable and growing, manifesting itself in everything from Firefox plugins (Gmail Manager is highly recommended) to community calendars (here’s the Red Sox iCal, and there’s even one for Maine tides). - Google Talk:
Google Talk was really something of an afterthought during the migration process, but it’s proven itself quite useful over the past week. While Cote and I tend to run traditional IM clients that support things like AIM, James’ prefers Skype messaging. The difficult with Skype is that the Linux client is terrible; when activated, it takes between five and ten minutes to discover all of my contacts. With Google Talk, however, you’re online whenever you’re on the web client (you can also configure it in GAIM, as I have – though Google’s instructions for some reason don’t mention that you need to set talk.google.com as the talk server), so there’s no overhead to it. Surprisingly convenient. - Mobile Access:
As one of the major reasons I pushed for a switch, it should come as no surprise that the mobile access story was of substantial interest. But it’s still difficult to convey just how liberating it is to be able to point the primitive web browser on my phone at calendar.redmonk.com and view my schedule. For someone that spends a fair amount of time traveling and therefore disconnected, simple access to calendar and email information is huge. It should become only more so when I head to UbuntuLive and OSCON in two weeks, because conferences are when I need that access the most. - Spam:
The anti-spam filters in Google have been nearly flawless thus far. One or two spam messages have penetrated the filters in the space of a week, while the only observed false-positives have been spammed comments mailed to me from WordPress. This is a time saver, since Maccius’ tuning of Zimbra’s Spamassassin capabilities was letting a high volume of Junk through.
It’s not all positive, though – Google Apps still has some work to do.
The negatives:
- Documentation:
The documentation for Apps has room for improvement. The primary difficulty seems to be that they’re relying heavily on the documentation for regular Calendar and Gmail, but there are slight differences between the two (in URI, if nothing else). If you don’t use the custom domain extensions, for example, how does one access their calendar from a mobile device? If you’re using regular Calendar, I believe it’s mobile.google.com/calendar (although calendar.google.com should render for you as well), but I’m not sure what it is for Apps. Nor did the documentation spell it out clearly. - Free/Busy:
I didn’t expect to be disappointed by the Free/Busy functionality, but I am. As you can see from my calendar here, it’s only marginally useful in that it displays only meeting start times, not end times. It’s better than nothing, to be sure, but it’s not what I’d expected. Fortunately, I should be testing an alternative solution that’s more sophisticated very shortly, but hopefully the Apps folks will upgrade the native Free/Busy capabilities in future. - No J2ME Mail Client for Apps?:
Speaking of differences between Apps and its non-commercial cousin, as nearly as I can determine from the Apps forums, there is no way to configure the Gmail J2ME application for usage with Apps. It’s easy enough to access via the web interface, of course, so this isn’t a major show stopper, but it’s unfortunate because the J2ME client is very nice.
All in all then, I’m quite pleased with the decision thus far, although we have 20 some odd days left to evaluate before we actually pay for anything. Will keep you all posted as we move forward with the tool.
