Building an Relationship Economy
Is there something new that open source development methods and values can bring to the economy? How about something old?
I think the answer may come from the developing world, where pre-industrial methods and values persist and offer some helpful models and lessons for a networked world that's less post-industrial than industrial in a new and less impersonal way.
This began to become apparent to me a few years ago I had a Socratic exchange with a Nigerian pastor named Sayo, whom I was lucky to find sitting next to me on a long airplane trip. We were both on speaking junkets. He was coming from an event related to his latest work: translating the Bible to Yoruba, one of the eight languages he spoke. I was on my way to give a talk about The Cluetrain Manifesto, a book I co-authored.
My main contribution to Cluetrain was a chapter called "Markets are conversations". Sayo asked me what we meant by that. After hearing my answer, he acknowledged that our observations were astute, but also incomplete. Something more was going on in markets than just transactions and conversations, he said. What was it?
I said I didn't know. Here is the dialogue that followed, as close to verbatim as I can recall it...
"Pretend this is a garment", Sayo said, picking up one of those blue airplane pillows. "Let's say you see it for sale in a public market in my country, and you are interested in buying it. What is your first question to the seller?"
"What does it cost?" I said.
"Yes", he answered. "You would ask that. Let's say he says, 'Fifty dollars'. What happens next?"
"If I want the garment, I bargain with him until we reach an agreeable price."
"Good. Now let's say you know something about textiles. And the two of you get into a long conversation where both of you learn much from each other. You learn about the origin of the garment, the yarn used, the dyes, the name of the artist, and so on. He learns about how fabric is made in your country, how distribution works, and so on. In the course of this you get to know each other. What happens to the price?"
"Maybe I want to pay him more and he wants to charge me less".
"Yes. And why is that?"
"I'm not sure."
"You now have a relationship".
He went on to point out that, in his country, and in much of what we call the developing world, relationship is of paramount importance in public markets. Transaction still matters, of course. So does conversation. But the biggest wedge in the social pie of the public marketplace is relationship. Prices less set than found, and the context for finding prices is both conversation and relationship. In many cases, relationship is the primary concern, not price. The bottom line is not everything.
Transaction rules the Industrialized world. Here prices are set by those who control the manufacturing, distribution and retail systems. Customers do have an influence on prices, but only in the form of aggregate demand. The rates at which they buy or don't buy something determines what price the "market" will bear in a system where "market" means aggregated demand, manifested in prices paid and quantities sold. Here the whole economic system is viewed mostly through the prism of price, which is seen as the outcome of tug between supply and demand.
Price still matters in the developing world, Sayo said, but relationship matters more. It's a higher context with a higher set of values, many of which are trivialized or made invisible when viewed through the prism of price. Relationship is not reducible to price, even though it may influence price. Families and friends don't put prices on their relationships. (At least not consciously, and only at the risk of cheapening or losing a relationship.) Love, the most giving force in any relationship, is not about exchanging. It is not fungible. You don't expect a payback or a rate of return on the love you give your child, your wife or husband, your friends.
Even in the industrialized world, relationship has an enormous bearing on the way markets work, Sayo said. But it is poorly understood in the developed world, where so much "comes down to the bottom line".
I shared this conversation a few weeks later with Eric S. Raymond, who put the matter even more simply. "All markets work at three levels", he said. "Transactions, conversations and relationships". Eric is an atheist. Sayo is a Christian. With those two triangulating so similarly on the same subject, I began to figure there was something more to this relationship business.
I began to ask questions. For example, What happens when you view markets through the prism of relationship? Why do we write free or open source code?
Linus says (in the title of his only book) he does it "Just for Fun". Yes, there are practical purposes there have to be. Scratching itches, for example. Development communities are notoriously long on conversation (check out the LKML for starters), and on relationship as well. Not a whole lot of transaction there, either, since the code is free. Next question: Are there economies involved?
I think the answer is yes, and they are concentrated on the manufacturing end. We make useful code for its "because effects". Thanks to Linux, much money will be made; but because of it, far more than with it. Just look at Google and Amazon as two obvious examples. Perhaps a billion of the world's Websites are Apache on Linux.
Relationship is involved here, too. Writing code that serves as abundant and free building material is an act of generosity. Dare we say we do it for love? Certainly a lot of us love doing it.
Likewise with performing artists. Musicians don't take up an instrument and develop their skills just to make money at it. They do it for love of the experience, of playing together with other musicians, of giving something to an audience, and to the world.
Of course, professionals like to get paid for their work too. That's what makes them professionals.
What if the goods are essentially free (as in beer, air or love)? That's the case with code, music, art, and anything else that can be digitized and copied. Many artists want or need to be paid for what they do. The question is how we get our love to fund theirs -- how we can relate in ways that work financially for both the supply and the demand of essentially free stuff.
The entertainment industry has had an answer ever since the Net showed up. Hollywood wasn't blind to the Net. Quite the opposite. They correctly saw the Net as a way for every device to be zero distance from every other device -- and to pass identical copies of anything between anybody a cost that rounded to zero. They saw this a threat to their incumbent business model. So they came up with a way to deal with that threat: DRM, or Digital Rights Management. DRM worked by crippling recorded goods so it can't easily be copied except by those whose rights were managed by suppliers.
It hasn't worked. A few days ago Steve Jobs said so himself, in a landmark essay titled Thoughs on Music, published on February 6. It not only notes the failure of DRM, but subtly recruits customers and fellow technologists to help Apple convince the record industry that it's best to sell music that isn't DRM'd. He concludes, "Convincing them to license their music to Apple and others DRM-free will create a truly interoperable music marketplace. Apple will embrace this wholeheartedly".
The operative verb here is "license".
Let's ignore the record companies for a minute. Instead, lets look behind them, back up the supply chain, to the first sources of music: the artists. Part of the system we need is already built for these sources, through Creative Commons. By this system, creative sources can choose licenses that specify the freedoms carried by their work, and also specify what can and cannot be done with that work. These licenses are readable by machines as well as by lawyers. That's a great start on the supply side.
Now let's look at the same work from the demand side. What can we do -- as music lovers, or as customers -- to find, use, and even pay for, licensed work? Some mechanisms are there, but nothing yet that is entirely in our control -- that reciprocates and engages on the demand side what Creative Commons provides on the supply side.
Yes, we can go to websites, subscribe to music services, use iTunes or other supply-controlled intermediating systems and deal with artists inside those systems. But there still isn't anything that allows us to deal directly, on our own terms, with artists and their intermediaries. Put another way, we don't yet have the personal means for establishing relationships with artists.
For example, I relate in some ways to Stewart Copeland, though he doesn't know it. Stewart is best known as the drummer in The Police, even though the band hasn't recorded an album since 1983 and Stewart has since then established himself as a first-rank composer of soundtracks, including "Rumble Fish", "Talk Radio" and "Wall Street". IMDb lists him as a composer of scores for sixty-nine movies and TV productions. You have to hit "page down" six times or more to get to the bottom of the listings. Still, much as I appreciate Stewart's compositions, I've always loved his drumming. I'm not a drummer, but I'm a serviceable percussionist. (When I pick up bongos, congas, a rub-board or a tambourine, I get approving nods from the real musicians I jam with -- as rarely as the occasion arises.) When the Police ceased touring and producing albums, I missed Stewart's drumming most of all.
Last year I got a big charge out of hearing an IT Conversations podcast interview with Stewart, though I was disappointed to hear he doesn't drum much anymore.
Then I heard last week on the radio that the Police may be getting back together and touring again. I can relate to that. But how? Stewart's website is one of those over-produced flash-filled things that recording an performing artists seem to think they need in order to "deliver an experience" or whatever. Nearly every internal link leads to a link-proof something-or-other in the same window, among other annoyances. To call it relationship-proof would be an inderstatement.
So instead let's look at relating through the IT Conversations podcast. I say that because yesterday Phil Windley, who runs IT Conversations, posted Funding Public Radio (and ITC) with VRM on his blog, and listed some of the things he might be looking for from VRM or Vendor Relationship Management. That is, from something that lives on the demand side, but can relate on mutually useful terms with the sjupply side which in his case is IT Conversations.
Here's the first answer: It can't be limited to a browser. I want a button, or a something, on my MP3 player that allows me to relate not only to IT Conversations as an intermediary, but to the artist as well -- if the artist is interested. They may not be. But I want that function supported. What we need on the user's side is a tool, or a set of tools, that support both independence and engagement.
If what we're looking for doesn't exist, how hard will it be to build? I'm sure it won't be easy, but it will be less hard than it was before the roster of open source tools and applications grew to six figures, which is where it stands now. And that's not counting all the useful standards that are laying around too.
What do we need?
First, I think we need protocols. These should be modeled on the social ones we find in free and open marketplaces. They should work like the ones Sayo talked about in his Socratic dialogue with me on the airplane. They should be simple, useful and secure.
Second, we need ways of supporting transactions. This is a tough one, because to work they need to be low-friction. I should be able to pay IT Conversations (or any public radio station, or any podcaster) as easily as I pay for a coffee. Or better yet, as easily as I tip a barista. So PayPal won't cut it. (Not the way I've experienced PayPal, anyway.)
Third, we need ways of selectively and securely asserting our identities, including our choice to remain anonymous. This means getting past sign-on hurdles on the Web, and past membership silos out in the physical world (such as the ones that require a special card, or whatever). Again, the friction should be as low as possible.
Fourth, we need ways of expressing demand that will bring supply to us. Let's say I want to hear other interviews with Stewart Copeland. I don't want to go through the standard Google/Yahoo text search. I want to tell the marketplace (in some cases without revealing yet exactly who I am) that I'm looking for these interviews, and then have them find me. Then I want an easy way to pay for them if I feel like it. As Sayo suggests, I might be more willing to pay something if I can relate to the source, and not just invisibly use goods produced by that source.
In Putting the Wholes Together, which I posted recently at Linux Journal, I said public broadcasting would be a good place to start -- not just because public broadcasting needs to find ways to make more money from more listeners and viewers, but because payment is voluntary. Seems to me that when payment is voluntary, relationship will drive up the percentage of those who pay. It's just a theory, but one that should be fun to test.
Soon as I get the time to put it together, I'll put out a challenge for developers (that's you, if you write code) to help out on this. Some developers are already collected at ProjectVRM, which is where we're organizing the effort.
I'm meeting with NPR in Washington, D.C. in a couple hours, and again tomorrow. I'll bring up the possibility of help from you guys when I talk to them. And I'll be in many meetings and talks next week at the IMA Convention in Boston and Beyond Broadcast in Cambridge. Help is welcome.
Let's show these folks how much more they can do because they relate. Let's obsolete those annoying fund-raising marathons when they shut off programming, plead poverty and give you some schwag if you send money. There has to be a better way. Let's build it.
Doc Searls is Senior Editor of Linux Journal
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- Interview with Patrick Volkerding
- Tips for Optimizing Linux Memory Usage
- What's GNU
- Secure Logging Over a Network
- Apache 2.0: The Internals of the New, Improved
- User-Mode Linux
- Getting Started with mod_security
- Using C for CGI Programming
- FSlint: annoyingly vague, but useful
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide