State of things with Chandler

Later this week I, along with several colleagues from other universities, are heading down to San Francisco for a "re-calibration" meeting with the Open Source Applications Foundation about the future Westwood version of the Chandler personal information manager. I'm looking forward to catching up with folks at OSAF about their latest thinking.

Recently, Mitch Kapor announced that OSAF's initial implementation of Chandler will not be a true peer-to-peer application as was originally envisioned, but instead will be based on a client-server model, with the Chandler repository residing on a WebDAV server. This is a huge change of focus, and, I think, an overall positive realization of what is possible with the current state of technology.

Trying to understand the relationship between OSAF's P2P vision and the enterprise server architectures that are widely deployed at universities has always presented unresolved issues in the discussions between OSAF and the Common Solutions Group about the use of Chandler in higher education.

I've always wondered what technology problems are solved by P2P applications that aren't better addressed by having well managed servers instead - the environment where P2P came of age, music file sharing, was largely a response to the legal issues raised by the music companies as they clamped down on people distributing files from ftp servers. I wrote about this in this post last October.

In the case of sharing personal information the problems of authentication, authorization, and synchronization in a P2P environment are extremely complex and largely unsolved, at least in the open source community (Mitch points out in a later post that Groove has largely dealt with these issues in a closed, proprietary p2p application).

Mitch notes, I think I've unfairly maligned servers in the past. It's not the server I dislike, it's the idea that as an end user I am disempowered if the work I want to do depends on the administration of a piece of software I don't control, can't get access to, and plays by a different set of rules. The PC-era pioneer in me says, "get rid of it". Another approach might be, "tame it and make it serve me".

I think that's largely what we've been trying to within higher ed for many years - putting highly available, high performance, highly reliable, servers within the reach of average computer users in our institutions. Sometimes we've succeeded better than other times, but in general I think it's been a good approach.

I have been impressed with Mitch and the OSAF organization for some time now, and I think his willingness to reconsider approaches speaks well for both his intelligence and for the future success of this important project.

A learning: We wound up focusing on the client software first, not the network architecture. Having had my formative software design experiences in the era of stand-alone PC's, it was easy to repeat the pattern of paying more attention to what is going on on the local machine than to what is happening across the network. While the repository is network-aware, and, in fact, very early versions of Chandler supported a simple form of accessing items from a remote repository, I didn't fully appreciate until this year the importance of considering issues of network availability, reliability, and performance as first-rate issues in and of themselves. You're never too old to learn (or to admit mistakes).