Hello PSP friends and members,
Last month, my friend Aaron Francis sent me an email. I can’t get this line out of my head:
”You’ve got to play the game on the field. You need to decide if you want to win or if you want to be right; if you want to be stubborn or if you want to [make progress].”
The Podcast Standards Project is a grassroots coalition dedicated to adopting new features that improve the open podcasting ecosystem for both listeners and creators.
In one sense, the PSP needs to play the game on the field. We need to understand what genuinely motivates creators and listeners and respond with features they care about.
But in another sense, we’re also trying to do the impossible: we’re trying to change the game.
We’re advocating for:
- large platforms to adopt open-standards,
- creators and consumers to understand the benefits of RSS and decentralized media,
- and features that improve podcast publishing and podcast listening.
We live in this tension: reflecting the reality on the field while also fighting for the ideals we want to see in the world.
It was an “unrealistic idealism” that gave the original Web Standards Project the audacity to petition Microsoft to adopt W3C standards in Internet Explorer 6. We’re trying to do something similar.
How we play the game on the field
If we’re going to adopt new RSS-based features, they should reflect what creators and listeners want.
The biggest risk to our project is adopting our own pet projects instead of building features that creators actually want to use.
This means identifying features/specs that have the potential to:
- reach a critical mass of podcasters and listeners,
- and fulfill a strong desire shared by podcasters and listeners.
I think the best example we have of this was the <podcast:transcript> feature. There was evidence that creators wanted it: many had been transcribing their episodes for years. Listeners wanted it as well! Many of them were reading transcripts, saving quotes, and so on.
Based on this evidence of real demand, hosting providers adopted the spec. Podcast apps later implemented the feature. And then, creators used the feature!
The reason transcripts worked is that we had evidence creators wanted it before we built it, and evidence they used it after we launched it. That should be the bar for everything we do.
We need to recognize the biases we bring to the table: the preferences we’ve accumulated over a lifetime (being computer nerds, syncing iPods to iTunes, etc). In so many ways, “we are not the end-user.”
Every once in a while, I’ll head over to Podping Watcher to see the stream of episodes from everyday podcasters. These creators (and their listeners) are our target market!
How we’re trying to change the game
Convincing a big company to do anything is a near-impossible task. (We all know this – and have the scars to prove it!)
But, at the PSP, we’ve decided to try because we know:
- The Web Standards Project proved it could be done.
- We need to reach a critical mass of podcast listeners.
- Collectively, our advocacy has an impact.
- Trying is better than not trying.
Still, we need to be judicious about where we invest our energy. The task of advocating for industry-wide change is difficult enough; we can’t make it harder.
Here’s an example: I’m really upset about browsers removing XSLT support for RSS feeds. In my heart, I’m “right” (this is a big loss for the open web). But the reality is that James Cridland is right: we have to pick battles we have a chance of winning. Everything else is wasted energy.
We have to prioritize what we bring to the table.
There are a few features we’ve already adopted that might be good candidates for speaking to the big platforms about:
- Support for the <alternateEnclosure> tag.
- Support for the <podcast:person> tag.
- Support for the <podcast:podroll> tag.
What bets do we want to make in 2026?
Up until now, we’ve adopted new features through discussion at our in-person meetings. But as the PSP grows, we need a more structured approach.
Kevin from Snipd put it well in a recent discussion:
Every proposal needs an explicit emphasis on the value it creates for the listener or the creator. Otherwise, it will never get off the ground. We should have a hypothesis about what this value is, force ourselves to formulate it clearly, and validate it.
Based on that discussion, I’ve moved ahead and created a proposals repo on GitHub.
A few highlights:
- Before we commit to building anything, we need to answer: do creators and listeners actually want this? Is there evidence of real demand?
- Proposals move through a clear pipeline: Proposal → Research → Vote → Beta → Vote → Standard. We can backtrack at any stage if the evidence isn’t there.
We’re a small group who’ve chosen to collaborate on something bigger. Let’s channel that energy into the battles we can actually win.
Let me know what you think!
Cheers,
Justin Jackson
Co-founder of Transistor.fm,
Organizing Member of Podcast Standards Project