One of my first decisions as Chief Architect at RadioPublic was to determine how episodes of shows were going to make their way into the app. There are a lot of great choices for efficiently transmitting structured data between two computers, some of which are specifically designed for our new, mobile world. But in my mind, the choice was clear. When you’re building a podcast app, you are building on a 15+ year legacy. Podcasts mean XML. Podcasts mean RSS.
I’m by no means a podcast purist — to me, podcasts are defined by a particular user experience, and the technology underlying that user experience may (indeed, must) change in the coming years. This is especially true if the medium is to maintain its current rate of growth. But a core user expectation is one of interoperability, where as a listener I know that I can listen to my favorite shows in whichever podcast app I choose, whether that’s the latest paid app or the Podcasts app pre-installed on my iPhone. And right now, the best way to enable that is to follow the rules and publish RSS. Which is exactly what hundreds of thousands of audio producers have chosen to do.
QUICK NOTE TO PODCASTERS: You can get all of our awesome podcaster tools at https://podcasters.radiopublic.com
Designed for Ease of Authorship
As others have pointed out, RSS is not without its limitations. The standard has been frozen since 2003, and some early decisions (like the fact that GUIDs are optional, and that they are not required to actually be GUIDs) were made to ensure ease of authorship rather than ease of consumption. This was an odd choice in retrospect, but understandable given that many early RSS feeds were hand written and not generated by machines. Some attempts have been made to replace RSS wholesale, with Atom being the most obvious competing format. But nothing has reached the level of adoption that RSS has seen, especially in the podcasting space.
So, as we at RadioPublic sought to introduce new functionality to our apps — such as play order, annotations, and best-of episodes — which were not supported by the existing RSS spec, we were left with another choice. Would we introduce a new API to support these features, or would we build on what was already there?
The Open Approach
At RadioPublic, we are dedicated to the principles of the open web, chief among them the idea that nobody needs to ask permission to participate as a producer or consumer. As a result, we knew we couldn’t set up a proprietary system which restricted participation to the small number of programs we could collect metadata for ourselves. Building yet another publishing platform for producers to share their data with us directly is fraught with technical, social, and ideological challenges. Plus, our founding partner PRX is already well established as an open publishing platform. So, we decided, any additional data should live in the open RSS feed, along with the rest of the data for the show.
Remember that the RSS spec is frozen, meaning that no improvements can be made to it, full stop. That said, RSS documents are written in XML, and XML has a feature called namespaces which can be leveraged to include data from multiple specifications in a single document. This allows one to create new specifications that could be used, not instead of, but in concert with RSS. iTunes did this when they initially added support for podcasts back in 2005, but little movement has happened in the intervening decade.
Indeed, there are some interesting initiatives to pick up where Apple left off, but they face a chicken-and-egg problem. Producers aren’t incentivized to add this extra metadata to their feeds until apps take advantage of them, and apps have no reason to add features that take advantage of data which doesn’t exist. Not only that, but figuring out which features users want depends on being able to test features, which depends on the supporting data existing in the first place.
One approach that answers all of these problems is to bootstrap the process by doing all of the parts as one organization — data, apps, & user testing. But once you’re collecting the data yourself, it’s usually easier to just stuff it in a database somewhere, rather than asking producers to include the data openly in their feeds. To the extent that apps are already exploring features enabled by additional data, this data is being stored in silos adjacent to the feeds, and producers still don’t have an easy way to participate.
We solved this problem with code.
Draper is a RadioPublic application that takes RSS in and puts RSS out. The RSS is transformed in the interim by a series of rules, defined in data, which can be automatically applied to feeds based on their URL. Those changes happen without impacting the important data that is already in the feed — meaning things like stats and post-publish changes to audio are not affected. Our apps consume this transformed RSS, instead of the original RSS. Most of the time these changes are small, like removing iTunes-specific tags that RadioPublic doesn’t use, but sometimes we add extra data to the feed.
The first trick I taught Draper was to add a unique identifier to every feed that will follow it even if the URL changes, or if the same feed lives in multiple places. It looks like this:
https://gist.github.com/cqr/636fcbc9836237964d2212160794ae0a#file-program-id-xml
This makes it easier to figure out if you’re already subscribed to a feed, but with a different capitalization, or maybe an older version of the URL. But if it’s done right, the user will never know it’s there.
What about a way to specify the best episode to start with?
https://gist.github.com/cqr/13d56f89e8103838585681acb0d957ce
We’ve reached out to dozens of producers asking them which episodes belong in their greatest hits, and which work best for new listeners, so users finding them through RadioPublic discover episodes producers want front and center first.
But what if we don’t have your email? What if you’re a member of the long tail of 250,000+ podcasts? That’s where our approach aligns with the decentralized web. Supporting these features is as simple as adding a custom tag to your feed, something the most commonly used podcast publishing systems already support. And if you’re not comfortable copying and pasting XML, we will be collaborating with top publishing platforms in the space to support these features without the need to manipulate your feed directly, as open standards.
I am particularly excited about the fact that producers are left in full control of their feeds, and they don’t need to reach out to us at all to make use of RadioPublic’s new features. If at any time a producer chooses to add a tag to her feed which supersedes the data in Draper, Draper’s data will be overwritten. Our apps don’t know or care which data came from the producer and which came from us.
We’ve been surprised by the number of times Draper has proven useful while testing out an idea for a feature. It has let us stay committed to an open web ethos where nobody has to ask permission to do their thing. We like to think of podcast apps, when they’re built right, as specialized web browsers. We’ve built an approach that allows us to innovate quickly without giving up what makes podcasts great.
I’m excited to see what comes next. We’re beginning early talks with others who are interested in improving podcast feeds by layering extensions on top of RSS to provide features that have been missing for years. And in the coming months, I will be open-sourcing Draper to encourage the types of experimentation in this space which will help to drive the medium forward, creating a better experience for listeners and producers alike.
If you’re interested in joining us, RadioPublic is hiring! We’re looking for a Full-Stack Engineer and someone to Lead Product Design. If you’re interested in joining the conversation about the future of podcasts on RSS, check out syndicated.media. And if you just want to get your hands on the Draper source code a little early, email me: chris.rhoden@radiopublic.com
