An open source approach to fixing public media funding
Christopher Lydon's RadioOpenSource is one of the best programs on radio. It's not about open source code, but about radio modeled on open source values and methods. As the show puts it, Open Source has become one of the most talked-about experiments in public media a civil union of online and on-air communities that trust each other to talk about pretty much anything.
Right now the project is The looking for funding directly from listeners and other participants. So the rescue ships are approaching the harbor, and still the wolf is at the door.
If you listen to the show, you're one of those ships. If you write code, you can float a lot more boats not just for one show, but for all of public media (a term that encompasses public radio, TV, podcasting and live online streaming).
What we need is an open source project, or code put together from a number of existing projects, to reduce the friction involved in paying for public media and at the same time to increase the opportunities for participation by listeners, producers and everybody else with something to contribute.
This is the first development project we've taken on at ProjectVRM, which I head as a fellow at the Berkman Center. If you care about public media, or just about fixing markets by making buyers more independent of sellers yet better able to relate to sellers, on the buyer's terms as well as the seller's terms we could use your help.
To show the problem we're trying to solve, here's an interesting exercise. Take any educated crowd of adult Americans. Ask how many listen to public radio. Nearly all hands will go up. Then ask how many pay for it. All but about 10% of the hands will go down. Then ask how many would make the effort if paying were easy. Nearly all the hands go up again.
Clearly there is too much friction involved. That even goes for online payments. So we need a new model one that radically improves on the one that's been used for as long as listener-supported radio has been around. That would be since 1949, when Pacifica, which was born, twenty-two years before NPR started up. What we came to call public broadcasting has had a high-friction funding model based on appeals for donations by listeners. These are facilitated by a combination of fund-raising "pledge breaks" and old fashioned direct-marketing, mostly to current and former contributors.
With pledge breaks, programming is slowed or halted while station personnel and guests plead for money on the air as volunteers take pledges over phones. Contributions are baited with matching grants, plus station schwag (tote bags, coffee mugs, t-shirts) and promotions (CDs, concert tickets).
Pacifica pioneered pledge breaks, which they called "marathons". Public radio in general copied the system, supplementing listener sponsorship with underwriting by what today have become the equivalent of advertisers.
RadioOpenSource's appeal follows the former model, but also short-circuits the distribution chain along which public media programming customarily flows toward listeners, and along which the money flows back up. That chain begins with program producers (such as RadioOpenSource) and runs through distributors (NPR, PRI, American Public Media, PRX) to stations (what you hear on a radio or through your computer or other online listening device). Stations are the retailers.
Stations-as-retailers is a system that is commonly misunderstood. What we call "NPR stations" are not run by NPR. Nor do they get money from NPR. They pay NPR for programs. In fact NPR takes no money directly from listeners. They get paid by stations, which buy programming from NPR and other suppliers. Yesterday I was talking to a friend who said she didn't pay for NPR programming because "my tax dollars go for that". This is almost entirely wrong. Federal contributions (mostly through the Corporation for Public Broadcasting) account for only 2% of NPR's income.
RadioOpenSource's short-circuit appealing directly to listeners and others for help is a matter of urgency. In this respect the program is squarely in a long-standing public broadcasting tradition. Since the early days of Pacifica, stations have raised money by making appeals based on the need to keep from going out of business. Self-pity isn't pretty, but it works.
Same goes for pledge breaks. Even at their most positive and upbeat, fund-raising breaks are notoriously annoying and widely disliked by both stations and listeners. Complaining about pledge breaks has been going on as long as pledge breaks have been around. And, as this post at Oregon Media Insiders says, "No one has found a better way to get that money than the beg-a-thon."
That's our challenge here. We can fix this thing. This isn't 1949. We have computers now.
Even beg-a-thons bring in money from 10% or fewer of stations' listeners and viewers. One good reason, obviously, is that the goods are free: anybody can listen or watch. Nobody has to pay for it. But, as we saw in our exercise above, the biggest reason is friction. It's too hard.
For example, take the PayPal link on the RadioOpenSource donations page. I just used it to send a few bucks their way, and the whole process took about forty seconds (not counting finding the donations page). That was relatively quick, but hardly a one-click (or better, no-click) exercise. And this represents the fast end of the range. A couple days ago I decided to send some bucks to WCPE, because we listen to it nearly every day and because I like the dedicated and pioneering work Deborah Proctor and her staff have been doing for both on-air and on-Web radio, going back thirty years. Making that payment took three minutes and forty seconds and I hurried as fast as I could. Among the many choices presented in the series of forms to fill and questions to answer was one that gave me the opportunity decline receiving membership schwag (CD, coffee cup, t-shirt), which would save the station additional money. I checked it off not just to spare the hassle, but because I'm not interested in "membership", either. Not if membership just means getting hassled by direct mail (in addition to trading money for schwag and fuzzies). And I'm not alone in that sentiment. Back in February Dave Winer wrote,
9 times out of 10, I don't give money to public radio stations, because once you do, you never hear the end of it.
A few weeks ago, in response to a request for support from On The Media podcast, I gave $100 to WNYC. I don't even live in NY. Now I'm getting a steady stream of spam from them with all kinds of special offers. This really sucks.
I listen to WNYC-AM almost every day I'm home in Santa Barbara (mostly over our Linux-based Sonos system). I haven't sent them money yet, though I might if I could be assured that I wouldn't hear them pitch for something every time I tuned in one of their Web streams — and if I could be spared the direct mail pitches Dave talks about. The will is there. We just need a better way.
I don't mean to pick on WNYC, incidentally. On the contrary, I want to salute WNYC for joining us at ProjectVRM in discussions about how to come up with a system that will reduce the friction that has persisted for the duration.
Back in March we met for a workshop on Public Media and VRM (Vendor Relationship Management the reciprocal of CRM, or Customer Relationship Management) at the Berkman Center in Cambridge. Representatives from WBUR, WGBH, WNYC, RadioOpenSource, NPR, Public Interactive, the Berkman Center itself and other organizations participated, and we made progress. ProjectVRM itself has moved forward since then as well, through an active mailing list, weekly conference calls and meetings at unconferences such as IOS in Brussels and IIW in Mountain View.
Next Monday afternoon we'll have another Public Media & VRM workshop at the Berkman Center. The first time we looked at the problem as a whole. (Here's what I wrote as we were leading up to that.) This time we'd like to concentrate on the technical side of the challenge.
Here's the goal: Make it possible for listeners to pay for what they want, when they want, in any amount they like, as easily as possible. That means paying by card, by cell phone, over the Net, on cell phone, on a listening device, whatever.
We don't want to approach this from the stations' side. That, in fact, is a big part of the existing problem. Right now stations are all doing their own fundraising, their own ways. They all have their own methods, their own online forms, their own databases, their own CRM systems each with their own set of "relationships" (which barely qualify for the noun), and so on.. But they all work as exclusive silos. This is no different for public media than it is for most companies with CRMs. The entire burden of the "relationship" is borne by the supply side. There is little or no room for variables of the customer's own choosing on the demand side. VRM should provide a way of putting those variables together and presenting them to the supply side.
Most of the programmers I've talked to have told me there's a good chance that most of the components we probably need are already developed, or adaptable in some way. In other words, we don't need to start from zero. David Sifry, for example, suggests this:
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.
It has been suggested that the listener doesn't need to be completely on their own here. VRM might be handled by a customer-advocating intermediary without media or silo-maintaining loyalties, such as Facebook (which has many millions of members already) or Google Checkout (in fact, I'm meeting with some Google folks today).
There are other ideas we've been thinking about, but I'd rather have yours.
If you're in the Boston area, or feel like coming in to meet with us next Monday afternoon, please do. For details contact me at doc at linuxjournal.com or doc at searls.com.
Hope to see you there. And if not, post your ideas here. Maybe open source can go beyond saving RadioOpenSource and help the whole noncommercial media industry prosper.
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!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
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