The disruptive Web

I DID AN EXPERIMENT last week that nicely demonstrates the disruptive potential of Weblogs, Web services, and digital identity. My experiment began with two observations.

Free IT resource Hear how top CIOs turn change into a competitive advantage. Sponsored by HP Free IT resource Try Sun servers, workstations and storage products free for 60-days. Sponsored by Sun Microsystems Disruptive Web services Executive Summary: An experiment in spontaneous integration -- involving the extraction of ISBN numbers from an existing RSS service to automate queries of libraries' form-driven Web sites -- shows how Weblogs, Web services, and digital identity can be jointly disruptive. Test Center Perspective: The Weblog network -- where, in our example, knowledge of frequently mentioned books, Web-based library lookup systems, and JavaScripting came together -- is an ideal medium to develop and disseminate simple, URI (Uniform Resource Identifier)-addressable services.

First, I noticed myself buying books from Amazon.com not on the basis of Amazon's recommendations but on the book-related blog postings gathered by a clever service called All Consuming ( www.allconsuming.net ). Like Blogdex ( http://blogdex.media.mit.edu ), Daypop ( www.daypop.com ), and Technorati ( www.technorati.com ), All Consuming measures the diffusion of links throughout a large network of blogs. But while the others measure the fluctuating interest in blogs themselves, All Consuming makes books the organizing principle.

All Consuming displays books mentioned on blogs in the last hour or week, summarizes and links to the citing blogs, and, using Amazon, Google, and other APIs, wraps book details, price comparison, and purchase apparatus around the discussion. Finally, it exports an RSS (Rich Site Summary) feed, an XML news-syndication format. As a subscriber to that feed, I'm reminded daily of the books being discussed on blogs. The reminders and the discussions they link to have raised my awareness of books and prompted me to buy them more often than usual.

The second observation followed directly: This was getting expensive. Could the local library help meet my surging demand for books? Its online catalog knew whether a book was locally available, but that information didn't appear in the right context. To switch from Amazon or All Consuming to the library's site for a requery doesn't take much effort. Once we establish a context, though, we are loath to abandon it. The question became how to avoid that context switch.

There was never any doubt that integration was possible. All these systems use ISBNs (International Standard Book Numbers) to identify books. When All Consuming scans blogs, it looks for ISBNs to find postings that mention books. All Consuming also uses ISBNs to create the SOAP calls that pull Amazon information into its Web pages and to form the URLs that send users to Amazon pages about those books.

Unlike Amazon, the library systems don't offer XML APIs. They appear to be merely form-driven Web sites. But hidden within those forms are the URLs that make every form-driven Web site a protoservice. And embedded within the search URL is the magic ISBN number.

I knew that manually copying the ISBN from one browser to another wouldn't satisfy most people. But I blogged that solution anyway because it was an interesting partial result that would provoke the blog hive mind to suggest how to take the next step. And it promptly did. Jenny Levine ( http://theshiftedlibrarian.com ) noted that my local library uses the same system as hers and that the system's vendor serves more than a thousand libraries. Another blogger, Scott Reynan, reminded me that bookmarklets, which are JavaScript snippets embedded in HTML links, can be installed in browsers' toolbars. A bookmarklet, when clicked, could inspect the current page's URL (say, at Amazon.com), capture the ISBN, form a library search URL incorporating the ISBN, and invoke that search in a new window.

One problem remained: How would I configure the bookmarklet for a given library? Reynan suggested a geographical method: Request (or discover) the user's postal code and map from it to the nearest library on the vendor's list. That was plausible, but the mapping wasn't readily available. Then a laughably simple solution presented itself: Generate a list of bookmarklets, one per library, and blog it. A user who visits that blog page and finds a local library there can drag its link to the toolbar to install the bookmarklet.

Thus a new service, potentially useful to millions of people, was deployed by blogging a Web page containing 900 links. The meme spread quickly in the petri dish that is the interconnected blog network. My published RSS feed spread the news to my subscribers, who passed it along to their subscribers, and soon the blog indexes picked it up and spread it even more widely. By the end of the day, the technique was verified to work with many libraries in the United States. What's more, it had mutated. Reports came in from around the world about adaptations that worked with library systems from other vendors. These mutations, packaged as HTML links, propagated through the blog network. People from Syracuse, N.Y., to Sweden found links in their RSS readers that could be installed and used immediately.

The vendor of the library lookup system that our bookmarklets were invoking, never having imagined or intended this disruptive outcome, hastily yanked its listing of the 900 libraries. The following day, the listing was just a ghost in the machine, manifesting itself in Google's cache and the Wayback Machine. What seemed to be an informational Web page turned out, to the vendor's surprise, to be a Web services directory. Moreover, the software that made it easy for people to tap into those services had a special property. Hyperlinks are the currency of the blog network. Packaged as hyperlinks, these scripts merged seamlessly into that currency flow. The medium for the exchange of ideas and the medium for the exchange of software became one.

These are the ideal conditions for what economist Hal Varian calls "recombinant growth." When it's viral, of course, such growth can also become cancerous. Malicious e-mail is the famous example, and it raises an interesting question. Most of us have learned by now to never click on executable e-mail attachments, even when they appear to come from friends or colleagues. Why then were users of these bookmarklets willing to ignore the warning (in some browsers) that the links contained possibly unsafe code? Here's the difference: digital identity. Although we can bind digital identity to e-mail messages by signing them, almost nobody does. The cumbersome mechanics of the PKI (public key infrastructure) certificate have made it a mainstream nonstarter. As a result, we can trust no one. That policy is formalized in the emerging white-list-style e-mail services, which classify all messages as spam unless the sender has registered with the recipient.

Blogs work differently. Instead of n-way authentication, there is only one-way authentication. Each author authenticates to a hosting service to post there. Each blog is bound to and emblematic of its author's identity. The popularity rankings that the blog indexers incessantly churn out are also measures of trust. As a longtime blogger, I've built trust that comes partly from speaking consistently over time with a credible voice and partly from peer validation expressed in the currency of links. Everyone can see that to violate that trust by spreading malicious code would be a self-destructive act.

If you're creating a Web service that you hope will have a disruptive impact, the lessons are clear. Support HTTP GET-style URLs. Design them carefully, matching de facto standards where they exist. Keep the URLs short, so people can easily understand, modify, and trade them. Establish a blog reputation. Use the blog network to promote the service and enable users of the service to self-organize. It all adds up to a recipe for recombinant growth.