# DevRel Directory - full content
> The main place for Developer Relations: guides, tools, communities, and jobs for DevRel professionals.
Last updated: 2026-07-22 (newest health-check verification across directory listings)
# DevRel Documentation (https://devrel.directory/docs)
devrel.directory is an open knowledge base for Developer Relations.
It explains what DevRel is, how the roles differ, and how to build a program that holds up in practice.
The content is written for practitioners, cites its sources, and is free to use.
New to the field? [Start here](/start) instead - a sequenced route in, built from live data: what to read in order, which communities are actually alive, which calls for papers are open now, and what the job market is really hiring for.
## DevRel in the AI era [#devrel-in-the-ai-era]
How DevRel changes when developers bring AI agents - the practical guide: [Agents Are Your New Developers](/docs/ai-era/agents-as-your-new-developers).
llms.txt, Markdown mirrors, and the structure that makes documentation retrievable and quotable by AI assistants: [Writing Docs LLMs Can Use](/docs/ai-era/docs-for-llms).
Why an MCP server is a DevRel surface, what to expose through it, and the work that makes one succeed: [MCP Servers Are the New SDK](/docs/ai-era/mcp-servers-as-devrel-surface).
Why classic web analytics undercount AI-driven adoption and what you can measure honestly instead: [Measuring Adoption You Cannot See](/docs/ai-era/measuring-ai-driven-adoption).
## Start with the fundamentals [#start-with-the-fundamentals]
What DevRel is and what it is not, with the research behind the definition: [Definition of Developer Relations](/docs/fundamentals/definition).
Why developer communities compound like network effects and what that means for a business: [The Importance of DevRel](/docs/fundamentals/importance).
Advocate, evangelist, developer experience, developer marketing: how the roles differ and where they overlap: [Roles and Responsibilities](/docs/fundamentals/roles-and-responsibilities).
Objectives, audience, and measurable goals for a DevRel program: [Crafting a DevRel Strategy](/docs/fundamentals/devrel-strategy).
How to build research-backed personas instead of guessing who your developers are: [Understanding Developer Personas](/docs/fundamentals/understanding-developer-personas).
## Put it into practice [#put-it-into-practice]
The core activity clusters, when each earns its place, and how to avoid activity soup: [DevRel Activities](/docs/practices/devrel-activities).
From the first fifty members to programs that scale, plus behaving well in communities you do not own: [Community Building](/docs/practices/community-building).
Content types, writing craft, distribution, and a pipeline a small team can sustain: [Content Creation](/docs/practices/content-creation).
## What is Developer Relations? [#what-is-developer-relations]
Developer Relations (DevRel) is the function that connects a company and the developers who build with its products.
Done well, it drives adoption, feeds honest feedback back into the product, and builds communities that outlast any single campaign.
"DevRel is more than just a job title - it's a strategic approach to building and nurturing relationships between companies and developers." - From our [Definition of Developer Relations](/docs/fundamentals/definition)
## More on the site [#more-on-the-site]
Longer pieces on strategy and planning live in the [blog](/blog).
What changed on the site and when: [changelog](/changelog).
Listings, jobs, events, and docs improvements are all welcome - start with the [contributing guide](/docs/additional-resources/contributing).
## This knowledge base is growing [#this-knowledge-base-is-growing]
The docs are being reworked and expanded section by section.
If a topic you need is missing or a page falls short, send a correction or a suggestion - the [contributing guide](/docs/additional-resources/contributing) explains how.
---
# Contributing to devrel.directory (https://devrel.directory/docs/additional-resources/contributing)
devrel.directory is an open resource, and contributions from people who do DevRel work are what keep it useful.
## What contributions are welcome [#what-contributions-are-welcome]
* **Directory listings**: tools, communities, and resources for the [directory](/directory). The submit button on that page opens a pre-filled email with the expected fields.
* **Job posts**: open DevRel roles for the [job board](/jobs). Free community listings go through the submit button there, which pre-fills an email to [jobs@devrel.directory](mailto:jobs@devrel.directory).
* **Event submissions**: DevRel conferences and meetups for the [events page](/events), via the submit button on that page.
* **Docs improvements**: corrections, sharper examples, or expanded sections anywhere in the knowledge base. Email [submit@devrel.directory](mailto:submit@devrel.directory?subject=Docs%20improvement) with the page and the change you have in mind.
## How changes land [#how-changes-land]
Every submission is reviewed by the maintainer before it goes live, against the criteria published in [How we curate](/docs/additional-resources/how-we-curate) - reading that page first is the best way to get a submission accepted.
Listings, events, and docs suggestions go to [submit@devrel.directory](mailto:submit@devrel.directory); job posts go to [jobs@devrel.directory](mailto:jobs@devrel.directory).
Include the essentials up front - what it is, where it lives, and a line on why it belongs - and it will typically be live within a few days.
## The editorial bar [#the-editorial-bar]
Docs contributions are held to a concrete standard: specific guidance, real examples, numbers where they exist, and honest tradeoffs.
Generic filler that could appear on any site gets rejected, even when it is well written.
The bar is strict for a structural reason: every docs page ships verbatim into the site's AI-facing mirrors at [/llms.txt](/llms.txt) and [/llms-full.txt](/llms-full.txt), and each page is served as raw Markdown at its own `.md` endpoint.
Thin content therefore does not just read badly on the page - it degrades how AI assistants represent the site to developers who never visit it directly.
## Getting help [#getting-help]
* Email [submit@devrel.directory](mailto:submit@devrel.directory)
* Message [@0xfabs](https://x.com/0xfabs) on X
---
# For agents and developers (https://devrel.directory/docs/additional-resources/for-agents)
devrel.directory is built to be read by machines as much as by people.
Every surface below is read-only, unauthenticated, and free to use: no API key, no signup, nothing to negotiate.
This page is the index; where a surface has deeper documentation, it links there.
## Markdown mirrors [#markdown-mirrors]
The site's content is available as plain Markdown, following the [llms.txt convention](https://llmstxt.org):
* [/llms.txt](/llms.txt): the index. The site's name, a one-line summary, and a linked map of the docs, blog, directory, jobs, events, feeds, and the MCP server.
* [/llms-full.txt](/llms-full.txt): the full corpus. Every docs page plus every directory listing, active job, and upcoming event, in one Markdown file.
* Markdown twins: append `.md` to a page URL to get that page as raw Markdown. This works for every docs page (`/docs/.md`, including [this one](/docs/additional-resources/for-agents.md)) and every directory listing (`/directory/.md`).
The thinking behind this setup is covered in [Writing Docs LLMs Can Use](/docs/ai-era/docs-for-llms); this site is its own reference implementation.
## MCP server [#mcp-server]
A remote Model Context Protocol server runs at `https://devrel.directory/mcp`, speaking Streamable HTTP.
It is read-only and unauthenticated, and exposes six tools: `search_directory`, `get_listing`, `list_jobs`, `list_events`, `directory_stats`, and `search_docs`.
It is published to the official MCP registry as `directory.devrel/devrel-directory`.
Connection snippets and full tool descriptions are on the [MCP server](/docs/additional-resources/mcp-server) page.
## Feeds [#feeds]
* [/rss.xml](/rss.xml): blog posts.
* [/events.ics](/events.ics): every upcoming DevRel event as an all-day iCal entry.
* [/cfps.ics](/cfps.ics): open CFP deadlines as timed iCal entries, each with a one-week reminder.
## Crawler policy [#crawler-policy]
AI crawlers are explicitly welcome.
[robots.txt](/robots.txt) names GPTBot, ClaudeBot, Claude-User, PerplexityBot, and Google-Extended with allow-all groups of their own, and the generic group allows everything for every other crawler too.
The only disallowed paths, for all user agents, are the payment and webhook endpoints under `/api`, which render nothing worth indexing.
The sitemap linked from robots.txt covers the site's indexable pages.
## Rate limits and fair use [#rate-limits-and-fair-use]
Two surfaces are rate limited per client, because each request does real work:
* `/mcp`: 60 requests per minute.
* `/llms-full.txt`: 30 requests per minute.
Requests over a limit get a `429` with a `Retry-After` header; back off for that long and retry.
Everything else is currently unthrottled, subject to fair use.
If you plan sustained high-volume access, email [submit@devrel.directory](mailto:submit@devrel.directory) first so it can be accommodated rather than mistaken for abuse.
## Attribution [#attribution]
If your agent or product cites data from here, please link back to [devrel.directory](https://devrel.directory) so readers can find the source.
---
# How we curate (https://devrel.directory/docs/additional-resources/how-we-curate)
Every listing on devrel.directory is reviewed by a person before it goes live, re-checked by automation on a schedule afterwards, and removed when it stops being true.
This page states those rules as they are actually enforced, so you can judge how much weight to give what you find here.
## What gets a listing [#what-gets-a-listing]
The [directory](/directory) lists tools, communities, newsletters, podcasts, and agencies.
Three things have to hold:
* **Relevant to DevRel practitioners.** The entry has to be something a person doing Developer Relations work would reach for: running a program, a community, docs, content, events, or measurement. General-purpose products with no specific DevRel use do not qualify, however good they are.
* **Live and operating.** The link must resolve to an operating product or community, and it must keep resolving: the same bar is re-checked automatically for as long as the listing exists.
* **Hand-reviewed.** Every listing goes live only after the maintainer has looked at the product and written or edited the entry. Nothing is auto-imported.
A listing cannot be bought, and submitting is free.
New listings only ever arrive through [submissions](/docs/additional-resources/contributing) and the maintainer's own research; the automated pipeline described below is structurally unable to add one - it can only update or remove what a person already accepted.
## The health pipeline [#the-health-pipeline]
Once a week, an automated run re-checks every listing in the directory:
* **Link health.** Each listing's URL is fetched. A dead link (HTTP errors, network failures), a parked domain (matched against registrar-lander fingerprints), and a redirect to an unrelated domain are each recorded. Rate limiting is deliberately not held against a listing: an HTTP 429 proves a live origin.
* **A strike, not an instant removal.** A dead or parked observation is a strike. Removal is only proposed after two separate weekly runs observed the problem, so a one-day outage can never delete a listing. A listing that recovers has its strike cleared.
* **Drift review.** For pages that answer, the live page's own title and description are compared against the stored description. A description the product has outgrown gets a proposed rewrite; a product that pivoted into something else gets a removal proposal.
* **Moved sites.** A redirect to a domain that is recognizably the same project becomes a proposed URL update; anything else is flagged for human review instead of silently rewritten.
* **A human reviews every change.** The run's entire proposal - updates, removals, and flags - lands as one pull request that the maintainer reads and either merges or rejects. Nothing the pipeline decides reaches the site without that review.
The **Verified** badge on a listing shows the month this pipeline most recently confirmed the link resolved to a live product page.
A listing without the badge has simply not been confirmed by a run yet; a listing that keeps failing the check leaves the directory.
## Jobs rules [#jobs-rules]
The [job board](/jobs) follows the same discipline with sharper deadlines:
* **DevRel-family roles only.** Candidates scraped from the public job boards of watched companies pass a DevRel title filter and an automated triage before the maintainer reviews them; submitted and paid postings are added by hand and held to the same bar. Adjacent engineering roles do not qualify.
* **Every posting expires.** A job listing runs for at most 60 days from its posting date, no exceptions, so a stale opening cannot linger.
* **Twice-weekly liveness checks.** Listed jobs are re-checked against the company's own board twice a week; a posting that has closed is proposed for removal in that run's pull request.
* **Salaries are verbatim or absent.** Stated pay is carried straight from the posting (a range may render in compact form, like $128k-187k); a posting that states no pay shows none. Figures are never estimated, inferred, or filled in from market data.
## Salary figures [#salary-figures]
A single posting shows the pay it states, as above.
The aggregate figures - the median band on the [job board](/jobs), and the salary block the [MCP server](/docs/additional-resources/mcp-server) returns - are derived from those stated numbers by these rules, and nothing else:
* **USD only, never blended.** A role counts toward the figures only if it states pay in USD; a stated amount with no currency is read as USD. Roles quoted in other currencies are left out rather than converted, so no exchange rate ever enters the numbers.
* **Live postings only.** The sample is the roles active on the board that day. Because every posting expires within 60 days, the figures move as the board turns over - they describe what is open now, not a market history.
* **The median is taken over per-role midpoints.** A role stating a range contributes the midpoint of that range; a role stating a single bound ("$150k+", "up to $90k") contributes that bound. The quoted minimum and maximum are the lowest and highest bounds any role in the sample states.
* **The sample size travels with the figure.** Every aggregate carries n, the number of roles disclosing pay. Below 20 the job board drops its salary headline entirely rather than caveat it, because the sample is senior-skewed and the median swings by double digits when one posting enters or leaves. The MCP server still returns the figures at lower n, flagged as a small sample, so an agent can see them and judge for itself.
## Money and editorial judgment [#money-and-editorial-judgment]
The two never touch:
* **Directory placement is never paid.** There is no price at which a listing, a description, a tag, or a position in the directory can be bought.
* **Featured job posts are the only paid product, and the label travels with the pin.** A featured post is pinned to the top of the job list on every surface that carries it: highlighted and tagged "Featured" on the job board, labeled a paid placement in the [machine-readable corpus](/llms-full.txt), and flagged featured by the [MCP server](/docs/additional-resources/mcp-server). Payment buys that placement for 30 days - nothing about the posting's content, and nothing in the directory.
* **Editorial verdicts are never sold.** Descriptions, removals, alternatives, and any "Our take" note reflect the maintainer's judgment of the product, dated so you can tell how current that judgment is. No part of that judgment is available for sponsorship.
## Corrections and submissions [#corrections-and-submissions]
If a listing is wrong, out of date, or missing, [contributing](/docs/additional-resources/contributing) explains how to submit a fix, a new entry, a job, or an event - every submission lands in the same review process described above.
---
# MCP server (https://devrel.directory/docs/additional-resources/mcp-server)
devrel.directory runs a remote [Model Context Protocol](https://modelcontextprotocol.io) server so AI agents can query the directory, the job board, the events calendar, and the docs directly.
It is read-only and unauthenticated: there is nothing to sign up for and no key to manage.
The server speaks Streamable HTTP at a single endpoint:
```
https://devrel.directory/mcp
```
## Tools [#tools]
The server exposes six tools.
Every result carries a canonical devrel.directory URL alongside any external link, so an agent can always cite the source.
* **search\_directory** - search the listings of DevRel tools, communities, newsletters, podcasts, and agencies by query and/or category.
* **get\_listing** - full detail for one listing by slug, including similar listings and any open jobs or upcoming events cross-linked to the same company.
* **list\_jobs** - currently open DevRel roles, filterable by query, remote, employment type, seniority level, and minimum salary (the same filters as the jobs page), with salary passed through exactly as the posting states it.
* **list\_events** - DevRel conferences and their call-for-papers deadlines, with filters for upcoming-only and open-CFP-only.
* **directory\_stats** - aggregate counts in one call: listings by category, active jobs with remote share, the remote/hybrid/onsite workplace mix, and distinct hiring companies, salary min/median/max over USD-stated roles only (always with the sample size `n`), and upcoming events with open and closing-soon CFPs.
* **search\_docs** - search the unified index of docs guides, blog posts, listings, jobs, and events (open CFPs included), with event results deep-linking to the specific event.
## Connect [#connect]
### Claude Code [#claude-code]
```sh
claude mcp add --transport http devrel https://devrel.directory/mcp
```
### Claude Desktop and Cursor [#claude-desktop-and-cursor]
Add the server to your MCP configuration:
```json
{
"mcpServers": {
"devrel": {
"url": "https://devrel.directory/mcp"
}
}
}
```
## Notes [#notes]
The server is read-only: the tools only ever return data, and none of them mutate anything.
It is unauthenticated and rate-limited per client, so keep requests reasonable.
Legacy SSE transport is not supported; use Streamable HTTP.
---
# Agents Are Your New Developers (https://devrel.directory/docs/ai-era/agents-as-your-new-developers)
## What changed [#what-changed]
For two decades, developer adoption started with a person: someone searched, read, evaluated, and typed the first API call.
That assumption is now quietly wrong.
An increasing share of first contact with a developer product is an AI system acting on a developer's behalf:
a coding agent scaffolding an integration inside an editor, a chat assistant comparing options and quoting docs, or an autonomous agent following a runbook end to end.
The developer is still in charge, but they arrive later: after a model has already read your docs, formed an opinion, and maybe written the first hundred lines against your API.
This is not a prediction, it is observable in traffic patterns most vendors already have:
AI crawlers and agent user agents in server logs, signups with no preceding web session, and support questions that quote model-generated code.
The practical shift for DevRel: your first user is often not a human anymore.
Your product now needs to make a good first impression on a machine that reads everything and forgives nothing.
## What agents need, versus what humans need [#what-agents-need-versus-what-humans-need]
Human developers tolerate ambiguity.
They skim, infer, hold context across pages, and forgive a stale screenshot if the idea is clear.
Agents fail differently, and what they need is stricter:
1. Deterministic quickstarts.
A step that "usually works" or depends on unstated environment assumptions will stall an agent every time.
Every prerequisite must be written down, in order, with no hidden state.
2. Copy-paste-complete snippets.
Code blocks that are runnable as-is, with imports, versions, and placeholders clearly marked.
An agent will run exactly what you wrote, including your typo.
3. Exact error messages.
Agents match errors verbatim against your docs.
Documenting the precise string of every common failure, with its fix, is now one of the highest-leverage docs tasks that exists.
4. Stable URLs and anchors.
Retrieval systems and model memories reference URLs; every broken link is an answer your product no longer appears in.
5. No marketing in the critical path.
A human skips the value proposition paragraph; a model treats it as signal and repeats it instead of the setup steps.
Keep positioning on marketing pages and keep task pages about the task.
Notice that every one of these also makes docs better for humans.
Optimizing for agents is not a separate track; it is the strictest version of docs quality you already believed in.
## The new funnel [#the-new-funnel]
The classic funnel was search, docs, signup, first call.
The agent-era funnel has different stages, and DevRel can influence every one of them:
1. Model training data.
Models learn your product from public text: docs, blog posts, forum answers, open-source code.
Influence: publish substantial, accurate, openly accessible content and keep it consistent, because contradictions in public text become contradictions in model answers.
This compounds slowly and is hard to reverse, in both directions.
2. Agent retrieval.
At question time, many assistants fetch live pages: your docs, your [/llms.txt](/llms.txt) index, community threads.
Influence: serve clean Markdown, keep an accurate llms.txt, make key pages reachable without JavaScript, and answer recurring questions in indexable places instead of ephemeral chat.
3. Tool docs and machine surfaces.
Agents that act, not just answer, work through machine-readable surfaces: OpenAPI specs, SDK types, MCP servers, CLI help text.
Influence: treat these as first-class documentation, because for an agent they are the product.
4. First successful call.
The agent runs the quickstart.
Either it works deterministically, or the developer watching concludes your product fights their tools.
Influence: instrument time-to-first-successful-call and treat every agent stall as a bug.
## Audit your quickstart with an agent [#audit-your-quickstart-with-an-agent]
The single most useful exercise: have a coding agent follow your quickstart cold, in a clean environment, with no help.
1. Start a fresh session with a capable coding agent and give it one instruction: "Integrate this product into a new project, following its documentation."
2. Watch where it stalls: the unstated prerequisite, the placeholder it cannot resolve, the step that assumes a dashboard click, the error message that appears nowhere in your docs.
3. Fix every stall point in the docs, not in the prompt.
The next thousand agents will not have your prompt.
4. Repeat monthly and after every breaking release, the same way you would run any regression test.
If an agent cannot complete your quickstart, an increasing share of your evaluations now fail before a human ever sees your product.
Teams consistently overestimate how well their docs survive this test until they run it.
## What this means for the DevRel role [#what-this-means-for-the-devrel-role]
The work shifts in emphasis, not in purpose.
The mission described in [the definition of DevRel](/docs/fundamentals/definition) stands: build trust with developers and remove friction between them and the product.
What changes is where the friction lives:
* Documentation work moves further up the priority list, because docs are now both the human interface and the machine interface.
* Community answers become training data: a correct, well-written answer in a public forum keeps teaching models for years.
* Developer experience work gains a new test subject: the agent-run integration, which is stricter than any human tester.
* Measurement needs new instruments, covered in [measuring adoption you cannot see](/docs/ai-era/measuring-ai-driven-adoption).
The rest of this section covers the concrete practices:
[writing docs LLMs can use](/docs/ai-era/docs-for-llms), [MCP servers are the new SDK](/docs/ai-era/mcp-servers-as-devrel-surface), and [measuring AI-driven adoption](/docs/ai-era/measuring-ai-driven-adoption).
## Related [#related]
* [Writing docs LLMs can use](/docs/ai-era/docs-for-llms) for the documentation practices in depth
* [Understanding developer personas](/docs/fundamentals/understanding-developer-personas) - agents arrive on behalf of personas you should still know by name
* [The importance of DevRel](/docs/fundamentals/importance) for the compounding logic that AI distribution accelerates
---
# Writing Docs LLMs Can Use (https://devrel.directory/docs/ai-era/docs-for-llms)
## Two audiences, one source [#two-audiences-one-source]
Documentation now serves two readers: the developer, and the AI systems answering that developer's questions.
The second reader consumes more of your docs than any human ever will, and it decides what to quote.
The good news: the two audiences want almost the same thing.
Clear structure, self-contained explanations, runnable code.
The difference is tolerance.
A human recovers from a vague heading or a screenshot of code; a retrieval pipeline just returns someone else's page instead.
## llms.txt and llms-full.txt [#llmstxt-and-llms-fulltxt]
The llms.txt convention gives AI systems a machine-friendly entry point to your site:
* `/llms.txt` is a Markdown index: the site's name, a one-line summary, and a curated list of links with descriptions.
It tells an agent what exists and where, without HTML noise.
* `/llms-full.txt` inlines the full documentation content as one Markdown file, for consumers that want everything in a single fetch.
This site practices what this page preaches:
[devrel.directory/llms.txt](/llms.txt) is the live index, and [devrel.directory/llms-full.txt](/llms-full.txt) is the full-content mirror.
Every docs page here is also available as raw Markdown by appending `.md` to its URL, and the page actions above let you copy the page or open it in an assistant directly.
Two honest caveats belong next to any llms.txt advice:
1. Adoption by AI vendors is uneven and changing; treat llms.txt as cheap insurance and a clear signal of intent, not a guaranteed pipeline.
2. An llms.txt that promises pages which 404, or describes content that no longer exists, is worse than none.
Generate it from your real content, never by hand.
## Structure that retrieves well [#structure-that-retrieves-well]
Retrieval systems pull chunks, not sites.
Whether your content surfaces depends on how well each chunk stands alone:
1. One concept per page.
A page that answers one question cleanly beats a mega-page where the answer hides in section four.
2. Self-contained sections.
Each heading plus its content should make sense without the surrounding page, because that is exactly how it will be quoted.
Write headings that state the topic ("Rotate an API key") rather than tease it ("Keeping things secure").
3. Descriptive frontmatter.
Titles and descriptions become index entries, search snippets, and llms.txt lines; write them as accurate one-line summaries, not slogans.
4. Code blocks with language tags.
Tagged blocks survive Markdown conversion and tell every consumer what they are looking at.
5. Text, not pixels.
Content locked inside interactive components, videos without transcripts, or images of terminal output is invisible to most of this pipeline.
Interactive elements can stay, but the information in them must also exist as text.
6. Stable anchors.
Heading anchors are how deep links and citations survive; renaming them casually breaks both.
## Markdown-first distribution [#markdown-first-distribution]
The durable strategy underneath all of this: keep a plain Markdown mirror of your documentation and let machines fetch it.
* Serve each docs page as raw Markdown at a predictable URL, next to the HTML version.
* Keep the mirror generated from the same source as the site, so it can never drift.
* Make copy-for-AI trivial: a copy-as-Markdown action on every page costs little and removes the last excuse for a model to work from a scraped, mangled version.
Markdown-first also future-proofs you.
HTML rendering fashions change; UTF-8 text with headings has outlived every one of them.
The test for all of this is empirical: paste a docs URL into an assistant and ask a real integration question.
If the answer misquotes or misses your docs, find out what the model actually received, then fix that.
## What not to do [#what-not-to-do]
The common failure modes, all observed in the wild:
* JavaScript-only content.
If the text renders only after client-side execution, a large class of crawlers and fetchers sees an empty shell.
* Paywalled or login-walled quickstarts.
Whatever is behind the wall does not exist in model answers; keep at least the evaluation path public.
* Screenshots of code and terminal output.
Unreadable to the pipeline, uncopyable for humans, stale within months.
Ship text with syntax highlighting instead.
* PDF-only documentation.
Technically parseable, practically mangled: layout, code, and tables rarely survive.
* Aggressive bot-blocking without allowlists.
Blanket rules written for scrapers routinely block the assistants your developers use; decide your crawler policy deliberately, as covered in [measuring AI-driven adoption](/docs/ai-era/measuring-ai-driven-adoption).
* Marketing prose inside reference pages.
Models compress; make sure what survives compression is the instruction, not the adjectives.
## A checklist to ship this quarter [#a-checklist-to-ship-this-quarter]
1. Generate `/llms.txt` from your content source and link it in your footer.
2. Add `/llms-full.txt` or per-page Markdown endpoints, whichever your stack makes easy; both is better.
3. Rewrite the ten most-retrieved pages for self-containedness: descriptive headings, complete snippets, exact error strings.
4. Add transcripts or text equivalents for anything that currently lives only in video or images.
5. Run the assistant test on your top five integration questions and file a docs issue for every wrong answer.
None of this requires new tooling budget.
It is editorial discipline applied with a new reader in mind, and it improves the docs for humans at every step - the same point [agents are your new developers](/docs/ai-era/agents-as-your-new-developers) makes about the shift as a whole.
## Related [#related]
* [Agents are your new developers](/docs/ai-era/agents-as-your-new-developers) for why the machine reader now matters
* [MCP servers are the new SDK](/docs/ai-era/mcp-servers-as-devrel-surface) for going beyond text into executable surfaces
* [Measuring AI-driven adoption](/docs/ai-era/measuring-ai-driven-adoption) for knowing whether any of this works
---
# MCP Servers Are the New SDK (https://devrel.directory/docs/ai-era/mcp-servers-as-devrel-surface)
## What MCP is [#what-mcp-is]
The Model Context Protocol (MCP) is an open standard that lets AI applications connect to external tools and data sources through a common interface.
A product ships an MCP server describing its capabilities as tools; any MCP-capable client, such as coding agents, desktop assistants, and IDEs, can then discover and call those tools on a developer's behalf.
The [specification and ecosystem documentation](https://modelcontextprotocol.io) cover the protocol itself; this page covers why it belongs on a DevRel roadmap.
The DevRel-relevant property: an MCP server makes your product usable by every agent-equipped developer without them reading anything first.
The agent reads the tool descriptions, the developer states an intent, and your product gets exercised.
That is an onboarding surface, whether or not anyone planned it as one.
## The new SDK, with the old lessons [#the-new-sdk-with-the-old-lessons]
SDKs earned a generation of DevRel attention because they were where developer experience was won or lost.
MCP servers now sit in the same position, with the same failure modes:
* An SDK with confusing method names produced support tickets.
An MCP server with vague tool descriptions produces agents that call the wrong tool, silently, at scale.
* An SDK with a broken install ruined evaluations.
An MCP server that fails auth setup ruins evaluations that no human even witnesses.
* A well-designed SDK taught the product's mental model through its structure.
A well-designed MCP server does the same for both the agent and the developer watching it work.
Treat the server as a product interface with documentation properties, not as an integration checkbox.
## What to expose [#what-to-expose]
Resist the temptation to mirror your entire API.
An agent choosing among eighty near-identical tools performs worse than one choosing among five sharp ones, and every extra tool description consumes context the agent needs for the actual task.
A practical starting shape:
1. The three to five highest-value actions.
The operations a developer would demo in their first hour: create the core resource, query it, trigger the flagship capability.
2. Docs search as a tool.
A `search_docs` tool that returns relevant documentation snippets turns your entire knowledge base into agent context on demand.
For many products this single tool outperforms everything else on the server.
3. Read-only introspection.
Safe tools that let an agent inspect current state ("list projects", "get usage") make every subsequent action smarter and are low-risk to expose.
4. Deliberately excluded: destructive operations without confirmation semantics, admin surface, anything you would not want executed by a probabilistic caller.
Start narrow; widen with evidence.
Auth deserves early design attention.
The smoother pattern today is scoped API keys or OAuth flows that the client initiates once and reuses; anything requiring manual token surgery per session will filter out most of your audience.
Whatever you choose, document the failure states exactly: agents quote error strings at their humans, so those strings are now user-facing copy.
## Tool descriptions are documentation [#tool-descriptions-are-documentation]
The text fields in your MCP server are read by a model every single time it decides whether and how to call you.
They deserve the same editorial care as API reference, and the same review process:
* State what the tool does, when to use it, and when not to, in plain declarative prose.
* Describe every parameter with its format, constraints, and a realistic example value.
* Say what the tool returns, including the shape of errors.
* Version and changelog the descriptions; a silent description change alters agent behavior as surely as a code change.
Write tool descriptions as if they will be read aloud to a competent developer who has never seen your product.
That is almost literally what happens.
## The DevRel work around a server [#the-devrel-work-around-a-server]
Shipping the server is the engineering half.
The DevRel half determines whether anyone uses it:
1. Examples that exercise it.
Publish transcripts and short videos of real tasks completed through the server, in the popular clients.
Developers evaluate MCP servers by watching them work.
2. Registry and directory presence.
Clients ship with registries and curated lists, starting with the official [MCP registry](https://registry.modelcontextprotocol.io); being listed accurately, with working install instructions per client, is table stakes distribution.
3. A quickstart per client.
Installation differs across editors and assistants.
One page per major client, each following the deterministic-quickstart rules from [agents are your new developers](/docs/ai-era/agents-as-your-new-developers), beats one generic page.
4. Feedback loop instrumentation.
Log which tools get called, which fail, and where agents give up, then feed that into the same product-feedback loop DevRel already runs for humans.
5. Community support surface.
Questions about the server will land in your community; make sure answers become searchable text, since those answers train the next model.
## Deciding whether to build one [#deciding-whether-to-build-one]
An honest gate, in the spirit of every other investment on this site:
Build one early when your product is developer-facing infrastructure, your API's core loop fits in a handful of operations, and your audience already lives in agent-equipped editors.
Wait when your product requires heavy human judgment per operation, when destructive actions dominate the API, or when you cannot yet resource the documentation and support work above.
A half-maintained MCP server with stale descriptions actively misleads agents and burns the trust the rest of your DevRel program builds.
Whichever you choose, decide it deliberately and revisit quarterly.
The measurement half of that decision lives in [measuring AI-driven adoption](/docs/ai-era/measuring-ai-driven-adoption).
## Related [#related]
* [Agents are your new developers](/docs/ai-era/agents-as-your-new-developers) for the funnel this surface serves
* [Writing docs LLMs can use](/docs/ai-era/docs-for-llms) for the documentation discipline the server depends on
* [DevRel roles and responsibilities](/docs/fundamentals/roles-and-responsibilities) for where this work sits in a team
---
# Measuring Adoption You Cannot See (https://devrel.directory/docs/ai-era/measuring-ai-driven-adoption)
## The measurement gap [#the-measurement-gap]
Classic developer marketing measurement assumes a visible journey: a person visits pages, analytics scripts fire, campaigns get credit, and the funnel reconciles.
AI-mediated adoption breaks every link in that chain:
* AI crawlers and assistant fetchers do not execute your JavaScript beacons, so that traffic is invisible to script-based analytics.
* Agentic browsers do run JavaScript, but their sessions land in your analytics indistinguishable from humans, inflating the "human" bucket instead.
* Answers are consumed inside chat interfaces; the developer may never load your site before signing up.
* When they do arrive, they arrive directly at a signup or install command, stripped of referrer context.
* The influence often happened weeks earlier, inside a model's training data, where no attribution system reaches.
The result: teams see flat or declining docs traffic while API signups hold or grow, then misread it as a content problem.
The traffic did not disappear; it moved to readers your analytics cannot see.
The dangerous response is forcing the old dashboard to stay green: blocking AI crawlers to protect pageviews, or walling docs behind logins to force attribution.
Both trade real adoption for measurement comfort.
The blocking decision is per class of machine traffic, not one switch:
* Training crawlers feed future model weights.
Blocking them is a slow-compounding opt-out of the funnel's first stage, affordable only if your category's training data already leans your way.
* Retrieval and assistant fetchers are answering a live developer question right now.
Blocking them turns real evaluations away at the door and is almost never worth the saved bandwidth.
* Agentic browsers ride full browser sessions.
You cannot block them without blocking humans, so plan for measurement contamination instead.
## What you can measure today [#what-you-can-measure-today]
None of these are precise.
Together they form a usable picture:
1. AI traffic in server logs.
Script-based analytics miss AI crawlers and fetchers, but your server logs do not.
Count requests by known AI user agents (model-provider crawlers, assistant fetchers, agent frameworks) and track the trend, not the absolute number.
Watch which pages they fetch most; that is your machine-readership ranking.
2. Machine-surface fetches.
Requests for [/llms.txt](/llms.txt), /llms-full.txt, per-page Markdown endpoints, and your OpenAPI spec are almost purely non-human signals, which makes them unusually clean indicators.
3. Dark-funnel signups.
Accounts created with no prior web session from that identity.
This bucket always existed; its growth rate is your best single proxy for chat-mediated adoption.
Agentic-browser evaluations can create a prior session, so treat it as a floor, not an exact count.
4. Self-reported attribution.
A free-text "how did you hear about us" on signup, actually read by a human monthly.
Developers say "asked Claude", "ChatGPT suggested it", "my coding agent used it" with surprising frequency, and the phrasing tells you which surface did the work.
5. Support and community tells.
Questions that quote model-generated code, or reference instructions you never wrote, indicate models are onboarding people onto your product, correctly or not.
## Leading indicators worth tracking [#leading-indicators-worth-tracking]
The lagging metrics above confirm what already happened.
The leading ones tell you where answers are forming:
1. Presence in model answers.
Monthly, run a fixed set of category prompts ("best way to do X", "compare tools for Y") across the major assistants, with search enabled and disabled.
Record whether you appear, how accurately, and what gets cited.
Keep the prompt set stable so the trend means something.
2. Accuracy of model answers about your product.
Ask the assistants your top ten real integration questions and grade the answers.
Wrong answers are a docs bug with a distribution channel; fix the source text they retrieve, then re-test.
3. MCP server installs and tool-call volume, if you ship one, per [MCP servers as the new SDK](/docs/ai-era/mcp-servers-as-devrel-surface).
4. Agent-framework and registry integrations.
Being packaged into agent toolkits and client registries is distribution that compounds ahead of any traffic you can see.
## Reporting honestly [#reporting-honestly]
The credibility rules from classic DevRel measurement apply double here, because every number is soft:
* Report direction and mix, not false precision.
"Machine fetches up 40 percent quarter over quarter, dark-funnel signups now a third of new accounts" is honest; a decimal-pointed AI-attribution percentage is fiction.
* Present it as triangulation: several weak signals agreeing beat one fabricated strong one.
* Keep definitions stable and written down, the same discipline as any [goal-setting framework](/blog/2024-10-29-devrel-team-goal-planning-strategy-okr).
* Say what you cannot know.
Executives handle "attribution here is directional" better than they handle discovering it later.
The pitch to leadership is not "we can now measure AI adoption".
It is "adoption is moving somewhere our old instruments cannot see, here are the instruments that can, and here is the trend they show".
## A minimal instrumentation plan [#a-minimal-instrumentation-plan]
Shippable in a week, without new vendors:
1. Add a log-based count of AI user agents and machine-surface fetches to whatever dashboard you already run.
2. Add the free-text attribution field to signup and calendar a monthly reading of it.
3. Define the dark-funnel signup segment in your existing analytics.
4. Write the fixed prompt set for presence testing and run it for the first time.
5. Put a quarterly reminder on reviewing your crawler policy, so blocking decisions stay deliberate.
Then leave the definitions alone for two quarters.
Trend lines need time to become evidence, and this corner of measurement changes fast enough without self-inflicted definition drift.
## Related [#related]
* [Agents are your new developers](/docs/ai-era/agents-as-your-new-developers) for the funnel these instruments observe
* [Writing docs LLMs can use](/docs/ai-era/docs-for-llms) for improving what the machines retrieve
* [Goals planning with OKRs](/blog/2024-10-29-devrel-team-goal-planning-strategy-okr) for wrapping these metrics in accountable goals
---
# Definition of Developer Relations (https://devrel.directory/docs/fundamentals/definition)
## A working definition [#a-working-definition]
Developer Relations is the function that owns the relationship between a company and the developers who build with its product.
The relationship runs in both directions.
Outward, DevRel earns developers' trust by removing friction between them and the product: documentation, onboarding, examples, support, community.
Inward, it represents developers' needs to product, engineering, and leadership with enough authority to change what gets built.
The academic framing agrees: Oliveira et al. \[2021] describe DevRel as a strategic function that builds and maintains relationships with developer communities, partner companies, and other key stakeholders through programs that engage and support developers.
The practitioner shorthand is shorter: help developers succeed with your product, and make sure your company hears what they need.
The litmus test is the direction of information flow.
A team that only pushes messages out is doing developer marketing.
The "relations" in the name means the channel carries feedback in - or it is not DevRel.
Trust is the working capital of the whole function.
Developers extend it slowly, verify it constantly, and withdraw it permanently when they catch a function optimizing for the company at their expense.
Every position in the rest of this page follows from protecting that capital.
## What DevRel is not [#what-devrel-is-not]
The definition gets muddier every year because adjacent functions borrow the label.
Four boundaries are worth defending explicitly.
### Not marketing with a hoodie [#not-marketing-with-a-hoodie]
Developer marketing is a legitimate discipline: campaigns, launches, paid reach, conversion.
The mistake is dressing it as DevRel - putting a technical-looking person on stage to deliver what is structurally a pitch.
Developers detect the switch immediately, and the cost lands on the whole function: once an audience decides your advocates are salespeople, no future talk, post, or forum answer from your company is read at face value.
The two disciplines can and should coexist, but they need different names, different metrics, and usually different people.
Marketing optimizes for reach and conversion this quarter.
DevRel optimizes for developer success and trust across years.
Measure one by the standards of the other and you break it.
### Not sales [#not-sales]
A DevRel team with a quota stops being believed, because its usefulness rests on the freedom to say "our product is the wrong fit for your use case."
A salesperson cannot say that sentence; an advocate must be able to.
Pipeline often follows good DevRel work - developers who succeed become champions inside buying decisions - but pipeline can be a consequence of the work, never its assignment.
The moment an advocate's compensation depends on a deal closing, every technical recommendation they make is compromised, including the honest ones.
### Not just conference talks [#not-just-conference-talks]
Talks are the most visible sliver of the job, which is exactly why they distort the picture.
The bulk of real DevRel work is unglamorous: rewriting the quickstart, answering the same question in the forum for the fortieth time, synthesizing feedback into filed issues, fixing the onboarding snag that stalls every new integration.
A team measured on talks delivered optimizes for airports, and a team hired for stage presence alone cannot do the desk work that actually moves adoption.
Treat speaking as one activity among many that must earn its place against a goal - the full activity map lives on the [DevRel activities page](/docs/practices/devrel-activities).
### Not the support queue [#not-the-support-queue]
DevRel answers developer questions, but it is not the support organization.
The distinction is what happens after the answer: support resolves the ticket, while DevRel asks why the question keeps arriving and fixes the doc, the error message, or the API design that generates it.
A DevRel team that becomes the de-facto support queue loses the time for exactly that second step, which is where its leverage lives.
Route the volume to support, and keep DevRel on the patterns.
One more boundary: DevRel is not a single job.
Advocacy, documentation, community, developer experience engineering, and developer marketing are distinct roles with distinct skills, and conflating them produces bad hires in both directions.
The role taxonomy has its own page: [roles and responsibilities](/docs/fundamentals/roles-and-responsibilities).
## Where DevRel should report [#where-devrel-should-report]
The honest answer: the reporting line matters less than the metrics it imposes, because metrics determine behavior.
But since the box on the org chart usually decides the metrics, the box is worth arguing about.
The default position for a developer-first company: DevRel should report into Product.
The inward half of the definition - carrying developer needs into roadmap decisions - requires a seat where roadmaps are actually decided.
A DevRel team inside Product can file the feedback where it becomes work; a DevRel team three reporting layers from product decisions can only write memos.
Engineering is a strong second home, and sometimes the better one when the work is docs-heavy and DX-heavy: SDK quality, API design feedback, reference documentation.
The trade-off is that engineering leadership rarely defends community and content work when headcount tightens.
Marketing can work, under two conditions that are frequently not met: leadership must be fluent in developer-audience norms, and the team's goals must genuinely be awareness rather than leads.
The predictable failure mode is inheritance - a DevRel team inside marketing inherits MQL targets and campaign calendars within a few quarters, drifts into lead generation, and burns the trust the function exists to build.
If your marketing organization can hold the line on that, the placement is fine; most cannot.
Sales is not a home for DevRel under any conditions, for the reasons in the previous section.
Three rules that hold regardless of the box:
1. The reporting line must never force lead or pipeline metrics onto the team.
2. DevRel needs a named executive sponsor who can defend multi-quarter payoffs, because most of the work compounds slowly.
3. The goals must be written down and tied to business outcomes - the [DevRel strategy page](/docs/fundamentals/devrel-strategy) covers how.
If you take one position from this page: never let DevRel report into an organization that is measured on this quarter's revenue.
The function's entire value is built on developers believing it is not trying to close them.
## The definition shifts with company stage [#the-definition-shifts-with-company-stage]
The one-paragraph definition holds everywhere, but what it means in practice changes with the company around it.
Hiring against the wrong stage's definition is one of the most common ways DevRel programs fail.
### Before product-market fit [#before-product-market-fit]
Here DevRel is a feedback loop with a person attached.
The job is to get the first hundred developers to a working result and report back, in specific detail, why everyone else failed.
The right hire is founder-adjacent: technical enough to fix docs and examples directly, close enough to the product team to change the product itself.
Community programs, conference circuits, and content calendars are premature at this stage - there is no community yet, and the product is still changing under every piece of content you write.
### Growth stage [#growth-stage]
Here DevRel is friction removal at scale.
The individual attention that worked for the first hundred developers cannot reach the next ten thousand, so the work shifts to leverage: documentation coverage, self-serve onboarding, a community where peers answer each other, content that answers the questions the team used to answer by hand.
This is the stage where [developer personas](/docs/fundamentals/understanding-developer-personas) and a written strategy stop being optional, because the team can no longer hold every developer in its head.
It is also the stage where [community building](/docs/practices/community-building) becomes a genuine program rather than a founder replying fast.
### Platform and enterprise scale [#platform-and-enterprise-scale]
Here DevRel is ecosystem stewardship.
The audience is no longer only your direct users - it is partner developers, agencies, marketplace builders, and companies whose businesses depend on your platform's stability.
The work adds new surfaces: partner enablement, deprecation policy, versioning discipline, and defending the ecosystem's long-term health against the company's short-term incentives.
At this stage the inward half of the definition is the harder half, because a platform that breaks its developers' trust at scale rarely gets it back.
## The definition shifts with product type [#the-definition-shifts-with-product-type]
Lewko and Parton \[2021] draw the most useful product-type distinction: developer-first versus developer-plus.
In a developer-first company, the developer is both the user and the effective buyer - API companies and developer tools.
Here DevRel sits close to the core product function, because docs, onboarding, and DX are not supporting material; they are most of the product surface a customer ever touches.
Underinvesting in DevRel at a developer-first company is underinvesting in the product.
In a developer-plus company, the product is bought and used by a broader audience, and developers extend it - platforms with app stores, plugin ecosystems, and integration marketplaces.
Here DevRel is an ecosystem growth function: its job is to make building on the platform attractive and profitable enough that third parties keep doing it.
The metrics shift accordingly, from direct adoption toward ecosystem health - active integrations, partner-built value, marketplace quality.
Open-source companies are a third case that cuts across both.
The community is simultaneously user base, contributor base, and free-tier audience, and DevRel manages the boundary between the open project and the commercial product.
The definition gains a stewardship duty toward people who will never pay, because their contributions and credibility are what make the commercial side worth paying for.
## The definition in the AI era [#the-definition-in-the-ai-era]
The mission does not change when the first reader of your docs is a model instead of a person: build trust, remove friction, carry feedback inward.
What changes is where the friction lives, because a growing share of first contact with developer products now happens through AI agents acting on a developer's behalf.
That shifts documentation and machine-readable surfaces further up the priority list and adds a new, stricter test subject for developer experience work.
The full argument lives in [agents are your new developers](/docs/ai-era/agents-as-your-new-developers).
## Related [#related]
* [Roles and responsibilities](/docs/fundamentals/roles-and-responsibilities) for the role taxonomy this page deliberately does not duplicate
* [The importance of DevRel](/docs/fundamentals/importance) for the business case and the compounding logic
* [DevRel strategy](/docs/fundamentals/devrel-strategy) for turning the definition into goals, audiences, activities, and metrics
* [DevRel activities](/docs/practices/devrel-activities) for the concrete work the definition translates into
* [Agents are your new developers](/docs/ai-era/agents-as-your-new-developers) for how the definition holds up when the first user is a machine
***
Sources & References:
* "Developing Successful Developer Relations Programs in Blockchain Data Companies: A Metrics-Driven Approach" by Fabian Hug | 2024
* [Raphael Oliveira, Camila Ajala, Davi Viana, Bruno Cafeo, and Awdren Fontão. Developer Relations (DevRel) Roles: an Exploratory Study on Practitioners' opinions.](https://dl.acm.org/doi/10.1145/3474624.3474628) September 2021. doi: 10.1145/3474624.3474628.
* "Developer Relations: How to Build and Grow a Successful Developer Program" by Caroline Lewko and James Parton, 2021
* [What is Developer Relations and why does it exist?](https://seanfalconer.medium.com/what-is-developer-relations-and-why-does-it-exist-37bf4ee6d3db) by Sean Falconer | October 2020.
* [DeveloperRelations.com - What is developer relations?](https://developerrelations.com/guides/what-is-developer-relations)
* [What is Developer Relations (DevRel)? A Complete Guide](https://www.jonobacon.com/2023/04/02/what-is-developer-relations-devrel-a-complete-guide/) by Jono Bacon | April 2023
---
# DevRel Strategy (https://devrel.directory/docs/fundamentals/devrel-strategy)
This page is the quick reference.
For the full walkthrough with worked examples, survey data, canvases, and a 30-60-90 day plan, read [DevRel Strategy - A Comprehensive Guide](/blog/2024-11-06-devrel-strategy).
## What a DevRel strategy is [#what-a-devrel-strategy-is]
A DevRel strategy is the written answer to four questions: what outcome the business needs, which developers you serve, what you will do for them, and how you will know it is working.
It is a living document, not a launch artifact - you revise it as the product, the community, and the market change.
Everything else in the DevRel toolbox - personas, journey maps, OKRs, 30-60-90 plans - exists to sharpen one of those four answers.
If you can state all four on a single page, you have a strategy; if you need a deck to explain it, you probably have a wishlist.
## Goals [#goals]
"Clearly define your goals. Is the goal to increase awareness of your stack? Build a loyal developer community? Gather actionable feedback for upcoming product development?" - Dani Passos
Goals tie DevRel to something the business already cares about: adoption, retention, support cost, product quality.
Pick two or three, give each a number and a deadline, and let everything else wait.
Example goals that pass that test:
* Cut median time from signup to first successful API call from 45 minutes to 15 by end of Q2.
* Get 50% of community support questions answered by peers within 24 hours by end of year.
* Land five developer-reported issues on the product roadmap every quarter.
* Grow traffic to problem-focused docs pages by 40% in six months.
* Reduce setup-related support tickets by 30% after the onboarding rework ships.
Two caveats on timeframes.
Goals set only for the next quarter produce a pile of initiatives with no long-term shape.
Goals set beyond 12 months are fiction in fast-moving spaces - plan in shorter cycles and reassess often.
For turning goals into OKRs with SMART key results, use the [goal planning guide](/blog/2024-10-29-devrel-team-goal-planning-strategy-okr).
## Audience [#audience]
"Developers" is not an audience - it is millions of people with different stacks, skill levels, and decision-making authority.
Segment until you can name who you are serving, then validate that the segment is large enough, valuable enough, and reachable with your current resources.
Example segments that are specific enough to act on:
* Backend engineers at seed-to-Series-B startups integrating a payments API for the first time.
* Data engineers at enterprises evaluating your warehouse connector against two alternatives.
* Hackathon and student builders who need a working result in one afternoon.
* Technical leads who will never write the integration themselves but must approve it.
Segment along four filters: technical (stack and platforms), user (experience and authority), organization (company size and industry), and market (geography, language, regulation).
Then turn your top two to four segments into personas, so the whole team argues about the same imagined person instead of a vague crowd.
The [developer personas page](/docs/fundamentals/understanding-developer-personas) covers how.
Segmentation is not a one-time exercise.
Revisit it every six to twelve months, because the segment that matters today may not be the one that matters next year.
## Activities [#activities]
Activities are how the strategy becomes visible work - and they only count when they map to a goal and a segment.
Start from where your audience actually drops off in their journey, not from what the calendar offers.
Concrete activities, each tied to the kind of goal it serves:
* A quickstart that gets your primary segment to a working result in under 15 minutes (adoption).
* A weekly hour in the community and support queue, logging repeated questions (community health, feedback).
* A monthly feedback synthesis that turns the month's questions into filed product and docs issues (product influence).
* A hands-on workshop built for one named segment at the one conference they actually attend (awareness, evaluation).
* Fixing the single worst onboarding snag developers hit each week (developer experience).
Fewer, repeated activities beat many occasional ones: two things done every week outperform six done sporadically.
The full activity map, including when each cluster earns its place, lives on the [DevRel activities page](/docs/practices/devrel-activities).
## Metrics [#metrics]
"There's a myth out there that DevRel is hard to track. Sure, there are activities that we participate in that are hard to track or hard to prove the ROI of (since developers need 4+ touch points before they engage). However, DevRel as a function is not hard to track when you define your strategy clearly, set the appropriate OKRs based on your objectives, and create thorough metric tracking." - Tessa Kriesel
Pair every activity with one signal you would actually act on.
Metrics that work, with their caveats:
* Time to first successful API call: the best leading indicator of onboarding health, but only if you measure the real integration path, not the polished demo path.
* Quickstart completion rate: reveals where developers stall, though instrumenting it takes real work.
* Time-to-first-answer and share of peer-answered questions: honest community health signals, unlike raw member counts.
* Traffic on problem-focused queries and content-assisted signups: meaningful reach, where total pageviews alone are not.
* Active projects retained month over month: the adoption truth, but a lagging one - it moves quarters after your work does.
* Roadmap items traceable to developer feedback: the metric that proves DevRel's value to product and engineering peers.
* Developer satisfaction surveys: useful direction, weak precision - small samples and happy-user bias distort them.
Attribution in DevRel is genuinely fuzzy, because developers need multiple touchpoints before they engage.
That is an argument for choosing metrics carefully, not for skipping measurement.
## Common failure modes [#common-failure-modes]
### Activity without goals [#activity-without-goals]
The team does a little of everything because everything is defensible: a conference here, a Discord there, a blog post when time allows.
This is activity soup - always busy, rarely measurable, and first in line when budgets tighten.
The test: for every item on the calendar, name the goal it serves; if you cannot, it is serving the calendar.
### Metrics theater [#metrics-theater]
The quarterly report is full of numbers that can only go up: cumulative signups, GitHub stars, event attendance, newsletter subscribers.
Numbers that cannot go down cannot tell you anything is wrong.
The test: if a metric could never embarrass you, it cannot inform you either - report at least a few metrics that could.
### Strategy-as-slide-deck [#strategy-as-slide-deck]
The strategy was written once for an executive review, approved, and never opened again.
A strategy that does not change what the team does next week is decoration.
The test: revisit it quarterly and name what you started, stopped, or changed because of it; if the answer is nothing, you do not have a strategy in use.
## Related [#related]
* [DevRel Strategy - A Comprehensive Guide](/blog/2024-11-06-devrel-strategy) for the full narrative version of this framework
* [DevRel activities](/docs/practices/devrel-activities) for the complete activity map
* [Understanding developer personas](/docs/fundamentals/understanding-developer-personas) for the audience work in depth
* [Goal planning with OKRs](/blog/2024-10-29-devrel-team-goal-planning-strategy-okr) for the goal-setting mechanics
***
Sources & References:
* [How to craft a great Developer Relations strategy](https://danipassos.substack.com/p/how-to-craft-a-great-developer-relations) by Dani Passos | February 14, 2024
* [My DevRel Strategy Breakdown](https://tessakriesel.com/my-devrel-strategy-breakdown/) by Tessa Kriesel | June 30, 2022
* "Developer Relations: How to Build and Grow a Successful Developer Program" by Caroline Lewko and James Parton, 2021
---
# The Business Case for DevRel (https://devrel.directory/docs/fundamentals/importance)
## The question this page answers [#the-question-this-page-answers]
[What DevRel is](/docs/fundamentals/definition) has its own page.
This page answers the harder question practitioners actually face: how do you justify DevRel investment to leadership, and how do you defend it when budgets tighten?
The uncomfortable context first.
In the 2024 State of Developer Relations survey, 61% of respondents said they find it difficult to prove their influence.
The same report found 62% of DevRel teams reporting to founders or C-level executives, and 20% directly to the CEO.
Read those two numbers together: DevRel sits unusually close to power, and too often shows up there without a business case.
That is a dangerous combination, because a function that is visible to executives and vague about its value is first in line when costs get cut.
The business case for DevRel is not "developers like us".
It is: developers decide which platforms win, their adoption compounds through network effects, and neglecting them creates real costs that land in other departments' budgets.
## Developers decide, then someone signs [#developers-decide-then-someone-signs]
The structural argument was made by RedMonk's Stephen O'Grady in The New Kingmakers back in 2013: developers, not their employers, have become the real technology decision makers.
Democratized access to software and infrastructure - open source, free tiers, cloud - means the people who build now choose the tools, and procurement formalizes choices already made.
The mechanics have only strengthened since.
SlashData estimated the global developer population at 47.2 million at the start of 2025.
A developer in that population can adopt your platform on a Tuesday afternoon: free trial, self-serve docs, working prototype before dinner, no salesperson involved.
By the time a contract reaches procurement, the technical evaluation is over and switching costs already exist.
If your product is something developers touch, you are in a developer-first go-to-market whether you fund it or not.
DevRel is the function that runs that motion deliberately, through [the roles the team page describes](/docs/fundamentals/roles-and-responsibilities) and the [activities that make it visible](/docs/practices/devrel-activities).
## The network effect, worked through [#the-network-effect-worked-through]
A network effect exists when a product gains value as more people use it.
For developer platforms the mechanism is concrete, not metaphorical:
* Every developer who succeeds leaves public exhaust: a Stack Overflow answer, a blog post, an open-source wrapper, example code in a public repo, a forum thread with the fix.
* That exhaust is onboarding material for the next developer, produced at no cost to you, and it never expires the way a paid campaign does.
* More adoption means a larger hiring pool that already knows your product, which lowers the cost for the next company to standardize on it.
* More integrations and community libraries make your platform the path of least resistance for adjacent use cases.
* And in the AI era, that same public corpus trains the models that now recommend tools and write integration code, so the flywheel extends to [developers who are agents](/docs/ai-era/agents-as-your-new-developers).
Each turn lowers the acquisition cost of the next developer while raising the value of joining.
That is the flywheel: more people building in an ecosystem makes the ecosystem more attractive to build in.
DevRel exists to start that flywheel and remove its friction - which is why the work looks like docs, [community](/docs/practices/community-building), and [content](/docs/practices/content-creation) rather than ad campaigns.
### A worked example: Twilio, in its own SEC filing [#a-worked-example-twilio-in-its-own-sec-filing]
The cleanest evidence is a company that built its business this way and then had to describe the machine to investors under securities law.
Twilio's Form S-1 states the model in one line: "we acquire developers like consumers and enable them to spend like enterprises."
It names the motion explicitly: "Our go-to-market model is primarily focused on reaching and serving the needs of developers. We are a pioneer of developer evangelism and education and have cultivated a large global developer community."
Now look at the funnel shape the filing discloses, as of June 30, 2016:
* Over 1,000,000 registered developer accounts.
* Over 100,000 paying customer accounts.
* Over 30,000 Active Customer Accounts, defined as generating at least $5 of revenue in the last month of a quarter.
Read that ratio correctly: roughly 97% of registered developer accounts were not meaningful revenue, and that was the design, not a failure.
The filing is explicit that "big ideas often start small", so developers were given free trials, self-service documentation, and free support to tinker years before a business problem arrived.
The payoff shows up one line down, in the expansion metric.
Twilio reported a Dollar-Based Net Expansion Rate of 155% for 2015 and 167% for the first half of 2016.
At 155%, an existing customer cohort doubles its revenue in roughly 19 months with zero new logos closed.
That is what "developers land small and grow" looks like when it finally reaches a financial statement.
When leadership asks why you would fund a million free accounts to get thirty thousand paying ones, this is the answer: developer-first businesses buy compounding expansion revenue with patience at the top of the funnel.
One honesty note, because this page argues against invented evidence in decks: Twilio proves the motion can work, not that it works everywhere.
Your version of these numbers depends on product quality, market timing, and execution - which is exactly why the case must be paired with [a strategy that names goals and metrics](/docs/fundamentals/devrel-strategy).
## What neglect actually costs [#what-neglect-actually-costs]
The costs of not doing DevRel do not disappear.
They move into other budgets, where nobody labels them.
### Support load [#support-load]
Every recurring developer question without a good doc or community answer becomes a support ticket, answered one-to-one, at cost, forever.
A canonical docs page or a well-run community thread answers it once and then keeps answering it.
The arithmetic is unforgiving: a question that arrives ten times a week and takes 30 support-minutes each burns about 65 hours a quarter - the ongoing price of never writing the one canonical answer.
Multiply by the dozen recurring questions every platform has, and "we can't afford DevRel" quietly becomes a support headcount line.
### Silent churn [#silent-churn]
Developers rarely complain before leaving.
They hit friction during integration, abandon quietly, and choose the competitor whose quickstart worked on the first try.
This churn never appears in a CRM, because the "customer" never became one - the deal that dies in a failed integration is invisible to sales reporting.
Without someone watching time-to-first-successful-call and onboarding drop-off, you learn about integration friction from win-loss analysis, a year late and one competitor behind.
### Docs decay [#docs-decay]
Documentation rots at the speed of your release cadence, and unowned documentation rots fastest.
Every stale page raises support load, extends onboarding time, and teaches developers that your platform cannot be trusted at exactly the moment they are deciding whether to trust it.
The AI era raises the stakes: stale and wrong pages are now retrieved and repeated by coding assistants, so a docs bug becomes misinformation with a distribution channel, per [writing docs LLMs can use](/docs/ai-era/docs-for-llms).
### Compounding in reverse [#compounding-in-reverse]
Network effects do not pause while you deliberate.
The public answer base, the integrations, the community expertise, and the model training data accumulate for whoever invests.
If that is your competitor, every quarter of your hesitation is a quarter of their flywheel - and catching up costs far more than keeping up, because you are then competing against compounded output.
None of these costs ever appear as a line item called "no DevRel".
They surface as support headcount, lost evaluations, and a developer brand people quietly route around - which is why the case has to be made before the damage is measurable.
## Arguing the case internally [#arguing-the-case-internally]
Proving influence is the top struggle in the survey data above, so treat the internal argument as part of the job, not an interruption to it.
Opinionated guidance on what belongs in the deck and what you should refuse to put there.
### Put in the deck [#put-in-the-deck]
* Two or three goals with numbers and deadlines, tied to outcomes the business already tracks: adoption, retention, support cost, product quality.
The [strategy page](/docs/fundamentals/devrel-strategy) shows what passes that test.
* The funnel-shape education.
Show the Twilio ratio and set the expectation up front that most developer engagement will never map to a closed deal, by design.
* A cost-of-neglect estimate in your own numbers: current recurring ticket themes in support hours, onboarding drop-off, stale-docs incidents.
Avoided cost is the budget argument finance actually respects.
* Leading indicators paired with lagging ones: time-to-first-successful-call and peer-answered questions now, retained active projects and expansion revenue later.
Say out loud that the lagging ones move quarters after the work does, and wrap both in [accountable OKRs](/blog/2024-10-29-devrel-team-goal-planning-strategy-okr).
* A reporting cadence you will actually keep.
The same handful of honest metrics every quarter builds the credibility that a scramble at budget time cannot.
### Refuse to promise [#refuse-to-promise]
* Per-activity revenue attribution.
Developers need multiple touchpoints before they engage, and promising clean attribution sets a trap that springs at renewal time.
* Marketing-comparable lead volume in the first two quarters.
DevRel compounds and paid spend does not - that difference is the reason to fund it, not a defect to apologize for.
* Community size or pageviews as success metrics.
Numbers that can only go up cannot prove anything, a failure mode the [strategy page](/docs/fundamentals/devrel-strategy) calls metrics theater.
* Revenue targets DevRel does not control.
Sign up for the leading indicators it does control, and show the causal chain to revenue instead of claiming the whole number.
A budget defense assembled the week of the budget meeting has already lost.
Report the same honest metrics every quarter so the defense is on record before anyone asks for it.
If your measurement problem is that adoption increasingly happens where analytics cannot see it - inside AI assistants and agent workflows - the [measuring AI-driven adoption page](/docs/ai-era/measuring-ai-driven-adoption) covers how to report that honestly too.
## Related [#related]
* [Definition of DevRel](/docs/fundamentals/definition) for what the function is before you argue what it is worth
* [Roles and responsibilities](/docs/fundamentals/roles-and-responsibilities) for the team shape the investment buys
* [DevRel strategy](/docs/fundamentals/devrel-strategy) for turning a funded mandate into goals, audience, activities, and metrics
* [Community building](/docs/practices/community-building) for the practice that powers the network effect
* [Measuring adoption you cannot see](/docs/ai-era/measuring-ai-driven-adoption) for defending the numbers when AI hides the funnel
***
Sources & References:
* [Twilio Inc. Form S-1](https://www.sec.gov/Archives/edgar/data/1447669/000119312516733893/d237988ds1.htm) | U.S. Securities and Exchange Commission, filed October 7, 2016
* [The New Kingmakers: How Developers Conquered the World](https://redmonk.com/sogrady/2013/01/09/the-new-kingmakers-the-book/) by Stephen O'Grady | RedMonk, January 9, 2013
* [Global developer population trends 2025](https://www.slashdata.co/post/global-developer-population-trends-2025-how-many-developers-are-there) | SlashData, 2025
* [11th Annual State of Developer Relations Report](https://www.devrel.agency/post/announcing-the-11th-annual-state-of-developer-relations-report) | DevRel Agency, September 10, 2024
---
# DevRel Roles and Responsibilities (https://devrel.directory/docs/fundamentals/roles-and-responsibilities)
## The role landscape [#the-role-landscape]
DevRel job titles are notoriously inconsistent: the same work ships under advocate, evangelist, community, developer experience, and half a dozen hybrids.
This page maps the roles as researched and as practiced, then answers the questions hiring managers actually have: who to hire first, where the team reports, and what seniority looks like.
If you want the definition of the function itself first, start with [what Developer Relations is](/docs/fundamentals/definition).
## The classic four roles [#the-classic-four-roles]
In an exploratory study of 116 practitioners, Oliveira et al. \[2021] identified nine distinct DevRel roles, from advocates and evangelists to developer programs engineers and technical writers.
This site condenses them into four families that cover most job postings:
| Title | Necessary Skills | Examples of Work |
| ------------------------- | --------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Developer Advocate | Deep technical understanding, communication skills, feedback gathering, problem-solving, advocacy. | Enabling developers to leverage the platform/Application Programming Interfaces (APIs), advocating for developers' needs to internal product teams, creating demos and code examples, finding solutions to product issues and bugs. |
| Developer Evangelist | Technical understanding, public speaking, event hosting, writing skills, social media management, feedback to product team. | Speaking at conferences, running events, writing blog posts, recording videos, overseeing developer social media presence, helping announce new features to the public. |
| Developer Experience (DX) | UX design, API/Software Development Kit (SDK) design, documentation writing, onboarding process design. | Owning onboarding flows, SDK/API design, and documentation, acting like product owners for anything developers use. |
| Developer Marketing | Marketing strategy, content creation, event sponsorship, ad campaign management. | Creating marketing campaigns and strategies to reach developers and technical audiences, content syndication, managing paid channels like Ad Words, event sponsorship. |
The taxonomy is from 2021 and the field has specialized since, but the table still holds as the skeleton.
Every newer title is one of these four rows with a narrower mandate or a bigger scope.
## Advocate vs evangelist: direction of travel [#advocate-vs-evangelist-direction-of-travel]
The two titles are conflated constantly in industry parlance, but the practical distinction is which way the person faces.
An advocate faces inward: they represent the developer community to the company, carrying feedback, friction reports, and filed issues to product and engineering teams.
An evangelist faces outward: they represent the company to the developer community through talks, posts, videos, and launch support, and traditionally sits closer to marketing (Hughes \[2022]).
Most practitioners do some of both, so the title signals which half is the job and which half is the side effect.
One wrinkle: "evangelist" has fallen out of favor at many companies for its connotations, so outward-facing work now often ships under the advocate title too.
Read the responsibilities in the posting, not the title on it.
## The modern role list [#the-modern-role-list]
Four titles from the wider role landscape, all of which now appear as distinct mainstream hires rather than folded into the families above.
### Community manager [#community-manager]
Owns the spaces where developers help each other: the forum or Discord, the champions program, moderation, and community events.
The skills are program design, moderation judgment, event operations, and enough technical literacy to triage questions and route the hard ones.
This role is the difference between a community that compounds and a Discord that decays; the [community building page](/docs/practices/community-building) covers the practice.
### Technical writer / docs engineer [#technical-writer--docs-engineer]
Owns documentation as a product: information architecture, reference accuracy, docs-as-code tooling, and the quickstarts that decide evaluations.
The docs engineer variant leans further into tooling - API reference generation, versioning, docs CI - and is the right shape when docs are large and change fast.
The role now has a second audience: AI assistants read the docs too, and [structuring documentation for LLMs](/docs/ai-era/docs-for-llms) is becoming part of the brief.
Where advocates create [content](/docs/practices/content-creation) that persuades, this role creates content that developers depend on.
### DevRel engineer [#devrel-engineer]
The most hands-on variant: builds sample apps, reference integrations, SDK improvements, and demo infrastructure rather than talking about them.
It overlaps with the Developer Experience row in the table, but as an IC engineering role inside DevRel instead of a product-ownership function.
New build surfaces keep appearing for this role, such as [MCP servers as a DevRel surface](/docs/ai-era/mcp-servers-as-devrel-surface) for the agent era.
Hire this shape when your bottleneck is working code - integrations, samples, tooling - rather than reach.
### Head of DevRel / Director [#head-of-devrel--director]
Owns the [strategy](/docs/fundamentals/devrel-strategy), the budget, the headcount plan, and the reporting-line conversation with executives.
The job is translation in both directions: business goals into a DevRel program, and DevRel results into terms the executive team funds.
It is a real management job, not a senior advocate with extra meetings - see the leveling section below.
## What every role shares [#what-every-role-shares]
Whatever the title, three responsibilities are non-negotiable across the whole function.
First, carrying feedback: every role hears developer friction, and every role is obligated to route it somewhere it gets acted on.
Second, writing: talks fade and demos rot, but written material keeps working, so writing ability is a hiring bar for every role on this page.
Third, using the product for real: a practitioner who has not personally hit the onboarding wall cannot represent the developers who do.
If a job description drops any of these three, it is describing a different job wearing a DevRel title.
## Who to hire first [#who-to-hire-first]
The right first hire depends on company stage, and getting the order wrong is one of the most common DevRel failure modes.
Live postings on the [jobs board](/jobs) show how companies are actually scoping these roles.
### Pre-seed and seed: founders first, then one generalist [#pre-seed-and-seed-founders-first-then-one-generalist]
Before product-market fit with developers, the founders are the DevRel team - they answer the questions, write the first docs, and give the first talks.
The first dedicated hire should be a senior generalist developer advocate: someone who can write, code, speak passably, and run the feedback loop alone.
Senior matters because a team of one sets its own strategy; generalist matters because the biggest problem changes every month.
Do not hire a Head of DevRel as the function's first employee.
A director with nobody to direct will either do IC work at a director's cost or build process for a team that does not exist yet.
### Series A to B: hire against the drop-off [#series-a-to-b-hire-against-the-drop-off]
Once the generalist is saturated, hire against the biggest drop-off in the developer journey, which your [personas work](/docs/fundamentals/understanding-developer-personas) should reveal.
If developers stall during evaluation because the docs are thin, the second hire is a technical writer or docs engineer.
If a real stream of user questions is going unanswered, it is a community manager.
If the samples and integrations are the bottleneck, it is a DevRel engineer.
A second advocate is the right call only when the first one's activities demonstrably work and simply need more coverage.
Beware the unicorn posting: one role asking for conference speaking, docs ownership, community management, SDK engineering, and pipeline targets.
That is four jobs from the table above compressed into one salary, and it predicts burnout for the hire and disappointment for the company.
### Growth and beyond: add a head, then specialize [#growth-and-beyond-add-a-head-then-specialize]
Around three or more ICs, the function needs a Head of DevRel - both to manage and to defend the budget with a coherent [strategy](/docs/fundamentals/devrel-strategy).
From there, specialization follows the goals: dedicated docs, dedicated community, dedicated developer marketing as a partner function.
The [business case](/docs/fundamentals/importance) has to be restated at every stage, because headcount that was obvious at seed gets questioned at scale.
## Where the team reports [#where-the-team-reports]
There is no consensus placement for DevRel, and the reporting line changes the job more than the job description does.
* Under engineering: the team gets technical credibility and a short path to fixing what developers complain about, but risks being treated as support overflow and measured against shipping metrics that do not fit.
* Under marketing: the team gets budget and distribution machinery, but gets measured in leads, and developer trust erodes fast once the content smells like campaigns.
* Under product: the team's core loop - developer feedback into product change - lands directly where decisions are made, and DX work has a natural owner.
* Standalone, reporting to the CEO or CTO: maximum autonomy and a clear signal that developers matter, but it only survives while that executive personally sponsors it, and it is usually the first structure dissolved in a reorg.
Our position: default to product when developers are the customer, with engineering as a close second.
Report into marketing only when awareness genuinely is the top goal, and negotiate developer-shaped metrics before accepting the org chart, not after.
Wherever the team lands, the placement test is simple: are the team's metrics ones it can honestly move, and does its feedback reach people who can act on it?
If either answer is no, the reporting line is wrong regardless of which department it points to.
## Seniority and leveling [#seniority-and-leveling]
Titles vary, but the leveling logic is consistent across companies that do this well.
* IC (advocate, writer, community manager, DevRel engineer): owns specific [activities](/docs/practices/devrel-activities) and one measurable signal per activity, and executes within an existing strategy.
* Senior IC / lead: owns a whole program area - the content program, the community, the DX backlog - plus its roadmap, and mentors other ICs without necessarily managing them.
* Head / director: owns strategy, budget, hiring, and the executive relationship, and is judged on business outcomes rather than activity output.
Two rules of thumb.
First, do not create a manager layer before there are roughly three ICs to manage; before that, seniority should mean broader ownership, not reports.
Second, keep a senior IC track open - forcing your best advocate into management to get promoted is how you lose your best advocate.
A note on reading postings: "Developer Advocate" can mean anything from entry level to principal, so weight the scope described over the title granted.
Three questions reveal the real level: what the role owns, who it reports to, and which signal it is measured on.
## Related [#related]
* [What Developer Relations is](/docs/fundamentals/definition) for the function these roles serve
* [DevRel strategy](/docs/fundamentals/devrel-strategy) for deciding what the roles should work on
* [DevRel activities](/docs/practices/devrel-activities) for the work each role executes week to week
* [The jobs board](/jobs) for how these roles are scoped in live postings
***
Sources & References:
* [Raphael Oliveira, Camila Ajala, Davi Viana, Bruno Cafeo, and Awdren Fontão. Developer Relations (DevRel) Roles: an Exploratory Study on Practitioners' opinions.](https://dl.acm.org/doi/10.1145/3474624.3474628) September 2021. doi: 10.1145/3474624.3474628.
* [What Does a Developer Evangelist Do?](https://draft.dev/learn/understanding-the-role-of-a-developer-evangelist) by Karl Hughes | May 2022
* [Best practices for Developer Relations Programs to measure success of an API platform](https://www.moesif.com/blog/developer-relations/measure-success/Best-practices-for-Developer-Relations-Programs-to-measure-success-of-an-API-platform/) by Derric Gilling | January 2020
* "Developing Successful Developer Relations Programs in Blockchain Data Companies: A Metrics-Driven Approach" by Fabian Hug | 2024
---
# Understanding Developer Personas and Needs (https://devrel.directory/docs/fundamentals/understanding-developer-personas)
## What a persona is for [#what-a-persona-is-for]
A developer persona is compressed research: everything you have learned about one segment, condensed into a single named character the whole team can argue about.
Without one, every planning meeting quietly optimizes for a different imagined developer - the one each person happens to know best.
With one, "would Dana read a 40-minute conceptual guide before her deadline?" is a question with an answer.
Personas come after segmentation, not instead of it.
The [DevRel strategy page](/docs/fundamentals/devrel-strategy) covers how to segment your audience and validate that a segment is worth serving - do that work first, then turn your top two to four segments into personas.
This page covers the turning-into part.
Two rules before anything else.
No data = no persona.
Every field in a persona must trace back to something you observed - an interview, a ticket, a usage cut.
A persona built from assumptions is a stereotype with a template around it, and it will confidently steer you wrong.
And cap yourself at three or four personas.
Beyond that, nobody remembers them, nobody uses them, and the exercise becomes documentation theater.
If you feel the pull toward a fifth, your segmentation is probably too fine-grained for your current resources - merge before you multiply.
## The template [#the-template]
Ten fields, each with a reason to exist.
If a field does not change a decision you make, it does not belong - that principle is also why the [what to cut](#what-to-cut) section exists.
1. **Handle**: a memorable name plus role label, like "Deadline Dana, backend engineer at a Series A startup".
Rationale: the handle is what makes the persona usable in conversation; nobody says "segment 2b" in a planning meeting.
2. **Segment**: which validated segment from your strategy this persona compresses.
Rationale: keeps the persona anchored to the audience work instead of drifting into fiction.
3. **Triggering situation**: the concrete event that brings this developer to your product.
Rationale: developers do not wake up wanting your tool; they hit a problem, and your onboarding must meet that exact moment.
4. **Job to be done**: the outcome they need, stated in their words, not your feature list.
Rationale: this is the sentence your quickstart, homepage, and first tutorial must answer.
5. **Stack and constraints**: languages, frameworks, deployment targets, and the tools they already live in.
Rationale: decides which SDKs you prioritize and which language your examples lead with.
6. **Domain experience**: how familiar they are with your problem space specifically, not how senior they are in general.
Rationale: a staff engineer who has never touched payments needs the idempotency explainer just as much as a junior does.
7. **Authority**: whether they choose the tool, recommend it, or implement someone else's choice.
Rationale: determines whether your content must convince them or arm them to convince someone else.
8. **Success definition**: the moment they would call the integration done.
Rationale: this is the finish line your time-to-first-success metric should measure toward.
9. **Failure triggers**: the specific frustrations that make them abandon and pick a competitor.
Rationale: retention work starts with knowing exactly where trust breaks.
10. **Evidence and review date**: links to the interviews, tickets, and data cuts behind each claim, plus when the persona was last validated.
Rationale: the evidence field is what separates a persona from a guess, and the date is what stops it from fossilizing.
Notice what is not in the template: age, gender, city, hobbies, or a photo.
More on that below.
## A worked example [#a-worked-example]
The persona below is an illustrative example for a fictional payments API.
It is not a real research study, and the specifics are invented to show what a completed template looks like.
Your persona must be filled with your own evidence, not adapted from this one.
**Handle**: Deadline Dana, backend engineer at a seed-stage startup.
**Segment**: backend engineers at seed-to-Series-B startups integrating a payments API for the first time.
**Triggering situation**: the founder committed to launching paid plans this quarter, and Dana picked up the "add checkout" ticket in this sprint.
**Job to be done**: "Get card payments working in production before launch, without becoming the payments expert on call for it forever."
**Stack and constraints**: TypeScript on Node, Postgres, deploys to a PaaS; heavy AI-assistant use for unfamiliar domains; no dedicated infra or security team to lean on.
**Domain experience**: five years of solid backend work, zero payments exposure - idempotency keys, webhook verification, and PCI scope are all new vocabulary this week.
**Authority**: de facto chooser; the founder will approve whatever Dana recommends after a one-paragraph Slack summary.
**Success definition**: a test-mode charge succeeding the same afternoon she starts, and a production checkout flow live before the launch date.
**Failure triggers**: webhooks that behave differently in sandbox and production, error messages that do not match the docs, and any pricing surprise she has to explain to the founder after the fact.
**Evidence and review date**: in a real persona, this field links to the eight interview notes, the tagged export of 150 support tickets, and the activation-funnel cut behind the claims above, plus a review date about six months out.
The example shows the payoff: from this one page you can derive the quickstart's target time, the first tutorial's topic (webhook handling, sandbox to production), the docs' vocabulary level, and the one-paragraph summary Dana needs for her founder.
A persona that cannot generate decisions like these is not finished.
## The research that feeds the template [#the-research-that-feeds-the-template]
Three methods cover most of what a persona needs.
Each answers different questions, and each has blind spots you should be honest about.
### Practitioner interviews [#practitioner-interviews]
Talk to five to eight developers per segment - fewer misses patterns, and returns diminish quickly past ten.
Source them from recent signups, support-ticket follow-ups, and community members, and deliberately include people who evaluated you and walked away, because your fans are the least representative sample you have.
A 30-to-45-minute call with a small thank-you gift card is the standard format, and expect the full round plus synthesis to take two to three weeks of calendar time.
What interviews tell you: motivations, decision processes, vocabulary, objections, and the triggering situations that no analytics event captures.
What they cannot tell you: prevalence.
Five people saying the same thing is a pattern worth checking, not proof that most of your audience feels it.
### Support-queue and community-thread mining [#support-queue-and-community-thread-mining]
Read the last 100 to 200 support tickets and community threads and tag each with the question type and whatever role signals appear.
This is a focused day or two of work, and it yields the exact language developers use when stuck - which is also the language your docs and error messages should use, as the [content creation page](/docs/practices/content-creation) argues.
What mining tells you: recurring pain points at real volume, where documentation fails, and which concepts confuse which kinds of users.
What it cannot tell you: anything about developers who bounced silently.
The queue only contains people who cared enough to write in, so it systematically overweights your most persistent users.
### Signup and usage data cuts [#signup-and-usage-data-cuts]
Cut your activation funnel by the dimensions that might define segments: company size, SDK language, referral source, and where in onboarding people stall.
If analytics are already instrumented, this is an afternoon; if not, budget real engineering time before the persona work starts.
What data cuts tell you: which segments actually exist in volume, and precisely where each one drops off.
What they cannot tell you: why.
The funnel shows the cliff, and only interviews and tickets explain the fall.
### Triangulate before you write [#triangulate-before-you-write]
A claim earns its place in a persona when at least two methods agree on it.
Interviews said webhooks are scary, tickets are full of webhook debugging, and the funnel shows a stall at webhook setup - now "webhook friction" belongs in the failure triggers field.
One method alone gets written down with an explicit caveat or parked until you can check it.
The [community](/docs/practices/community-building) is a standing research asset here: the questions people ask every week are a continuous, free stream of persona evidence.
## What to cut [#what-to-cut]
Most persona templates in the wild are marketing hand-me-downs, and the classic critique is Claire Hunsaker's DevRelCon talk "Personas: you're doing it wrong".
Three things to delete on sight:
* **Demographics**: age, gender, and city do not change a single decision about your docs, SDKs, or onboarding.
Experience, stack, and authority do, so spend the space there.
* **Stock photos**: a photo adds fake specificity, invites bias about who a "real" developer looks like, and communicates nothing the handle does not.
* **Fictional biographies**: "Dana enjoys hiking and craft coffee" is decoration.
Hobbies have never changed a content plan, and every invented detail trains the team to treat the researched details as equally invented.
The test for any field: if it changed tomorrow, would you do anything differently?
If not, cut it.
## Negative personas [#negative-personas]
A negative persona documents who you deliberately do not serve, so the team stops paying attention to loud but wrong-fit feedback.
For the fictional payments API above, a negative persona might be the hobbyist building a side project with no revenue - lovely people, vocal in the community, and structurally unable to become customers of a per-transaction product.
One or two negative personas are enough, and they earn their keep the first time someone proposes an initiative aimed squarely at people who will never convert.
Negative does not mean ignored.
It means you consciously choose not to optimize the roadmap and the content calendar for them, which is a strategy decision the [goals framework](/docs/fundamentals/devrel-strategy) should back up.
## Keeping personas alive [#keeping-personas-alive]
Personas expire, because products, markets, and audiences move.
Revisit each one every six to twelve months, alongside the segmentation review the strategy page recommends, and check the evidence links: if the newest source behind a persona is two years old, it is describing your former audience.
Retire personas whose segments stopped mattering - a wall of outdated personas is worse than none, because the team still trusts them.
Personas only pay off when they leave the DevRel team.
Put them where product, docs, and marketing plan their work, and reference them by handle in reviews - "would Dana get past step three?" is the sentence that makes the whole exercise worth it.
One boundary worth naming: AI agents increasingly evaluate and consume developer products on developers' behalf, and that audience needs its own treatment - see [agents as your new developers](/docs/ai-era/agents-as-your-new-developers) - but the personas on this page are about the humans who still make the adoption decisions.
## Related [#related]
* [DevRel strategy](/docs/fundamentals/devrel-strategy) for the segmentation work that comes before personas
* [Content creation](/docs/practices/content-creation) for writing to a reader you can name
* [Community building](/docs/practices/community-building) for the ongoing evidence stream that keeps personas current
* [DevRel Strategy - A Comprehensive Guide](/blog/2024-11-06-devrel-strategy) for how personas fit the full strategy walkthrough
***
Sources & References:
* "Personas: you're doing it wrong" by Claire Hunsaker | [https://developerrelations.com/strategy-and-metrics/personas-youre-doing-it-wrong](https://developerrelations.com/strategy-and-metrics/personas-youre-doing-it-wrong) | DevRelCon San Francisco 2019
* "Putting names to faces - Developer Personas" by DevRel Agency (Developer Go To Market Series) | [https://www.devrel.agency/post/personas](https://www.devrel.agency/post/personas) | April 26, 2023
* "What are developer personas? Your complete guide" by Teresa Garanhel | [https://www.developermarketing.io/the-complete-guide-to-developer-personas](https://www.developermarketing.io/the-complete-guide-to-developer-personas) | October 22, 2024
---
# Community Building (https://devrel.directory/docs/practices/community-building)
## Why community compounds [#why-community-compounds]
A developer community is the only DevRel asset that answers questions while you sleep.
Every solved thread becomes searchable capital, every active member lowers the load on the next one, and the resulting network effects are the core of [why DevRel matters](/docs/fundamentals/importance) commercially.
That is the payoff.
The cost is that community is slow to start, easy to fake with vanity numbers, and impossible to outsource.
## Do you actually need one yet? [#do-you-actually-need-one-yet]
Be honest about this gate before creating anything.
A community space earns its existence when three things are true:
1. Developers are already using the product in production, or seriously trying to.
2. They ask questions with answers worth preserving.
3. Someone on your side will show up every day for the first months.
If those are not true yet, a community space becomes an empty room with your logo on it, and an empty room actively signals that nobody uses the product.
A support channel is not a community.
If every thread is answered by an employee and members never talk to each other, run it as support and do not label it community.
Until the gate is met, participate in external communities instead: it reaches developers where they already are, at a fraction of the cost.
## Choosing the home [#choosing-the-home]
Every option trades reach against ownership.
* GitHub Discussions: lives next to the code, indexed by search engines, zero extra accounts for developers.
Weak for real-time chat and casual presence.
* Discord: excellent for real-time energy and voice events, familiar to most developers.
Content is unsearchable from the outside and effectively disappears; treat it as ephemeral by design.
* Slack: comfortable for B2B audiences that live in Slack at work.
Message history limits and workspace sprawl make it a poor archive.
* A forum such as Discourse: the best long-term archive, fully owned, search-indexed.
Higher setup and moderation cost, and it feels slower socially.
A practical pattern: one real-time space for presence plus one indexable space for durable answers, with the discipline to move solved chat threads into the indexable one.
The worst pattern is four half-alive spaces.
## The cold start: your first fifty members [#the-cold-start-your-first-fifty-members]
Communities do not start with scale, they start with hospitality.
Do things that do not scale:
1. Invite people personally: your first users, beta testers, the developers who filed thoughtful issues.
A personal note beats any announcement.
2. Be present daily: founders and DevRel answering within the hour sets the tone for everything after.
3. Seed real content: post the questions you get by email, with answers, so the room never looks empty.
4. Create one ritual: a weekly office hour, a Friday showcase thread, a monthly call.
Rituals give people a reason to come back.
5. Welcome individually: greet every new member by name for as long as that is physically possible.
Expect the 90-9-1 shape: roughly ninety percent of members read silently, nine percent respond, one percent create.
Design for the readers too; they are adopting your product even when they never post.
## Growing past the founder era [#growing-past-the-founder-era]
Once strangers answer strangers, shift from hosting to building programs:
* Office hours and AMAs: scheduled access to your team, cheap to run, reliably productive.
* Showcase channels: members demoing what they built, which doubles as a content and case-study pipeline.
* Champions or ambassador programs: give your most invested members early access, a direct line to the team, and a stage.
Design incentives around recognition and access rather than payment; paying for advocacy converts your most credible voices into contractors.
* Community-sourced content: guest posts and talks by members, reviewed for accuracy by your team.
Set the guardrails early:
* A short, enforced code of conduct from day one.
Publishing it after the first incident is too late.
* Moderation coverage: name who acts, and how fast, when something crosses a line.
* An explicit escalation path from community questions into your issue tracker, so recurring pain becomes [product feedback](/docs/practices/devrel-activities) instead of folklore.
## Showing up in communities you do not own [#showing-up-in-communities-you-do-not-own]
Most of your audience will never join your space.
They are on Stack Overflow, Reddit, Hacker News, and in other products' Discords, and how you behave there shapes your reputation more than anything you do at home.
What works:
* Answer questions about your problem space, not just your product, and be genuinely useful.
* Disclose who you are every time; a bio line and a plain "I work on X" is enough.
* Follow each community's self-promotion rules to the letter.
* Bring value first: share the fix, then link the deeper guide if it genuinely helps.
What burns trust permanently:
* Drive-by promotion in threads you never participated in before.
* Undisclosed employees "recommending" the product.
* Copy-pasted marketing responses to nuanced technical questions.
In someone else's community you are a guest.
Guests who show up only to sell stop being invited.
## Measuring community health honestly [#measuring-community-health-honestly]
Member count is the weakest possible signal: it only ever goes up, and it says nothing about life inside.
Track behavior instead:
* Active participants per week or month: people who posted, replied, or reacted.
* Time to first response for new questions, and who responded.
* Member-answered ratio: the share of questions resolved by non-employees.
This is the single best indicator that a community, not a support desk, exists.
* Returning participants: members active this month who were also active last month.
* Qualitative signals: unprompted show-and-tell, members defending nuance in public threads, inside jokes.
Set targets for these the same way you set any goal, with explicit measurement definitions, as laid out in the [OKR planning guide](/blog/2024-10-29-devrel-team-goal-planning-strategy-okr).
If a metric can be inflated by an announcement blast, it is a marketing metric, not a community health metric.
## Related [#related]
* [DevRel activities](/docs/practices/devrel-activities) for where community fits among the other clusters
* [Content creation](/docs/practices/content-creation) for turning community questions into durable content
* [Understanding developer personas](/docs/fundamentals/understanding-developer-personas) for knowing who you are hosting in the first place
***
Sources & References:
* [The 90-9-1 Rule for Participation Inequality in Social Media and Online Communities](https://www.nngroup.com/articles/participation-inequality/) by Jakob Nielsen | Nielsen Norman Group, 2006
* [The Art of Community](https://www.jonobacon.com/books/artofcommunity/) by Jono Bacon | O'Reilly, 2nd edition 2012
* [The Business of Belonging: How to Make Community Your Competitive Advantage](https://www.wiley.com/en-us/The+Business+of+Belonging%3A+How+to+Make+Community+Your+Competitive+Advantage-p-9781119766124) by David Spinks | Wiley, 2021
---
# Content Creation (https://devrel.directory/docs/practices/content-creation)
## Content is leverage [#content-is-leverage]
For most DevRel teams, content is the highest-leverage activity available.
A good guide works around the clock, scales without headcount, and compounds: through search for years, and now through AI assistants that answer developer questions with whatever material explains the problem best.
The bar, however, has moved.
Developers skim, verify, and bounce fast, and generic content is now free to produce and therefore worthless.
What earns attention is content that is specific, runnable, and honest about tradeoffs.
## Content types and the job of each [#content-types-and-the-job-of-each]
Different formats do different jobs.
Confusing them is how docs end up with tutorials that read like reference and blog posts that read like ads.
* Quickstart: from zero to one working call in minutes.
Job: prove the product works and respect the reader's time.
* Tutorial: a guided path to a meaningful outcome, with the reader following along.
Job: teach by doing.
* How-to guide: a focused recipe for one task the reader already understands.
Job: unblock.
* Conceptual explainer: how the system thinks, its model and its boundaries.
Job: build the mental model that prevents the next ten questions.
* Reference: exhaustive, accurate, boring on purpose.
Job: answer precise questions precisely.
* Blog essay: opinion, experience, architecture stories, honest postmortems.
Job: reach and trust, especially with people not yet using the product.
* Video and livestreams: demos, walkthroughs, launch streams.
Job: show real usage, including the stumbles; the recording becomes an asset.
* Example repositories: complete, running applications developers can clone.
Job: be the starting point people actually build from.
The [Diátaxis framework](https://diataxis.fr) formalizes much of this split and is worth reading once.
Use it as a lens, not a bureaucracy.
## Writing for developers [#writing-for-developers]
The craft rules that separate content developers use from content they close:
1. Lead with working code.
Developers read prose to understand the code, not the reverse.
2. Make every snippet copy-paste complete: imports, versions, and setup included, no invisible prerequisites.
3. Show exact error messages.
Errors are what people search for; matching their text verbatim is free search traffic and instant recognition.
4. State versions and dates.
Nothing destroys trust like a tutorial that silently broke two releases ago.
5. Write for scanning: descriptive headings, short paragraphs, code blocks with language tags, one idea per section.
6. Keep marketing out of the critical path.
A quickstart that pauses to celebrate the product loses the reader at the pause.
7. Edit ruthlessly.
First drafts explain what you did; good drafts explain what the reader needs.
Test every tutorial by following it yourself in a clean environment, top to bottom, before publishing.
Every step where you improvise is a step where readers get stuck.
These same properties (self-contained sections, exact errors, runnable snippets) are also what make content usable by AI assistants, which increasingly sit between your docs and your developers.
[Writing Docs LLMs Can Use](/docs/ai-era/docs-for-llms) covers that shift in more depth.
## Distribution: where content meets developers [#distribution-where-content-meets-developers]
Publishing is not distribution.
A realistic distribution model for a developer audience:
* Search is the durable channel.
Target the problem queries developers actually type, including error messages, not brand terms.
* Your own channels are the asset you keep: docs, blog, newsletter, RSS.
Every platform channel is rented ground.
* Social platforms reward channel-native formats.
A link dump performs poorly everywhere; a short standalone insight with the link in follow-up performs fine on most platforms.
* Developer norms punish growth hacks.
No engagement bait, no fake questions, no reply-guy automation; disclose who you are, as in [community spaces](/docs/practices/community-building).
* Consistency beats virality.
One useful post a week for a year outperforms one lucky hit, and it is plannable.
The repurposing tree makes one effort feed many channels: a conference talk becomes a blog post, the post becomes a code sample, the sample becomes three short posts and a newsletter section.
Plan the tree when you plan the talk, not after.
## A pipeline a small team can sustain [#a-pipeline-a-small-team-can-sustain]
Content programs die of ambition more often than laziness.
A sustainable loop for a team of one or two:
1. Intake: keep one list fed by community questions, support tickets, sales objections, and release plans.
Recurring questions are commissioning briefs someone already wrote for you.
2. Selection: pick by audience impact and search demand, not internal excitement.
3. Cadence honesty: commit to the rhythm you can hold on a bad week.
Biweekly and reliable beats weekly and abandoned by March.
4. Technical review: every piece gets an accuracy pass from someone close to the code.
5. Publication checklist: metadata, code tested, links checked, one internal link to related material.
6. Refresh loop: revisit the top pages quarterly; updating a high-traffic guide usually beats writing a new one.
## Measuring content [#measuring-content]
Content measurement is directional, not precise, and pretending otherwise erodes trust in every number you report.
Leading indicators:
* Search rankings and impressions for the problem queries you target.
* Traffic to problem-solving pages, weighted by whether the page is on the adoption path.
* Quickstart and tutorial completion, if instrumented.
Lagging indicators:
* Content-assisted signups and activation: accounts whose session history touched key content before converting.
* Recurring support questions disappearing after the answering guide ships.
Attribution will be incomplete: developers read on one device and sign up on another, and AI assistants increasingly consume content on their behalf.
Report ranges and trends, note the blind spots, and set targets with explicit measurement definitions as in the [OKR planning guide](/blog/2024-10-29-devrel-team-goal-planning-strategy-okr).
Pageviews alone reward clickbait.
Pair every traffic number with a behavior that indicates the reader got somewhere.
## Related [#related]
* [DevRel activities](/docs/practices/devrel-activities) for how content fits the wider program
* [Community building](/docs/practices/community-building) for the question-to-content feedback loop
* [Understanding developer personas](/docs/fundamentals/understanding-developer-personas) for writing to a reader you can name
***
Sources & References:
* [Diátaxis: A systematic approach to technical documentation authoring](https://diataxis.fr) by Daniele Procida
* [Docs for Developers: An Engineer's Field Guide to Technical Writing](https://docsfordevelopers.com) by Jared Bhatti, Zachary Sarah Corleissen, Jen Lambourne, David Nunez, and Heidi Waterhouse | Apress, 2021
* [Google developer documentation style guide](https://developers.google.com/style) | Google
---
# DevRel Activities (https://devrel.directory/docs/practices/devrel-activities)
## The activity map [#the-activity-map]
DevRel work becomes visible through activities: the talks, posts, community threads, and feedback loops a team runs week after week.
Activities are not a strategy.
A [strategy](/docs/fundamentals/devrel-strategy) decides which developers you serve and what outcome the business needs; activities are how you get there.
The most common failure mode in DevRel is activity soup: doing a little of everything because everything is defensible.
A team stuck in activity soup is always busy, rarely measurable, and first in line when budgets tighten.
Pick a small set of activities that map to your current goal, run them long enough to judge honestly, and say no to the rest out loud.
This page maps the core activity clusters, what each one is good for, and how to choose between them.
## The six clusters [#the-six-clusters]
### 1. Content [#1-content]
Writing and producing material developers use to evaluate and adopt your product: quickstarts, tutorials, guides, reference material, blog posts, videos.
Content is the highest-leverage activity for most teams because it scales without headcount and compounds over time through search and, increasingly, AI assistants.
It earns its place from day one.
Signals it is working: rising traffic on problem-focused queries, quickstart completion, content-assisted signups.
Failure mode: publishing what the company wants to say instead of what developers are trying to do.
The full practice has [its own page](/docs/practices/content-creation).
### 2. Community [#2-community]
Creating and tending the places where developers using your product help each other: your own space, and your presence in spaces you do not own.
Community compounds like a network: every answered question becomes searchable capital, and every active member lowers the load on the next one.
It earns its place once there is a steady stream of real users asking questions, and not before.
Signals it is working: falling time-to-first-answer, member-answered questions, returning participants.
Failure mode: opening a Discord because everyone has one, then presiding over an empty room.
The full practice has [its own page](/docs/practices/community-building).
### 3. Speaking and events [#3-speaking-and-events]
Conference talks, meetups, workshops, webinars, and hackathons: high-touch moments where a person represents the product to a room.
Events create trust and reach density that content alone cannot, and they generate raw material for weeks of derivative content.
They earn their place when you know which audience attends and what you want them to do afterwards.
Signals it is working: qualified conversations, workshop completions, follow-up adoption you can trace to the room.
Failure mode: conference-driven development, where the calendar sets the roadmap and the team measures itself in booth hours.
Events are the most expensive activity per developer reached.
Treat every acceptance as a spend decision, not a reward.
### 4. Developer feedback and product influence [#4-developer-feedback-and-product-influence]
The inward-facing half of DevRel: collecting what developers struggle with and turning it into product and documentation changes.
This is the activity that separates DevRel from marketing.
It earns its place immediately, because it makes every other activity smarter, and it is how the team proves value to engineering and product peers.
Signals it is working: filed issues that get fixed, roadmap items traceable to community input, shrinking lists of repeated questions.
Failure mode: collecting feedback into a document nobody reads, which quietly teaches developers that talking to you changes nothing.
### 5. Developer experience work [#5-developer-experience-work]
Improving the product's first-run path: onboarding flows, error messages, sample apps, SDK ergonomics, and the documentation surrounding them.
Some organizations make this its own role, as covered in [roles and responsibilities](/docs/fundamentals/roles-and-responsibilities).
It earns its place when the data shows developers stalling between signup and first success.
Signals it is working: time-to-first-successful-call going down, fewer support tickets on setup steps.
Failure mode: shipping polish for the demo path while the real integration path stays rough.
### 6. Ecosystem and partnerships [#6-ecosystem-and-partnerships]
Integrations, co-marketing with adjacent tools, guest content, and champion programs that give your most invested users a bigger stage.
Ecosystem work multiplies reach through other people's audiences.
It earns its place after the basics work: partners amplify a good developer experience, they cannot fix a bad one.
Signals it is working: adoption arriving through integration paths, champions producing content you did not ask for.
Failure mode: logo-collecting partnerships that produce a press release and nothing else.
## Choosing activities by journey stage [#choosing-activities-by-journey-stage]
Different activities move different stages of the developer journey.
Start from where developers actually drop off, which your [personas work](/docs/fundamentals/understanding-developer-personas) should tell you.
* Awareness: talks, essays, podcasts, and being genuinely useful in external communities.
* Evaluation: comparison-friendly docs, honest quickstarts, sample apps that resemble real use.
* Activation: onboarding fixes, error message work, time-to-first-success instrumentation.
* Retention: release communication, changelogs, office hours, community support.
* Advocacy: champion programs, showcases, conference CFP support for community members.
If you cannot name the stage an activity serves, it is probably serving the calendar.
## A sample week for a team of one [#a-sample-week-for-a-team-of-one]
A realistic split for a solo DevRel practitioner with a shipped product and an early community:
1. Two mornings on content: one substantial piece in progress at all times.
2. One hour a day in the community and support queue, answering and logging patterns.
3. One afternoon on feedback synthesis: turn the week's questions into two or three concrete product or docs issues.
4. One afternoon on developer experience: fix the single worst snag developers hit that week.
5. A monthly, not weekly, slot for events and partnerships.
The exact split matters less than the discipline: recurring blocks, one owner, one measurable signal per activity.
## Prioritization heuristics [#prioritization-heuristics]
* Few over many: two activities done every week beat six done occasionally.
* Repeatable over spectacular: a talk is a moment, the recording plus the write-up is an asset.
* Measurable over comfortable: prefer the activity whose effect you can observe, even roughly, using goals set the way the [OKR planning guide](/blog/2024-10-29-devrel-team-goal-planning-strategy-okr) describes.
* Downstream of strategy: when someone requests an activity, ask which goal it serves before asking when.
* Keep a stop-doing list: every quarter, name one activity you are ending and say why.
## Related [#related]
* [Crafting a DevRel strategy](/docs/fundamentals/devrel-strategy) for deciding which goals the activities serve
* [Content creation](/docs/practices/content-creation) and [community building](/docs/practices/community-building) for the two deepest clusters
* [The importance of DevRel](/docs/fundamentals/importance) for the business case behind the work
***
Sources & References:
* [The Business Value of Developer Relations](https://www.devrelbook.com) by Mary Thengvall | Apress, 2018
* [The AAARRRP Developer Relations Strategy Framework](https://www.leggetter.co.uk/aaarrrp/) by Phil Leggetter | 2017
* [Developer Relations: How to Build and Grow a Successful Developer Program](https://link.springer.com/book/10.1007/978-1-4842-7164-3) by Caroline Lewko and James Parton | Apress, 2021
---
## Directory listings
# Advocu (https://devrel.directory/directory/advocu)
Runs developer ambassador and experts programs: applications, activity tracking, and program reporting in one place.
Covers the full program lifecycle: application and review flows, onboarding, activity submissions with approvals, and reporting on member contributions. Google's Developer Experts program is among the programs running on it. The step up from spreadsheets once an ambassador program needs auditable contribution history and renewal decisions.
- Category: Tools
- Website: https://www.advocu.com
- Pricing model (read 2026-07-26): paid
- Tags: advocacy, community
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Algolia DocSearch (https://devrel.directory/directory/algolia-docsearch)
Free hosted search for open-source docs sites; the default search layer on thousands of developer docs.
Crawls your documentation on a schedule and serves a hosted Algolia index through a drop-in search UI with typo tolerance and keyboard navigation. Free for public developer documentation and technical blogs, commercial or open source; search beyond docs goes through the paid Algolia plans. For a docs maintainer it removes the search-infrastructure job entirely: no index to host, no crawler to write.
- Category: Tools
- Website: https://docsearch.algolia.com
- Repository: https://github.com/algolia/docsearch
- Repository activity (checked 2026-07-26): 4.3k stars, last commit 2026-07, last release 2026-04
- Pricing model (read 2026-07-26): free
- Tags: docs, search
- Added: 2026-07-12
---
# Answer Overflow (https://devrel.directory/directory/answer-overflow)
Indexes Discord help channels into Google so community answers become searchable content.
Bridges Discord support to the open web: marked help channels are mirrored as indexable pages, so an answer written once in chat keeps earning search traffic for years. Communities opt in per channel and control what becomes public. It solves the standing DevRel complaint that Discord knowledge dies in scrollback.
- Category: Tools
- Website: https://www.answeroverflow.com
- Repository: https://github.com/AnswerOverflow/AnswerOverflow
- Repository activity (checked 2026-07-26): 1.9k stars, last commit 2026-07, last release 2024-10
- Tags: community, seo
- Added: 2026-07-08
---
# Apache Answer (https://devrel.directory/directory/apache-answer)
Open-source Q&A platform for running a self-hosted developer support forum with reputation and moderation.
Ships voting, accepted answers, reputation, badges, and moderation tools out of the box, with themes and plugins for customization. As an Apache top-level project its license and governance suit companies that cannot put support content on third-party SaaS. Fits teams that want an owned, searchable developer knowledge base instead of chat history.
- Category: Tools
- Website: https://answer.apache.org
- Repository: https://github.com/apache/answer
- Docs: https://answer.apache.org/docs
- Repository activity (checked 2026-07-26): 15k stars, last commit 2026-07, last release 2026-07
- Tags: community, forum, open-source
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Asciinema (https://devrel.directory/directory/asciinema)
Records terminal sessions as lightweight text-based embeds for docs, READMEs, and tutorials.
Recordings are text rather than video: files stay tiny, rendering stays sharp at any size, and viewers can pause and copy commands straight out of the player. It ships a CLI recorder, an embeddable web player, and a hosting service, all open source and self-hostable. Ideal for CLI quickstarts and release notes where a video would blur exactly the part that matters.
- Category: Tools
- Website: https://asciinema.org
- Repository: https://github.com/asciinema/asciinema
- Docs: https://docs.asciinema.org
- Repository activity (checked 2026-07-26): 17k stars, last commit 2026-06, last release 2026-06
- Pricing model (read 2026-07-26): free
- Tags: content, open-source
- Added: 2026-07-12
---
# Bevy (https://devrel.directory/directory/bevy)
Platform for distributed chapter and meetup programs; powers Google Developer Groups and CNCF community groups.
Gives a community team one platform to run hundreds of local chapters: organizer permissions, event pages, registration, emails, and cross-chapter analytics. Google Developer Groups and other large programs run their chapter networks on it, and the product has since broadened into forums, groups, and AI-driven engagement. Priced and shaped for enterprise community programs rather than a single meetup.
- Category: Tools
- Website: https://bevy.com
- Tags: events, community
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Bump.sh (https://devrel.directory/directory/bump-sh)
API documentation platform that diffs every deploy and generates changelogs, now also offering MCP server documentation for AI agents.
Turns an OpenAPI or AsyncAPI spec into hosted reference docs and records every deployment as a diff, so API consumers get a readable changelog and breaking changes surface before they bite integrators. Hubs group multiple APIs into one catalog. Built for API-first teams that treat the spec as the source of truth.
- Category: Tools
- Website: https://bump.sh
- Docs: https://docs.bump.sh
- Pricing model (read 2026-07-26): paid
- Tags: docs, api, changelog
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Buttondown (https://devrel.directory/directory/buttondown)
Markdown-first newsletter tool with an API, popular for developer-audience newsletters.
Newsletter infrastructure that behaves like a developer tool: write in Markdown, automate everything through a REST API, and keep your subscriber list portable. It handles paid subscriptions, RSS-to-email automation, and public archives without marketing-suite bloat. A common choice for personal DevRel newsletters and product digests.
- Category: Tools
- Website: https://buttondown.com
- Docs: https://docs.buttondown.com
- llms.txt: https://buttondown.com/llms.txt
- Pricing model (read 2026-07-26): freemium
- Tags: newsletter, content
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Canny (https://devrel.directory/directory/canny)
AI-powered customer feedback management platform for capturing and prioritizing feature requests and feedback.
Collects feature requests into voteable boards, deduplicates them, and ties each request to the users and revenue behind it, so prioritization arguments come with numbers attached. Public roadmap and changelog views close the loop with the people who asked. For DevRel it gives community feedback a paper trail that product managers accept.
- Category: Tools
- Website: https://canny.io
- llms.txt: https://canny.io/llms.txt
- Pricing model (read 2026-07-26): freemium
- Tags: feedback, changelog
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Common Room (https://devrel.directory/directory/common-room)
Platform that aggregates member activity across Discord, Slack, GitHub, and social to provide buyer intelligence and community insights through AI agents.
Stitches activity from chat platforms, GitHub, forums, social, CRM, and product data into one member graph, so you can see who is engaging, what they touch, and which companies they belong to. It has grown from community intelligence into a broader AI go-to-market platform aimed at sales as much as community teams; Zoom announced an agreement to acquire it in July 2026. Still one of the few tools that can tie community activity to pipeline influence.
- Category: Tools
- Website: https://www.commonroom.io
- llms.txt: https://www.commonroom.io/llms.txt
- Pricing model (read 2026-07-26): paid
- Tags: analytics, community
- Added: 2026-07-08
- Last verified: 2026-07-15
---
# confs.tech (https://devrel.directory/directory/confs-tech)
Community-maintained list of developer conferences and CFP deadlines, the standard place to find speaking slots.
Filterable by topic, country, and date, with a companion view for open CFPs; the data lives in a public GitHub repository anyone can send a pull request to. You can subscribe to new conferences per topic. The zero-cost starting point for building a conference and speaking pipeline.
- Category: Tools
- Website: https://confs.tech
- Repository: https://github.com/tech-conferences/confs.tech
- Repository activity (checked 2026-07-26): 1.7k stars, last commit 2026-03, last release 2018-03
- Tags: events, cfps, speaking
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Context7 (https://devrel.directory/directory/context7)
Serves version-specific library docs to AI coding tools over MCP; getting indexed here is docs distribution now.
Parses library documentation into version-pinned, code-focused snippets and serves them to coding assistants over MCP, so generated code matches the API surface a developer actually installed. Maintainers can submit and tune their own projects. As AI assistants become a primary docs surface, being resolvable here is a distribution channel in its own right.
- Category: Tools
- Website: https://context7.com
- Repository: https://github.com/upstash/context7
- MCP endpoint: https://mcp.context7.com/mcp
- Repository activity (checked 2026-07-26): 59k stars, last commit 2026-07, last release 2026-07
- llms.txt: https://context7.com/llms.txt
- Pricing model (read 2026-07-26): open-core
- Tags: ai, docs
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# daily.dev (https://devrel.directory/directory/daily-dev)
Personalized developer news feed; a distribution channel for getting technical content in front of developers.
An aggregated feed developers read in a new-tab browser extension and app, with topic tags, squads, and profiles layered on top. For DevRel it works as a distribution channel: useful posts earn organic reach beyond your own audience, and paid placements exist for launches. Content wins on merit, which rewards genuinely good technical writing.
- Category: Tools
- Website: https://daily.dev
- Repository: https://github.com/dailydotdev/daily
- Docs: https://docs.daily.dev
- Repository activity (checked 2026-07-26): 19k stars, last commit 2026-07, no published releases
- llms.txt: https://daily.dev/llms.txt
- Tags: content, marketing
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Descript (https://devrel.directory/directory/descript)
Text-based video and podcast editing, a fast way to produce tutorials, talks, and developer shows.
Edits video and audio by editing the transcript: delete a sentence from the text and it disappears from the media, with filler-word removal and studio-grade voice cleanup built in. Screen recording and multitrack editing cover tutorial and podcast workflows end to end. Lets a small team ship polished talks and demos without a dedicated video editor.
- Category: Tools
- Website: https://www.descript.com
- llms.txt: https://www.descript.com/llms.txt
- Pricing model (read 2026-07-26): freemium
- Tags: video, content
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Discord (https://devrel.directory/directory/discord)
Real-time chat platform used by developer communities for group communication and community building.
Servers combine chat, forum channels, voice stages, and scheduled events, with roles, permissions, and automations that scale from a side project to very large communities. It is the default venue for product communities, hackathons, and office hours. The tradeoff is discoverability: conversations are invisible to search engines unless you bridge them out.
- Category: Tools
- Website: https://discord.com
- Docs: https://docs.discord.com
- llms.txt: https://docs.discord.com/llms.txt
- Tags: community, chat
- Added: 2026-07-08
- Last verified: 2026-07-15
---
# Discourse (https://devrel.directory/directory/discourse)
The standard open-source forum software for long-form developer community discussion.
Threaded, searchable, SEO-friendly discussion with categories, trust levels, and moderation tooling that holds up at scale. Runs self-hosted or on official hosting, with a plugin ecosystem covering SSO, chat bridges, and AI answering. The durable complement to real-time chat: slower conversations that compound into a public knowledge base.
- Category: Tools
- Website: https://www.discourse.org
- Repository: https://github.com/discourse/discourse
- Repository activity (checked 2026-07-26): 47k stars, last commit 2026-07, no published releases
- Pricing model (read 2026-07-26): open-core
- Tags: community, forum
- Added: 2026-07-08
- Last verified: 2026-07-15
---
# Docusaurus (https://devrel.directory/directory/docusaurus)
Open-source docs framework from Meta, the workhorse of OSS documentation sites.
React-based static docs with versioning, internationalization, MDX components, and a built-in blog, plus first-class Algolia DocSearch integration. A large plugin and theme ecosystem keeps most needs a config change away. The safe default for open-source projects that want docs-as-code without building a site from scratch.
- Category: Tools
- Website: https://docusaurus.io
- Repository: https://github.com/facebook/docusaurus
- Docs: https://docusaurus.io/docs
- Repository activity (checked 2026-07-26): 65k stars, last commit 2026-07, last release 2026-07
- Pricing model (read 2026-07-26): free
- Tags: docs, open-source
- Added: 2026-07-08
- Last verified: 2026-07-15
---
# F5Bot (https://devrel.directory/directory/f5bot)
Free email alerts when your product is mentioned on Reddit, Hacker News, or Lobsters; the zero-budget listening option.
Watches Reddit, Hacker News, and Lobsters for your keywords and emails you within minutes of a mention, fast enough to join a thread while it is still on the front page. The base tier is free, with paid plans adding Slack and Discord delivery, feeds and API access, and AI filtering. Still the right first social-listening setup for a team of one.
- Category: Tools
- Website: https://f5bot.com
- Pricing model (read 2026-07-26): freemium
- Tags: social-listening
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Fern (https://devrel.directory/directory/fern)
Generates SDKs and a docs site from an OpenAPI spec, so a small team can ship a full developer portal.
From one API definition it generates idiomatic SDKs in the major languages plus a hosted docs site with an interactive API explorer. Docs live in your repo and publish through CI, keeping reference, guides, and client libraries in lockstep with the spec. Now part of Postman, it suits API companies that want a complete developer portal without stitching together separate vendors.
- Category: Tools
- Website: https://buildwithfern.com
- Repository: https://github.com/fern-api/fern
- Docs: https://buildwithfern.com/learn
- Repository activity (checked 2026-07-26): 3.7k stars, last commit 2026-07, last release 2026-05
- llms.txt: https://buildwithfern.com/llms.txt
- Pricing model (read 2026-07-26): open-core
- Tags: api, sdk, docs
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Ghost (https://devrel.directory/directory/ghost)
Open-source publishing platform behind many engineering blogs and paid developer newsletters.
A complete publishing stack: a clean editor, memberships and paid subscriptions, native newsletter sending, and a theme ecosystem, self-hostable or managed on Ghost(Pro). Performance is strong out of the box and there is no plugin sprawl to babysit. Fits developer-audience publications that want to own their platform and their subscriber list.
- Category: Tools
- Website: https://ghost.org
- Repository: https://github.com/TryGhost/Ghost
- Docs: https://docs.ghost.org
- Repository activity (checked 2026-07-26): 54k stars, last commit 2026-07, last release 2026-07
- llms.txt: https://docs.ghost.org/llms.txt
- Pricing model (read 2026-07-26): open-core
- Tags: content, blogging, open-source
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# GitBook (https://devrel.directory/directory/gitbook)
Documentation platform with Git sync for product and developer docs, now emphasizing AI-powered knowledge management and question answering.
A hosted docs editor that syncs with your Git repository, so writers work in a WYSIWYG UI while engineers keep changes flowing through pull requests. Includes AI answers over your content, change requests with review, and insights into what readers search for and miss. A fit for teams where non-engineers write a lot of the documentation.
- Category: Tools
- Website: https://www.gitbook.com
- Docs: https://docs.gitbook.com
- llms.txt: https://docs.gitbook.com/llms.txt
- Pricing model (read 2026-07-26): freemium
- Tags: docs
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# GitHub Discussions (https://devrel.directory/directory/github-discussions)
Threaded forums attached to your repos; the lowest-friction community home for open-source projects.
Q&A with accepted answers, polls, announcements, and categories, living next to the code and issues your users already navigate, with no extra accounts or moderation surface to stand up. Threads convert to issues when they turn into work, and content gets indexed by search engines. The lowest-friction forum for an open-source project.
- Category: Tools
- Website: https://github.com/features/discussions
- Docs: https://docs.github.com/discussions
- Tags: community, forum, open-source
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# kapa.ai (https://devrel.directory/directory/kapa-ai)
AI answer widget trained on your docs and community threads; deflects developer questions with cited answers.
Deploys as a docs widget, Slack and Discord bot, or API, answering developer questions from your docs, changelogs, and forum history with citations back to the sources. Dashboards show what developers ask and where answers fail, feeding the docs backlog. Popular with API and infrastructure companies drowning in repeat support questions.
- Category: Tools
- Website: https://www.kapa.ai
- Docs: https://docs.kapa.ai
- llms.txt: https://www.kapa.ai/llms.txt
- Tags: ai, docs, support
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Luma (https://devrel.directory/directory/luma)
Event pages, registration, and calendars used heavily for developer meetups.
Event pages that look good by default, with registration, reminders, waitlists, and check-in handled, plus followable calendars so each event grows the audience for the next one. It has become the default for tech meetups, community dinners, and launch events. Simple enough that volunteer organizers actually use it.
- Category: Tools
- Website: https://luma.com
- Docs: https://docs.luma.com
- llms.txt: https://docs.luma.com/llms.txt
- Pricing model (read 2026-07-26): freemium
- Tags: events
- Added: 2026-07-08
- Last verified: 2026-07-22
---
# Material for MkDocs (https://devrel.directory/directory/material-for-mkdocs)
The most widely deployed open-source docs theme; Markdown in, a polished documentation site out.
Turns a folder of Markdown and one YAML file into a polished docs site: instant search, dark mode, navigation tabs, admonitions, and hundreds of configuration options with no frontend work. The formerly sponsor-gated Insiders features are now free for everyone, and the project is in maintenance mode while its team builds a successor, Zensical. Still the pragmatic choice for existing MkDocs setups; plan new builds with the transition in mind.
- Category: Tools
- Website: https://squidfunk.github.io/mkdocs-material/
- Repository: https://github.com/squidfunk/mkdocs-material
- Repository activity (checked 2026-07-26): 27k stars, last commit 2026-07, last release 2026-07
- Tags: docs, open-source
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Mintlify (https://devrel.directory/directory/mintlify)
Documentation platform with built-in analytics and AI features; now positioning toward agents and self-updating documentation.
MDX-based docs from a Git repo with hosted previews, an interactive API playground generated from OpenAPI, and built-in AI surfaces: an assistant, llms.txt output, and agent-readable pages. Analytics show search terms and page engagement so you can see where readers get stuck. The current default for polished startup developer docs.
- Category: Tools
- Website: https://mintlify.com
- Docs: https://mintlify.com/docs
- MCP endpoint: https://www.mintlify.com/docs/mcp
- llms.txt: https://mintlify.com/docs/llms.txt
- Pricing model (read 2026-07-26): freemium
- Tags: docs
- Added: 2026-07-08
- Last verified: 2026-07-15
---
# OBS Studio (https://devrel.directory/directory/obs-studio)
Free, open-source recording and streaming; the default rig for live coding, demos, and talk recordings.
Scene-based compositing of screens, cameras, and overlays with per-source audio control, streaming to any RTMP destination and high-quality local recording. Virtual camera output and remote control ship built in, and a deep plugin ecosystem covers captions, NDI, and automated scene switching. Most livestream, talk-recording, and demo rigs standardize on it eventually.
- Category: Tools
- Website: https://obsproject.com
- Repository: https://github.com/obsproject/obs-studio
- Docs: https://docs.obsproject.com
- Repository activity (checked 2026-07-26): 74k stars, last commit 2026-07, last release 2026-07
- Tags: video, streaming, open-source
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Octolens (https://devrel.directory/directory/octolens)
Social listening tool tracking mentions across Reddit, X, LinkedIn, and other platforms; evolving to serve the agent era with API and MCP integrations.
Tracks keyword mentions across Hacker News, Reddit, X, LinkedIn, GitHub, YouTube, and more, filters them with AI so the feed stays relevant, and pushes alerts to Slack for fast responses. Mentions can be triaged and measured over time. Built for devtools companies, which shows in the choice of channels it watches.
- Category: Tools
- Website: https://octolens.com
- llms.txt: https://octolens.com/llms.txt
- Pricing model (read 2026-07-26): paid
- Tags: social-listening, analytics
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# OSS Insight (https://devrel.directory/directory/oss-insight)
Analytics over public GitHub events for open-source trends; now emphasizing AI agent frameworks, LLM tools, and MCP servers alongside general repo benchmarking.
Explorable dashboards over billions of public GitHub events: star, contributor, and pull-request trends for any repository, side-by-side comparisons, and ecosystem rankings. Built by PingCAP as a TiDB showcase, and free to use. Useful for benchmarking your project against alternatives with data instead of vibes.
- Category: Tools
- Website: https://ossinsight.io
- Repository: https://github.com/pingcap/ossinsight
- Docs: https://ossinsight.io/docs
- Repository activity (checked 2026-07-26): 2.4k stars, last commit 2026-07, no published releases
- llms.txt: https://ossinsight.io/llms.txt
- Pricing model (read 2026-07-26): free
- Tags: analytics, open-source
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Plausible (https://devrel.directory/directory/plausible)
Lightweight, privacy-first web analytics for docs and blogs; no cookie banner needed for developer audiences.
A single lightweight script, no cookies, EU-owned infrastructure, with goals, funnels, and UTM breakdowns covering what a content team actually checks. It is open source and can be self-hosted if data must stay on your infrastructure. For docs and blogs it answers which content works without a consent banner or a privacy review fight.
- Category: Tools
- Website: https://plausible.io
- Repository: https://github.com/plausible/analytics
- Docs: https://plausible.io/docs
- Repository activity (checked 2026-07-26): 28k stars, last commit 2026-07, last release 2026-05
- Pricing model (read 2026-07-26): open-core
- Tags: analytics, open-source
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# PostHog (https://devrel.directory/directory/posthog)
Open-source product analytics platform with AI-powered features for automated debugging and code generation.
Event analytics, funnels, session replay, feature flags, experiments, and SQL access in one platform, with a free tier that covers small products. DevRel teams use it to trace docs-to-signup funnels and measure which content actually activates users. The all-in-one option when product and DevRel want to share a single analytics stack.
- Category: Tools
- Website: https://posthog.com
- Repository: https://github.com/PostHog/posthog
- Docs: https://posthog.com/docs
- MCP endpoint: https://mcp.posthog.com/mcp
- Repository activity (checked 2026-07-26): 37k stars, last commit 2026-07, last release 2026-07
- llms.txt: https://posthog.com/llms.txt
- Pricing model (read 2026-07-26): open-core
- Tags: analytics, open-source
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# pretalx (https://devrel.directory/directory/pretalx)
Open-source call-for-papers and conference scheduling, trusted by FOSDEM-scale community events.
Handles the whole talk pipeline: CFP forms, review rounds with optional anonymization, acceptance emails, speaker information collection, and schedule building with published program exports. Self-host the open-source core or use the hosted service. The community-conference standard once CFP management outgrows forms and spreadsheets.
- Category: Tools
- Website: https://pretalx.com
- Repository: https://github.com/pretalx/pretalx
- Docs: https://docs.pretalx.org
- Repository activity (checked 2026-07-26): 900+ stars, last commit 2026-07, last release 2026-07
- Pricing model (read 2026-07-26): open-core
- Tags: events, cfps, open-source
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Profound (https://devrel.directory/directory/profound)
Tracks how your product shows up in ChatGPT, Perplexity, and Claude answers as AI search reshapes discovery.
Runs your key prompts against the major AI assistants on a schedule, tracking whether your product gets mentioned or recommended, with what sentiment, and which sources the models cite. Competitor views show who wins which question. Answer-engine visibility is the new organic search problem, and this is its measurement layer.
- Category: Tools
- Website: https://www.tryprofound.com
- Pricing model (read 2026-07-26): paid
- Tags: ai, analytics, seo
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Read the Docs (https://devrel.directory/directory/read-the-docs)
Automated building, versioning, and hosting of docs from Git; the long-standing home of open-source documentation.
Connect a repository and every push builds and hosts versioned documentation, with pull request previews, full-text search, and downloadable offline formats. It works with Sphinx and MkDocs and stays free for open-source projects. The boring, reliable choice that has hosted a large share of OSS documentation for over a decade.
- Category: Tools
- Website: https://about.readthedocs.com
- Repository: https://github.com/readthedocs/readthedocs.org
- Docs: https://docs.readthedocs.com
- Repository activity (checked 2026-07-26): 8.3k stars, last commit 2026-07, last release 2026-07
- llms.txt: https://docs.readthedocs.com/llms.txt
- Tags: docs, open-source
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# ReadMe (https://devrel.directory/directory/readme)
Interactive API documentation hubs with real-time API logs and guides.
Hosted developer hubs where the OpenAPI-driven reference lets developers call your API from the page with their own keys, and real request logs feed per-customer metrics. Guides, changelog, and discussions live in the same hub. Strong when developer support wants to debug from actual traffic rather than screenshots.
- Category: Tools
- Website: https://readme.com
- Docs: https://docs.readme.com
- llms.txt: https://docs.readme.com/llms.txt
- Pricing model (read 2026-07-26): freemium
- Tags: docs, api
- Added: 2026-07-08
- Last verified: 2026-07-15
---
# Redocly (https://devrel.directory/directory/redocly)
Maker of Redoc, the long-standing OpenAPI reference renderer, plus a full API docs platform.
Redoc renders an OpenAPI spec into the familiar three-panel API reference; the commercial platform adds hosted portals, spec linting with configurable rulesets, and preview deployments. The linting is the quiet DevRel win: API governance in CI keeps reference docs consistent before anything publishes. A fit for companies managing many API specs.
- Category: Tools
- Website: https://redocly.com
- Repository: https://github.com/Redocly/redoc
- Docs: https://redocly.com/docs
- Repository activity (checked 2026-07-26): 25k stars, last commit 2026-07, last release 2026-05
- llms.txt: https://redocly.com/llms.txt
- Pricing model (read 2026-07-26): open-core
- Tags: docs, api
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Scalar (https://devrel.directory/directory/scalar)
Open-source API reference and request client that renders OpenAPI specs into interactive docs, with SDKs and API registry.
Renders OpenAPI specs into modern, themable reference docs with an integrated API client for trying requests, embeddable in existing sites or hosted on its platform. The core is open source, with offline-capable client apps alongside. A fresh alternative to the incumbent reference renderers.
- Category: Tools
- Website: https://scalar.com
- Repository: https://github.com/scalar/scalar
- Docs: https://scalar.com/docs
- Repository activity (checked 2026-07-26): 15k stars, last commit 2026-07, last release 2026-07
- Pricing model (read 2026-07-26): open-core
- Tags: docs, api, open-source
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Scarf (https://devrel.directory/directory/scarf)
Provides intelligence on how agents and developers use open-source packages and containers, with focus on GTM signals and risk.
Acts as a configurable gateway in front of package downloads, container pulls, and links, resolving anonymous traffic into company-level adoption signals, with pixels for docs and READMEs. Maintainers and commercial OSS teams use it to see which organizations actually run their software. It turns raw download counts into an account list a sales team can act on.
- Category: Tools
- Website: https://about.scarf.sh
- Docs: https://docs.scarf.sh
- Pricing model (read 2026-07-26): freemium
- Tags: analytics, open-source
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Sessionize (https://devrel.directory/directory/sessionize)
Call-for-papers and speaker management for conferences and meetups.
Runs the speaker side of an event: CFP submissions, multi-round review with rating teams, acceptance workflows, speaker communication, and schedule building with an embeddable agenda. It is free for community events and paid for commercial ones. Speaker profiles double as portfolios, listing past sessions and surfacing open calls.
- Category: Tools
- Website: https://sessionize.com
- Pricing model (read 2026-07-26): freemium
- Tags: speaking, events
- Added: 2026-07-08
- Last verified: 2026-07-15
---
# Slack (https://devrel.directory/directory/slack)
Team chat platform where developer and customer communities collaborate and automate workflows.
Channels, threads, huddles, and workflow automation in the tool your members already have open for work, which is exactly why B2B and enterprise developer communities keep choosing it. Free-plan history limits make community archives fragile, so pair it with a public knowledge surface. Fits audiences that live in Slack all day anyway.
- Category: Tools
- Website: https://slack.com
- Docs: https://docs.slack.com
- llms.txt: https://slack.com/llms.txt
- Pricing model (read 2026-07-26): freemium
- Tags: community, chat
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Slidev (https://devrel.directory/directory/slidev)
Markdown-based slide decks with live code and syntax highlighting, built for developer talks.
Decks are Markdown plus Vue components: syntax-highlighted code blocks, live coding in an embedded Monaco editor, presenter mode, and PDF or hosted exports, all version-controlled in Git. Slides diff and review like code because they are code. The talk tool for developer advocates whose slides are mostly code anyway.
- Category: Tools
- Website: https://sli.dev
- Repository: https://github.com/slidevjs/slidev
- Repository activity (checked 2026-07-26): 47k stars, last commit 2026-07, last release 2026-07
- llms.txt: https://sli.dev/llms.txt
- Pricing model (read 2026-07-26): free
- Tags: speaking, open-source
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Slido (https://devrel.directory/directory/slido)
Live Q&A and polls inside talks and webinars, standard kit for audience interaction at developer events.
Audience Q&A with upvoting, live polls, quizzes, and word clouds that drop into PowerPoint, Google Slides, or a browser tab, with moderation over incoming questions. Part of Cisco's Webex family but works standalone with any setup. The standard way to keep large-room developer talks two-way.
- Category: Tools
- Website: https://www.slido.com
- Tags: events, speaking
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Stainless (https://devrel.directory/directory/stainless)
SDK generator and API tooling platform used by OpenAI, Anthropic, and Cloudflare; now also generates MCP servers and API documentation.
Generates SDKs that read like a careful engineer wrote them, with pagination, retries, streaming, and auth handled idiomatically per language. Anthropic acquired Stainless in May 2026 and is winding down the hosted SDK generator: existing customers keep their SDKs, but new signups are closed. For new SDK pipelines, evaluate the alternatives in this directory instead.
- Category: Tools
- Website: https://www.stainless.com
- Docs: https://www.stainless.com/docs
- llms.txt: https://www.stainless.com/docs/llms.txt
- Pricing model (read 2026-07-26): freemium
- Tags: api, sdk
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# star-history (https://devrel.directory/directory/star-history)
Charts GitHub star growth over time; the graph in every devtool launch post and pitch deck.
Paste repositories and get a comparable star-growth chart, embeddable as a live image in READMEs and blog posts. Free and open source, with a browser extension for quick checks. Handy for launch posts, investor updates, and keeping honest score against alternatives.
- Category: Tools
- Website: https://www.star-history.com
- Repository: https://github.com/star-history/star-history
- Repository activity (checked 2026-07-26): 9.3k stars, last commit 2026-07, no published releases
- Tags: analytics, open-source
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Starlight (https://devrel.directory/directory/starlight)
Astro's documentation framework with search, i18n, and theming out of the box; a fast-growing Docusaurus alternative.
Ships search, internationalization, dark mode, and accessible navigation on Astro's zero-JavaScript-by-default architecture, so docs stay fast without tuning. Content is Markdown or MDX, and components from any framework can be embedded where interactivity earns its keep. The performance-first pick among modern docs frameworks.
- Category: Tools
- Website: https://starlight.astro.build
- Repository: https://github.com/withastro/starlight
- Repository activity (checked 2026-07-26): 8.9k stars, last commit 2026-07, last release 2026-07
- Pricing model (read 2026-07-26): free
- Tags: docs, open-source
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Vale (https://devrel.directory/directory/vale)
Command-line prose linter that enforces a docs style guide in CI; keeps large doc sets consistent.
Checks prose against a style guide as code: adopt packaged rules for the Google or Microsoft style guides or write your own checks in YAML. It runs in CI, editors, and pre-commit hooks, failing builds on violations the way a linter fails on code. How docs teams keep a hundred contributors sounding like one writer.
- Category: Tools
- Website: https://vale.sh
- Repository: https://github.com/vale-cli/vale
- Docs: https://vale.sh/docs
- Repository activity (checked 2026-07-26): 5.6k stars, last commit 2026-07, last release 2026-07
- Tags: docs, open-source
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# Zulip (https://devrel.directory/directory/zulip)
Open-source threaded team chat; the community home of Rust and other projects that outgrew unthreaded chat.
Every message lives under a topic within a channel, so conversations stay followable asynchronously and remain searchable years later; public archives can be exposed to the open web. Self-host the open-source server or use the cloud, which is free for open-source projects. Chosen by communities that treat chat history as documentation rather than scrollback.
- Category: Tools
- Website: https://zulip.com
- Repository: https://github.com/zulip/zulip
- Docs: https://zulip.com/help
- Repository activity (checked 2026-07-26): 25k stars, last commit 2026-07, last release 2026-06
- Pricing model (read 2026-07-26): open-core
- Tags: community, chat, open-source
- Added: 2026-07-12
- Last verified: 2026-07-15
---
# CMX (https://devrel.directory/directory/cmx)
Community for community professionals with events and research, much of it DevRel-adjacent.
Runs a large practitioner network with a Slack community, local chapters, the annual CMX Summit, and research on community strategy and careers. It is community-industry rather than DevRel-specific, strongest on program design, metrics, and career development. Part of Bevy since 2019.
- Category: Communities
- Website: https://cmxhub.com
- Tags: community-management
- Added: 2026-07-08
- Last verified: 2026-07-15
---
# dev.to (https://devrel.directory/directory/dev-to)
Large developer blogging community, a common distribution channel for DevRel content.
A blogging platform with a built-in audience: posts reach readers through tags and feeds without you bringing followers, and canonical URLs make cross-posting safe for SEO. Organization pages collect posts from everyone writing about your product. Reliable distribution for tutorials and launch write-ups that need reach beyond your own blog.
- Category: Communities
- Website: https://dev.to
- Repository: https://github.com/forem/forem
- Repository activity (checked 2026-07-26): 22k stars, last commit 2026-07, no published releases
- Tags: content, blogging
- Added: 2026-07-08
- Last verified: 2026-07-15
---
# Developer Marketing Alliance (https://devrel.directory/directory/developer-marketing-alliance)
Community and content hub focused on marketing to developers.
Now folded into Product Marketing Alliance, where developer marketing lives on as a resources track and an annual Developer Marketing Summit. The content covers the marketing half of reaching developers: positioning, campaigns, and measurement. Useful when DevRel sits next to a marketing org and the two need shared vocabulary.
- Category: Communities
- Website: https://developermarketing.io
- Tags: marketing
- Added: 2026-07-08
---
# DevRel Collective (https://devrel.directory/directory/devrel-collective)
Slack community of DevRel practitioners; the de-facto watercooler of the profession.
A practitioner Slack where DevRel people trade advice, opportunities, and war stories they cannot share inside their own companies. Joining goes through a short application reviewed by the admins. The first place to ask how other teams handle whatever you are stuck on.
- Category: Communities
- Website: https://devrelcollective.fun
- Tags: slack, peers
- Added: 2026-07-08
- Last verified: 2026-07-15
---
# Hashnode (https://devrel.directory/directory/hashnode)
Developer blogging platform with custom domains, popular for personal dev branding.
Developer blogging with a built-in newsletter and a community feed that gives new posts initial distribution. The differentiators moved to the five-dollar-a-month Pro plan in 2026: custom domains, automatic GitHub backup of posts, and a headless mode that serves content over APIs, with free blogs hosted on a hashnode.dev subdomain. Still a middle ground between dev.to reach and fully self-hosted ownership.
- Category: Communities
- Website: https://hashnode.com
- Tags: content, blogging
- Added: 2026-07-08
- Last verified: 2026-07-15
---
# build mode (https://devrel.directory/directory/build-mode)
PostHog's newsletter on building and growing products, formerly Product for Engineers; covers marketing, activation, and product lessons from PostHog's own work.
- Category: Newsletters
- Website: https://newsletter.posthog.com
- Tags: marketing, weekly
- Added: 2026-07-17
- Last verified: 2026-07-22
---
# console.dev (https://devrel.directory/directory/console-dev)
Free weekly newsletter reviewing new developer tools and beta releases, sent every Thursday.
- Category: Newsletters
- Website: https://console.dev
- Tags: weekly, devtools
- Added: 2026-07-17
- Last verified: 2026-07-22
---
# Developer Avocados Weekly (https://devrel.directory/directory/developer-avocados-weekly)
Weekly email roundup of Developer Relations articles, resources, and conference CFPs.
Curated the week's DevRel writing, talks, and open CFPs into one email, maintained by practitioners as a community service. Publication has been dormant since mid-2024, but the archive remains browsable and maps the recurring themes of the profession well. Worth a look for the back catalog rather than for fresh issues.
- Category: Newsletters
- Website: https://developeravocados.net
- Tags: weekly, cfps
- Added: 2026-07-08
- Last verified: 2026-07-15
---
# Community Pulse (https://devrel.directory/directory/community-pulse)
Podcast on community and DevRel topics, hosted by long-time practitioners.
Long-running episodes on the unglamorous realities of the job: burnout, layoffs, metrics, career ladders, and program politics, discussed by hosts who do the work themselves. Guests come from across the community and DevRel world. Worth a listen when you need proof that your weird org problems are everyone's problems.
- Category: Podcasts
- Website: https://www.communitypulse.io
- Tags: podcast
- Added: 2026-07-08
- Last verified: 2026-07-15
---
# devtools.fm (https://devrel.directory/directory/devtools-fm)
Podcast about developer tools and the people who make them; hosts Andrew Lisowski and Justin Bennett interview maintainers and devtool builders.
- Category: Podcasts
- Website: https://www.devtools.fm
- Tags: podcast, devtools, open-source
- Added: 2026-07-17
- Last verified: 2026-07-22
---
# Scaling DevTools (https://devrel.directory/directory/scaling-devtools)
Interview podcast by Jack Bridger on how developer tools companies grow; founders and operators talk marketing, positioning, and DevRel.
- Category: Podcasts
- Website: https://scalingdevtools.com
- Tags: podcast, devtools, marketing
- Added: 2026-07-17
- Last verified: 2026-07-22
---
# The Business of Open Source (https://devrel.directory/directory/the-business-of-open-source)
Interview podcast by Emily Omier on positioning and company building for commercial open-source companies.
- Category: Podcasts
- Website: https://www.emilyomier.com/podcast
- Tags: podcast, open-source, marketing
- Added: 2026-07-17
- Last verified: 2026-07-22
---
# Catchy (https://devrel.directory/directory/catchy)
Developer marketing agency working with large tech platforms; covers go-to-market strategy, demand generation, content production, and developer programs.
- Category: Agencies
- Website: https://www.catchyagency.com
- llms.txt: https://www.catchyagency.com/llms.txt
- Tags: marketing, consulting
- Added: 2026-07-17
- Last verified: 2026-07-22
---
# Draft.dev (https://devrel.directory/directory/draft-dev)
Technical content agency that produces tutorials, blog posts, and video for developer tools and platform companies, with emphasis on AI-powered content systems and search engine optimization.
- Category: Agencies
- Website: https://draft.dev
- llms.txt: https://draft.dev/llms.txt
- Tags: content, marketing
- Added: 2026-07-17
- Last verified: 2026-07-22
---
# EveryDeveloper (https://devrel.directory/directory/everydeveloper)
Technical content strategy consultancy run by Adam DuVander; helps API and devtool companies earn developer visibility, trust, and adoption.
- Category: Agencies
- Website: https://everydeveloper.com
- Tags: content, consulting
- Added: 2026-07-17
- Last verified: 2026-07-22
---
# Hoopy (https://devrel.directory/directory/hoopy)
Developer relations consultancy by Matthew Revell, also behind DevRel.net and DevRelCon.
Consulting on developer relations strategy, program design, and developer experience, drawing on the network behind the DevRelCon conference series and the DeveloperRelations.com resource library (formerly DevRel.net). One of the longest-running dedicated DevRel consultancies. Where teams go for outside help standing up or refocusing a program.
- Category: Agencies
- Website: https://www.hoopy.io
- Tags: consulting
- Added: 2026-07-08
- Last verified: 2026-07-15
---
# Ritza (https://devrel.directory/directory/ritza)
Technical content agency for developer platforms; engineers turned writers produce documentation, tutorials, onboarding guides, and SEO content.
- Category: Agencies
- Website: https://ritza.co
- Tags: content, docs
- Added: 2026-07-17
- Last verified: 2026-07-22
---
# Wizard on Demand (https://devrel.directory/directory/wizard-on-demand)
Content marketing agency for devtools and enterprise infrastructure companies; creates technical articles and resources and runs SEO distribution.
- Category: Agencies
- Website: https://www.wizardondemand.com
- Tags: content, marketing
- Added: 2026-07-17
- Last verified: 2026-07-22
## Comparisons
# Apache Answer vs Discourse (https://devrel.directory/directory/compare/apache-answer-vs-discourse)
Apache Answer and Discourse are both listed under Community platforms in this directory. On the criteria this directory records they differ on focus, stars, documentation, pricing model. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | Apache Answer | Discourse |
| --- | --- | --- |
| Category | Tools | Tools |
| Type | Community platforms | Community platforms |
| Focus | community, forum, open-source | community, forum |
| Public source repo | Yes | Yes |
| Last commit | Jul 2026 | Jul 2026 |
| Stars | 15k | 47k |
| Documentation | Yes | Not stated |
| Pricing model | Not stated | Open core (checked Jul 26, 2026) |
| Link verified | Jul 15, 2026 | Jul 15, 2026 |
| Listed since | Jul 12, 2026 | Jul 8, 2026 |
## What each one is
### Apache Answer (https://devrel.directory/directory/apache-answer)
Open-source Q&A platform for running a self-hosted developer support forum with reputation and moderation.
Apache Answer is listed under Community platforms, tagged open-source.
### Discourse (https://devrel.directory/directory/discourse)
The standard open-source forum software for long-form developer community discussion.
Discourse is listed under Community platforms.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
---
# Bevy vs Luma (https://devrel.directory/directory/compare/bevy-vs-luma)
Bevy and Luma are both listed under Events & speaking in this directory. On the criteria this directory records they differ on focus, documentation, llms.txt, pricing model. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | Bevy | Luma |
| --- | --- | --- |
| Category | Tools | Tools |
| Type | Events & speaking | Events & speaking |
| Focus | events, community | events |
| Documentation | Not stated | Yes |
| llms.txt | Not stated | Yes |
| Pricing model | Not stated | Freemium (checked Jul 26, 2026) |
| Link verified | Jul 15, 2026 | Jul 22, 2026 |
| Listed since | Jul 12, 2026 | Jul 8, 2026 |
## What each one is
### Bevy (https://devrel.directory/directory/bevy)
Platform for distributed chapter and meetup programs; powers Google Developer Groups and CNCF community groups.
Bevy is listed under Events & speaking, tagged community.
### Luma (https://devrel.directory/directory/luma)
Event pages, registration, and calendars used heavily for developer meetups.
Luma is listed under Events & speaking.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
---
# Bump.sh vs Redocly (https://devrel.directory/directory/compare/bump-sh-vs-redocly)
Bump.sh and Redocly are both listed under API & SDK tooling in this directory. On the criteria this directory records they differ on focus, public source repo, last commit, stars, llms.txt, pricing model. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | Bump.sh | Redocly |
| --- | --- | --- |
| Category | Tools | Tools |
| Type | API & SDK tooling | API & SDK tooling |
| Focus | docs, api, changelog | docs, api |
| Public source repo | Not stated | Yes |
| Last commit | Not stated | Jul 2026 |
| Stars | Not stated | 25k |
| Documentation | Yes | Yes |
| llms.txt | Not stated | Yes |
| Pricing model | Paid (checked Jul 26, 2026) | Open core (checked Jul 26, 2026) |
| Link verified | Jul 15, 2026 | Jul 15, 2026 |
| Listed since | Jul 12, 2026 | Jul 12, 2026 |
## What each one is
### Bump.sh (https://devrel.directory/directory/bump-sh)
API documentation platform that diffs every deploy and generates changelogs, now also offering MCP server documentation for AI agents.
Bump.sh is listed under API & SDK tooling, tagged docs, changelog.
### Redocly (https://devrel.directory/directory/redocly)
Maker of Redoc, the long-standing OpenAPI reference renderer, plus a full API docs platform.
Redocly is listed under API & SDK tooling, tagged docs.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
---
# Bump.sh vs Scalar (https://devrel.directory/directory/compare/bump-sh-vs-scalar)
Bump.sh and Scalar are both listed under API & SDK tooling in this directory. On the criteria this directory records they differ on focus, public source repo, last commit, stars, pricing model. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | Bump.sh | Scalar |
| --- | --- | --- |
| Category | Tools | Tools |
| Type | API & SDK tooling | API & SDK tooling |
| Focus | docs, api, changelog | docs, api, open-source |
| Public source repo | Not stated | Yes |
| Last commit | Not stated | Jul 2026 |
| Stars | Not stated | 15k |
| Documentation | Yes | Yes |
| Pricing model | Paid (checked Jul 26, 2026) | Open core (checked Jul 26, 2026) |
| Link verified | Jul 15, 2026 | Jul 15, 2026 |
| Listed since | Jul 12, 2026 | Jul 12, 2026 |
## What each one is
### Bump.sh (https://devrel.directory/directory/bump-sh)
API documentation platform that diffs every deploy and generates changelogs, now also offering MCP server documentation for AI agents.
Bump.sh is listed under API & SDK tooling, tagged docs, changelog.
### Scalar (https://devrel.directory/directory/scalar)
Open-source API reference and request client that renders OpenAPI specs into interactive docs, with SDKs and API registry.
Scalar is listed under API & SDK tooling, tagged docs, open-source.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
---
# Buttondown vs Ghost (https://devrel.directory/directory/compare/buttondown-vs-ghost)
Buttondown and Ghost are both listed under Content & media in this directory. On the criteria this directory records they differ on focus, public source repo, last commit, stars, pricing model. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | Buttondown | Ghost |
| --- | --- | --- |
| Category | Tools | Tools |
| Type | Content & media | Content & media |
| Focus | newsletter, content | content, blogging, open-source |
| Public source repo | Not stated | Yes |
| Last commit | Not stated | Jul 2026 |
| Stars | Not stated | 54k |
| Documentation | Yes | Yes |
| llms.txt | Yes | Yes |
| Pricing model | Freemium (checked Jul 26, 2026) | Open core (checked Jul 26, 2026) |
| Link verified | Jul 15, 2026 | Jul 15, 2026 |
| Listed since | Jul 12, 2026 | Jul 12, 2026 |
## What each one is
### Buttondown (https://devrel.directory/directory/buttondown)
Markdown-first newsletter tool with an API, popular for developer-audience newsletters.
Buttondown is listed under Content & media.
### Ghost (https://devrel.directory/directory/ghost)
Open-source publishing platform behind many engineering blogs and paid developer newsletters.
Ghost is listed under Content & media, tagged open-source.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
---
# dev.to vs Hashnode (https://devrel.directory/directory/compare/dev-to-vs-hashnode)
dev.to and Hashnode are both listed under Communities in this directory. On the criteria this directory records they differ on public source repo, last commit, stars. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | dev.to | Hashnode |
| --- | --- | --- |
| Category | Communities | Communities |
| Focus | content, blogging | content, blogging |
| Public source repo | Yes | Not stated |
| Last commit | Jul 2026 | Not stated |
| Stars | 22k | Not stated |
| Link verified | Jul 15, 2026 | Jul 15, 2026 |
| Listed since | Jul 8, 2026 | Jul 8, 2026 |
## What each one is
### dev.to (https://devrel.directory/directory/dev-to)
Large developer blogging community, a common distribution channel for DevRel content.
dev.to is listed under Communities.
### Hashnode (https://devrel.directory/directory/hashnode)
Developer blogging platform with custom domains, popular for personal dev branding.
Hashnode is listed under Communities.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
---
# Discord vs Slack (https://devrel.directory/directory/compare/discord-vs-slack)
Discord and Slack are both listed under Community platforms in this directory. On the criteria this directory records they differ on pricing model. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | Discord | Slack |
| --- | --- | --- |
| Category | Tools | Tools |
| Type | Community platforms | Community platforms |
| Focus | community, chat | community, chat |
| Documentation | Yes | Yes |
| llms.txt | Yes | Yes |
| Pricing model | Not stated | Freemium (checked Jul 26, 2026) |
| Link verified | Jul 15, 2026 | Jul 15, 2026 |
| Listed since | Jul 8, 2026 | Jul 12, 2026 |
## What each one is
### Discord (https://devrel.directory/directory/discord)
Real-time chat platform used by developer communities for group communication and community building.
Discord is listed under Community platforms.
### Slack (https://devrel.directory/directory/slack)
Team chat platform where developer and customer communities collaborate and automate workflows.
Slack is listed under Community platforms.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
---
# Discord vs Zulip (https://devrel.directory/directory/compare/discord-vs-zulip)
Discord and Zulip are both listed under Community platforms in this directory. On the criteria this directory records they differ on focus, public source repo, last commit, stars, llms.txt, pricing model. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | Discord | Zulip |
| --- | --- | --- |
| Category | Tools | Tools |
| Type | Community platforms | Community platforms |
| Focus | community, chat | community, chat, open-source |
| Public source repo | Not stated | Yes |
| Last commit | Not stated | Jul 2026 |
| Stars | Not stated | 25k |
| Documentation | Yes | Yes |
| llms.txt | Yes | Not stated |
| Pricing model | Not stated | Open core (checked Jul 26, 2026) |
| Link verified | Jul 15, 2026 | Jul 15, 2026 |
| Listed since | Jul 8, 2026 | Jul 12, 2026 |
## What each one is
### Discord (https://devrel.directory/directory/discord)
Real-time chat platform used by developer communities for group communication and community building.
Discord is listed under Community platforms.
### Zulip (https://devrel.directory/directory/zulip)
Open-source threaded team chat; the community home of Rust and other projects that outgrew unthreaded chat.
Zulip is listed under Community platforms, tagged open-source.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
---
# Discourse vs GitHub Discussions (https://devrel.directory/directory/compare/discourse-vs-github-discussions)
Discourse and GitHub Discussions are both listed under Community platforms in this directory. On the criteria this directory records they differ on focus, public source repo, last commit, stars, documentation, pricing model. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | Discourse | GitHub Discussions |
| --- | --- | --- |
| Category | Tools | Tools |
| Type | Community platforms | Community platforms |
| Focus | community, forum | community, forum, open-source |
| Public source repo | Yes | Not stated |
| Last commit | Jul 2026 | Not stated |
| Stars | 47k | Not stated |
| Documentation | Not stated | Yes |
| Pricing model | Open core (checked Jul 26, 2026) | Not stated |
| Link verified | Jul 15, 2026 | Jul 15, 2026 |
| Listed since | Jul 8, 2026 | Jul 12, 2026 |
## What each one is
### Discourse (https://devrel.directory/directory/discourse)
The standard open-source forum software for long-form developer community discussion.
Discourse is listed under Community platforms.
### GitHub Discussions (https://devrel.directory/directory/github-discussions)
Threaded forums attached to your repos; the lowest-friction community home for open-source projects.
GitHub Discussions is listed under Community platforms, tagged open-source.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
---
# Docusaurus vs Material for MkDocs (https://devrel.directory/directory/compare/docusaurus-vs-material-for-mkdocs)
Docusaurus and Material for MkDocs are both listed under Docs & dev portals in this directory. On the criteria this directory records they differ on stars, documentation, pricing model. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | Docusaurus | Material for MkDocs |
| --- | --- | --- |
| Category | Tools | Tools |
| Type | Docs & dev portals | Docs & dev portals |
| Focus | docs, open-source | docs, open-source |
| Public source repo | Yes | Yes |
| Last commit | Jul 2026 | Jul 2026 |
| Stars | 65k | 27k |
| Documentation | Yes | Not stated |
| Pricing model | Free (checked Jul 26, 2026) | Not stated |
| Link verified | Jul 15, 2026 | Jul 15, 2026 |
| Listed since | Jul 8, 2026 | Jul 12, 2026 |
## What each one is
### Docusaurus (https://devrel.directory/directory/docusaurus)
Open-source docs framework from Meta, the workhorse of OSS documentation sites.
Docusaurus is listed under Docs & dev portals, tagged open-source.
### Material for MkDocs (https://devrel.directory/directory/material-for-mkdocs)
The most widely deployed open-source docs theme; Markdown in, a polished documentation site out.
Material for MkDocs is listed under Docs & dev portals, tagged open-source.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
---
# Docusaurus vs Mintlify (https://devrel.directory/directory/compare/docusaurus-vs-mintlify)
Docusaurus and Mintlify are both listed under Docs & dev portals in this directory. On the criteria this directory records they differ on focus, public source repo, last commit, stars, mcp endpoint, llms.txt, pricing model. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | Docusaurus | Mintlify |
| --- | --- | --- |
| Category | Tools | Tools |
| Type | Docs & dev portals | Docs & dev portals |
| Focus | docs, open-source | docs |
| Public source repo | Yes | Not stated |
| Last commit | Jul 2026 | Not stated |
| Stars | 65k | Not stated |
| Documentation | Yes | Yes |
| MCP endpoint | Not stated | Yes |
| llms.txt | Not stated | Yes |
| Pricing model | Free (checked Jul 26, 2026) | Freemium (checked Jul 26, 2026) |
| Link verified | Jul 15, 2026 | Jul 15, 2026 |
| Listed since | Jul 8, 2026 | Jul 8, 2026 |
## What each one is
### Docusaurus (https://devrel.directory/directory/docusaurus)
Open-source docs framework from Meta, the workhorse of OSS documentation sites.
Docusaurus is listed under Docs & dev portals, tagged open-source.
### Mintlify (https://devrel.directory/directory/mintlify)
Documentation platform with built-in analytics and AI features; now positioning toward agents and self-updating documentation.
Mintlify is listed under Docs & dev portals.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
---
# Docusaurus vs Read the Docs (https://devrel.directory/directory/compare/docusaurus-vs-read-the-docs)
Docusaurus and Read the Docs are both listed under Docs & dev portals in this directory. On the criteria this directory records they differ on stars, llms.txt, pricing model. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | Docusaurus | Read the Docs |
| --- | --- | --- |
| Category | Tools | Tools |
| Type | Docs & dev portals | Docs & dev portals |
| Focus | docs, open-source | docs, open-source |
| Public source repo | Yes | Yes |
| Last commit | Jul 2026 | Jul 2026 |
| Stars | 65k | 8.3k |
| Documentation | Yes | Yes |
| llms.txt | Not stated | Yes |
| Pricing model | Free (checked Jul 26, 2026) | Not stated |
| Link verified | Jul 15, 2026 | Jul 15, 2026 |
| Listed since | Jul 8, 2026 | Jul 12, 2026 |
## What each one is
### Docusaurus (https://devrel.directory/directory/docusaurus)
Open-source docs framework from Meta, the workhorse of OSS documentation sites.
Docusaurus is listed under Docs & dev portals, tagged open-source.
### Read the Docs (https://devrel.directory/directory/read-the-docs)
Automated building, versioning, and hosting of docs from Git; the long-standing home of open-source documentation.
Read the Docs is listed under Docs & dev portals, tagged open-source.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
---
# Docusaurus vs Starlight (https://devrel.directory/directory/compare/docusaurus-vs-starlight)
Docusaurus and Starlight are both listed under Docs & dev portals in this directory. On the criteria this directory records they differ on stars, documentation. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | Docusaurus | Starlight |
| --- | --- | --- |
| Category | Tools | Tools |
| Type | Docs & dev portals | Docs & dev portals |
| Focus | docs, open-source | docs, open-source |
| Public source repo | Yes | Yes |
| Last commit | Jul 2026 | Jul 2026 |
| Stars | 65k | 8.9k |
| Documentation | Yes | Not stated |
| Pricing model | Free (checked Jul 26, 2026) | Free (checked Jul 26, 2026) |
| Link verified | Jul 15, 2026 | Jul 15, 2026 |
| Listed since | Jul 8, 2026 | Jul 12, 2026 |
## What each one is
### Docusaurus (https://devrel.directory/directory/docusaurus)
Open-source docs framework from Meta, the workhorse of OSS documentation sites.
Docusaurus is listed under Docs & dev portals, tagged open-source.
### Starlight (https://devrel.directory/directory/starlight)
Astro's documentation framework with search, i18n, and theming out of the box; a fast-growing Docusaurus alternative.
Starlight is listed under Docs & dev portals, tagged open-source.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
---
# F5Bot vs Octolens (https://devrel.directory/directory/compare/f5bot-vs-octolens)
F5Bot and Octolens are both listed under Analytics & listening in this directory. On the criteria this directory records they differ on focus, llms.txt, pricing model. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | F5Bot | Octolens |
| --- | --- | --- |
| Category | Tools | Tools |
| Type | Analytics & listening | Analytics & listening |
| Focus | social-listening | social-listening, analytics |
| llms.txt | Not stated | Yes |
| Pricing model | Freemium (checked Jul 26, 2026) | Paid (checked Jul 26, 2026) |
| Link verified | Jul 15, 2026 | Jul 15, 2026 |
| Listed since | Jul 12, 2026 | Jul 12, 2026 |
## What each one is
### F5Bot (https://devrel.directory/directory/f5bot)
Free email alerts when your product is mentioned on Reddit, Hacker News, or Lobsters; the zero-budget listening option.
F5Bot is listed under Analytics & listening.
### Octolens (https://devrel.directory/directory/octolens)
Social listening tool tracking mentions across Reddit, X, LinkedIn, and other platforms; evolving to serve the agent era with API and MCP integrations.
Octolens is listed under Analytics & listening.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
---
# Fern vs Stainless (https://devrel.directory/directory/compare/fern-vs-stainless)
Fern and Stainless are both listed under API & SDK tooling in this directory. On the criteria this directory records they differ on focus, public source repo, last commit, stars, pricing model. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | Fern | Stainless |
| --- | --- | --- |
| Category | Tools | Tools |
| Type | API & SDK tooling | API & SDK tooling |
| Focus | api, sdk, docs | api, sdk |
| Public source repo | Yes | Not stated |
| Last commit | Jul 2026 | Not stated |
| Stars | 3.7k | Not stated |
| Documentation | Yes | Yes |
| llms.txt | Yes | Yes |
| Pricing model | Open core (checked Jul 26, 2026) | Freemium (checked Jul 26, 2026) |
| Link verified | Jul 15, 2026 | Jul 15, 2026 |
| Listed since | Jul 12, 2026 | Jul 12, 2026 |
## What each one is
### Fern (https://devrel.directory/directory/fern)
Generates SDKs and a docs site from an OpenAPI spec, so a small team can ship a full developer portal.
Fern is listed under API & SDK tooling, tagged docs.
### Stainless (https://devrel.directory/directory/stainless)
SDK generator and API tooling platform used by OpenAI, Anthropic, and Cloudflare; now also generates MCP servers and API documentation.
Stainless is listed under API & SDK tooling.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
---
# GitBook vs Mintlify (https://devrel.directory/directory/compare/gitbook-vs-mintlify)
GitBook and Mintlify are both listed under Docs & dev portals in this directory. On the criteria this directory records they differ on mcp endpoint. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | GitBook | Mintlify |
| --- | --- | --- |
| Category | Tools | Tools |
| Type | Docs & dev portals | Docs & dev portals |
| Focus | docs | docs |
| Documentation | Yes | Yes |
| MCP endpoint | Not stated | Yes |
| llms.txt | Yes | Yes |
| Pricing model | Freemium (checked Jul 26, 2026) | Freemium (checked Jul 26, 2026) |
| Link verified | Jul 15, 2026 | Jul 15, 2026 |
| Listed since | Jul 12, 2026 | Jul 8, 2026 |
## What each one is
### GitBook (https://devrel.directory/directory/gitbook)
Documentation platform with Git sync for product and developer docs, now emphasizing AI-powered knowledge management and question answering.
GitBook is listed under Docs & dev portals.
### Mintlify (https://devrel.directory/directory/mintlify)
Documentation platform with built-in analytics and AI features; now positioning toward agents and self-updating documentation.
Mintlify is listed under Docs & dev portals.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
---
# Material for MkDocs vs Starlight (https://devrel.directory/directory/compare/material-for-mkdocs-vs-starlight)
Material for MkDocs and Starlight are both listed under Docs & dev portals in this directory. On the criteria this directory records they differ on stars, pricing model. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | Material for MkDocs | Starlight |
| --- | --- | --- |
| Category | Tools | Tools |
| Type | Docs & dev portals | Docs & dev portals |
| Focus | docs, open-source | docs, open-source |
| Public source repo | Yes | Yes |
| Last commit | Jul 2026 | Jul 2026 |
| Stars | 27k | 8.9k |
| Pricing model | Not stated | Free (checked Jul 26, 2026) |
| Link verified | Jul 15, 2026 | Jul 15, 2026 |
| Listed since | Jul 12, 2026 | Jul 12, 2026 |
## What each one is
### Material for MkDocs (https://devrel.directory/directory/material-for-mkdocs)
The most widely deployed open-source docs theme; Markdown in, a polished documentation site out.
Material for MkDocs is listed under Docs & dev portals, tagged open-source.
### Starlight (https://devrel.directory/directory/starlight)
Astro's documentation framework with search, i18n, and theming out of the box; a fast-growing Docusaurus alternative.
Starlight is listed under Docs & dev portals, tagged open-source.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
---
# Mintlify vs ReadMe (https://devrel.directory/directory/compare/mintlify-vs-readme)
Mintlify is listed under Docs & dev portals and ReadMe under API & SDK tooling. On the criteria this directory records they differ on type, focus, mcp endpoint. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | Mintlify | ReadMe |
| --- | --- | --- |
| Category | Tools | Tools |
| Type | Docs & dev portals | API & SDK tooling |
| Focus | docs | docs, api |
| Documentation | Yes | Yes |
| MCP endpoint | Yes | Not stated |
| llms.txt | Yes | Yes |
| Pricing model | Freemium (checked Jul 26, 2026) | Freemium (checked Jul 26, 2026) |
| Link verified | Jul 15, 2026 | Jul 15, 2026 |
| Listed since | Jul 8, 2026 | Jul 8, 2026 |
## What each one is
### Mintlify (https://devrel.directory/directory/mintlify)
Documentation platform with built-in analytics and AI features; now positioning toward agents and self-updating documentation.
Mintlify is listed under Docs & dev portals.
### ReadMe (https://devrel.directory/directory/readme)
Interactive API documentation hubs with real-time API logs and guides.
ReadMe is listed under API & SDK tooling, tagged docs.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
---
# OSS Insight vs star-history (https://devrel.directory/directory/compare/oss-insight-vs-star-history)
OSS Insight and star-history are both listed under Analytics & listening in this directory. On the criteria this directory records they differ on stars, documentation, llms.txt, pricing model. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | OSS Insight | star-history |
| --- | --- | --- |
| Category | Tools | Tools |
| Type | Analytics & listening | Analytics & listening |
| Focus | analytics, open-source | analytics, open-source |
| Public source repo | Yes | Yes |
| Last commit | Jul 2026 | Jul 2026 |
| Stars | 2.4k | 9.3k |
| Documentation | Yes | Not stated |
| llms.txt | Yes | Not stated |
| Pricing model | Free (checked Jul 26, 2026) | Not stated |
| Link verified | Jul 15, 2026 | Jul 15, 2026 |
| Listed since | Jul 12, 2026 | Jul 12, 2026 |
## What each one is
### OSS Insight (https://devrel.directory/directory/oss-insight)
Analytics over public GitHub events for open-source trends; now emphasizing AI agent frameworks, LLM tools, and MCP servers alongside general repo benchmarking.
OSS Insight is listed under Analytics & listening, tagged open-source.
### star-history (https://devrel.directory/directory/star-history)
Charts GitHub star growth over time; the graph in every devtool launch post and pitch deck.
star-history is listed under Analytics & listening, tagged open-source.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
---
# Plausible vs PostHog (https://devrel.directory/directory/compare/plausible-vs-posthog)
Plausible and PostHog are both listed under Analytics & listening in this directory. On the criteria this directory records they differ on stars, mcp endpoint, llms.txt. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | Plausible | PostHog |
| --- | --- | --- |
| Category | Tools | Tools |
| Type | Analytics & listening | Analytics & listening |
| Focus | analytics, open-source | analytics, open-source |
| Public source repo | Yes | Yes |
| Last commit | Jul 2026 | Jul 2026 |
| Stars | 28k | 37k |
| Documentation | Yes | Yes |
| MCP endpoint | Not stated | Yes |
| llms.txt | Not stated | Yes |
| Pricing model | Open core (checked Jul 26, 2026) | Open core (checked Jul 26, 2026) |
| Link verified | Jul 15, 2026 | Jul 15, 2026 |
| Listed since | Jul 12, 2026 | Jul 12, 2026 |
## What each one is
### Plausible (https://devrel.directory/directory/plausible)
Lightweight, privacy-first web analytics for docs and blogs; no cookie banner needed for developer audiences.
Plausible is listed under Analytics & listening, tagged open-source.
### PostHog (https://devrel.directory/directory/posthog)
Open-source product analytics platform with AI-powered features for automated debugging and code generation.
PostHog is listed under Analytics & listening, tagged open-source.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
---
# pretalx vs Sessionize (https://devrel.directory/directory/compare/pretalx-vs-sessionize)
pretalx and Sessionize are both listed under Events & speaking in this directory. On the criteria this directory records they differ on focus, public source repo, last commit, stars, documentation, pricing model. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | pretalx | Sessionize |
| --- | --- | --- |
| Category | Tools | Tools |
| Type | Events & speaking | Events & speaking |
| Focus | events, cfps, open-source | speaking, events |
| Public source repo | Yes | Not stated |
| Last commit | Jul 2026 | Not stated |
| Stars | 900+ | Not stated |
| Documentation | Yes | Not stated |
| Pricing model | Open core (checked Jul 26, 2026) | Freemium (checked Jul 26, 2026) |
| Link verified | Jul 15, 2026 | Jul 15, 2026 |
| Listed since | Jul 12, 2026 | Jul 8, 2026 |
## What each one is
### pretalx (https://devrel.directory/directory/pretalx)
Open-source call-for-papers and conference scheduling, trusted by FOSDEM-scale community events.
pretalx is listed under Events & speaking, tagged open-source.
### Sessionize (https://devrel.directory/directory/sessionize)
Call-for-papers and speaker management for conferences and meetups.
Sessionize is listed under Events & speaking.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
---
# ReadMe vs Redocly (https://devrel.directory/directory/compare/readme-vs-redocly)
ReadMe and Redocly are both listed under API & SDK tooling in this directory. On the criteria this directory records they differ on public source repo, last commit, stars, pricing model. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | ReadMe | Redocly |
| --- | --- | --- |
| Category | Tools | Tools |
| Type | API & SDK tooling | API & SDK tooling |
| Focus | docs, api | docs, api |
| Public source repo | Not stated | Yes |
| Last commit | Not stated | Jul 2026 |
| Stars | Not stated | 25k |
| Documentation | Yes | Yes |
| llms.txt | Yes | Yes |
| Pricing model | Freemium (checked Jul 26, 2026) | Open core (checked Jul 26, 2026) |
| Link verified | Jul 15, 2026 | Jul 15, 2026 |
| Listed since | Jul 8, 2026 | Jul 12, 2026 |
## What each one is
### ReadMe (https://devrel.directory/directory/readme)
Interactive API documentation hubs with real-time API logs and guides.
ReadMe is listed under API & SDK tooling, tagged docs.
### Redocly (https://devrel.directory/directory/redocly)
Maker of Redoc, the long-standing OpenAPI reference renderer, plus a full API docs platform.
Redocly is listed under API & SDK tooling, tagged docs.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
---
# Redocly vs Scalar (https://devrel.directory/directory/compare/redocly-vs-scalar)
Redocly and Scalar are both listed under API & SDK tooling in this directory. On the criteria this directory records they differ on focus, stars, llms.txt. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | Redocly | Scalar |
| --- | --- | --- |
| Category | Tools | Tools |
| Type | API & SDK tooling | API & SDK tooling |
| Focus | docs, api | docs, api, open-source |
| Public source repo | Yes | Yes |
| Last commit | Jul 2026 | Jul 2026 |
| Stars | 25k | 15k |
| Documentation | Yes | Yes |
| llms.txt | Yes | Not stated |
| Pricing model | Open core (checked Jul 26, 2026) | Open core (checked Jul 26, 2026) |
| Link verified | Jul 15, 2026 | Jul 15, 2026 |
| Listed since | Jul 12, 2026 | Jul 12, 2026 |
## What each one is
### Redocly (https://devrel.directory/directory/redocly)
Maker of Redoc, the long-standing OpenAPI reference renderer, plus a full API docs platform.
Redocly is listed under API & SDK tooling, tagged docs.
### Scalar (https://devrel.directory/directory/scalar)
Open-source API reference and request client that renders OpenAPI specs into interactive docs, with SDKs and API registry.
Scalar is listed under API & SDK tooling, tagged docs, open-source.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
---
# Slack vs Zulip (https://devrel.directory/directory/compare/slack-vs-zulip)
Slack and Zulip are both listed under Community platforms in this directory. On the criteria this directory records they differ on focus, public source repo, last commit, stars, llms.txt, pricing model. The table below compares them on identical criteria, drawn from what each product publishes.
## Side by side
| Criterion | Slack | Zulip |
| --- | --- | --- |
| Category | Tools | Tools |
| Type | Community platforms | Community platforms |
| Focus | community, chat | community, chat, open-source |
| Public source repo | Not stated | Yes |
| Last commit | Not stated | Jul 2026 |
| Stars | Not stated | 25k |
| Documentation | Yes | Yes |
| llms.txt | Yes | Not stated |
| Pricing model | Freemium (checked Jul 26, 2026) | Open core (checked Jul 26, 2026) |
| Link verified | Jul 15, 2026 | Jul 15, 2026 |
| Listed since | Jul 12, 2026 | Jul 12, 2026 |
## What each one is
### Slack (https://devrel.directory/directory/slack)
Team chat platform where developer and customer communities collaborate and automate workflows.
Slack is listed under Community platforms.
### Zulip (https://devrel.directory/directory/zulip)
Open-source threaded team chat; the community home of Rust and other projects that outgrew unthreaded chat.
Zulip is listed under Community platforms, tagged open-source.
## How to read this
Every fact on this page is copied from the product's own site or repository and dated. We do not test these tools hands-on, and the criteria are structural (what a product publishes) rather than qualitative (how well it works). Pricing is read off each product's own pricing page and carries the date it was read, so check the current page before budgeting. Where a product does not state something, the table says so instead of guessing.
## Jobs
- [Startup Community Manager](https://careers.nebius.com/?gh_jid=4757012101) at Nebius - Paris, France (posted 2026-07-26)
- [Senior Developer Advocate, Neon](https://databricks.com/company/careers/open-positions/job?gh_jid=8428818002) at Databricks - San Francisco, CA - $149k-205k (posted 2026-07-24)
- [Staff Developer Advocate, Asia Pacific & Japan Lead](https://careers.datadoghq.com/detail/8081537/?gh_jid=8081537) at Datadog - Singapore, Singapore (posted 2026-07-24)
- [Senior Developer Advocate, Developer Education](https://job-boards.greenhouse.io/temporaltechnologies/jobs/5193357007) at Temporal - Remote (US) - $150k-180k (posted 2026-07-24)
- [DevRel Engineer, Agentic Infrastructure](https://job-boards.greenhouse.io/vercel/jobs/6122437004) at Vercel - Hybrid (San Francisco) - $168k-252k (posted 2026-07-24)
- [Developer Relations Evangelist](https://job-boards.greenhouse.io/assemblyai/jobs/4703690005) at AssemblyAI - San Francisco, CA - $130k-190k (posted 2026-07-21)
- [Senior Technical Writer](https://jobs.ashbyhq.com/camunda/9ce12e95-88cd-4da4-8f61-f9cb198b1cc8) at Camunda - Remote (posted 2026-07-21)
- [Staff Developer Experience Engineer](https://jobs.ashbyhq.com/deepgram/c0a4b3fb-2c15-4b03-86f9-688eec8a8187) at Deepgram - Remote (US) - $219k-277k (posted 2026-07-21)
- [Technical Writer](https://jobs.ashbyhq.com/firecrawl/27a38804-9e98-49bb-8a43-b8dddea1ae15) at Firecrawl - Hybrid (San Francisco, CA) - $140k-185k (posted 2026-07-21)
- [Staff Developer Advocate, Community & Events](https://jobs.ashbyhq.com/livekit/8ce9b064-e20b-4c71-8c53-385ea89299ae) at LiveKit - Hybrid (San Francisco, CA) - $210k-284k (posted 2026-07-21)
- [Developer Advocate, Token Factory](https://careers.nebius.com/?gh_jid=4845016101) at Nebius - Remote (US) - $150k-188k (posted 2026-07-21)
- [Developer Community Manager](https://careers.nebius.com/?gh_jid=4907624101) at Nebius - Remote (US) - $121k-151k (posted 2026-07-21)
- [Technical Writer](https://careers.nebius.com/?gh_jid=4862408101) at Nebius - Remote (EMEA) (posted 2026-07-21)
- [Senior Developer Advocate](https://boards.greenhouse.io/neo4j/jobs/4689451006?gh_jid=4689451006) at Neo4j - Remote (US) - $190k-260k (posted 2026-07-21)
- [Developer Advocate](https://jobs.ashbyhq.com/notion/0cc39c60-4c89-4213-954e-d77ced4cb7e7) at Notion - New York, NY (posted 2026-07-21)
- [Developer Experience Engineer](https://jobs.ashbyhq.com/openai/bc40de6b-6dbc-49ce-9fc4-d9728baa1ec6) at OpenAI - San Francisco, CA - $198k-335k (posted 2026-07-21)
- [Technical Community Lead, Campus Leaders](https://jobs.ashbyhq.com/openai/eb58b9cb-4a87-4d58-863b-5516ed1fbcae) at OpenAI - San Francisco, CA - $162k-240k (posted 2026-07-21)
- [Technical Community Manager](https://jobs.ashbyhq.com/posthog/c539d9f2-ea48-47f1-a45b-414b49fe5c15) at PostHog - Remote (posted 2026-07-21)
- [Head of Developer Experience](https://jobs.ashbyhq.com/sentry/fb3d5644-6172-43ca-9941-91c025ab16c9) at Sentry - San Francisco, CA - $220k-300k (posted 2026-07-21)
- [Senior Developer Experience Engineer](https://jobs.ashbyhq.com/sentry/7ed2b263-3873-44c6-a730-2ca96100c58f) at Sentry - San Francisco, CA - $150k-190k (posted 2026-07-21)
- [Event Programs Manager, Developer Community & Ecosystem](https://jobs.ashbyhq.com/supabase/715ba1ea-bd0b-4960-9d5a-defca99f2e24) at Supabase - Remote (posted 2026-07-21)
- [Software Engineer II, AI Developer Experience](https://job-boards.greenhouse.io/temporaltechnologies/jobs/5183565007) at Temporal - Remote (US) - $160k-200k (posted 2026-07-14)
- [Enterprise Community Lead](https://job-boards.greenhouse.io/anthropic/jobs/5231468008) at Anthropic - San Francisco, CA - $320k (posted 2026-07-12)
- [Developer Relations](https://jobs.ashbyhq.com/linear/1d652292-04d9-405c-8101-578efd020e94) at Linear - Remote (US) (posted 2026-07-12)
- [Community Manager](https://jobs.ashbyhq.com/modal/fa7c9c0a-c8de-4c99-8e10-c52242f44e38) at Modal - San Francisco, CA - $120k-160k (posted 2026-07-12)
- [Developer Relations Engineer, Sandboxes](https://jobs.ashbyhq.com/modal/5113f35e-988d-41bc-a899-3261a9454e40) at Modal - New York, NY - $130k-250k (posted 2026-07-12)
- [Senior Developer Advocate](https://www.okta.com/company/careers/opportunity/7379845?gh_jid=7379845) at Okta - San Francisco, CA - $165k-220k (posted 2026-07-12)
- [Senior Developer Advocate](https://job-boards.greenhouse.io/postman/jobs/7651740003) at Postman - San Francisco, CA - $210k-230k (posted 2026-07-12)
- [Technical Community Manager](https://job-boards.greenhouse.io/postman/jobs/7761536003) at Postman - San Francisco, CA - $175k-195k (posted 2026-07-12)
- [Principal Developer Advocate, AI](https://job-boards.greenhouse.io/temporaltechnologies/jobs/4947867007) at Temporal - San Francisco, CA - $260k-325k (posted 2026-07-12)
- [Senior Manager, Enterprise Developer Advocacy](https://job-boards.greenhouse.io/temporaltechnologies/jobs/5184806007) at Temporal - Remote (US) - $240k-295k (posted 2026-07-12)
- [Developer Experience Director, APAC](https://jobs.lever.co/xsolla/c3513ba1-5642-4b16-9975-8ab813fe8f83) at Xsolla - Seoul, South Korea (posted 2026-07-12)
- [Senior Developer Advocate, Modern App Development](https://careers.datadoghq.com/detail/7985840/?gh_jid=7985840) at Datadog - Remote (US) - $128k-187k (posted 2026-07-10)
- [Developer Relations Engineer](https://jobs.ashbyhq.com/supabase/a1320bbf-bfae-49a8-a1b7-12eeccaf39ca) at Supabase - San Francisco, CA (posted 2026-07-10)
- [Staff Developer Advocate, Enterprise](https://job-boards.greenhouse.io/temporaltechnologies/jobs/5137122007) at Temporal - Remote (US) - $190k-240k (posted 2026-07-10)
- [Head of Developer Community](https://job-boards.greenhouse.io/vercel/jobs/5832366004) at Vercel - Hybrid (SF, NYC, Austin) - $200k-300k (posted 2026-07-10)
## Events & CFPs
- [API World](https://apiworld.co/) - Santa Clara, CA - 2026-09-01 to 2026-09-03
- [DevOpsDays Graz](https://www.devopsdays.at) - Graz, Austria - 2026-09-04 to 2026-09-05 - CFP deadline 2026-04-30: https://pretalx.com/devopsdays-graz-2026/cfp
- [Write the Docs Berlin](https://www.writethedocs.org/conf/berlin/2026/) - Berlin, Germany - 2026-09-06 to 2026-09-08 - CFP: https://www.writethedocs.org/conf/berlin/2026/cfp/
- [API Conference NYC](https://apiconference.net/new-york) - Online - 2026-09-28 to 2026-10-02
- [DevOpsCon New York](https://devopscon.io/new-york) - Online - 2026-09-28 to 2026-10-02
- [DevOpsDays Berlin](https://devopsdays.org/events/2026-berlin/welcome) - Berlin, Germany - 2026-09-29 to 2026-09-30
- [KCD Sofia 2026](https://kcd.bg) - Sofia, Bulgaria - 2026-09-29 - CFP deadline 2026-07-18: https://sessionize.com/kcd-sofia-2026
- [Apidays London](https://www.apidays.global/events/london) - London, United Kingdom - 2026-09-30 to 2026-10-01 - CFP deadline 2026-09-29: https://apidays.typeform.com/to/ILJeAaV8
- [TechSummit Amsterdam](https://techsummit.io) - Amsterdam, Netherlands - 2026-09-30 - CFP deadline 2026-05-15: https://pretalx.com/techsummit-2026/cfp
- [Open Tech Day: Software-defined Storage](https://opentechday.de) - Nürnberg, Germany - 2026-10-01
- [Kubernetes Community Days Argentina](https://ocgroups.dev/cncf/group/6vnv695) - Buenos Aires, Argentina - 2026-10-02 - CFP deadline 2026-08-02: https://sessionize.com/kubernetes-community-days-argentina-2026
- [Devoxx Belgium](https://devoxx.be/) - Antwerp, Belgium - 2026-10-05 to 2026-10-09
- [Open Source Summit Europe](https://events.linuxfoundation.org/open-source-summit-europe/) - Prague, Czechia - 2026-10-07 to 2026-10-09
- [The Nordic APIs UnConference](https://nordicapis.com/events/napis-unconference-2026) - Stockholm, Sweden - 2026-10-12
- [Platform Summit](https://nordicapis.com/events/platform-summit-2026) - Stockholm, Sweden - 2026-10-13 to 2026-10-14
- [Joomla! World Conference](https://conference.joomla.org) - Online - 2026-10-16 to 2026-10-18
- [All Things Open](https://2026.allthingsopen.org/) - Raleigh, NC - 2026-10-19 to 2026-10-20
- [swampUP Europe](https://swampup.jfrog.com/europe) - Barcelona, Spain - 2026-10-20 to 2026-10-22 - CFP deadline 2026-05-18: https://sessionize.com/swampup-europe-2026
- [Umbracokalaset](https://www.umbracokalaset.se) - Stockholm, Sweden - 2026-10-20 - CFP deadline 2026-08-16: https://sessionize.com/umbracokalaset-2026
- [Bergen Open Source](https://boskonf.no) - Bergen, Norway - 2026-10-23 - CFP deadline 2026-08-16: https://sessionize.com/boskonf26
- [Community Day for Java](https://www.gujaratjug.org) - Ahmedabad, India - 2026-10-23 - CFP deadline 2026-08-31: https://sessionize.com/community-day-for-java-2026
- [Open Source Observability Day](https://osoday.com) - Online - 2026-10-23 - CFP deadline 2026-08-31: https://osoday.com/call-for-papers
- [DevOpsDays Floripa](https://devopsdays.org/events/2025-florianopolis/welcome) - Florianópolis, Brazil - 2026-10-24 - CFP deadline 2026-08-31: https://sessionize.com/devopsdays-floripa26
- [Kubernetes Community Days Indonesia 2026](https://kcd.cloudnative.id) - Bandung, Indonesia - 2026-10-24 - CFP deadline 2026-07-31: https://sessionize.com/kubernetes-community-days-indonesia-2026
- [Apidays Australia](https://www.apidays.global/events/australia) - Melbourne, Australia - 2026-10-28 to 2026-10-29 - CFP deadline 2026-10-27: https://apidays.typeform.com/to/ILJeAaV8
- [GitHub Universe](https://githubuniverse.com/) - San Francisco, CA - 2026-10-28 to 2026-10-29
- [Mozilla Festival](https://www.mozillafestival.org) - Barcelona, Spain - 2026-10-28 to 2026-10-30
- [Open Source Analytics Conference](https://osacon.io) - Online - 2026-11-02
- [KCD Budapest](https://kcdbudapest.hu) - Budapest, Hungary - 2026-11-03 - CFP deadline 2026-08-29: https://sessionize.com/kcd-budapest-2026
- [Open Source in Finance Forum New York 2026](https://events.linuxfoundation.org/open-source-finance-forum-new-york) - New York, NY, United States - 2026-11-04 to 2026-11-05 - CFP deadline 2026-07-27: https://sessionize.com/open-source-in-finance-forum-new-york-2026
- [Conf42 Platform Engineering](https://www.conf42.com/platform2026) - Online - 2026-11-05 - CFP deadline 2026-10-05: https://papercall.io/cfps/6478/submissions/new
- [PlatformCon Live Day São Paulo](https://saopaulo.platformcon.com) - São Paulo, Brazil - 2026-11-07 - CFP deadline 2026-09-16: https://sessionize.com/platformcon-live-sao-paulo
- [Maintainer Summit: KubeCon + CloudNativeCon North America 2026](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/features-add-ons/maintainer-summit) - Salt Lake City, UT, United States - 2026-11-08 - CFP deadline 2026-07-20: https://sessionize.com/maintainer-summit-na-2026
- [KubeCon + CloudNativeCon North America](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/) - Salt Lake City, UT - 2026-11-09 to 2026-11-12
- [API Conference Berlin](https://apiconference.net/berlin) - Online - 2026-11-16 to 2026-11-20
- [Open Source Monitoring conference](https://osmc.de) - Nürnberg, Germany - 2026-11-17 to 2026-11-19 - CFP deadline 2026-06-30: https://osmc.de/call-for-papers
- [ASF Community Over Code / ChurConf](https://au.churconf.com) - Sydney, Australia - 2026-11-18 to 2026-11-19 - CFP deadline 2026-07-31: https://communityovercode.org/sydney-2026/
- [KCD Porto x DevOps Days Portugal](https://community2.cncf.io/events/details/cncf-kcd-porto-presents-kcd-porto-2026-collab-with-devops-days-portugal) - Porto, Portugal - 2026-11-19 to 2026-11-20 - CFP deadline 2026-07-15: https://sessionize.com/kcd-porto-2026
- [APIConf](https://apiconf.io) - Online - 2026-11-30 to 2026-12-02
- [DevOpsCon Munich](https://devopscon.io/muenchen) - Online - 2026-11-30 to 2026-12-04
- [Apidays Paris](https://www.apidays.global/events/paris) - Paris, France - 2026-12-01 to 2026-12-03 - CFP deadline 2026-11-30: https://apidays.typeform.com/to/ILJeAaV8
- [Cloud Native AI Summit Europe](https://www.cloudnative.ai) - Paris, France - 2026-12-02 to 2026-12-03 - CFP deadline 2026-08-14: https://sessionize.com/cloud-native-summit-europe-2026
- [Open Source Summit Japan](https://events.linuxfoundation.org/open-source-summit-japan/) - Tokyo, Japan - 2026-12-07 to 2026-12-09 - CFP deadline 2026-08-24: https://events.linuxfoundation.org/open-source-summit-japan/program/cfp/
- [KCD Suisse Romande](https://cloud-native-romandy.ch/kcd2026) - Genève, Switzerland - 2026-12-09 to 2026-12-10 - CFP deadline 2026-08-15: https://sessionize.com/kcd-suisse-romande-2026
- [droidcon London](https://london.droidcon.com/) - London, UK - 2026-12-10 to 2026-12-11 - CFP deadline 2026-09-06: https://sessionize.com/droidcon-london-2026/
- [Incontro DevOps Italia](https://www.incontrodevops.it) - Bologna, Italy - 2027-03-08 to 2027-03-09 - CFP deadline 2026-12-13: https://sessionize.com/incontro-devops-italia-idi-2027
- [Great International Developer Summit (GIDS)](https://developersummit.com) - Bangalore, India - 2027-04-27 to 2027-04-30 - CFP deadline 2026-09-30: https://developersummit.com/cfp