[esonderegger]

I've been wrestling with the idea of how to enable monetization for smaller podcast producers since I decided to start building an AppleTV app for playing video podcasts this past winter. What I think could work is namespaced tags for specific players that offer ad-insertion. This allows for the platform to remain default-open and opt-in for publishers who want to go this route.

For example, much like <itunes:explicit> is not part of any RSS spec, a publisher could choose to include a tag like <castanet:monetize>yes</castanet:monetize>, which would tell the Cast-a-net app that the publisher of that podcast would like ads to be inserted. The publisher would then need to setup an account with Cast-a-net to share the ad revenue, verify ownership, etc.

There is a significant chicken and egg problem, of course. The player needs to have enough users for the publishers to consider setting up an account to be worthwhile. The ad experience also can't get so obnoxious that users move to other apps. This approach allows publishers to gain monetization and metrics without ceding ownership and control to the platform.

By the way, my player, Cast-a-net, doesn't yet offer this feature. I've been working on making the UI good enough to attract real users first, then hoping it can grow to be something worthy of specific attention from video podcast producers.

(edit: as was pointed out in a reply, Marco is very anti-ads, so I swapped the example tags. I had only meant to use Overcast as an example of a popular independent player that doesn't want to become a walled garden for just a subset of the total podcast universe.)

[rackforms]

One possible alternative/addition is what I've done for my Podcast app, SkipCast (http://skipcast.net/).

I worked with Blubrry to create a new donate tag:

http://create.blubrry.com/resources/powerpress/advanced-tool...

If the feed supports this tag, a simple donate link appears in SkipCast and when tapped, takes you directly to the donate page. This tag can be supported by any Podcast client.

To me this is a clear win-win situation, though the feature depends heavily on adoption of simple, easy to use and deploy donation services, and of course the user supplying the tag.

One good example of the donate model working is the Crate and Crowbar podcast (PC Gaming). They created a Patreon and literally shut it down after a few months. The reason: they got hundreds in weekly, recurring donations and simply didn't need that much money.

Donations can work, and could be a huge boon to smaller, independent Podcasters. This could in turn ensure a healthy ecosystem that's more resilient to monolithic entities.

[esonderegger]

SkipCast looks really cool! Nicely done!

I think there is a lot of potential for funding the production of great content via donations. I think the "right" way to fund a particular piece of content depends largely on the content itself. For example, PBS funds NewsHour largely through donations and sponsorships, but NBC funds Nightly News via advertising. Both are valid choices, and I believe everyone is better off when publishers are free to decide how to monetize, and viewers/listeners are free to decide what they want to give their money and attention to.

I'd love to support the <rawvoice:donate> tag in Cast-a-net, but unfortunately AppleTV doesn't have a web view, so a link to a Patreon page wouldn't really work. I may try to set up something like a <castanet:acceptdonations> tag that uses in-app purchases, though. I think both users and publishers might like that better than the first monetization options being advertising.

[starik36]

This is actually pretty cool. It lets publishers just focus on content, while the podcast apps offer the opportunity to monetize. Kind of like YouTube.

As long as the apps don't start doing stupid stuff like unskippable commercials.

[TylerE]

So, it'll take about 5 seconds for someone to setup a proxy that strips the ad-insert tags, no?

[esonderegger]

It's the player software making the request directly to the server hosting the xml file, no? Who would be doing the proxying?

The whole point is that other players are free to completely ignore the tag.

I suppose if the podcast creator didn't want other players to be able to access the feed, they could set up some flavor of authentication. Requests from the preferred player app would include a key, and all other requests would get a 403. I don't really see what advantage that approach would have over a completely closed platform, though.