This actually happened! Please check out the site: maintainersanonymous.com
I think podcasts are a good medium to open up conversations about topics we should talk about in public but aren't, and to do it in a more conversational yet nuanced way (I was pleasantly surprised with how Hope in Source was received).
So I'm thinking of a podcast that isn't necessarily about current events or any particular project/language/event. And if it's going to be "timeless", then the format could be more by seasons (or theme) rather than per week.
I think I'd like to talk more about the how (what it "feels" like) vs. the what (the content, which is more googlable) of being a maintainer. There are plenty of podcasts that interview guests on what a particular project does, why it's used, or how to use it but we could talk more about their motivations, struggles, and hopes!
To shed light on the process of working as a maintainer (bonus if we get more contributors from it).
- Empathy for maintainers as people rather than open source projects as code (e.g. who can be a maintainer, what exactly does a maintainer do)
- Present missing context and clearing up misunderstandings into what's "behind the scenes" (e.g. why does it take so long to merge a PR or make a release? what goes into it?)
- Sharing in the similar struggles that we all face as developers and as people (e.g. understanding what you know and don't know)
Maybe it's fine if end up with more questions than answers; I don't know what I'm doing here so I'm eager to learn and discuss with everyone!
Just some ideas and potential questions as an example.
- Growing Maintainers: How do projects inspire others to join a project?
- Onboarding program, welcoming team, mentorships
- Programs: Summer of Code, Hackathons, Company Workshop, Meetups, Conferences
- Dealing with the fear of contributing
- How to stick with it (not just how to get started)
- What are the different ways to contribute, not just code? What roles are there?
- Maintainer Struggles
- Learning to set boundaries: overwork, distractions, set hours of availability
- Losing passion, burnout, handing off projects, letting go, delegation, etc
- Pride, entitlement, dealing with negative feedback
- Stories of failure, likewise handling "success" + pressure
- Events like left-pad and event-stream
- Handlng perfectionism, scope creep, when to release and "be done"
- OSS as a business
- How much do we need? What do we want money for?
- How should money be divided?
- Common Questions
- Why isn't my PR merged?
- Why does a release take so long?
- Why don't you do x?
- What makes a healthy project?
- How do we measure success?
- Why do we feel so guilty in open source?
- What's the nature of the relationship we have with the community as a maintainer?
- What is a project's life-span?
Example of a specific theme/season:
- Language Standards: I originally thought of making a Babel podcast (maybe I still should) for this idea. People tend to think "ivory tower", so it could be interesting to speak with folks on TC39 to better explain how things are done, how to get involved, and what can change.
- How does it differ from other language standards like C or browser APIs?
- How has the committee grown over time in the mix of people: language designers, implementors, practioners, educators?
- History of a specific feature: how does it get finalized?
- What's a meeting like: who goes, how it is organized? Is there much arguing or voting?
- How has decision making evolved over time? (the Staging process)
- How is "feedback" received or taken?
- How important are "edge cases": why does it matter?
- Perception of the language over time: moving too fast, moving too slow
- Questions about language design: performance, usability, teachability, aesthetics, syntax budget, etc.
- Ecosystem alignment: how is the language shaped by tools, libraries, other use cases other than the web?
Anything about open source that you'd want to hear about or discuss that we don't say much about? Let me know!
Releasing by topic or season seems to make sense. Can we go into detail just about a specific question, or just start with a general problem and see where the conversation goes?
I certainly don't see myself wanting to do a solo podcast so not opposed to just talking with a guest or doing a series of episodes with the same guest? Maybe it's better to try it out and see where it goes?
And as for guests, of course we can interview open source maintainers! But I'm curious about talking with contributors, people who haven't yet, or people in other fields that do "maintainer-like" roles on their perspectives?
Would appreciate your feedback as I'm still thinking through this!