A public infrastructure of servers.

Somewhere during the development process of Chandler, Kapor rethinks the peer-to-peer foundations:

Kapor was rethinking the merits of peer-to-peer anyway. At a June meeting where he formally announced the adoption of a server-based sharing design to his staff, he explained, "I've had a significant change of point of view. There was a kind of frontier idealism that was well intentioned but not practical on my part. The issue is about empowering people. It's not about the infrastructure. Maybe we need a robust public infrastructure of servers to let people do what they want to do. My and OSAF's original position was, electricity is good, therefore everyone should have their own power plant! Unconsciously, I always imagined that user empowerment somehow meant a server-free or server-light environment. Now I think that's actually wrong."

(Rosenberg: p. 214)

Could that "public infrastructure of servers" be what Google and others have been building in the past few years? The time when individuals can have their files "on the cloud" is here already. Millions of people have their music, pictures and opinions hosted on sites such as Google Documents, Blogger, MySpace, Facebook, Picassa, Shutterfly, Flickr, YouTube and many others. Right now they access all this information via snappy web applications written in AJAX but there is nothing stopping us from adding these services to regular, old-style rich apps. Actually, the folks at the Mozilla Labs are already working on some Firefox extensions to do exactly that. In this respect, it could very well be that the project to build Chandler started too early for its own sake.

WebDAV, peer-to-peer and the influence of hype.

Who doesn't remember the big peer-to-peer trend that happened a few years back? Napster showed up in the radar, it quickly became the next big thing and... well, it quickly went away too. Yes, it also served a purpose. Who thinks that we'd have the iTunes store today without that little experiment? Still, it's also true that peer-to-peer became fashionable, trendy, cool, the thing to do and, all of a sudden, everybody wanted to fit the framework into whichever project they were working on. According to what we can read in Dreaming in Code, that's precisely what happened to Kapor and the team behind Chandler:

If WebDAV could do it, why was it so har for Chandler? Chandler's peer-to-peer approach meant there was no central server to be what developers call, with a kind of flip reverence, "the source of truth". WebDAV's server stored the document, knew what was happening to it, and could coordinate messages about its status to multiple users. Under a decentralized peer-to-peer approach, multiple copies of a document can proliferate with no master copy to rely on, no authority to turn to.

Life is harder witout a "source of truth". For programmers as for other human beings, canonical authority can be convenient. It rescues you from having to figure out how to adjudicate dilemmas on your own. After just a few weeks at OSAF, Dusseault became convinced that the peer-to-peer road to Chandler sharing was likely to prove a dead end. The project had little to show for its efforts to date anyways. "But it was like, we're doing peer-to-peer. We have to. We said we would. We decided to."

(Rosenberg: p. 213)

WebDAV was certainly much better suited to the project they had in mind that peer-to-peer. The same could be said of the traditional client-server approach. So, what's the morale of the story? Even the best hackers make mistakes when they let themselves be influenced by hype.