Scalix is designed to be a replacement for Microsoft Exchange, functioning as an e-mail and calendaring server that offers open APIs to enable third-party and homegrown software to hook into the platform. But does it live up to its billing as an "open source Exchange killer?" Justin James offers a comparison of Scalix and Exchange, examining both features and costs.
The Scalix 11 platform aims to be a suitable replacement for Microsoft Exchange. It functions as an e-mail and calendaring server and provides open APIs to allow companies to hook other systems, such as CRM and ERP, into the Scalix system. It also hooks into Novell Evolution, but since I do not have experience with that system, I am not qualified to make any comparisons to it. Scalix can use any LDAP authentication source, including Active Directory, and Red Hat and Novell directory systems. For most potential users, Scalix' main selling point is the Exchange cooperation, allowing users with Outlook to take full advantage of the functionality that the Outlook/Exchange combination provides. Scalix also claims to "play nice" with existing Exchange servers within a network.
Scalix comes in three flavors: the Community Edition, the Small Business Edition, and the Enterprise Edition. The three versions offer an increasingly advanced feature set, while allowing more Premium Users to access the system. The pricing of the system is rather interesting. Users are divided into two categories: Standard and Premium. Each version of Scalix allows an unlimited number of Standard Users and a fixed number of Premium Users. The Premium Users receive additional functionality beyond what the Standard Users get, most notably full compatibility with the Microsoft MAPI system and calendar functions on par with what Outlook users are used to when connecting to a Microsoft Exchange server.
For the"Standard Users, Scalix does not offer any functionality that's not available via a wide variety of open source mail servers: POP/IMAP/SMTP e-mail functionality, Web mail, and basic calendaring functions. To have Scalix function as a true Exchange replacement, you will want each of your users be Premium Users.
Installation of the product is easy enough if the server meets the requirements and has all of the dependencies installed. This was a major sticking point for me. Scalix is supported on Red Hat and SUSE versions of Linux. In the Linux world, "supported on" usually means "will run on all versions of Linux, but we will provide support only for certain distributions." As a result, I initially tried to load Scalix on an installation of CentOS, since it is compatible with Red Hat Enterprise Linux. The Scalix installer balked at CentOS, stating that it was an unsupported operating system. Not willing to try to fake CentOS into providing a RHEL OS stamp, I opted to install Scalix onto a trial version of SUSE Linux Enterprise Server 10. This installation went without a hitch, once all of the dependencies were installed. As a side note, the documentation for Scalix is of a very high quality and was both informative and useful.
I was a bit disappointed in Scalix' dependency list. For one thing, while it required Apache, it installed its own version of Tomcat. This means that you will need to rely upon Scalix to maintain its special version of Tomcat, and that this version (as well as Scalix) is outside the standard patching system for your particular Linux distribution.
Another gotcha is that Scalix requires the PostgreSQL database server. Although many will claim that PostgreSQL is more powerful than MySQL, the fact of the matter is that many more IT shops have familiarity and comfort with MySQL. Between the special installation of Tomcat and the dependency upon PostgreSQL (instead of offering MySQL support as well), Scalix is not in line with what many IT departments are used to.
Finally, Scalix required sendmail as a dependency. While sendmail has shown large improvements over the years, it has had a history of being a major security problem. The Scalix Web site claims that it will use sendmail or Postfix as an MTA, but the installer balked at the default SUSE Linux installation that had Postfix installed, forcing me to use sendmail.
A major concern that I had during the installation was the manual's instructions to "disable or remove" the firewall on my server. This is a showstopper. Mail servers have a large amount of exposure to the outside world. While the manual does list what ports need to be open, I thought it very strange that the manual would state that the firewall not be active. No enterprise class system administrator would ever allow that to happen. The up-level versions of Scalix can be configured in a multiserver configuration that can be split between the internal zone and the DMZ, but the idea of a mail server "requiring" that the firewall be disabled is quite disturbing.
After installation, the system came right up and was working as expected. I was able to immediately establish a POP3, SMTP, IMAP, and Web mail session to the server using the default username and the password established during installation. The Web mail system (Figure A) is quite heavily influenced by Outlook Web Access and is nearly an identical clone. OWA and Outlook users will feel right at home.
The options and configuration options were rather sparse compared to Outlook or OWA. A feature that I really missed was the ability to have the system send outbound e-mail on a schedule instead of immediately. This means that if you make a mistake in writing an e-mail, you need to catch it before clicking Send. E-mail power users will definitely prefer to work with Outlook as a Premium User rather than using the Web mail. The Web mail is an AJAX system, and I saw no problems using it in IE 7 or Firefox 2. Overall, I felt that the Web mail system was fine and did everything that it needed to do.
The Scalix administration system (Figure B) is equally utilitarian. One nice touch is that the administration system requires you to select a check box acknowledging that you are not using an SSL-secured connection. This small touch stood out in my mind. Sadly, this check box is not present in the public Web mail system, and the public Web mail system does not automatically redirect users to an SSL-secured connection when they sign in to the system. The administration Web service lets you manage the server's settings and view the various queues' contents, as well as start and stop individual services and daemons. There is nothing here that Exchange does not have, and the layout and the items will feel familiar (but not identical) to Exchange.
Overall, the Scalix system does seem to work as advertised. One quirk I found is that for e-mail bound for the local, default domain, it does not perform a lookup against the domain's MX record. It simply delivers the mail locally. To make this a more problematic scenario, there is no way to delete the default domain, only to change it. Therefore, administrators who do not want to use the Scalix system to receive e-mail will need to use a bogus local domain. While this might not sound like a common scenario, it will affect people who want to have all mail, even internal mail, pass through a different machine for spam or virus scanning.
I also found it curious that while the Scalix Web site states that ClamAV and SpamAssassin are part of the "Scalix Ecosphere," neither was offered as choices during the initial installation. Administrators wishing to use these standard open source packages (ClamAV performs antivirus, and SpamAssassin handles antispam duties) for their antivirus and antispam chores will need to install and configure them separately. Even after I installed them, the Scalix administration system did not automatically detect them or hook into them. The documentation provides good, yet lengthy directions on getting both of these items to work with Scalix. It is hard to understand why Scalix does not come pre-bundled with these products, or at least able to work with them without a lengthy configuration process. Even more frustrating is that "advanced functionality," like performing backups, must be performed on the command line of Linux, not through the administration system.
It is also difficult to understand Scalix' value proposition for large enterprises. For basic SMTP/POP3/IMAP connectivity, it is trivial to use a standard open source package or combination of packages for the same functionality. For the full Exchange compatibility, the price advantage falls off quickly. Scalix is charging $60 per Premium User with a minimum of 50 users for the Enterprise Edition, and another $12 per year thereafter for the Software Subscription Service. Without paying this yearly fee (you must either pay for all users or no users), you will not be eligible to receive patches, updates, or other routine software maintenance.
In comparison, a Microsoft Exchange Enterprise Server license costs $3,999 up front, and a per-user license is $67 for a perpetual license (Exchange Standard CAL; the features included in the Enterprise CAL make Exchange much more feature rich than Scalix and do not offer a fair comparison). Note that all prices listed and discussed are manufacturer's list prices; Scalix offers volume discounts, as does Microsoft and many of its distributors. The technical support ($300 per e-mail incident, $1,000 for five e-mail incidents, or $1,500 for five e-mail/phone incidents) is quite pricey indeed, even compared to Exchange ($250 per phone/e-mail incident).
At the end of the day, the cost savings of using Linux instead of Windows melt in the face of the cost of Scalix' support and license fees. Even then, Scalix is supported only on Red Hat Enterprise Linux and SUSE Linux Enterprise Server, both of which come with hefty support fees of their own ($1,299 per year for Red Hat Enterprise Linux, Premium Subscription, compared to $1,000 for a Windows 2003 Standard Server perpetual license). Smaller businesses may do well with Scalix, but for the money at many of the price points, it is cheaper to use outsourced e-mail servers or to build a system from open source. Furthermore, Scalix offers to charge $5 per user ($3 if you have more than 250 users) for its migration tool. Paying to migrate to a more expensive tool feels a bit like gouging to me.
The following table show some basic price comparison numbers:
* These numbers take into account $60 per user Scalix perpetual license for Scalix Enterprise Edition, the Scalix Migration Tool costs ($5/user for 250 users or less, $3/user for more than 250 users), $1,299 per year for a RHEL Enterprise Linux Premium Subscription, and the $12 per user per year (after the first year) Scalix Software Subscription Service fees. On the Microsoft side, there is a $999 Windows 2003 Enterprise Server R2 license, $3,999 Exchange 2007 Enterprise Edition license, and $67 Exchange Standard CAL per user.
One thing to add to the price comparison, though, is that the $12 per-user yearly fee for the Software Subscription Service also appears to cover version upgrades. That means that the unfavorable long-term price comparison between Scalix and Exchange may become weighted in Scalix' favor, based upon the cost of future Exchange upgrades and how frequently you choose to upgrade Exchange.
Microsoft does offer a yearly licensing scheme for Exchange (the Software Assurance program), which reduces the upfront cost and provides for free upgrades. Under the Open Business license, the Exchange Standard CAL is $100 for the initial two-year term and $34 to renew for an additional two-year term. Over the course of four years, that brings the cost of an Exchange CAL to $33.50 per year. Depending upon your timing within the software upgrade cycle and your upgrade preferences, the Microsoft SA program may be less expensive than Scalix, but it most likely will not be.
Pros and cons
Scalix does offer a few advantages that Exchange does not. However, even these advantages are not complete differentiating factors. For example, Scalix boasts that it offers an "open" platform. Many would construe this to mean "open source". Indeed, most mentions of Scalix seem to refer to it as an "open source Exchange killer," which is not entirely true. The Core Collaboration Engine of Scalix is open source, but not the entire application. Companies hoping to simply download the source code, recompile it, and not pay Scalix will be disappointed. Scalix does support open standards to allow third-party and homegrown software to hook into its platform. This is a big bonus. On the other hand, Microsoft has long provided documentation aimed at helping developers target applications to tie into Exchange. While the Microsoft APIs are not "open," it is certainly possible for application writers to target it, and many of them do.
I like the fact that Scalix is offering Exchange compatibility on a Linux platform, but Scalix is hard to recommend. Between the costs of the Linux license and the cost of the Scalix licenses, Windows and Exchange perpetual licenses look like a potential bargain on price after the first two or three years, depending upon the number of users you have -- but again, your mileage may vary based upon the upgrade cycle you choose to stick with.
In terms of features, Exchange will always be compatible with Outlook, and I simply did not see anything in Scalix that Exchange did not have, other than an easier installation process. The Exchange administration and OWA are both more full-featured than their Scalix equivalents.
Overall, if you are running a 100 percent Red Hat Enterprise Linux or SUSE Linux Enterprise Server shop and are looking for full Exchange compatibility, Scalix is definitely worth considering. If your company is already somewhat (but not completely) committed to the Microsoft platforms, Scalix might still make sense, provided that your needs are such that you could have with a high ratio of Standard Users to Premium Users.
Check out this worksheet for a detailed comparison of Scalix vs. Exchange costs.