Date: Thur, 15 Dec 2006 012:00:00 -0600
From: SuitWatch 
To: suitwatch@ssc.com
Subject: SuitWatch - December 15




                             SuitWatch -- December 15, 2006
 _____________________________________________________


 Can we relate?

   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 http://cyber.law.harvard.edu/.
   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 http://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 http://jeremie.com/blog/, the father
   of Jabber http://www.jabber.org/ and its XMPP protocol
   http://www.xmpp.org/rfcs/ -- 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 IM'd to tell me we had
   an extra fifteen minutes before our meeting, so I jumped back on IM and
   asked Jeremie what was up.  He said he had been working on (what we would
   later call) the VRM problem.  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.  That gave me the
   confidence to propose VRM as the project I'd like to pursue here at Berkman
   (where I'm writing this).

   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.

   That's what I did at two productive VRM sessions at the Internet Identity
   Workshop last week.  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
   http://www.linuxjournal.com/node/1000035 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 http://en.wikipedia.org/wiki/RFP, 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.

     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.

     -- Doc Searls is Senior Editor of Linux Journal, a Visiting Scholar with
     the Center for Information Technology and Society at UC Santa Barbara, and
     a Fellow with the Berkman Center for Internet and Society at Harvard
     University.
   _________________________________________________________


 FEATURED EVENTS

   Join us February 14-15, 2007 for LinuxWorld OpenSolutions Summit

   A new conference from the producers of LinuxWorld.  OpenSolutions Summit
   will feature two days of peer-to-peer case studies, technical training, and
   insightful keynotes that will provide best practices and the latest
   innovations across the enterprise. http://www.linuxworldsummit.com

                            Sponsor: Pogo Linux

   Pogo Linux prides itself on providing affordable and reliable Linux servers,
   workstations, and storage solutions.

   We bundle high-quality hardware, a knowledgeable sales staff, and superior
   technical support into every system.
   http://www.pogolinux.com/
   ________________________________________________________

   To remove yourself from this list, see http://www.ssc.com/mailing-lists.
   ________________________________________________________