The Human Side of DevRel in the Age of AI
It has never been easier to ship open source software. AI assistants write the first draft of a feature, open the pull request, review it, and sometimes merge it. Bug-finding bots comb the codebase while everyone sleeps. Work that used to eat a weekend now takes an afternoon, and a lot of projects are moving faster than they ever have.
That speed hides an uncomfortable question: is the community actually healthy?
Velocity and health are not the same thing. A repository can be busy and still be lonely. The questions that measure a community's health are the ones the activity charts don't answer: whether contributors come back after their first PR, whether the project draws people from more than one or two organizations, and whether more questions get answered than asked. Those are the usual goals of any big, active project, along with the usual problems. As AI ramps up, they get better and worse at the same time. The rest of this is about why, and what you can do about it.
What AI already changed
Start with how a repository runs now. The old loop was human all the way around: someone authored a change, someone hunted for bugs, someone reviewed it, someone merged it. Today an agent can sit at every one of those stations. It authors the PR, runs a pass to find bugs, leaves review comments, and waits at the merge button for a human to nod, if a human is even required. The human is still in the loop, but in more and more places the human is optional.
Look at where the humans are in that loop. We are slowly disappearing from it. We're automating ourselves out of the old work, and the new work is keeping the wheel spinning faster. A lot of the tooling you reach for every day exists precisely to help you do that, and on balance that is a good thing. The drudgery leaving is the better half of the story.
Content went through the same shift. AI writes a growing share of the blog posts, docs, and tutorials. AI also reads them, since agents now consume documentation on a developer's behalf far more often than the developer does directly. Human blog readership is down. Search traffic is down. The audience you used to write for is increasingly a model.
If that leaves you feeling like nobody writes, reads, codes, or cares anymore, you're partly right. Some of the work that used to require a person no longer does, and pretending otherwise won't help anyone.
The part that doesn't change
Here is what the activity charts miss. People still want the things they always wanted from a community: collaboration, commiseration, and communication. The urge to build something with other people, to complain to someone who gets it, and to be heard, none of that went away when the tooling got faster.
Sometimes that means real help with a real problem. Sometimes it is just wanting to vent to someone who has been there, or a second opinion on an idea before you sink a weekend into it, or plain reassurance that the idea is worth the effort at all. Not everyone wants to work alone, and most people do their best work when they don't have to.
That is why your voice still matters, maybe more now than ever. Opinions and lived experience supply something a model can't, and the most important voice in the room might belong to the person who just showed up. The whole job is working out how to notice that voice and nurture it.
The best thing you can do as a human, then, is to be human. So the useful question isn't whether AI can do your job. It's what people still do better than AI, and how to spend more of your time there.
I spend most of mine on Apache Superset, an open source data exploration and visualization project with a contributor base in the thousands and a Slack community north of twenty thousand people. I have been lucky enough to wear a lot of hats there and at Preset, the company behind much of Superset's development: designer, staff engineer, engineering manager, developer relations, and lately even marketing. Developer relations is where my heart settled, and over the years I kept asking what it actually is that I do to support a community of developers.
So I built a framework for it, a way to catalog my own investments in the community and decide where the next hour of effort should go. It came out as ten roles, the hats a community person puts on over the course of a week. None of them is automated away, because all of them are really about stewardship: keeping the project somewhere people want to stay.
The Greeter
The Greeter stands at the front door and owns the first impression. They watch the issue tracker and the forums for new faces, reply quickly and warmly to first-time contributors, keep the "getting started" docs honest, host the occasional office hour, celebrate first contributions in public, and steer questions to the channels where they'll get answered.
Why it matters
The speed and warmth of that first response is one of the strongest signals of whether someone comes back. A newcomer who gets a friendly reply the same day is far more likely to open a second PR than one whose first attempt sits untouched for two weeks. A bot can auto-label an issue and post a templated thank-you. Being noticed by an actual person is a different feeling, and it's the one that turns a drive-by contributor into a regular.
The Custodian
The Custodian keeps the house in order. They audit docs for accuracy, close out stale issues and PRs with a real explanation, archive dead repositories with a clear pointer to what replaced them, clear outdated information out of Slack and the wiki, keep CI and the bots running, follow up on work that quietly got dropped, and resurface good initiatives that stalled.
Why it matters
A project broadcasts its health through small details. A failing CI badge, a three-year-old "good first issue" that nobody ever picked up, docs that reference a feature you removed two releases ago. Each one tells a newcomer the lights might be off. Tidiness is a trust signal, and someone has to do the unglamorous work of maintaining it.
The Matchmaker
The Matchmaker connects people. They carry a mental map of who's working on what, pair contributors with the right reviewers and mentors, pull subject matter experts into the threads that need them, set up collaboration and pairing sessions, and make introductions between people who should know each other.
Why it matters
In a big project, most of the important knowledge lives in people's heads, not in the docs. The fastest path to an answer is often a name. AI can surface a related issue from two years ago, but it can't tell you that the person who wrote that subsystem is approachable, lives three time zones over, and would genuinely enjoy a fifteen-minute call. Those introductions are how knowledge moves and how people put down roots.
The Gardener
The Gardener tends ideas. They listen for patterns starting to form in the discussions, make space for promising ideas to develop, run the occasional brainstorm, prune threads that aren't going anywhere, move conversations to the right venue, give the good ideas enough attention to take root, and balance quick wins against slower long-term bets.
Why it matters
Good ideas usually show up half-formed and easy to lose in the noise. Without someone watching for the seed and protecting it long enough to grow, a project either stagnates or chases every shiny distraction. The Gardener is the difference between a roadmap that comes from the community and one that gets imposed on it.
The Investor
The Investor spends today's attention on next year's health. They champion the refactors and technical-debt paydown nobody wants to prioritize, build the contribution templates and automation that make work repeatable, write the governance docs and contributor guides, experiment with new process and tooling, measure what's actually working, and argue for the resources the community needs to keep going.
Why it matters
Communities grow until something cracks under the weight. The Investor watches the load-bearing parts and reinforces them before they give. On Superset, a lot of this comes down to actually looking at the numbers. We keep a public community dashboard tracking stars, repo activity, and new contributors over time, so decisions about where to invest come from what the data shows instead of a gut feeling. (That dashboard happens to be a Superset dashboard, which is a nice bit of dogfooding.)
The Tinkerer
The Tinkerer takes friction out of the system. They build the GitHub Actions, bots, and integrations that handle the mechanical work, automate triage and labeling, prototype new features to show what's possible, improve the local dev and testing setup, and share the tricks that make everyone faster.
Why it matters
Every minute a maintainer spends rubber-stamping labels is a minute they're not spending on a person. This is the role where AI helps the most, and that's the point. Hand the repetitive parts to bots and you free up the human parts for humans. The goal of all that automation isn't to replace the community person. It's to give them their time back for the work only they can do.
The Politician
The Politician keeps the governance functional. They communicate policy clearly and consistently, mediate conflicts by pointing back to shared values, build consensus when a new policy is needed, represent the community's interests to the organizations that fund or depend on it, balance competing agendas with some diplomacy, document how decisions get made, and let the governance evolve as the project grows.
Why it matters
Every active project eventually hits a disagreement that money or code can't resolve. Whether that moment fractures the community or strengthens it depends on someone who can hold the room and broker a compromise people will actually accept. AI can summarize a contentious thread in seconds. It cannot earn the trust that makes a hard decision stick.
The Cartographer
The Cartographer shows everyone where the project is headed. They maintain and communicate the roadmap, track progress against goals, document the big architectural decisions, connect day-to-day work back to the larger objectives, post regular status updates, and flag roadblocks before they turn into emergencies.
Why it matters
Contributors give more when they can see how their piece fits into the whole. A clear roadmap is also a recruiting tool, since it tells a prospective contributor exactly where they could plug in. Superset runs much of this in the open through its improvement proposal process, so the map isn't locked in one person's head. It's a shared document anyone can read and steer by.
The Oracle
The Oracle holds the institutional memory. They document the reasoning behind historical decisions, give context on why features and code got deprecated, connect new proposals to lessons from old attempts, answer questions about how the project evolved, keep a record of recurring problems and their fixes, and tell the stories that remind everyone what the project stands for.
Why it matters
A project that forgets its history relives its mistakes. As contributors rotate in and out, the Oracle keeps hard-won lessons from walking out the door with them. An AI trained on your repo can recite what changed and when. The Oracle remembers why, and can tell you that the "obvious" fix someone just proposed was tried in 2021 and caused a mess. That context saves a community from going in circles.
The Advocate
The Advocate keeps the community fair and open. They amplify voices that don't usually get heard, make sure credit lands where it's due, step in when a thread turns unproductive or unkind, hold space for dissent, connect members to speaking and leadership opportunities, watch for bias creeping into decisions, and celebrate the contributions that aren't code.
Why it matters
A mix of perspectives produces better software, and people stay in places where they feel seen. Code is the visible contribution, but triage, documentation, translation, mentorship, and event organizing keep a project alive just as much. The Advocate makes sure the people doing that work get counted, and that the door stays open for the next person who doesn't look like the last one.
Wearing all the hats
You don't pick one of these and specialize. Most good community people put on several of these hats in a single day, leaning on whichever ones come naturally. The Greeter in you welcomes a newcomer in the morning; the Custodian closes out a pile of stale issues after lunch; the Politician shows up for a governance call before you log off.
That's also the value of naming them. The set works as a map for your own growth. Find the hats you reach for out of habit, then find the ones gathering dust, and try one on. Be a generalist, play to your strengths, and use the rest as a guide for where to stretch.
What humans still win at
AI is genuinely good at creating. It writes, it codes, it summarizes, it generates, and it does all of it faster than you can. Fighting it on that ground is a losing game, and there's no reason to.
None of this is an argument against AI. I use it for the vast majority of my own work, and if your computer isn't doing something useful while you sleep, you're doing it wrong. The point is what you do with the hours it gives back. Spend them on the part of the work that was always yours: being a good steward for the people who show up, fostering the human qualities you already have, and teaching the next person to do the same so it scales past you.
What humans still win at is communicating. Making another person feel like they belong somewhere, like their work mattered and someone noticed, is the thing the machines can't fake. So the job is to give contributors a stable home worth moving into: a place that's welcoming, well-kept, well-connected, and built to last. Build that home, keep it in good repair, and the people will come and stay.
There's a version of this for everyone. The best thing a user can do for an open source project is tell the world they use it. The best thing a maintainer can do is support the people who show up and give them a reason to stay.
It feels right to leave the last word to Stephen Hawking, who put it better than I can:
With the technology at our disposal, the possibilities are unbounded. All we need to do is to make sure we keep talking.
