I think we can get some clarity about VRM — and growth of customer power in the marketplace — by re-positioning what we’ve been calling “parties.”
Among numbered parties the best-known one today is the third party. Wikipedia currently defines a third party this way (at least for the computer industry):
- Third-party developer, hardware or software developer not directly tied to the primary product that a consumer is using
- Third-party software component, reusable software component developed to be either freely distributed or sold by an entity other than the original vendor of the development platform
In general, a third party works on the vendor’s side of the marketplace. However, the vendor is not generally called the “first party” (except in the game business, as Wikipedia says here). In fact, the most common use of the term “first party” in business is with insurance, where the term refers to the insured. (The insurer is the second party.)
So I see this as an opportunity. Let’s give numbers to parties involved in customer relationships, starting with the customer. In the process we can unpack some distinctions between categories of work within the VRM development community.
The first party is the customer:
The second party is the vendor:
The third party is vendor-driven, and on the vendor’s side:
The fourth party is customer-driven, and on the customer’s side:
Together, they look like this:
Here’s how the r-button might represent both sides of the marketplace, and how those sides are attracted to each other:
There are lots of ways one can look at this.
For example, on the left half is VRM, on the right half is CRM.
VRM is about enabling the first party. It is also about building fourth-party user-driven (and within that, customer-driven) services, which make use of first-party enablement.
We can also substitute user for customer, and organization for vendor, since the scope of VRM far exceeds the vendor-customer relationship continuum. Thus fourth parties are user-driven and not just customer-driven. The picture here would look like this:
Fourth parties will provide many services for first parties. In fact, VRM should grow large new fourth party businesses, and give new work to large old businesses in the same categories. (Banks, brokers and insurance companies come to mind.) Native enablements, however, need to live with first parties alone, even if fourth parties provide hosting services for those enablements.
Fourth parties also need to be substitutable. They need service portability, just as the customer needs data portability between fourth (and other) party services. That way whatever they can provide can be swapped out by the user, if need be.
A good example of how this works is email. Before the Net took off in the mid-’90s, there were many email services. Customer choice was between silos:
None of the email companies could crack the interoperability problem. That had to come from the user’s side, by way of geeks who defined email via protocols that saw workstations as the units that mattered. While servers were involved, they could also live anywhere. Both SMTP (which appeared first in RFC 821) and POP (which first appeared in RFC 918) were born in the early 1980s, out of the need for workstations to communicate with each other.
What matters for our purposes is that email enables individuals to do two things that are VRM hallmarks: 1) be independent of other entities (including both providers and vendors), and 2) be better able to engage with those entities.
Even to this day, anybody can host a mail server — or even a Web server — on their own device. Yet there are big businesses in hosting email, and most users opt to host their email on those services out in various clouds. So, just as mail and Web servers and services are Net-native, so should VRM enablements be Net-native.
Silo mentality is mostly gone from Net-native businesses. But it’s still going strong in lots of brick & mortar business categories. For example, the hotel business. Right now that business still looks like your-choice-of-silo:
With the customer in charge, it should look more like this:
Here’s how all four parties fit together:
For travel, third parties include Orbitz, Travelocity and other intermediaries operating mostly on the vendor side of the marketplace. They wouldn’t have to stay there, of course. They could become instruments of customers as well. There can be blurring between third and fourth parties.
But, as customers get more power, fourth parties are bound to flourish — and not just because they’re located on the side of the customer and his or her money. Fourth parties will flourish because they will help more intelligence flow into the marketplace, and help the customer both manage and apply that intelligence.
Fourth party business will bloom for every company that wishes to be user-driven and customer-driven. This will include countless new companies, of course. But there will also be fresh work for existing companies that already side with the individual in some way. This group includes banks, real estate agents, travel agents, insurance companies… any business that wants to side with free customers, because they know in their bones that free customers are more valuable than captive ones.
Even traditionally locked-down monopolies, such as phone and cable companies, are in good positions to provide, or help provide, fourth party services — simply because these companies already have relationships with millions of customers. (Not to mention old and in some cases dying core businesses.)
What will keep fourth parties from turning on customers, and becoming essentially third parties for the big silo-maintaining vendors — in other words, wolves in sheeps’ clothing?
The only answer is native individual power. This is why it is critical to provide individuals with tools that enable their independence. A tool such as PayChoice‘s “pricing gun” cannot be something provided by only one company. It has to belong to nobody and therefore to everybody, just like the existing suite of native Internet protocols. In fact, these native capabilities should enlarge the roster of protocols and other enablements that comprise the Internet’s suite of benefits for everybody.
Kinds of work
There will be many new development projects and organizations involved in making VRM happen. Some are already underway and have moved far downstream. In the course of this, there is a need to distinguish types and scopes of development efforts, and types and scopes of organizations.
I want to leave the latter open for now, and concentrate just on development work. Here the challenge is reconciling closed and open source work — and to help migrate some of the former into the latter.
There are now perhaps a million or more open source code bases in the world. Most are small. Some, such as Linux, Apache, MySQL, Perl and Python, are large and familiar. Nearly all are not run by companies, or even by .orgs. The programmers who contribute to the code base are inherently independent, even if they work for a company with an interest in the project. Such is the case with the many Linux kernel programmers who work for IBM, Red Hat and Oracle. It’s also true of Monty Widenius and David Axmark, who founded MySQL and came with it to Sun.
Open source code essentially belongs — in the sense that somebody has control over it — to the individual developers who contribute to it. The closest expression to ownership is usually the license. Developers on a free software or open source project like to pick a license and move forward without any further concern about legalities, including issues of ownership. “Intellectual property” is anathema to them. The only form of intellectual property that interests them much is copyright — which is why the free software folks invented copyleft, which carries forward with open source as well.
Both free and open source software possesses qualities we call NEA: Nobody owns it, Everybody can use it, and Anybody can improve it. These qualities make that code generative: that is, maximally supportive of the largest variety of uses. In his book The Future of the Internet — and How To Stop It, Jonathan Zittrain shows how generative code and standards work by locating them at the waist of an hourglass with many possibilities both below and above:
While all code is in some ways owned, it is controlled by those who write it. These include contributors, committers and maintainers. Some projects use just one or two of those terms. A good example of one using all three is here. Some small projects just use one term or none at all. Practice varies widely It is always understood, however, that somebody, or some small group of people, decide which code gets added to the base. The Mine! Project is one open source effort within VRM. ListenLog will be another. There will be many more.
What matters for VRM purposes is that free software and open source projects are inherently independent. Even if a company hires programmers to write code, both the code and its authors will be independent of those paying for it. This means the employed programmers, or anybody, can work on the code, and do whatever they want with it — provided it passes muster with the maintainers (or whoever decides what code gets into the base).
Closed source code for which there are no open source ambitions will play roles in many fourth party services and applications. Where we face challenges with VRM is with closed source code that does have open source ambitions. If we want to open closed source code, how do we do it? Craig Burton uses this illustration in his discussions of various options:
These options are faced where companies already have code under intellectual property burdens, and where code development is already far downstream and decisions about what to release and where to put it (such as in code repositories, with choices about versioning, etc.) impact administrative as well as developmental overhead. There are existing organizations that can help with this kind of thing. Work has already begun on our own as well.
A Personal Note
While I’m not a developer (the only code I know is Morse), I’ve been covering open source development for the better part of two decades, and have been working toward VRM for most of my adult life. I’m 61 years old, and most benefits of VRM won’t appear until after I’m gone. So I take a long view, even though I am as impatient as anybody to make things happen soon.
What I want for VRM is maximal enablement of first parties, and maximum business for the other three parties — especially the fourth parties that will grow on top of the enormous because effects of first parties in the world.
Because effects are positive externalities of public goods that support boundless economic activity. Think of them as private benefits of public goods. The Internet Protocol, for example, is a public good. While nobody makes money with the Internet Protocol, the whole world can make money because of it.
We want the same kind of leverage from first-party enablement of VRM. None of us will make much, if any, money with the native enablements of customers, and users, in the marketplace. (Though we will save much money and hassle.) Perhaps $trillions will be made because of those enablements.
In respect to what happens with first and fourth parties, I locate my interests primarily with the individual, and with enabling the individual. For that reason I look for minimal organizational restrictions on how that happens. I just want to see as much open source development as we can possibly bring in. This also means I welcome all kinds of organizational activity outside the VRM “kernel,” in the fourth party space. In fact I think we need that very much, and have for a long time.
My perspective here is something like that of Linus Torvalds, who makes a point of only caring about kernel development, and not about what’s done with the kernel. When asked about what happens outside the kernel, Linus often says, “That’s user space. I don’t care about user space.” (The distinction is explained at that last link.) The scope of my interests, however, is much larger. I do care about what happens outside the individual’s “kernel space.” I especially want to see business grow in the fourth party space, which to me is analogous to Linux’s “user space.”
But I don’t have the time or the inclination to care about everything. I need to focus. And what I want to focus on is enabling individuals, and getting enormous because effects out of that. So I rely on others to do the organizing outside of the individual’s “kernel space.” This does not involve giving up power on my part, but locating power outside my own immediate interest area, out where others are more interested and competent than I am.
In respect to those, I see my main job as helping make clear where “kernel space” ends and “user space” begins. Hence this draft. Hope it makes sense to all of you.
Bonus Links: Making a New World — my chapter in O’Reilly’s Open Sources 2.0; and Net Worth, the 1999 book by John Hagel and Marc Singer that introduced the infomediary concept (a fourth party, basically), way ahead of its time.
And special thanks to Hugh McLeod for the fun images used here.