Apple is leveraging the power of open source development in a new effort to directly target Microsoft Exchange Server. A new standards based, open source Calendar Server will debut this year with Leopard Server; the source itself is already available at MacOSForge.org .

The company's last major effort in developing messaging services, PowerTalk and the Apple Open Collaboration Environment, was abandoned ten years ago as an unwieldy project built upon the foundation of the classic Mas OS, which was never designed to be a server platform.

In the decade since, Apple has focused primarily on recovering its desktop Mac business and expanding into consumer electronics.

While corporate IT has historically paid little attention to Apple's products, things are changing. Additionally, Apple has customers outside of corporate IT who want server solutions from the company:

Apple Serves

In 2002, Apple introduced the Xserve. Paired with Mac OS X Server, the Xserve makes a good workgroup server, but as a product it sits in an awkward position, particularly when compared to Microsoft’s common offerings.

It's almost too much for most small businesses, but it does not compete against Microsoft's full range of server products; in particular, Apple has not offered anything similar to Exchange as an integrated email, contacts, and calendar server.

This year, Apple will release new initiatives to address those problems. The first is a replacement for Exchange, a step far more significant than analysts seem to realize. Apple's strategy is a full frontal assault on one of the most valuable asset in Microsoft's Enterprise portfolio.

Despite its flaws, Exchange Server is the reason many IT shops embark on Windows-exclusive plans. Here's why Apple is teaming up with open source development, and why an Exchange alternative is needed.

Teaming up with Open Source

As the article Open Source Values & the Peanut Gallery pointed out, when Apple opens something up, it has a clear strategy in play.

In the case of its new Calendar Server, Apple intends to impact a target that the open source community hasn't itself been able to dent, despite several parallel efforts.

Apple has strengths as a product oriented, commercial developer with visible market share, but it has weaknesses in the server arena. Open source development has weaknesses in pushing slick desktop products, but strengths in server deployments. Working together, both can contribute strengths to open development.

Leopard's new Calendar Server is based upon the open CalDAV standard for exchanging calendar information. In addition to working to develop interoperability with existing CalDAV open source calendar servers and clients, Apple is also opening its own Calendar Server code under the Apache license.

Existing projects will benefit from Apple throwing its significant desktop user base behind CalDAV, and Apple will benefit from wide development efforts working on CalDAV. Users will benefit from more choices in clients and servers that all work together.

Working with Apple to build and establish an open interoperable standard is also easier and more elegant than trying to break open a closed, proprietary standard.

Open vs Broken Open

Open source, and in particular Linux, has been cutting into Microsoft's proprietary stranglehold on PC servers for over a decade. Much of this progress has been established with free software built upon open protocols and code, such as the Apache web server.

When open standards are adopted, different vendors and projects are free to introduce competing but interoperable implementations. Everyone wins.

In other cases, the open source community has worked to break open proprietary protocols and standards, in particular Microsoft's. This allows Linux to compete in areas dominated by closed software and protocols, but helps to establish Microsoft's closed protocols and technologies as de facto standards. Some examples:

• the Samba project built a copy of Microsoft's SMB file sharing protocol to allow other systems to connect to and serve the Windows File Sharing protocols • many projects use the FAT file system designed for DOS • NTFS-3G and other projects have broken open the NTFS file system Microsoft designed for Windows NT • Cedega and Wine offer compatible Windows APIs without using Windows • OpenOffice and similar projects attempt to copy Office and its document formats • Open Xchange and Evolution work to duplicate the functionality and protocols of Exchange and Outlook

The goal of breaking open Microsoft's closed technologies is to create interoperability with standards that are already ubiquitous, so that Linux and other platforms can compete in a proprietary world already dominated by Microsoft.

Apple uses Samba code in Mac OS X to share files and printers with Windows PCs and connect to Windows servers, for example.

Problems with Breaking Open Closed Protocols

The downside to breaking open proprietary standards is that they are commonly not originally engineered for cross platform use, and can further entangle open development with dependancies on other proprietary code.

In addition, break-open efforts embroil open source development in risk, because Microsoft holds patents on many of these technologies. Busting open NTFS is very useful, but using it as a file system creates an opportunity for Microsoft to attack resulting products as infringing technology.

Linux has little recourse; it is designed and conceived as a way to deliver free versions of existing software, not primarily as an effort to invent new software. People use Linux to escape having to pay for Windows on the PC.

Apple doesn't have that same limitation because it drives its own market and is free to introduce its own ways of doing things. Apple doesn't have to copy Microsoft.

The Special Lock of Exchange Server

While open alternatives exist for many of Microsoft's server products, the company has maintained a special lock on messaging and calendaring in Exchange Server.

Once users get accustomed to using Outlook and Exchange features, it becomes very hard to replace them with open alternatives. From there, its a slippery slope for IT groups to standardize on Windows for desktops, invest in Microsoft's IIS web server, and exclusively buy everything else the company sells.

Exchange uses open standards to send email over the Internet; the lock lies between the Exchange Server and its Outlook clients. The lock is difficult to break because Microsoft's MAPI is secret, complex, and subject to change with every revision to Exchange, just like every other private API in Windows.

Competing with Exchange

The tight integration between Outlook and Exchange makes it difficult for other vendors to compete against the duo. Additionally, Exchange is more than just an email server; it handles specially encoded email messages that Outlook interprets as calendar items, tasks, and contacts. Other email clients see these items as cryptic emails.

The only alternatives to competing with Exchange are to:

• break open Exchange's MAPI and related Exchange RPC protocols, duplicate their functionality, and make existing mail servers and mail apps MAPI compatible • copy Exchange and Outlook in principle and deliver a clone of both based on open standards • build a new system from the ground up that is not based on Exchange at all

Trying to break open MAPI is like trying to get Wine working; both are huge engineering efforts to pound sand down a rat hole while the rats are busy digging other holes.

Breaking open Microsoft's protocols is complex and difficult, incurs patent risks, and ends up with a work alike product suffering from the same problems as Microsoft’s, with odd little incompatibilities on top.

Rather than chasing the moving target of a proprietary standard and trying to break it open, it is ideally better to design an open, interoperable standard.

The second option, copying the idea without the specifics of emulated compatibility, also requires major engineering efforts. Microsoft has been working on Exchange for over a decade. Duplicating those engineering efforts would be a massive undertaking, with unclear payback.

Free software can't afford to take major risks because there is no profit potential to pay back speculatively invested efforts. Further, the actual design of Exchange is not ideal. Exchange is intended to sell Windows desktops and servers, not serve as an interoperable email or calendaring system.

The best way to compete against Exchange is to rethink how to offer email and calendaring services--learning from the mistakes made in Exchange--and offer strong competition to it with a federation of open, interoperable implementations. That’s what Apple is doing.

Exchange and Apple

Apple doesn't appear interested in directly competing against Office because it wants and needs to maintain a Mac version of the Office suite; that same logic doesn't apply to Exchange for two reasons:

First, Microsoft doesn't provide a real MAPI client for Mac OS X. There's only Entourage, which only provides a subset of the features that Outlook for Windows has. This marginalizes the Mac in Enterprise environments that have standardized on Exchange and begs for a better client experience.

Entourage actually talks to Exchange server using IMAP and the Exchange web interface; Apple already offers some of the same functionality in its own applications. Entourage is neither a strong Microsoft app nor a strong Mac-like app. Apple would rather see Mac OS X users on Mail than tied to the problematic Entourage.

Second, Microsoft isn't going to port Exchange to Mac OS X Server. That's a barrier for Apple in selling its Server product to Exchange shops. If they currently use Exchange, there is no way they can migrate to Apple's product.

The lack of an Exchange alternative keeps IT shops running both Exchange and Windows. Without an Exchange for Mac OS X Server, it suits Apple to build its own server products that obviate any need for Exchange at all.

Replacing Exchange

Exchange Server ties calendaring and a contacts directory to email, making it difficult to sell a competing product. Apple has an email and directory server; it has been missing a calendar server.

Apple faced two options: continue trying to ship improvements to iCal and Mail that integrate with and depend upon Exchange, or work to build a replacement for Exchange and enable sales of Mac OS X Server, as well as a whole new market segment for selling Xserves.

The next article will look at what Exchange Server is, and three big problems with Exchange that will drive users to open alternatives from Apple and its partners.

Next Articles:

This Series