Scalix potentially a serious contender to Exchange

After reading David Berlind's blog and listening to his podcast about a potential contender to Microsoft Exchange server, Scalix sounded almost too good to be true. As someone who's overseen and designed many Microsoft Exchange installations with hundreds or thousands of users, I have always been haunted by several issues related to any Exchange contender. My skepticism prompted me to post a follow-up blog, in which I asked some hard-hitting questions and this talk-back to David's original blog. Since that time, Julie Farris (founder of Scalix) replied to my blog with some very impressive responses that showed Scalix was indeed a serious contender and not like some other pretenders of the past few years (hint: A guy named Larry).

However, as powerful as Farris' defense of Scalix was in terms of the client end (i.e., Web Client and Outlook plug-in), the description of the backend manageability left me a little concerned. Still, the client end sounded so impressive that I had to check out the WebEX demo of its Scalix Web Client and download a demo version of Scalix to see for myself if Scalix lived up to the hype. Here is what I found.

• The Scalix Web Client was so impressive that it even surpassed the Microsoft Exchange 2003 OWA (Outlook Web Access) client in terms of functionality and richness. Although the Scalix Web Client may not look as "pretty" as the OWA 2003 client in terms of matching Outlook 2003's appearance and animated GUI, it easily surpassed OWA 2003 in terms of functionality -- and without the use of a flimsy and bloated J2RE applet or Microsoft's proprietary ActiveX technology. For example, the search function was phenomenal in the way that it narrows down the results in real-time as you type each letter. It populated the "To:" field and provided a pull-down menu of likely recipients as I typed each letter of the recipient's name. Even the Scalix Web Calendar was far superior to the OWA 2003 client. I think the Scalix Web Client sets a new standard for browser-based applications.
• As for transparency on the client end for switching the Outlook client from an Exchange server to a Scalix server, the use of the word "transparent" may be a little bit of a stretch, since you can't actually keep the same type of client configuration. You have to download and install a plug-in component to connect Outlook to a Scalix server. Having said that, this isn't really too much of a downside since it's a relatively simple installation. Also, Julie Farris has promised that RPC over SSL capability will be added to a future version of the Scalix client for Outlook 2000, 2002 (aka XP), and 2003. RPC over SSL allows the full-blown Outlook client to do secure authentication and communication with an Exchange server even when a VPN is not in use. This comes in handy when your VPN client doesn't work because it's behind a firewall, doesn't support your particular VPN solution, or if VPN is blocked intentionally. Microsoft supports RPC over SSL only for Outlook 2003 and Exchange 2003, which leaves out the majority of Exchange/Outlook users. We'll have to see how long it takes Scalix to deliver on this new feature, or if Microsoft will start feeling the heat and deliver a free RPC over SSL patch for Outlook 2000 and 2002. Why bother with the full-blown Outlook client when the Scalix Web Client or even OWA 2003 already work so well? The answer is simple: Browser-based clients don't work offline and Win32 clients generally can.
• After receiving the download link and the instructions for implementing the Scalix solution, here is where the saying "the devil is in the details" started to surface. Implementing Scalix requires a Linux guru who has some experience with Tomcat application server and is comfortable with the command-line interface. (Most of the serious configuration changes must be done with a command-line interface.) Now, this may be perfectly fine with an organization that already possesses a Linux guru or is willing to hire one, but it's completely alien to an Exchange shop. Even a happy Scalix customer, who posted this response to my original blog, admitted that Scalix wasn't for everyone.

As a result of these findings, I sent Scalix a letter with my mixed response. Even though I was extremely impressed with its solution, I had some misgivings about the lack of a manageable interface for the backend. Here is an excerpt from my letter:

It's fairly routine for a Linux guru and someone who has experience working with Tomcat application server. However, those are foreign languages to an Exchange or Windows administrator. I'm assuming those are the people you're targeting. In addition, setting up the hooks to merge into an existing AD and Exchange environment looks like it requires a CLI (Command Line Interface), which is by no means trivial for an Windows/Exchange guy. The management interface appears to be lacking and I can tell you that you will have a huge obstacle convincing people that this will be as easy to manage as their AD/Exchange environment. What is needed is a bootable ISO that you can burn to a CD. The CD would boot and let you install Linux, Tomcat, J2RE, Scalix web access, Scalix server, and anything else that is needed using a menu driven interface. All configurations should have some kind of intuitive graphical interface, although having the CLI is still good for automating tasks. Otherwise, you're looking at a whole day's labor using a skill set that is most likely not available from in-house or will be expensive to hire and maintain. This is what would be expected as an Exchange replacement. The reality is that CIOs and IT directors want things as simple as possible to make it manageable by their existing staff. Having the Linux included is very important because it will eliminate the need to buy Redhat Enterprise server (which is about $1500 a year for maintenance) vs. an existing Windows 2003 server with a one time licensing fee of $500. The support model for Windows or Exchange is $250 per incident and that is extremely attractive to companies. These are critical issues, but they're not something you can't correct.

Note that this was the most critical part of my letter to Scalix. By no means do I think that Scalix is not a serious threat to Microsoft Exchange, even in its current form. I don't believe Scalix is so much a threat to Outlook, since it clearly seeks to serve that market with its Scalix plug-in for Outlook. Julie Farris replied with a thoughtful response by admitting some weakness in user friendliness of the backend and said that they would seek to rectify it in future.

The bottom line is that Scalix in its current state is very impressive but has some flaws. However, Scalix in its promised state should make Microsoft management quake in their boots if it's not already doing so. If Scalix will deliver on its promises for a more manageable backend and some other enchancements, it has the potential to put a serious dent in the e-mail/groupware market. Microsoft, on the other hand, will be feeling the pressure soon, if it isn't already. Microsoft might even be pressured to reverse its decision not to release the next version of Exchange in 2006 and to reverse its decision to not convert its database backend to SQL. Microsoft might even be pressured to improve its older versions of Outlook for versions 2000 and 2002. If all this pans out, the customer wins no matter which solution they choose.