Project VRM - User contributions [en]

The Matrix (Blue Pill)

2010-01-13T11:48:38Z

Killspam:

'''VRM Scenarios - "The Matrix (Blue Pill)"'''

http://www.socialcustomer.com/images/bluepill.jpg

Vendors control production, allocation and distribution, and at the same time understand that a connected customer is a lifetime customer. Supply chain models such as [http://www.inventoryops.com/ConsignmentInventory.htm vendor managed inventory and consignments] are used. The vendor controls what purchase options are given to the customer, and realizes that he must be equitable, or the customer will terminate the relationship. The vendor has perfect information on the behavior of his customers, including purchase history. Vendors use this information to continually refine and model the selection and quantity of goods and services made available to each customer to not only maximize profits, but also to ensure continued access to that customer. Customers select their vendors based on the belief that they will have an ongoing relationship with the vendors they choose, and give them feedback as to what they'd like to see.

Principles

2010-01-13T11:47:22Z

Killspam:

This page is a draft proposal. Please send any comments to [mailto:joe@switchbook.com] or to the Project VRM [[mailing list]].

==Charter==
Create an ecosystem of tools, protocols, and services that help users manage vendor relationships.
==Principles==
#User control
#Reduce, Reuse, Recycle (Don't Reinvent the Wheel)
#Reciprocity & Everybody Wins
#Leverage network effects
#Relationships are more than transactions
#Solve real-world problems

===User control===
Work from the perspective of the end-user. Users should control who, how, and what happens throughout the entire process. The process should create value for the user first, vendors and others second. Note that by creating value for users, there should be plenty to go around. See Reciprocity.
===Reduce, Reuse, Recycle===
Don't Reinvent the Wheel. A lot of technology and solutions have already been developed to address various pieces of our online world. When possible, reuse existing tech and learn from prior experiences. That means researching what has already been done and integrating the past whenever possible.
===Reciprocity & Everybody Wins===
VRM should create value for everyone in the value chain. Although the focus is on the user (see User-centricity), each link in the relationship should come out better after implementing a VRM Protocol. When everbody wins, it will be much easier to convince everyone to participate.
===Leverage network effects===
Network effects scale as more people participate. Whenever possible, build systems with this characteristic. In particular, reducing transaction costs across many different transactions can dramatically change a market, even when those costs are relatively small part of each transaction. So, use network effects to leverage the value of our efforts as far and wide as possible.
===Relationships are more than transactions===
Although vendor relationships are ultimately bounded by transactions, they begin well before and continue well after. Build systems that enable rich, long-lived relationships in ways that create real value.
===Solve real-world problems===
People have lots of challenges and frustrations with existing sales, shopping, and support systems. Pick one and re-invent it from a user perspective. If putting the user in control creates real value with minimal investment by the vendor, we have a good chance of getting traction with both users and vendors.

This is an early draft. I encourage corrections and addendums. Especially from our fearless leader. =) [[User:Joe.andrieu|Joe.andrieu]] 00:29, 2 February 2007 (EST)

Project VRM:Community Portal

2010-01-13T11:45:20Z

Killspam: Undo revision 4216 by Cryp18 (Talk)

[[November 11 2009 Conference Call]]

[[September 30 2009 Conference Call]]

[[September 02 2009 Conference Call]]

==Prior Conference Calls==
[[conference call archive]]

[[:Category:conference call]]
[http://www.sexalemi.org sikis izle]
[http://www.pornositeleri.net porno izle]
[http://www.sexalemi.org sex izle]
[http://www.sexalemi.org sikis]
[http://www.cinsel.name sikis izle]
[http://www.cinsel.name.tr sikis]
[http://www.hiphopalemi.net hiphop]
[http://www.kelebekchat.net kelebek chat]
[http://www.kelebeksohbet.org kelebek sohbet]
[http://www.chatsohbet.org chat sohbet]
[http://www.siberchat.net chat]
[http://www.pornositeleri.net porno]
[http://www.pornositeleri.org porno izle]
[http://www.pornositeleri.org porno siteleri]
[http://www.sexpormok.net sex]
[http://www.mynetsohbet.net mynet sohbet]
[http://www.hiphopalemi.net chat]
[http://www.hiphopalemi.net rap]
[http://www.kelebekchat.net kelebek]
[http://www.gaychat.gen.tr gay chat]
[http://www.cinsel-sohbet.com cinsel sohbet]

Prototyping VRM Mobile Social, iPhone

2010-01-13T11:44:46Z

Killspam: Undo revision 4219 by Cryp18 (Talk)

Stuart- Prototyping a mobile VRM that leverages Social Network fabric

iPhone is a good conduit

Phone
SMS
Email
3.0 notification
Bluetooth

Stuart says that we have all these ways to contact people

iPhone adds location

Adds time

Presence â and what Iâm doing

Things that recognize that âstate has changedâ

Relationships provide context regarding âWho are you?â

The questions revolve around access control

âWe have this thing in our pocket that provides all these things to us, but we have no controlâ¦

â¦on the other side, the people have no idea whatâs happening on this end.â

It doesnât have to do with calls necessarily, but when it âescalatesâ from a message

Rules for Pre-call Information

Recipient only knows phone number if the caller is not in the directory

The originator really has no control over what information is provided

Using the rideshare use caseâ¦ thereâs an issue surrounding the Buddylist

Using Google Voice you can treat each caller differently â¦

Right now Google Voice gives you a âflavorâ of all the rules you can attach to incoming calls

Ribbit could be a platform for all of these services

Voice mail treatment on an iPhone is an issue because the iPhone voice mail store is on the device, not on a shared host

Comment â originator may want to indicate a different originating phone

Originator may also want to send a pre-call alert â IM/SMS (the Can you talkâ message)

Caveat â you will pile all kinds of capabilities for the power users â but other people wonât use it.

So you need to monitor and analyze all that behavior and deliver

You can establish groups.

Another way to look at it is that you can have my GrandCentral # and it is related to all the ways that I can be reached and will be associated

Need to talk about the difference between synchronous/asynchronous

Is it that important to do a synchronous conversation.

So basically it gets down to hooking up a system where the caller is in control

âIn a VRM world, the phone owner is in controlâ and how you get there is to take away the possibility of the caller to control the terms and conditions

This could be the origination vehicle

The systemic smarts are much more interesting than the granular control

Because the granular stuff should be automated.

You can trick thisâ¦ just get a fictitious number and point it where you want

**Stuart has an idea for a Craigâs list for Twitter (called Twitmark) instead of a phone number and address you put a Twitter handle, but whatâs missing is the escalation to a phone number. The other thing thatâs missing is that you have to do an abbreviated link to (e.g. a Craigâs list ad)â¦

Another idea that was brought up is the Farley Fileâ¦ whereby you keep track of all the people that you meet.

The phone gets it backwards, inbound now might be able to relate it to a record in the phone infrastructureâ¦ But what if you have a âWhoâs this?â button to relate other stuff in the social graph and CRM space to figure out whoâs calling.

Observation â thereâs probably a latency issue. Unless you preload some set of most likely callers and their might be other premapping.

People can more accustomed to âpromiscuous messagingâ â that is basically adsâ¦ âI need xâ or âIâm selling Yâ then you can also use location awareness to figure out whoâs twittering nearbyâ¦

Observation â youâre social graph and list of people youâre in touch with

One of the premises for this discussion is that if VRM is going to work, it will be on a mobile device.

Observation â there are a lot of interesting initiatives underway and we have to figure out how they will bolt together.

Some compete
Some could augment each other.

Weâre talking a lot about the requester time. And not how you find relevant providers â¦ So you need to know âhow sees thisâ?

A: in the twitter exampleâ¦ Daycare companies might have a âbot monitoring peopleâs requests, determining where the person is. They can send a direct messageâ¦ And they may have their own filter

Narrowcast exchangesâ¦

Which Phil Wolff â calls âsearchâ

E.g Rent-a-Coder
O-Desk
E-lance

Where you have not a job offer but a short gig. So you craft a message

**Capability goes in seek of a need and vice versa***

Thereâs an aggregation function to be served.

If youâre looking specifically for a pair of tennis shoes specificallyâ¦ Itâs not readily apparent exactly how you get to there from here.

Angieâs list + ribbit exposes the latency issue

Stuart is saying that â as things âescalate toward a transactionâ and Darius is wondering how you get there from hereâ¦ Can you make this a âcheck boxâ item in their lsting that âfor an extra $2 to add a phone numberâ for the duration of the interest.

Phweet demonstrates that the identity layer can be set up independent of other services.

It will work anywhere and it is initiated on the basis of a text exchange. The contract is a URL for that exchange.

You probably have it in your headâ¦ Thatâs a feature, not a product.

How do you make a product
How do you build usage.

Phil â Talked to an eBay employee latelyâ¦ Asked why do you think eBay never embraced Skypeâ¦ He said that eBayâs attachment to keeping the conversation controlled so that they couldnât be cut out of the equation, so they made it harder

As market makers they are also getting a percentage of the transaction so they just put up barriers.

Buy in depends on âwhat their stake isâ if you think the transaction will go on outside their walled garden, they wonât buy in .

E.g. you can architect this so that an assigned, ephemeral URL can be a revenue opportunity for Twitter. The Tweet controls how long the thing stays nailed up. You can do it on Twitter or Identica or anywhere. You can set up a VRM like relationship. And thatâs what makes it interesting

Closingâ¦ align VRM with the core metrics of each of the service providers.

Events

2010-01-13T11:44:43Z

Killspam: Undo revision 4217 by Cryp18 (Talk)

==Future Events==

* [http://cyber.law.harvard.edu/projectvrm/VRM_East_Coast_Workshop_2009 VRM East Coast Workshop 2009], 12-13 October 2009 at Harvard Law School, Cambridge, MA.
* [http://cyber.law.harvard.edu/projectvrm/VRooM_Leadership_Workshop November 2009 Leadership Workshop], Location TBA
* [http://www.internetidentityworkshop.com/ Internet Identity Workshop 2009 (IIWIX, IIW)], 3-5 November 2009 at the Computer History Museum in Mountain View, CA.

==Past Events==

[[VRM West Coast Workshop 2009]]

[[VRMworkshop]] at Harvard Law School, July 2008

[[VRM Hacker Session]] November 9th 2007 London

[http://www.supernova2006.com/ Supernova] 20-22 June, 2007 San Francisco

[http://conferences.oreillynet.com/os2007/ OSCon] 23-27 July, Portland

[http://conference.digitalidworld.com/2007/ Digital ID World (DIDW)] 24-26 September 2007, San Francisco

[http://www.windley.com/events/iiw2007a/announcement Internet Identity Workshop (IIW)] May 14-15, 2007, Mountain View, CA

[https://events.projectliberty.org/details.php?id=11 Identity Open Space (IOS)], 26-27 April, 2007 Brussels

[[Notes from VRM & Public Media Workshop]] at the Berkman Center, April 4, 2007
* Includes follow-up brainstorming ideas from April 6, 2007

[http://cyber.law.harvard.edu/identity/Mobile_Identity_Workshop Mobile Identity Workshop], January 26, 2007

[[Notes from VRM Meeting]], January 25, 2007

[[Notes from Internet Identity Workshop 2006b]], December 4-6, 2006

Interesting Links

2010-01-13T11:44:15Z

Killspam: Undo revision 4218 by Cryp18 (Talk)

[http://cyber.law.harvard.edu/ The Berkman Center for Internet

Stephen Downes - Distributed Digital Rights Management
-- (The 'VRM' of this website is the 'Customer Broker' of the Downes presentations)
-- [http://www.slideshare.net/tag/ddrm Slide shows on DDRM]
-- [http://odrl.net/workshop2004/paper/odrl-downes-paper.pdf Distributed Digital Rights Management: The EduSource Approach to DRM] - presented at ODRL 1.0

Usage Committee

2010-01-13T11:43:50Z

Killspam: Undo revision 4220 by Cryp18 (Talk)

The objective of the Usage Committee is to
'''Drive VRM usage'''

This page will be the central point of organization for the committee.

== Committee members ==

*Adriana Lukas
*Chris Carfi (present and reporting for duty!)
*Deb Schultz
*Alan Mitchell
*Dean Landsman
*Sean Bohan
*Kaliya Hamlin
*Bart Stevens

== Approaches to driving VRM Usage ==

#industry/vendor driven
#web/user driven

Help:Contents

2010-01-13T11:43:46Z

Killspam: Undo revision 4221 by Cryp18 (Talk)

It's easy to start editing pages on this wiki! It is the job of every registered user to try and improve these pages. Wikis work best when everyone is involved and adding, editing, reworking, and checking the contents.

==== How Do I Start? ====
Log in (you must have a login to edit). Click on the "edit" tab at the top of any page. You will then begin editing the page you are on. There is a helpful [[Help:Cheatsheet|Cheatsheet]] to learn the basics of formatting your changes.

==== Can I Practice? ====
You bet. Try out editing on the [[Project_VRM:Sandbox|Sandbox]] Page. Anything goes there.

==== When Should I Jump In? ====
A Wiki benefits from the "[http://en.wikipedia.org/wiki/Wikipedia:Be_bold_in_updating_pages Be bold]" philosophy. If you see something that can be improved, do not hesitate to do it yourself. Improvements come from the iterative additions and edits of all of us. Pages keep a revision history, so nothing can't be undone (click on the "history" tab at the top of the page).

==== What Happens When There is Disagreement? ====
If someone disagrees with you, or you with them, then good! We've inspired involvement, and through edits and discussion on the [[Help_Talk:Contents|Talk Page]], consensus can be reached (each wiki page has its own respective talk page). Wikis work great for emerging concepts and themes like VRM that will benefit from exploration and the evolution of mutual agreement. Paradoxically, edits that introduce diversions from commonly-held understanding is what helps best build and spread editorial consensus.

==== When Should We Use the Talk Page? ====
Every wiki page has a talk page. Click on the "discussion" tab at the top of the page to get there. Whenever you have a question that's holding you back from an edit or when conversation seems more appropriate than document-building. Please sign your comments on the talk page with four tildes ("<nowiki>~~~~</nowiki>") which will automatically drop in your username and time stamp.

==== How Do I Keep Track of What's Going On? ====
There is a special page called "[[Special:Recentchanges|Recent Changes]]" that keeps a running list of all recent changes to the wiki. Think of this like a news feed of what's going on. Check out what other people are doing. Piggyback on their changes.

You can also watch pages by clicking on the "watch" tab at the top of a page. This adds the page to your personal [[Special:Watchlist|Watchlist]]. You can visit this page any time to see what changes have been made, by whom, and when. For example, you can add the [[VRM vision]] page to your watchlist by clicking [http://cyber.law.harvard.edu/projectvrm/watch/VRM_vision here]. There are all sorts of additional [[Special:Specialpages|Special Pages]] that are worth checking out.

==== Can I be Automatically Alerted Through Email? ====
You can receive email alerts when changes happen to watched pages by adjusting your [[Special:Preferences|Preferences]] page.

Process

2010-01-13T11:43:17Z

Killspam: Undo revision 4211 by Spekof2 (Talk)

This page is a draft proposal. Please send any comments to [mailto:joe@andrieu.net] or to the Project VRM [[mailing list]].

(On 19 May 2008, [http://www.mediainfluencer.net/2008/05/from-misapprehensions-to-alternatives/ Adriana Lukas suggested] that the process described here is "identity-based VRM", and should be distinguisted from "[http://docs.google.com/View?docid=df9dfsgj_1ghhqgjfq feeds-based VRM]". So, a note to selves: these should be distinguised in this wiki as well. - Doc)

==VRM Process==
One thing that Iâve been noodling lately is how we, as a community, can organize our efforts around VRM.

===Microformats Inspiration===
In a recent [http://bankwatch.wordpress.com/2007/01/05/microformats-as-information-brokers-revisited/ exchange] with [http://bankwatch.wordpress.com/about/ Colin Henderson] at [http://bankwatch.wordpress.com/ BankWatch], he asked about [http://microformats.org microformats] and VRM. I [http://blog.joeandrieu.com/2007/01/19/vrm-microformats/ replied] that I think there is a lot to learn from their efforts. In particular, microformats has a great ironclad process, established in the early days, that continues to serve as a corral and assembly line for new microformats proposal. It is the foundation for how they forge community consensus. Along with the principle of paving the cowpaths, the process severely cuts down on distracting hypothetical conversations and assures a wiki-documented evolution towards a community consensus. Many newbie questions have been productively answered by a link to the process page and a polite invitation to read it and start working their ideas through it.

===A Standard Process===
Establishing such a standard process could have a great positive influence on VRM, especially as Project VRM has the potential to become a clearinghouse for different approaches in different domains, each requiring independent investment, development, and consensus. For example, VRM solutions for vendor selection are likely different from those for Personal Health Records and those for Banking.

Early community norms about how we go from âA great ideaâ to something people can start implementing, would, I believe, help more ideas reach critical success more quickly, as people spend more time doing the work rather than debating hypothetical design points and process issues. A good process would also let people know how to contribute and assure that good ideas are fully fleshed out as they develop. Of course, concrete design issues, grounded in context, goals, and constraints, are good topics for conversation.

This actually dovetails, nicely I think, with Chrisâs [http://www.socialcustomer.com/2007/01/more_on_vendor_.html comments] earlier on putting the cart before the horse in VRM development. As he said so concisely:
<blockquote>
Before diving into creating a new technical spec, step outside and look around a bit.
</blockquote>

So, here is a strawman proposal for how we might, as a community, organize a process for developing VRM systems. The idea is that each of these steps helps elucidate the details of a problem that could be solved by VRM. Each step is itself straightforward, building upon the steps before hand, and once complete, moving to interoperable implementations should be fairly simple. *grin*

===Scenarios===
It turns out that Usage Scenarios could be an important part of this process, meaning Scenarios in the context of Use Cases and user-driven development. Chris Carfi has started an excellent thread about future [[VRM Scenarios]], using a subtly different meaning of the word. Iâll generally stick with Usage Scenarios to clarify my use.

Usage Scenarios are, for me, a simple, short, narrative description of one or more specific and detailed interactions with the current or proposed system. The idea is to keep it real, to keep it colloquial, and to capture the essence of the situation rather than a detailed list of all possible variants. In my projects, Usage Scenarios have proven to be a great bridge between the problem domain and a technical specification. And when kept to just a paragraph or so, they are easy to write, too.

==='''''Protocol''''' as VRM Output===
In writing this, it became clear that we might benefit from having a specific noun for describing the output of our work. Microformats produces microformats. Pretty straight forward. What does VRM produce? Perhaps '''''Protocol''''' would be appropriate:

* To develop a new VRM Protocol, one would shephard it through the VRM process on the Project VRM wiki.
* To implement a component of, or software that connects with, a VRM Protocol, one would implement the interfaces and protocols of that Interchange.
* The VRM Loan Protocol currently supports mortgage applications.
* The VRM pRFP Protocol allows for the secure, identity-controlled digital requests-for-proposals in an open marketspace.

Protocal seems to work. However, I would definitely appreciate feedback and alternative suggestions for such a term.

==Draft VRM Process==
The proposed process follows. The idea is that each section would have its own wiki page, preceeded by the name of the Interchange. Eg. http://projectvrm.org/Interchanges/pRFP/Domain and http://projectvrm.org/Interchanges/pRFP/Current_usage_scenarios

#'''Problem Domain''' A discussion of the problem domain, in the nature of a real-world problem that is containable, i.e., a specific solvable problem. This becomes the charter for this particular Interchange.
#'''Current Scenarios''' Brief prose descriptions of actual instances of the problem.
#'''Desired Scenarios''' Brief prose descriptions about how it might all be made better.
#'''Existing Efforts''' A review of what has already been done in this area and who (organizationally) is still working on this problem. This will serve both to incorporate existing efforts and to learn from past mistakes.
##'''Software'''
##'''Protocols'''
##'''Formats'''
##'''Initiatives'''
##'''Organizations'''
#'''Users''' A quick run down of who the system must support at various different levels. This should list both categories of users and some specific examples in each category. There may be many subcategories under each of the following major categories. The idea here is not to build the system to be perfect for each of these users, but to make sure we have all the stakeholders in context as we flesh out the design. Ultimately just a handful of target users will be the focus.
##'''End users'''
##'''Vendor users'''
##'''Supporting Users'''(retailers? regulators?)
##'''Implementors'''
#'''Use Cases''' These are specific, complete transactions between users and the system. All critical use cases should be listed, along with various incidental or support cases that could influence overall design. Ultimately, a handful of defining use cases will drive system design.
##'''Abstract, High-Level Use Cases''' Single sentences describing a use case. When done well, they become the name of the use case. For an ATM, you might have âWithdraw Cashâ or âTransfer Fundsâ as abstract high-level use cases.
##'''Concrete Detailed Use Cases''' Detailed use cases describe the chronological back & forth (action/reaction) between users and the system to realize a particular transaction. Concrete use cases are free to use specific design and implementation choices. This is useful either at the very beginning when transcribing scenarios (when the specifics help you understand what is actually happening) and at the very end (when the specifics represent design decisions).
##'''Abstract, Detailed Use Cases''' Abstract use cases are stripped of the design decisions to more completely and accurately describe the critical steps while also freeing up the design process to innovate. For example, a concrete use case for the ATM might include the concrete steps of inserting a bankcard, prompting for a PIN, entering pin on keypad, and verifying PIN. And abstract version of that same use case could be âidentify user, authenticate user.â Itâs easy to see how the abstract version allows for alternative implementations where the first one presumed a bankcard, keypad and PIN.
#'''Brainstorming''' Free-form inspirations and ideas about how to realize one or more of those use cases.
#'''Draft''' After some brainstorming, a basic system design will emerge, either meeting all the use cases or accepting the loss of some use cases as part of the design choices in the draft.
##'''Entities'''
##'''Communications'''
###'''Protocols'''
###'''Formats'''
###'''Transactions'''
#'''Proposal''' Once the draft is bandied about and improved on by the community, the group who has taken stewardship of the domain can propose it to the entire VRM community as a standard VRM Interchange. This would expose it to more feedback and improvements and engage the entire VRM universe in the final stages of development.
#'''Published Standard''' After the community as a whole has had a chance to contribute, the Interchange would eventually either be approved and published as a standard or disbanded. I donât see any reason for a specific timeframe for any of these steps in the process, but there may be efforts that get proposed that ultimately are better served by other means or by breaking them into smaller Interchanges. It is at the publication stage that a standard becomes âofficialâ and earns a version number. Amendments or revisions to the standard would go through some related process and be published with a later version.
#'''Reference Implementation''' Create a reference implementation of the standard, to provide a sandbox against which implementers can test their implementations, and to provide a baseline for interoperability.
#'''Implementation Directory''' The standard is added to a directory of the different people and/or services who claim support for the standard. (This could also include external points-of-view/reviews of how well that person/service supported the standard.)

Feedback is definitely welcome.
[[User:Joe.andrieu|Joe.andrieu]] 09:28, 23 January 2007 (EST)

Main Page

2010-01-13T11:41:55Z

Killspam: Undo revision 4215 by Cryp18 (Talk)

== About VRM ==

VRM, or Vendor Relationship Management, is the reciprocal of CRM or [http://en.wikipedia.org/wiki/Customer_Relationship_Management Customer Relationship Management]. It provides customers with tools for engaging with vendors in ways that work for both parties.

CRM systems for the duration have borne the full burden of relating with customers. VRM will provide customers with the means to bear some of that weight, and to help make markets work for ''both'' vendors and customers  in ways that don't require the former to "lock in" the latter.

The goal of VRM is to improve the relationship between Demand and Supply by providing new and better ways for the former to relate to the latter. In a larger sense, VRM immodestly intends to improve markets and their mechanisms by equipping customers to be independent leaders and not just captive followers in their relationships with vendors and other parties on the supply side of the marketplace.

For VRM to work, vendors must have reason to value it, and customers must have reasons to invest the necessary time, effort and attention to making it work. Providing those reasons to both sides is the primary challenge for VRM.

== Project VRM ==

[http://projectvrm.org Project VRM] is a community-driven effort, led by [http://cyber.law.harvard.edu The Berkman Center for Internet and Society] at Harvard University, to support the creation and building of VRM tools. ProjectVRM carries forward thinking by various parties around the world. These include ideas brought up by Doc Searls and his fellow [http://cluetrain.com Cluetrain Manifesto] authors, work of the [http://www.rightsideup.net/ Buyer Centric Commerce Forum] and other allied efforts in the U.K., and many sessions at Internet Identity Workshops.

ProjectVRM is headed by [http://cyber.law.harvard.edu/people/dsearls Doc Searls], a fellow with the Berkman Center.

In addition to this wiki, ProjectVRM has [http://blogs.law.harvard.edu/vrm a blog] and a [http://cyber.law.harvard.edu/projectvrm/Mailing_list mailing list].

Read more about ProjectVRM on the [[About | About Page]].

== VRM Principles ==

#Relationships are voluntary.
#Customers are born free and independent of vendors.
#Customers control their own data. They can share data selectively and control the terms of its use.
#Customers are points of integration and origination for their own data.
#Customers can assert their own terms of engagement and service.
#Customers are free to express their demands and intentions outside any companyâs control.

These can all be summed up in the statement ''Free customers are more valuable than captive ones''.

In a broader way, the same should be true of individuals relating to organizations. With VRM, however, our primary focus is on customer relationships with vendors, or sellers.

== VRM Goals ==

#Define and advocate a clear vision for a VRM world
#Ensure the development and publishing of open standards and specifications for VRM services
#Create a lightweight and effective organisational structure
#Drive VRM usage
#Create and oversee VRM compliance program

== VRM Current Topics ==

This is a catch-all where we can point both to ongoing conversations and current development work. These include (but are hardly limited to)...

*[[Media Logging]]
*[[Listen Log]] (the general topic) and [[ListenLog]] (the development project0
*[[PayChoice]]
*[[Personal RFP]]
*[[FCRA: Access to credit data]]

== VRM Committees ==

*[[Vision Committee]]
*[[Marketing Committee]]
*[[Standards Committee]]
*[[Organization Committee]]
*[[Usage Committee]]
*[[Compliance Committee]]

== Allied Efforts ==

*[[The Mine! Project]]
*[http://mydex.org/ MyDex]
*[http://www.vrmhub.net VRM Hub]
*[http://www.vrmlabs.net VRM Labs]
*[http://publicradiotuner.org Public Radio Tuner]
*[http://www.switchbook.com/ SwitchBook]

== Resources ==

* ProjectVRM [[mailing list]]

* ProjectVRM [http://blogs.law.harvard.edu/vrm blog]

* [[VRM FAQ]]

* VRM [Twitter stream http://twitter.com/vrm]

* Project VRM [[committees]]

* VRM and -related [[events]]

* VRM [[Initiatives]]

* VRM [[Principles]]

* VRM [[Process]]

* VRM [[scenarios]]

* VRM [[technology]]

* VRM coverage in [[blogs]]

* VRM discussion in [[VRM discussion in podcasts | podcasts]]

* [[Questions raised]] by VRM

* [[VRMcompanies]]  A list of VRM or VRMlike comnpanies

* [[Expressions of Relationships]] (notes from VRM meeting)

* [[Random Notes from Jan 25th VRM Developers Meeting]] (stream of consciousness / ears and brain to fingertips and keyboard)

* [[Website planning]]

* Other [[related efforts]]

Conference Call archive and audio links have been moved to the [[Project_VRM:Community_Portal | Community Portal]] page.

== VRM Events ==

[[VRooM Leadership Workshop]] took place on 31 Oct * 1 Nov in Mountain View, CA

[[VRooM Boston 2009]] took place on 12-13 October 2009

[http://vrmhub.pbwiki.com/ VRM Hub] Monthly Meetings in London

[[VRM2008]] took place in Munich on 21/22 April 2008

[[VRM Workshop 2008]] took place in July 2008 at Harvard University

[[VRM at SXSW 2009]] March 2009, Austin, TX

[[VRM West Coast Workshop 2009]] May 15-16, Palo Alto, CA

[[VRM East Coast Workshop 2009]] 12-13 October at Harvard University

== Join Us! ==

Looking to contribute to the Project VRM Wiki? Sign up for the [http://cyber.law.harvard.edu/lists/info/projectvrm Project VRM mailing list], send an email to the owners, and we'll get you up and running!

Main Page

2010-01-13T11:41:42Z

Killspam: Undo revision 4227 by Andromeda (Talk)