I was recently asked, “What’s the hardest part, for you, about podcasting?”
Staying out of the way.
I’ve spent so much of my life diving in and fixing things, that it has become my first instinct. To rush in and grab the controls. To attach a sense of artificial urgency to everything. To become frustrated that others aren’t immediately taking action now that a solution or idea has been found.
Certainly, an important step is to first cultivate a team who can do great work. But once that’s done enough, the hard part for me is staying out of their way.
Many people would say that I value action over thought. This is absolutely not the case. I am driven to find evidence, to investigate, to look for previous examples of similar solutions and ideas, to gather data, to analyze, to sort, to organize, to imagine… and then I act— often frenetically.
It is right before that last step that I’m learning to self-intervene.
Zoom H4N recorder, a pair of SM58s (didn’t even have pop filter foam covers) with table-top mic stands. I went to the trouble of finding a power cord that matched the Zoom’s bayonette jack (on the chin at the left, between the XLR cables) and had a standard USB plug on the other. This of course only worked because the Zoom would accept 5v DC. One pair of Vogek folding headphones for me. Stand USB battery brick. I kept this all packed into a Pelican case much smaller than a shoebox.
Pop filters — definitely need to add those.
Mic stand extensions — I found some three-inch long tubes that fit the Shure mic holders and the little folding stands. This took almost all of the “slouch” out of me and guest.
2nd pair of headphones — Things are massively better once you give the guest headphones. I carried (still do) the tiny pair of Monster brand headphones in the photo, but let the guest plug in whatever they wanted (ie, their favorite pair if they had headphones when I showed up.)
Headphone splitter — New, short cable in the photo coming off the H4N that splits into two headphone jacks so the guest and I can plug in.
This kit was terrific and I used it for about 20 interviews.
Eventually I encountered a scenario where we didn’t have a table to put between us. I got a longer XLR cable (blue markers to mic on the right) and a simple headphone cord extension. The extension is the right length so the mic and headphones for the guest are the same basic length. This let us lounge near each other. More flexibility with only a tiny bit of additional cables and it fit in the same Pelican case I was using.
Four Channel Recording
And then one day, I needed to interview three people at the same time.
I bought a Zoom H6. (Still using this today—this thing is amazing.) With two more XLR cables, two more stands (with extension tubes) and two more SM58s. We’re in business with four people talking at the same time.
This Zoom has a USB port on the side that can always be used to power the device. (The H4N has a USB port, but you can only power the device that way when using it as an audio interface. So I had to power the H4 from it’s 5v input bayonette jack on its chin.) That’s also a different power brick (see below), but in this photo I’m just pointing out it drives the H6 via the brick’s standard 5V USB port.
Guests Need Headphones
Then things got complicated. Here comes an entire (albeit tiny) powered headphone amp with separate volume controls.
Here you can see my headphones (lowerleft) plugged straight into the recorder where I have my own volume control. Off the chin (bottom) of the H6 is a “line out” (no volume control on this line out) audio jack which runs over to the input on the headphone amp.
There are four 1/4″ to mini adapters plugged into the amp so I can drive the more usual mini-sized headphones from the amp’s more standard 1/4″ jacks. As a bonus, the production assistant can now have headphones too. 3 guests, +1 person, on the external amp.
The amp unfortunately takes 12v power on a bayonette jack. I do not want anything plugged into wall power. I don’t want to be cord-length restricted, nor do I even want to require power. (Outside? no problem, done it often.) Also, anything plugged into a wall outlet brings our enemy 60-cycle line buzz. So I had to custom make the male-to-male bayonette cable from the headphone amp to the power brick. So, here’s the new power brick from the last photo, which has both 5v USB and a 12v bayonette. It has a special bayonette power brick for charging over-night between uses.
This add a lot of complexity as now I have to walk the guest through playing with their volume level. It has to be loud enough for them to hear, but I have to make sure they are using the mic correctly—if they sound quiet to themselves I want them to get cozy with the mic. So I set up my mic give them headphones and I talk at the right level (voice volume and mix proximity) and have them set the volume from my voice. Then they leave it set and it “encourages” them to use mic tech to get their voice loud enough.
Put the mics in here. (Note my emergency backup memory card there.)
The power brick, headphone amp and H6 go in here. I spent some time to add some scissored foam. These aren’t crush-proof cases—this is only meant to survive normal travel/back-packing handling.
Little messy, but that’s three headphones (two fullsize folders, and the third in-ear pair.) All the power cables, and the power brick wall adapter. Also, I’m still carrying the single headphone cord extension in case I want to go in “lounge mode” needing extra distance.
I had to do a bit of cutting to remove a little angle brace on these stock Shure mic holders. But then they fold a full 90° and nest like this. Yes, I’m a child of Tetris.
On the left are the 3rd and 4th pairs of folding headphones. The stands are in the bottom on the right under all the coiled XLR cords. This, by the way, is the case the TSA seems to be 50/50 on… I’ve been stopped, and the inspecting agent looks at the screen sees the microphones and goes, “podcasting equipment, why did they flag this…”
All of that is in here. The guests often enjoy the show where I produce all this stuff out of the containers and then make it all magically go back in.
This article got out of hand, and is 3,000 words. I encourage you to skip around; There’s more discussion of specific tools and how-to material in the last third.
In the beginning
In the beginning, podcasts were simply audio files which people shared directly either by emailing them to each other, or by providing download links on their web sites.
RSS technology has been around for a while and provided a way for a web site to publish a “here’s what’s new” feed. It was soon realized that RSS could be used to provide a feed specifically of podcasts. Software able to retrieve and understand a podcast feed, could then automatically download the podcast files, and alert you of new episodes. Sharing a new show with friends then meant simply giving them the “feed URL” which one would “subscribe to” by adding it to your feed reader.
It was only a matter of time before someone realized that a central directory that stored all the feed URLs would be extremely useful. That directory would enable me to search for new shows, new episodes (across any show), and so on.
All of this depends on meta-data; information about the shows and about each episode. Applications for mobile platforms, desktops, and web sites sprang up each of which communicated only with some directory. At first, it was just Apple’s iTunes directory of podcasts, but now there are many different directories maintained by various entities.
Today, “submitting” your show means getting it added to a directory.
About the feeds
A feed contains two things: Information about the podcast (name, author, description, etc.) and a list of episodes and their information (title, description, download URL for the audio file, etc.). Specifically, it’s a file marked-up with XML which is meant to be read by programs. Here’s a screenshot of a podcast feed shown as raw text:
Here’s the same feed shown using a tool which understand the XML and can present it in a way slightly easier for humans to read:
Ignore those yellow highlights as it’s just commentary from the parser. Note that the display goes for more than 1,600 lines.
No one creates these feeds by hand. They need to change frequently, (each time an episode is published,) and it’s tedious. So show feeds are generated automatically. This is why you “publish” your show in one place, and then you have to “submit” your show to the directories, but then you can publish new episodes without having to notify anyone/anything.
You can install software on your web site which will let you create your episodes and it will generate your feed from there. That software would tell you the URL where it created your feed. You can join a service which lets you upload your episodes, and type in some of the meta-data. The service will then handle playing the file to people who use their web site or mobile app, and it will, (perhaps,) generate a feed for you too. In both these cases you can take your feed URL and submit it to other directories. (I’ll talk more about how this leads an ecosystem, below.)
The key take-away here is: Some software or service is creating your podcast feed (the “publisher”) and some service(s) are consuming your podcast feed (the “directories.”)
The publishers—whether this is your own WordPress web site with Podcast publishing plugins, or service like Simple Cast—accept your episodes when you upload them, take the meta-data you enter (title, description) and create your feed. The directories accept your show’s initial registration and then continuously consume all of the feeds from all show publishers, building a database of all known shows and episodes.
Potential problem: Detecting updated feeds
Directories have a big challenge: If there are +500,000 shows, by definition that means there are that many feed URLs. People want to see episodes appear immediately. The directory has to monitor those half-million URLs for changes. How often does it “poll” each URL?
After over a decade, things are quite advanced. Directories can ask, “is it updated?” instead of “give me the whole thing” and checking against their last fetched data. They can also learn how often each show generally publishes, and then adjust their checking to better align with that. But this is still a HUGE number of requests they need to make.
On the other side, where your feed is published, do you really want each directory (there are dozens) asking your publishing service, “is it updated?” “is it updated?” every five minutes?
This is simply an effect of the nature of RSS feeds; They are “pulled” by the consumer. The solution, created long ago, is to create a push-pull system, (I prefer to call it “bump-pull.”) The publishing service, (WordPress, Simple Cast, etc.,) sends a small alert to a hub whenever the podcast feed is updated. The directories subscribe to podcast feeds by telling the hub, “notify me if this feed URL notifies you.”
Now the directories can vastly cut down their workload. They immediately fetch any RSS feed when the hub bumps them to inform that the publisher bumped them. They can also look for stale feeds which haven’t been updated recently and proactively make a direct request to the feed publisher, “hello? is this thing still on?” and see what they get back.
This started as a proprietary project and has become an open standard, WebSub.
Having covered the publishers, and the directories, the last part is the players (the software which plays the audio files.) Your favorite podcast player has three parts:
A searching and subscribing front end that enables you to find things in somedirectory,
a download-and-store or streaming (or both) manager for the podcast files,
and an audio player. (…hey look, finally! …this is the entire point of podcasting!)
This creates a beautiful ecosystem where the publishing services do their job creating standardized feeds, and serving out the podcast audio files when they are downloaded or streamed-live. The directories create large databases of what shows and episodes exist, their titles, their content ratings, where’s the episode cover art, etc. The players (mobile apps, desktop apps, and web sites) handle all the end-user interface features (playback speed, silence-skipping, rewind, subscribe, sharing, episode play ordering, auto-download for offline listening, and on and on.)
Potential problem: Who pays for this?
I don’t believe our species can survive unless we fix this. We cannot have a society, in which, if two people wish to communicate, the only way that can happen is if it’s financed by a third person who wishes to manipulate them.
Publishing: My personal soapbox is that the podcast creator must choose to pay for the publishing part of the ecosystem. There are a few ways to do this, from choosing a partner which charges to create your feed, to rolling your own from scratch with a hosting company. It’s a good sign that there are a huge number of ways to “publish” your podcast; This part of the ecosystem is doing very well.
Listening: For your podcast player, you should always choose one which is notfree; It’s best if it’s one which charges a recurring fee, (annual is nice,) to the software provider to support their work. Never use free-with-ads players, unless you can pay to remove the ads (and you should do so to support that project.) This part of the ecosystem is doing mediocre.
Directories: Unfortunately, the directories you can’t actually pay. Some of the publishers are their own directory, which they use to enable only their own players. So in some cases you are effectively supporting a directory through your choice of publisher. That may or may not be a good thing.
Fracturing of the ecosystem
Suppose I want to listen to a show. (My friend said I should listen to, “Movers Mindset.”) I open my favorite player and search, but I can’t find it. What do I do? Well, as the end-listener, I can do nothing. As a show creator you are going to find this endlessly frustrating.
What’s going on is that some entities want to control the listeners (the people using the players,) so they entice podcast creators to submit their show feed to their closed directory. There are many of these closed directories. Even worse, they always come with odious click-wrap contracts; To submit your show, you have to agree that they can alter it by adding ads, or that you must defend them in court cases, and so on.
Apple’s iTunes directory is currently the only open directory; Meaning anyone can create player-software that uses their directory. Creating a player is not easy, and there are rules from Apple about directory use, but it is open to anyone’s use. There are other open directories, but they don’t have nearly as many shows as Apple’s, yet.
Currently (spring 2019) the BBC is embroiled in a PR mess for having removed all of their shows from Google’s podcasts directory. (Google’s podcast directory is not open, but Googles player apps use it, and that’s a lot of listeners.) The BBC wants people to use the BBC-provided players. But the rest of the podcast universe is not in the BBC’s directory, and so not available in their player. That means I have to have two players: one for the BBC and one for all the other plays-well-with-others podcast shows. In reality, I feel it’s best to simply shun any shows which refuse to be good podcast citizens and feed into the public directories.
On the other hand, it is not a good idea to have one single entity stewarding the only open directory that is large enough to be useful. We’re all currently relying on Apple to remain the adult in the room as the caretaker of the directory. I don’t like this idea either. Switching our lone egg to another basket controlled by someone else is no better.
What we, the podcast creators need is a self-assembled directory that we all co-create and take part in supporting. It would be built by the creators, and run by funding from the creators. This would become the One True Directory. Each show would pay a small annual fee to register in the global directory. This may sound familiar. Solving the problem of who controls the domain names on the Internet is the same problem of cooperation. The U.S. government started the domain name system, and some wise people worked really hard to create and shift everything to a global entity which now controls it democratically.
Potential problem: How many episodes can a show have?
The answer would seem to be “as many as the creator wants” but there’s a potential problem with the podcast feed structure. How many episodes are actually included in the feed? Directories do not store episodes’ information if they disappear from a feed; You wouldn’t be able to delete an episode if they did that. (Well, not easily, and not without some changes to how RSS works.)
The directories just keep the information which is currently in each feed. If the feed has 12 items, (some real-world defaults are this low,) when you publish episode 13, episode 1 “falls off” the bottom of your feed. This makes it disappear from the directories and from the players. (Cue your friends saying, “I can’t find that episode in my player.”)
If you want every episode of your show to remain in the directory, and therefore findable and playable, you need to ensure the feed will include that many episodes.
Here’s where it starts to be clear why you might want to control your own publishing deployment. What if your chosen publisher only includes 25 episodes? (More realistically, the free version of their publishing service limits you to a very small number to encourage you to step up.) If you have control of your podcast feed publication you can always change anything. The downside of course is the need for the technical knowledge to operate and publish the feed.
How to examine your feed
There are many web sites that will validate XML. (Remember, your show’s feed is marked up with XML.) A great example, which has been around as long as I can remember, is from the World Wide Web Consortium (W3C). Their XML validator is https://validator.w3.org/feed/ and here’s what is has to say about the Movers Mindset feed:
That’s rather gnarly looking. But it is also very accurate. If it mattered, I would change the feed to fix every one of those problems it reports. As it turns out though, the directories are not so strict when it comes to reading these feeds.
What we really need is an XML validator that understand we are trying to verify our podcast feed. Turns out this is also a thing. Meet your new best friend, the Cast Feed Validator. Here’s what it has to say about the Movers Mindset feed:
(Go find your feed URL and put it into the Cast Feed Validator.)
This is much easier to understand. The Cast Feed Validator is doing two jobs: Checking the structure of our feed (the XML validation) and checking for “podcast sanity.” It does a beautiful job of visually presenting the information in a way that we can see what’s going on, without having to directly read the XML ourselves.
We can take this a step further. Podnews.net runs a free lookup service which checks a lot of things about your feed—not the feed XML validity per se. I call this “meta-commentary” as they will tell you which directories you are visible in, and other nuances such as wether you are doing your titles in a way that makes Apple happy. The Movers Mindset page from Podnews’ includes a lot (not shown here) but this section is priceless:
One day, something is wrong… is it with the publisher of your show’s feed, the directory, or the player?
First off, I’d like to point out that since you are now able to understand how those three interact, you are way ahead on problem solving. You’ll know to ask questions to start teasing out, (from whoever reported the problem,) in which of the three parts of the ecosystem does the problem lie. “What player are you using?” is something you will grow tired of asking.
The vast majority of problems I have encountered, (or heard of,) fall into two categories:
the directory doesn’t include the feed at all, or it hasn’t fetched the feed recently
the information in the feed is wrong, mangled, missing, etc.
The first problem is mostly beyond the control of the podcast creator. We can submit our show’s feed URL, and we can reach out to support if it’s not yet included. But generally, directories poll for changes as they see fit and you’re either in, or you’re out. However, “I can’t find it in my player,” is almost alwaysbecause your show isn’t in the corresponding directory. This isn’t really a problem. It’s really just expected behavior.
The second case is where all the problems fall.
But first, I want to show you one more tool that will take you to Wizard-level.
Saving a copy of your feed to a text file
If you can save your podcast feed to a file, then you can do “before and after” comparisons. Imagine you find a problem and you think you’ve fixed it. (Perhaps you’ve made a change in your publishing service’s web interface; maybe you want to change all your episode titles to conform to Apple’s latest rules.)
Unfortunately, I cannot provide specific instructions because there are so many environments. But if you can figure out how to save your feed from your web browser—point your browser at your podcast feed, what happens? …can you save-as… to capture it? Or, if you know how to use a command-line on your computer, do you have the “curl” program installed? And so on…
I know I’m way out in the weeds here, but here’s a screenshot from a tool for showing the differences between two files. In this case, I saved a copy of the feed before and after making some text change. (I edited the HTML tags in the sponsorship section of an older podcast.) I can quickly verify that the onlydifferences are what I wanted:
If I didn’t know how to do this with my feed, I’d have to wait for some directory to load the feed and then wait for my favorite player app to refresh… and then realize I have typo… arrrr! another day-delay… Instead, save a copy, make a change, verify the change, and I’m done.
Namespaces in XML
Wow, you’re still reading?
You may have noticed in the screenshots of XML, that some tags are, <title>and some have a colon in them like, <itunes:title>. The itunes: part is an XML namespace. This enables everyone to invent their own tags without having to all agree on the tag names. So Apple’s directory will use the <title>information, unless you specify an <itunes:title>—then they’ll prefer their tag. You’ll see this come up when you read things like, “if you use Apple’s tags, you can…”
There are lots of namespaces and they’re declared at the top of the XML files with xmlns:URL in the (in this case) main <rss ...> tag that begins the XML. Don’t bother learning them—even I’m not that crazy. Instead, just remember that namespaces are a thing that groups tags.
In early 2019 there was a lot of noise about Apple changing the rules about podcast tiles. Your first thought should be, “why does Apple make the rules?” …they don’t, they make rules about what their directory will accept. Technically, they always had the rule that caused the fuss. What happened was they emailed all the creators and said they were going to start enforcing it. The rules is that numbers—among many other things—are not allowed in titles. So, “23. Interview with John Doe” is not allowed as an episode title by Apple.
Everyone freaked out.
A few people noted the rule is actually: Numbers are not allowed in Apple’s title tag. Which means, not allowed in the title tag in Apple’s namespace, our friend the <itunes:title> tag. So I went in and fixed all my <itunes:title> tags. In the end this was an improvement to our feed overall. Now I have my general <title> tags with what I want, (we happen to use numbers as prefixes,) and I conform to Apple’s guidelines for their Apple-namespace titles.
Remember that feeds are meant to be read by the computers. You shouldn’t have to ever mess with any of this, but now that you know how…
I didn’t bother talking about the various tags in the feed file. Now that you have some tools, you’ll discover the tag names have obvious meanings.
But forget business for a minute. Stores are much bigger than that, they’re central to our human existence. The way we shape reality is through storytelling. If we can tell a story about it, that means it exists. And this explains our species’ unique capacity for metaphor…for that is how we turn abstract ideas into stories.
~ Gaping Void
As I mentioned in the meta-interview of me for the Movers Mindset podcast, I love stories and story-telling. But helping others tell their stories is what I enjoy most about the interviews. Everyone is so incredibly different—yes, I too thought that was obvious before I started interviewing people. ;) Some people, I have nothing more to do then press the ‘record’ button. Some people, have something they need to say but it takes hours of conversation to figure that out before I can press ‘record’.
I’ll be candid: The podcast is incredibly painful to create. Until you’ve tried it—I urge you to never try it, by the way—you cannot understand how much time, effort, and money it takes to do it well … did I mention the time? Worse, the more I work on the craft of story-telling, interviewing, and the countless nuances of producing a show. Bottomless, hopeless, endless, thankless, merciless.
But then I randomly listen to an episode from the catalog, one from a while ago that I’ve sort of half-forgotten and I remember why it would be inconceivable to stop this early in the journey.
This conversation with Mandy was the first time I tried simply recording a long conversation [which we published with almost zero editing]. I had been talking to people on our team about trying this form of recording, but at some point, you just sort of have to jump in the pool.
I don’t remember where or when I first met Mandy. I don’t remember if someone said, “you should interview Mandy.” “Who?” “Mandy, over there— here, I’ll introduce you.” …or maybe we first met training. I really don’t recall. But I do recall that after a conversation we were like, yeah, let’s do an interview. At some point. Somewhere. Somewhen.
Then a few more conversations. Then a few stories at Gerlev, and then we were at the 3rd Évry Move event and we were like, we better make time for an interview…
Aside: I promised snapshots and stories… not coherency.
So after dinner one evening, Tracy, Mandy and I kicked our feet up in a hotel room overlooking the fountain in front of the Évry Cathedral.
…and talked for more than two hours trying to decide what to talk about in her interview. Two terrific hours of great conversation. We kept looking out from the 4th floor, with the big window swung open wide to the warm night, and thinking, “This is Évry. We’re just casually chatting about communities and life and everything… in the middle of Évry.”
…and the huge water fountain in the plaze sounding like a waterfall.
…and we really should press record soon.
“…ok, so, we’ve now been talking for 2-and-a-half hours. We should maybe press record soon. Maybe.”
Finally, I was like, “fuck it. ready?” and I hit record… and then we talked for another two hours. We recorded this sleep-drunk sort of rambling conversation, and the whole time I’m thinking, “omg this is going to be so bad. No one will ever want to listen to this.”
Weeks later, I finally listened to it.
There’s a team of people behind the podcast and they always want to know how each interview went. I bet you’ve heard the phrase, “like pulling a rabbit out of your hat,” used when—with a touch of panache—you manage something akin to snatching victory from the jaws of defeat.
This ongoing series of posts will contain my memories and thoughts from the interviews which I have been doing for the Movers Mindset podcast.
You can—obviously—listen to each interview. But in this series I want to share things about the interviews. I realized that I have begun to tell stories about the interviews, and people are fascinated by those stories as much as by the interviews themselves.
And so I want to share snapshots—imagery and ideas conveyed through storytelling—from the interviews. The podcast is about, among other things, sharing stories and for every interview I have at least one great story I want to tell.
Stories from before the interviews, or after. Or the people in the room you didn’t hear, or beautiful spaces I get to visit, or the time of day, the light, the vibe, the orgin-story of how I first met the guest, how they affected my life or my journey, …
I’m already 27 stories behind and even the most cursory romp down memory lane has brought countless stories to mind.
They just assumed I must be just like all the other people they represent- hungry and desperate and willing to sign anything.
~ Jason Korman
People sometimes ask, when the Movers Mindset podcast isn’t available in their favorite podcast-player app, why not?
tl;dr: odious clauses in click-wrap contracts.
You should see some of the things! Obviously, there are “hold harmless” clauses obsolving them of any possible responsibility—sure, ok, that’s fine, I am deriving benefit from having our podcast distrbuted through your thing. But some of them want the right to insert ads—not just run ads before or after. Sure, ok, again, you need to pay for your thing; I get that. But insert ads in the middle? Or how about clauses that bind me to defend them in any lawsuit. Not even just related to the content we created—but any lawsuit. Or how about my not being allowed to mention in our advertising that we’re being carried by their thing . . .
sorry i digress
These odious cases have arisen because it’s a lovers’ triangle: The thing/app convinces the users that everything is rosy. The users lean on me because they can’t hear the podcast, and then the thing/app extorts me. Which is all very closely related to Jaron Lanier’s comment about “our society cannot survive, if…” (And that’s a link to the web site where you can always listen to the podcast, for free, because we control our web site.)
Please—you reading right now—please start paying for things. Choose a podcast player app which is not free. That makes you the customer, and enables them to build a great app. Then they don’t have to strong-arm me. Choose a messaging system, choose a source of information, choose everything(!) by being part of a fair trade with another party.
If you find yourself in a position, where you’re thinking, “this is great and free!” please look around and try to figure out who is actually being taken advantage of… it’s clearly not you, but I assure you, it’s someone else.
This past weekend I had the opportunity to attend a Winter Immersive retreat hosted by the Movement Creative. There I finally got a chance to sit down with Jesse and record an interview. Be sure to follow the Movers Mindset on the web site, or wherever you prefer to listen to podcasts!
Hopefully, you’ve discovered the the podcast project. (Originally it was called “Parkour, They Said”.) The original project was entirely based on the written word and was inspired — ironically — by podcasts in general.
In late 2015, I was lying on the floor slow-roasting myself before the wood stove. I had stumbled onto a new-to-me podcast — yes I remember which one, no I’m not telling — and I was starting from their first episode. The episodes were horrible, but I knew they would get better, since a recent episode is what had drawn me in.
But listening to those early episodes left me with a litany of ideas:
I can’t even understand them with this crappy audio. Why aren’t all podcast episodes fully transcribed and available?
But honestly, no one would read the entire, long transcript of this horrible ramble-session. Why not break that large interview apart into its basic themes? Then people can read the entire interview, or just a part.
Why not have a standardized set of themes on the site? Then the “chunks” of the interview can be organized under those themes, and people can read just the material on a particular theme.
Why not add translation functionality? That’s way better than a podcast because people can read the interviews in many languages.
So wait, why bother with podcasts at all?
Why not just open it up with a form where anyone can write anything? Then people can contribute their writing in any source language, and the site then facilitates communication by translating everything to/from every language.
…and why not make it a generic project, conveying whatever everyone contributes? Well, what would we call that? It’s just a collection of whatever it is that people have to say…
…and why not make several sites, each on a particular topic. How do we name and label each site?
“Parkour, They Said.”
(Bully on you for reading this far! You now know that the “Try Parkour they said, It’ll be fun they said,” meme is not in any way related to “Parkour, They Said”. :)
What could possibly go wrong?
I know, right… that whole project above is a TERRIBLE idea. (I’m not being sarcastic.) There are at least two, major problems:
Writing is hard. People don’t like to write. Actually, it turns out that writing well is also very much harder. It’s as if one could make an entire living if one could write well. :P So this project’s success depends on… Oh, that’s a problem.
The way the project works, and its purpose, are not the least bit obvious, and the name is downright obtuse. Worse, the name uses a wonky grammatical construct, (“topic, more information”) which is uncommon generally, and a straight-up Unicorn in spoken language. And the meme does not help. So, go ahead, say, “Parkour, They Said” out loud. Did you manage to convey everything about the project? Oh, that’s a problem.
But, whenever I spent 10 minutes blabbing about the project, people seemed to think it was a good idea. (This was probably the conversational equivalent of Beer Goggles on my part.) So, after many months of talking about it, we built it anyway.
“You should write something for Parkour, They Said!”
I spent more than a year, randomly in my spare time, talking about the project and trying as politely as possible to repeatedly nag a few hundred people into writing. I learned at least two things:
Writing is in fact really hard, and people already know this.
“Parkour, They Said” is a strikingly unhelpful name for an already non-obvious project. If the project had been called Snorklewacker, (yes, yes it is, yes I did,) it wouldn’t have been any harder for me to explain, or any harder for everyone to remember. And just for the triple-bonus, start in the hole, difficulty score, we put it on a “.world” domain.
Surprisingly, a number of people actually managed to write some really interesting things. This made me very happy.
“Craig, why don’t you just make a podcast?”
I really like talking. (Everyone who knows me just laughed and thought, “collossal understatement there Craig.”)
Via a perfect storm of things not worth the deep dive, I wind up in a ton of fun, wide-ranging, interesting, and educating conversations. That’s not just me being hyperbolic; I regularly find people glommed onto my conversations. (I literally have a new friend who — their words — “was just eavesdropping the shit out of that conversation”, and we started talking when my original conversation partner moved on.)
People — often the people who were eavesdropping my conversations — started saying “that conversation should have been a podcast episode.” So the idea of making a podcast was gaining some footing in my head space.
But, I have a problem. It’s called shiny thing syndrome, or ADHD, or whatever. (“Get off my lawn! We didn’t have all these fancy acronyms back in my day.”) So I was really, REALLY, determined to not add “podcast” to my list of things to do. I already had this crazy “Parkour, They Said” web site sucking up time.
In one last-ditch, Herculean effort to avoid the inevitable, I started offering to help people write by recording Skype calls and passing them the transcripts. I think I did three recorded calls before I had convinced myself that-