A Public Market for Public Music
On the one hand, it's a bummer that the new per-song/per-listener royalty rates threaten to put Internet radio out of business. On the other hand, I don't mind paying Radio Paradise $.0019 (that's under 2/10ths of one cent) to hear Joseph Arthur singing "In the Sun" or to pay the same to RadioKAOS for Jo Jo Gunne singing "Run Run Run". (To name two songs I like that are being played right now.) I can afford that. I also like the idea of paying artists and their friends for their work but not on coercive terms over which I have no control.
Right now there are only two ways of doing that. One is the advertising based commercial radio model. The other is the donation-based public radio model. The first doesn't involve me at all. The second only barely involves me, and then only as a "member" of a station.
So I have a proposal. Let's turn this thing around. Take it from the point of view of a listener who wouldn't mind using the radio station as an intermediary for paying artists on a voluntary basis. Give radio's consumers an easy way to become customers with tools that let them pay on a voluntary, a la carte basis for stuff that's available for free but is worth more than that. Let's create a new and truly open market for music that's led by listeners rather than followed by them. Let's solve common problems in ways that work for everybody because they're conceived as common opportunities.
We can do that by taking the "willing seller/willing buyer" concept out of the abstact and making it concrete. That concept was laid out in 17 U.S.C. 112(e)(4), which says "The Copyright Royalty Judges shall establish rates that most clearly represent the fees that would have been negotiated in the marketplace between a willing buyer and a willing seller." Apparently nobody involved in any of these lawmaking and regulatory proceedings has imagined a marketplace where listeners can be customers, equipped not only to express demand but to pay for the goods.
This a challenge I'd like to see VRM (Vendor Relationship Management) developers take up. I'd like to make it ambitious too. Let's take it beyond streaming alone. Let's make VRM tools that let us pay voluntarily (without coercion) for all sources and all forms of programming including radio programs, streams, downloaded files and contents of files. (The latter would apply to multiple songs found in programs such as Tony Steidler-Dennison's Roadhouse Podcasts.)
It's significant that the Copyright Royalty Board decided to make commercial and noncommercial stations pay the same royalty rates, ending "carve-outs" for CPB-funded stations (which enjoyed special treatment under a now-obsolete agreement with SoundExchange the RIAA's collection agency). Also that the decision ended special treatment for small webcasters. Now everybody offering valuable free goods is in the same situation, and therefore on the same team. Dark cloud, silver lining.
I'm wondering about a project name and description. Right now I like Project Pay4Play, or p4p. With p4p tools, I should be able to say "I'll pay for that" when I hear a song or a program I like. I want to be able to do this with any podcast or stream that I hear on my browser, my mobile phone, my PDA, my iPod, my iTunes even my car radio.
As it turns out, p4p already has a meaning that's so close to what we're talking about here that I'd like to hijack it for its own good: "pay for performance". As Wikipedia currently puts it,
P4P is an abbreviation of the term "Pay for Performance". The concept was invented at Overture (now Yahoo! Search Marketing) and later adopted by their competitors, most famously Google's AdWords. Under the model advertisers bid on the rights to present a search result for a specific search terms in an open auction. When someone enters a search term that has been bid on, the results from the auction on that search term are presented, ranked from highest bid to lowest. It is also referred to as Pay per click advertising.
Not coincidentally, copyright law pointedly insists that music on Internet radio web streams are "performances". It's these performances that they want to be paid up to $.0019 for, on a per-listener basis. The problem with the old p4p (described above) is that it's an advertising system. This isn't. We're talking here about putting economic control in the hands of the listeners, by making them actual customers. Again, on a voluntary basis. They pay what they want for what they value.
We can make this voluntary because the goods in question are freely available. That means they are non-coercive. No DRM required. No distrust or control freakage on the supply side. No scarcity games. No silos. No inventory systems with SKUs or barcodes or security guys checking packages at the door. Just free goods, on display for everybody to see and use. Plus something new: the ability, on the user's side, to actually pay for usage, at the user's own discretion.
Lately at gatherings I've asked a series of questions that go like this:
- How many of you listen to public radio?
- How many of you pay for public radio?
- How many of you would pay if paying were easy?
The answer to 1 is usually around 90%. The answer to 2 is usually around 10%. The answer to 3 usually goes back up to 90% again.
Clearly this form of free stuff has value. The key to monetizing that value is by making it easy.
That can't be done with systems that are different for every station, every site, every tune, every whatever. We need a system that works, first and foremost, for the user. We need tools of independence and engagement that allow us, individually, to pay for stuff that's free-as-in-beer.
In some cases we're willing to pay and perhaps to pay more if we sense or know we are actually relating to (and not just paying) the artists, producers and distributors of these goods. For this we need the means to scaffold real relationships built on mutual respect and mutual interests and not just on coercion or guilt or any of the conventional methods employed by suppliers.
We are at square one here. We do not have tools of independence and engagement. Not for P4P. Not for paying radio stations or streamers or podcasters or developers of code bases.
But how hard will it be to put these tools together? Ten years ago I would have said it was impossible. But back then the LAMP stack was still new. Now it's well over 145,000 letters long, and that's just counting the open source projects on SourceForge. There are countless open standards, countless new and better ways to mash up all kinds of stuff, thanks to Web services, open APIs and Lego-like approaches to putting code and practices together in useful ways.
On the supply side every webcast already carries identifying data about itself, its programs and about the musical selections it plays. So does every satellite channel on XM and Sirius (which currently have business models based on subscriptions and advertising, but there is no reason they should be limited to that). And surprise: so do lots of FM stations. Thanks to a standard called RDS, for Radio Data System, stations can carry a variety of identifying data types. This means RDS can be used to provide necessary data as digital output to p4p tools.
On the demand side, there are already ideas from real programmers who make useful tools. For example, here's David Sifry of Technorati:
I posed a thought experiment: What if we made it really easy to pay for things that we liked on public radio and TV? How about using a shortcode from your mobile phone to 'vote' on your favorite shows while they're playing? Think 'American Idol' style, and you'll immediately see how interesting and lucrative this could be. First off, you're getting your listeners and viewers more active, and what they do has an immediate effect. But what also happens is that the people formerly known as the audience are then in control - they don't get signed up on a list, they don't have to give their name, address, and credit card number . So here was the thought experiment: What if you made a policy that you'd never collect or sell personal information about your donors? And what if you made it really really easy for people to become donors, like using that mobile code to vote for the story they just heard? What if you really put the listener in charge?
And that's just one idea -- one I consider important because we can't limit our solutions just to browsers. We need p4p to work on devices that aren't computers. Among those I'd put cell phones at the top of the list.
At Beyond Broadcast, one of the sixteen working groups was Public Radio and Open Source, which pushed forward on open source efforts around PubForge.org. There a venue already exists where efforts can be joined and code can be gathered. The IMA 2007 blog has a post titled PBCore for publishing, sharing, and preservation that loops together RSS, XML, metadata, the Open Archives Institute and PBCore, the Public Broadcasting Metadirectory Dictionary. The purpose of PubForge is to "ally the already common interests of public broadcasting and the open source developer community".
Leading up to Beyond Broadcast I spent two days at NPR in Washington followed by a week at Public Media 2007 in Boston, where I gave the closing talk. In the course of all this I was involved in VRM conversations with folks from NPR, KQED, WXPN, WGBH, PRX, Public Interactive, WNYC, Vermont Public Television, ThoughtCast, Jazkarta, IT Conversations, KPBS, WBUR, radeo, Public Radio Capital, KUSP, WUNC, Wisconsin Public Radio, North Country Public Radio, the Radio Foundation and WAMU -- to name just a few among many. Everyone I spoke to was intrigued by the VRM concept. Nobody said it wouldn't work. But then, we don't have anything yet. Just a big empty market space, ready to be filled.
We've been talking about how "the customer is king" and "the customer is always right" for many decades. Lately in the tech world we've been talking about "user in charge". Yet those things are not broadly true not as long as the payoff for entrapment exceeds the payoff for liberation.
We have to build tools for liberation. Developing easy ways to pay for free goods would be a fun place to start.
We'll be meeting to talk about VRM, and to get development moving, at a number of upcoming conferences. If you're interested, check your calendars to see if you can make some. Here they are:
- Identity Open Space in Brussels on April 26-27
- Internet Identity Workshop in Mountain View on May 14-16
- Supernova in San Francisco on June 20-22
- OSCon in Portland on July 23-27
- LinuxWorld Expo in San Francisco on August 6-9
- Digital ID World, September 11-13
- Identity Open Space at DIDW, September 11
- Defrag, November 5-6
Meanwhile, if you'd like to help, check out what's happening at projectvrm.org, pubforge.org or any of the other open source development efforts (such as those by members of the Identity Gang) that are moving in the same complementary direction.
Markets are going public. Private silo'd markets are going to be subordinated to public open ones. Customers will lead the way. All we need is to give them the means.
Doc Searls is Senior Editor of Linux Journal
Practical Task Scheduling Deployment
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.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
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