Imagine being able to relate to vendors -- productively, on mutually agreeable terms -- rather than just paying them money for whatever they're selling, and occasionally giving them "feedback" through surveys that aggregate our "input" inside some impersonal "customer relationship management" (CRM) system. That's the idea behind VRM, or Vendor Relationship Management. It's the reciprocal of CRM: a toolset for independence and engagement. That is, of independence from vendors and engagement with vendors.

VRM is also a development effort -- ProjectVRM -- that we've started at the Berkman Center for Internet and Society. There are no VRM tools yet, so we're starting with a blank slate. We've begun filling that in with a wiki and a mailing list, both open. Find them through ProjectVRM.org.

On the one hand, it feels audacious for me to push a development effort when the only code I know is Morse. On the other hand, a number of actual developers are interested in making VRM happen. In fact it was the interest of one developer — Jeremie Miller, the father of Jabber and its XMPP protocol — that convinced me that VRM would be a productive area of interest for Berkman.

Back in September, when I was getting ready to go into a meeting with Colin Maclay (Berkman's Managing Director) and talk about what I planned to do, I was unsure about pursuing VRM -- mostly because it would need to be a development project and I'm not a developer. All that day Jeremie had been pinging me on IM, and I had been putting him off because I was too busy. Then Colin told me we had a fifteen minute delay before our meeting, so I jumped back on IM and asked Jeremie what was up. He said he had been working on the VRM problem (which we were still calling "Independent Identity Managment" or something like that). As we exchanged ideas, it became clear to both of us that VRM was not only do-able, but something that needed to be done. There were projects to pursue here. Ideas to test out. This gave me the confidence to propose VRM as the project I'd like to pursue: both as a Berkman fellow and as a contributor — and not just a writer — in the open source community.

Not long after that Dave Winer (a former Berkman fellow as well as a veteran developer) told me the time was ripe for users to lead developers, rather than vice versa. Dave had long been an advocate of users and developers working together, but this was the first time I heard him suggest that a user -- yours truly -- might be ready to play a leading role.

So that's what I did at two productive VRM sessions at the Internet Identity Workshop early this month. A number of ideas and use cases that came out of those.

First was data independence. The individual needs to own and control their own data, independent of vendors. Dave Winer gave the example of movie reviews. He would like to write reviews that would be useful to Netflix and Amazon but not locked in either company's silo. I like the example of photographs. While Netflix and Amazon trap movie reviews inside their silos, Flickr and Tabblo both treat my photos as something independent of their systems, which are silo'd as little as possible. That's why they have APIs that allow me to move photos from one service to another. But while this creates a bigger photography market ecosystem, it's still mostly a vendor-to-vendor relationship. I would like VRM tools to help me control not only how my data is used, but what kind of relations I would like to see between the various companies I relate with. This might even extend into revenue sharing if one of my photos is sold. Independence of patient data also came up. Our medical records should belong to us, and not just to health care providers. We should have means for selectively revealing and using that data.

Second was the inside-out nature of relationships between customers and vendors. That is, customers are at the center -- at the inside -- and relate outward toward any number of vendors. The idea is not to take the old top-down few-to-many pyramid of vendor-controlled markets and turn it upside down, with customers now on top. Instead, we equip customers with the means to function in more ways inside marketplaces, at the center of relationships with any number of vendors.

Third was the roles of reputation, intention and preference -- or "what I've done", "what I want" and "what I like". All three bear on relationships, and there is an enormous amount that can be done with each of them.

Fourth is what Joe Andrieu called a "personal RFP". Requests For Proposal, or RFPs, are formal appeals for bids that companies send out to suppliers. Why not equip customers with the means to send out RFPs of their own? Why not equip customers with the means for issuing RFPs as well?

Ethan Zuckerman summed up several of these points in one blog post. Here's the gist of it:

The term - VRM - is a direct reaction to CRM - "Customer Relationship Management", a process that Doc and others wrote the Cluetrain Manifesto in angry opposition to. CRM isn't actually about building relationships with that customer - it’s about controlling that customers data, nagging them at regular intervals to make additional purchases and making it difficult for the customer to leave the company, often by claiming ownership of data or settings she or he has created.

Vendor Relationship Management is designed to invert this whole process. It posits a customer with control over how much data she's willing to give out and the ability to put specific requests to a wide set of possible vendors. Doc offers a specific example: I'm landing at LAX on December 28th and I want to rent a midsize car that has the ability to play mp3 CDs. Who's got a vehicle for me, and how much does it cost? First, this request breaks the system of nearly all car rental companies at present. Second, in the paradigm we currently use, you as a consumer are forced to go to each company’s website and repeat your requests. A more fluid market would allow you to specify your needs and see who wanted to bid to serve you.

The idea behind VRM is moving beyond a relationship where the ownership of the data in a transactional relationship is all on the side of the vendor. It's a move towards independence from vendors and engagement with vendors on our own terms - I may be willing to tell you my car request, but not my identity or payment information until you make me an offer.

Another VRM challenge is improving relations between public broadcasting and its customers. Public broadcasting is in an unusual and privileged position: its consumers are also its customers. For commercial broadcasters, those two populations are split. Advertisers pay for commercial broadcasting. Not the viewers and listeners, who consume the goods but don't pay for them. Viewers and listeners are not really in the market for commercial broadcasting's goods. In fact, viewers and listeners are the product commercial broadcasters sell to its real customers: the advertisers. (Specifically, they sell the attention of consumers.) Meanwhile, public broadcasting actually sells its products directly to viewers and listeners. True, ten percent of that population pays for what a hundred percent get for free. But shouldn't that ten percent should get something more out of their relationships with stations than promotional cups and CDs? And hey, wouldn't more viewers and listeners buy public broadcasting's goods and services if an actual relationship were involved? How can we facilitate that? Certainly we can do better than what we have now: stations turning off regular programming for two weeks, pleading poverty, threatening to go off the air or drop programming "unless you help" and promising schwag to "supporters" who call volunteers on the phone.

Here's one way VRM could have big vendor appeal: by making it possible to pay voluntarily for anything we think is worthwhile, such as a podcast or a public radio or TV show. And by putting in the accounting mechanisms that give stations (or any vendor) valuable data about what people actually prefer, actually use and actually want. With their permission, of course.

Control is the issue, and the means. It belongs in our hands now. Let's put it there. For the good of vendors as well as ourselves.

[An earlier draft of this posting went out as a SuitWatch newsletter.]