DevRel, AI, and the Maintainer Gap: Community + Code Ep. 26

---

Chris Reynolds had me back on Community + Code for Episode 26, and it turned into one of those conversations that wandered exactly where it needed to. We started with how we first met — me trying to keep him from wallflowering at PressConf — and ended up somewhere around the ethics of AI-assisted coding and the maintainers we never see. Have a listen, or read on for the bits I keep thinking about.

The wallflower thing

The reason Chris and I got connected in the first place: he was heading to PressConf 2025 as a brand-new developer advocate at Pantheon, going solo for the first time, and he asked if I’d make sure he didn’t end up against the wall. I took that as a personal challenge.

I’m a little funny on the introvert/extrovert spectrum. I get energy from being around people — did theater, love a good event — but I also need a small nudge to insert myself into conversations that are already happening. Once I’ve got one person to anchor to, I’m fine. Probably more than fine. And one of the most useful things I can do for somebody new in this space is be that anchor for them, then start handing them off to other anchors. That’s it. That’s the whole trick.

What DevRel actually looks like at a hosting company

Chris asked me how I “devril” for WordPress, and the honest answer is: a lot of it is dotted-line work. If you’ve spent any time in a corporate org chart, you know what that means — you’re the connector of the things. You don’t fully belong to any single team, which means you can sit across teams and translate between them.

At GoDaddy, that looks like coordinating meetings between our hosting engineers and core contributors to stress-test new features (collaborative editing in 7.0 is a current example — how does that perform on shared hosting versus managed?). It looks like watching a Matt Mullenweg walkthrough where he floats the idea of a command palette in the admin bar and immediately thinking, ” Oh, that’s going to collide with a half-dozen things plugins and hosts have stuffed up there — somebody internally needs to know this is coming, even though there’s no ticket yet. It looks like logging a meta ticket because somebody on Twitter noticed the WordPress login page logo doesn’t match the new default blue.

Is that DevRel? Yeah. It’s all DevRel.

The DevRel framework, briefly

I sketched out the developer relations framework on the show because I think it gets undersold. Picture a tree:

• Community is the trunk. That’s the base.
• Developer marketing, developer experience, and developer success are three branches up from there.
• Developer education is at the top.

Most of us fall into DevRel sideways — usually as engineers, sometimes as teachers (that’s me), occasionally from support or comms. Then we specialize in whichever branch fits our background. Teachers gravitate toward dev ed. Engineers often land in dev experience. Developer marketing is its own strange beast because developers, famously, hate being marketed to, and pulling that off without insulting your audience is a real skill.

The thing I want people to take from this: if you’re doing the work — speaking, writing, organizing, answering questions in a community Slack — you’re already doing DevRel, even if nobody’s put it in your title yet. That was true for Chris, and it was true for me long before GoDaddy.

The AI conversation (with Claude literally open in the background)

Full disclosure, I made on the show: I had Claude running on the side during the recording, hitting accept on a couple of issues. I’m not going to pretend I don’t use these tools.

Here’s some of what I actually use AI for:

• Captioning and transcription for Learn.WordPress.org videos and Big Orange Heart’s Wordfest events back during the pandemic. This is where I started, and it’s still one of the most defensible uses I make of it.
• Knowledge work. I run a daily review loop — RSS, YouTube, dev.to, daily.dev — and send things I want to keep into Readwise, which auto-creates structured notes in my Obsidian vault. I still manually highlight the things that matter. AI is the scaffolding, not the thinking.
• Descript for video editing — eye contact correction (within reason) and fixing the moments where I called Airo AI Builder “Airo” instead of saying the full product name.
• Claude Code on a hosted environment, not on my laptop. I’ve got it set up against my Elestio instance where I’m running Penpot, Activepieces (an OSS Zapier competitor), and n8n. I can hand off long-running work and go do something else.
• Vibe coding plugins. Post Formats for Block Themes. The XFN plugin (real old-school internet, IndieWeb-adjacent). Another one I’m almost done with. I would not have shipped these as fast as I have without AI. I also wouldn’t have shipped them at all without going back and asking AI to walk me through Playwright, Jest, PHPUnit, and security testing — the things I know engineers do but had never done myself.
• Research at the product-manager level. I borrowed this from how Tammy Lister and Nick Hamze used AI during Blocktober — having it survey the Gutenberg issue queue and adjacent plugins to identify the actual gaps before building. That’s a better use of AI than blindly asking it to write code.
• Translating my brain to humans. I info-dump. AI is decent at turning that into something a doctor or a coworker can actually parse. Nothing sensitive, no medical specifics — just “help me phrase these questions like a person who isn’t me.”

The license problem Juliette keeps warning us about

Chris brought up their recent conversation with Juliette Reinders Folmer on a previous episode, which is worth watching in full. Her concern, distilled: AI was trained on the open web, including a lot of open-source code under various licenses, and those licenses aren’t all compatible with each other. When you let AI write code for you, you have no real visibility into the provenance of what it’s giving you, and no certainty that the license under which you ship your project is actually compatible with the code embedded inside it.

She’s right. I don’t have a clean answer. What I told Chris is what I genuinely do: I prompt for license awareness. Look up the license on every piece of code you’re pulling from. Tell me if it’s MIT, GPL, Apache, or something else. Flag conflicts. That is not the same as Juliette reviewing my code — Juliette doesn’t want to review my code, she’s the maintainer of WPCS and PHPCS, and a small number of people in the world understand that intersection of the language and the standards the way she does. But it’s better than not asking at all.

I also suspect, watching the early case law on AI-generated work, that the courts are going to land roughly on “we can’t trace it, so the license doesn’t attach.” That is probably not the answer that protects open source. It’s just the answer that’s easier to enforce. I’d love to be wrong.

The maintainer gap

This is the part I keep turning over.

cURL had to shut down its HackerOne bug bounty program because AI-generated “vulnerability reports” were drowning the maintainers. The Matplotlib maintainer was harassed by an OpenClaw bot for not accepting a pull request. These are load-bearing pieces of the internet. WordPress calls cURL. When something goes wrong with it, suddenly, people can’t upload zip files to their WordPress sites.

What worries me most is the widening gap AI is creating between developers and the people who maintain the tools their products depend on. AI can find the package, install the library, and patch the missing pieces—so you can ship without ever seeing the maintainers behind it. That means not knowing who keeps your stack running, who is close to burnout, or how to support the work through thanks, funding, or contributions.

That’s not an AI problem, exactly. It’s an “always was” problem that AI is accelerating. But it’s worth naming, because the answer — if there is one — has to include developers deliberately closing that distance back up. Read the changelogs. Read the GitHub issues. Know whose work you’re standing on.

Where to listen and what’s next

The full episode is up on YouTube above, and Chris publishes Community + Code at communitycode.dev. Go subscribe. He’s having exactly the conversations our corner of the internet needs more of.

A few things I’m working on that came up in passing on the show:

• Another plugin, almost done, aimed at the IndieWeb crowd.
• The 7.0 testing coordination work, which is mostly invisible but is the kind of glue work I keep arguing matters.

If you took anything from this episode, I’d love to hear it — either in The WP Community Collective space, on Mastodon, or wherever you find me. And if you’re new to DevRel and feeling like a wallflower at your first event: find me. I owe Chris a chain of paying it forward, and I’m always happy to add to it.