del.icio.us, del.irio.us, and the architecture of intermediation

When Steve Mallett recently cloned del.icio.us to create de.lirio.us, the predictable controversy ensued. Here's a capsule summary:

Good! del.icio.us is closed-source, the world needs an open-source social bookmarking service.

Bad! Geez, what a lame ripoff!

The title of today's entry is a deliberate echo of Tim O'Reilly's wonderful phrase the architecture of participation, which I used in this entry that elaborated on this InfoWorld column. The column, which is about Red Hat's Fedora project, argues that "open source" and "innovation" are sometimes fellow travelers, but not always or necessarily. In the follow-on blog entry I added that while open source participation historically meant hacking source code, the rise of services creates new modes of participation. As we use infoware (another great Tim O'Reilly coinage), we also help to create it.

Fair enough, but when you need a feature that a service doesn't provide -- private bookmarks, for example -- somebody's going to have to participate as a programmer, not just as a user. The del.icio.us/de.lirio.us flap reminds me that our models of programmer participation haven't yet caught up with the shift from open source to open services.

Let's talk about private bookmarking. It's something I want, and that lots of people want. Consider this del.icio.us tag: mssecurity_iw_2004-10. I used it while researching an InfoWorld feature on Windows security. Alert PR folk could have noticed my use of that tag, seen which sources I was and wasn't noticing, and tried to steer me in other directions. Now in fact, that might not have been a bad thing, if they'd lay off the email and just allow me to poll the global mssecurity_iw_2004-10 tag. At some point I might even propose this mechanism as yet another way to invite the blogosphere into my research process. But I digress. We can all imagine cases where we'd like to mark some things private.

Here's the current state of play: if you want that feature, you have to either wait for del.icio.us to offer it, or clone del.icio.us and add it yourself. As it happens, de.lirio.us doesn't offer private bookmarking either, but with source code in hand -- the thinking goes -- you can extend rather than recreate.

I took a few tentative steps down that path. de.lirio.us requires the CPAN module Rubric is a very thin layer on top of an application called Rubric, which in turn requires a whole bunch of supporting modules. In the middle of building all this stuff, I pulled the ripcord. For my purposes, this was overkill.

All I really want to do is redirect a small subset of my del.icio.us transactions to a private datastore, and make the del.icio.us interface aware of that datastore. So I took a few tentative steps down another path. I set up a local web proxy and explored what it would take to intercept and modify the del.icio.us URLs and pages. It's doable -- everything is, by hook or crook -- but again I pulled the ripcord. This was the right approach, but the prevailing model of web-based software doesn't really support it.

What's needed is an architecture of intermediation. Sure, Internet protocols have always been open to basic intermediation, that's why I can choose from among 17 open source HTTP proxies written in Python. But that's low-level intermediation. We need to gain altitude.

In the web services realm, buzzwords like "concern-based" and "aspect-oriented" point the way forward. Privacy is a concern that I may have with respect to my use of del.icio.us, and a potential aspect of my transactions with the service. Joshua Schacter shouldn't have to modify del.icio.us, and Steve Mallett shouldn't have to fork it, in order to satisfy this need. A lightweight intermediary ought to suffice. The popular style of intermediation may or may not wind up being WS-*, but something like it will be how we avert these kinds of conflicts and tailor services to our needs.

Former URL: http://weblog.infoworld.com/udell/2005/03/30.html#a1205