Since the outset, we've intended that Chandler be useable by groups without requiring a server. Sharing calendars among a small group should not require the considerable effort and expense of purchasing and maintaining an Exchange server. Instead, a peer-to-peer protocol can be used to coordinate the flow of information. In this way, Chandler will enable small groups of non-technical users to be far more self-sufficient than they would in a situation which requires special server hardware and software, the administration of which is outside the expertise of the users themselves.

In general, we have emphasized a style of usage in Chandler that can be called decentralized, in which there is no central authority or controller of resources, and in which peer-to-peer exchange is the dominant means of communication.

I must confess to a long-standing personal disposition in favor of decentralization. Ten years ago I was (naively) holding out hope in Wired magazine that a decentralized Internet would lead the way to a revival of Jeffersonian democracy. This obviously did not happen, and I let go of my na�ve techno-determinism. However, my affection for the non-hierarchical remained strong, something which can clearly be seen in Chandler's original conception.

What has become crystal clear though is that we must also support more centralized approaches if we are to gain the organizational adoption crucial to having the impact we hope to have.

A couple of months ago we were invited by a major foundation to meet with representatives of the computing services organizations of a group of major research universities. The agenda was set up to explore whether Chandler's calendaring capabilities would address a pressing need felt by the group. Our meeting led in turn to a more general discussion of scenarios for Chandler on campus.

Universities operate in a partially centralized fashion with respect to their computing and networking infrastructure. Typically, authentication and authorization functions depend on centrally maintained computing infrastructure like Kerberos and LDAP directories. Storage in the form of high-capacity IMAP servers for email are also important elements on most large campuses.

As we continued to discuss how to adapt Chandler to work in a university environment, it became clear that any flavor of organizational deployment of Chandler, whether campus or corporate, was going to run into the issue of integration and interoperation with one or another set of centralized resources. Without a clear technical strategy for penetrating organizations, Chandler's impact would be blunted, if not marginalized. While many of Chander's advocates (including most of the OSAF staff) are personally disposed toward a decentralized style of operation, the drive to be pragmatic about accomplishing our mission required us to embrace a mode of Chandler suitable for organizational deployment, one which embraces relevant uses of external, centralized infrastructure. This is to be done in conjunction with, not as a substitute for a decentralized, P2P approach. Chandler, as an integrated whole, must support both.