Linux or other open source operating systems can largely replace proprietary systems as network or file sharing servers. Many businesses use them for this purpose. However, there is one network service provided under Windows NT with which open source solutions can not compete: calendaring and workflow.
Microsoft Exchange is a mail and groupware server for Windows NT. The preferred client for connecting to it is Microsoft Outlook. Together, they provide a suite of groupware/workflow tools which many businesses find essential to their smooth running.
The problem is that Exchange/Outlook calendaring (& etc.) are tightly coupled to the Exchange mail server, the IIS web server, and Windows itself. This means that open source software must be able to replace all of them in order to be accepted. A proposed solution which uses (for instance) Linux or BSD, Apache, and Sendmail will be found unsuitable because it does not support calendaring. Since all the other Microsoft software is required to support calendaring anyway, Microsoft-running businesses see no need to replace any of it.
It is not the intent of this white paper to discuss why one would want to replace NT with Linux or BSD, IIS with Apache, or Exchange mail server with sendmail, postfix, qmail, or whatever. It is assumed that the reader understands the relative costs, benefits, and problems of each. We will, therefore, assume that replacing an all-Microsoft environment is considered a desirable outcome.
A number of efforts have begun to address the need for open standards and software for calendaring and workflow. Foremost among these is the IETF standards-track document for calendaring, RFC 2445, which describes a core object specification for Internet Calendaring and Scheduling. This specification is referred to as "iCalendar".
At the time of writing, there is one reference implementation of the iCalendar specification. In order for iCalendar to become an actual standard (as, for instance, TCP/IP is) there need to be at least two independent reference implementations of the specification.
The official standardisation of RFC 2445/iCalendar (and subsequent pressure on software houses to support the standard) is not the only benefit of developing another iCalendar implementation. More iCalendar implementations will:
help us (the development community) refine our understanding of calendaring systems and improve the available technologies
provide wider choice for users
promote hybrid vigour by cross-fertilization of ideas between projects
provide a base for project management systems (another much-needed area of software in the open source arena)
| Next | ||
| The toolkit approach |