Andrew Bogusky‘s New Conscious Consumer Bill of Rights post just came to my attention, thanks to this tweet by @jamiedsmith, who adds “Needs more symmetry of power for consumers though”. All due respect to Andrew’s efforts (and he deserves much), I think the only way to get symmetry of power for consumers is by turning them into full-power customers—with their own tools. That’s what we’ve been working on in the VRM development community.
Several years ago I put up a list of ten principles of VRM. That was before we had most of the tools in development today. So now I’d like to post instead a list of characteristics that define VRM tools. As usual, these are provisional:
- VRM tools are personal. As with hammers, wallets and mobile phones, people use them as individuals,. They are social only in secondary ways.
- VRM tools help customers express intent. These include preferences, policies, terms and means of engagement, permissions, requests and anything else that’s possible in a free market (i.e. the open marketplace surrounding any one vendor’s silo or walled garden for “managing” captive customers).
- VRM tools help customers engage. This can be with each other, or with any organization, including (and especially) its CRM system.
- VRM tools help customers manage. This includes both their own data and systems and their relationships with other entities, and their systems.
- VRM tools are substitutable. This means no vendor of VRM tools can lock users in.
So, tell me how to improve the list, or suggest a better one.
VRM should facilitate the work of 4th Party Agents where a customer determines she needs one.
This is a great list, but I have doubts about #5.
Throughout the history of software, I can’t think of a single example of compatable software where any one piece of software was ever substitutable for another piece of software without losing a lot of data (or meta-data) or, in the best case, without requiring significant manual porting effort. Even with the best intentions of the vendor e.g. various open-source projects.
How would that look like?
How about email? What matters there are POP3, IMAP and SMTP. On the receiving end, mbox (which isn’t perfect, but works) Thanks to those I could move mail from one client and/or server to another without a lot of hassle. (But yes, with significant manual porting effort.)
But I get your point. Mine is about lock-in. There’s a letter and a spirit to a rule that’s hard to define here. What would both be?
Perhaps standard data formats specific to the class of the tool?
I suppose text editors (almost) fit the category … (not rich text or “Office”) .. as long as the character encoding is set…
Either way — #5 is a differentiator that empowers the VRM user, and lets a specific product/project/software stand on the merits of its own feature, not vendor-lockin.
VRM Tools must be neutral : they should never be involved in the transaction or service they allow nor should never influence the consumer ?
It works for non-formatted text files most of the time (overlooking \n vs \r which in the aggregate must have cost many millions of dollars over the years) but that’s about as good as we can do so far. (Think Microsoft attachments in e-mail)
But Doc’s question in the comment is a good one about a rule.
What about the freedom to fork? Not just code, but also the policies (e.g. data sharing, which ads I have to suffer through) that go with it?
Doc… What about volly (www.volly.com : digital mail box by Pitney Bowes)? Could services such as volly be one of the main (or fundamental) VRM tools allowing customer’s data first aggregation ?
Didier,
Looks to me like Volly is one more way that vendors can control their interactions with many customers, but not a way for customers to control their interactions with many vendors.
Unless I’m missing something.
Not saying it won’t be useful to users. Just that it’s not sold that way.
If it works as a way for a customer to pull in, say, collected data from vendors, then maybe it’s a useful tool in the VRM sense. But, as a user, I don’t want to have many different ways of doing the same thing. That would be like email was before SMTP, POP3 and IMAP were widely used. I had to use many different mail systems, none of which talked to each other.
Johannes, I like the freedom to fork. In fact, I think a lot of FOSS (free and open source software) conventions should apply more generally.
For example, see Crosbie Fitch’s license in the box at the bottom of this page: http://digitalproductions.co.uk/index.php?id=69. Very GPL/copyleft, that.