A friend joined a developer relations team as its new leader and inherited the usual evidence pile: conference photos, registration counts, Discord growth, GitHub stars, sponsor recaps, and enough anecdotes to keep a quarterly review alive.

One question made the slide wobble.

Did anyone ship code afterward?

I have seen the pattern across the industry: fly somewhere photogenic, give a talk, collect business cards, post photos to LinkedIn about the room feeling busy, call the room a signal, and move on to the next city.

Call it developer tourism: being everywhere while producing little that can be connected to a developer’s next action. Clean slide, unclear consequence.

Conferences can work. Some do. The failure is not the event; it is leaving the event unable to say whether anyone built afterward.

Attendance photos cannot answer the budget

Developer Relations has a metrics problem, but not a shortage of numbers. GitHub stars, Discord members, UTM links, registrations, and badge scans are everywhere. Meaning is the scarce part.

According to the State of Developer Relations 2024, proving business impact jumped from 7th to 2nd place among DevRel challenges. A full 61% of practitioners struggle to prove their influence. Once that bill arrives, attendance photos are no longer accepted as payment.

Most collected metrics are what Mary Thengvall calls “easily gamed vanity metrics.” GitHub stars can be bought or botted. Discord membership says little about intent. Event attendance proves someone entered a room, not that they adopted a product.

None of these answer the second question.

Commits give the conversation a floor

While DevRel teams have been counting Discord reactions, data infrastructure has made a more serious question practical. Electric Capital has been tracking actual developer activity.

Their methodology is plain enough to trust. Analyze public GitHub commits. Map developers to ecosystems. Count who is building what, where. Their 2024 Developer Report analyzed 902 million code commits across 1.7 million repositories.

Electric Capital provides the missing floor. Not self-reported surveys. Not signup forms. Not aspirational Discord channels. Actual, verifiable evidence that a person wrote code and pushed it to GitHub.

Its units are ordinary enough to trust:

  • Monthly Active Developers (MADs): Anyone who committed code in a rolling 28-day window
  • Developer tenure: Time since first commit across ecosystems
  • Activity classification: Full-time (10+ days/month), part-time (regular but not daily), one-time contributors

A weak sentence says “we have an active community.” A stronger one says “we have 847 developers who committed code last month, 23% of whom have been building in crypto for over two years.”

Only one survives a board meeting.

Resolve attendees to builders

Start with the almost embarrassingly direct join. Did this person, after attending this event, write code?

Every event now produces a conversion funnel:

Total Participants → Resolved to GitHub → New Developers → Activated (7/14/28/60 days)

“Resolved to GitHub” is the key step. We take your messy CSV of hackathon registrants—with their inconsistent column names and email addresses that may or may not match anything—and match them to canonical developers in the Electric Capital database.

Resolution is deliberately fussy. We scan every column for GitHub URLs. We extract usernames from repository URLs that no longer exist. We match emails against developer profiles. We check repository contributor lists. Elegance can wait. The humbler fact has to come first: who actually showed up, and whether they stuck around.

Budgets get harder to bluff at activation rate. What percentage of new developers who attended your hackathon were still committing code 28 days later? 60 days?

Activation rate is where developer growth separates from developer tourism. Anyone can attract a crowd. Builders are harder to fake.

Signals that force decisions

Churn risk

Churn risk made the dashboard more personal. We built a scoring system that identifies developers about to go silent, which is uncomfortable because it turns “community health” into names.

Three inputs drive the score:

  • Last commit date (longer ago = higher risk)
  • Declining activity trends (falling off vs. steady)
  • Commit patterns (small, infrequent commits = disengaging)

Retention is cheaper than acquisition. A developer who has shipped 100 commits and is losing steam is worth an email, a DM, a “what are you working on?” That person already knows your platform. They have already climbed the learning curve. Letting them drift away is a failure of relationship, not marketing.

Cohort data flags these at-risk developers before they disappear. Write to the person with 100 commits who is slowing down before spending another dollar acquiring someone who has never built on the platform.

Retention cohorts

Thirty-, sixty-, and ninety-day retention cohorts answer the question most DevRel teams avoid until the budget meeting: Is our onboarding getting better?

Compare the September cohort’s 30-day retention to October’s. If October is higher, something you did (or fixed) worked. If it is lower, something broke. A/B testing for developer experience, except the test group is everyone.

Color coding is merciless. Green means at least 50% retention. Yellow means 30-49%. Red means the first-run experience deserves immediate attention, preferably before another event budget is approved.

Multichain activity

One split surprised me: exclusive versus multichain developers.

Exclusive developers only contribute to your ecosystem. Multichain developers hedge their bets across multiple blockchains.

Both have value, but they tell different stories. A high exclusive ratio suggests you’ve built something developers commit to (literally and figuratively). A high multichain ratio means you’re attracting experienced crypto developers who are keeping options open.

Neither is inherently superior. But if the goal is developer mindshare, the split changes the decision: deepen exclusive builders, or deliberately court experienced multichain developers who are still choosing.

Packages close the loop

In Web3, the full developer path is not commit to done. It is:

Developer → Code Commit → Package Deployment → On-chain Transactions → Actual Usage

Link 278,000+ Move packages to their GitHub repositories, then to their developers, then to their on-chain transaction counts, and the question changes from “which participants committed code?” to “which participants deployed packages that generated real usage?”

DevRel teams talk about the developer-to-revenue pipeline in theory and rarely measure it in practice. The loop closes only when a package, a developer, and usage can be read together.

A painterly editorial collage for DevRel measurement, showing scoreboard, field lines, and developer programme measures.
Scoreboard, field lines, and developer-programme measures.

The dashboard gets impolite

“Exclude Employees” is the first uncomfortable toggle.

Turn it on and some ecosystems lose more than half their apparent activity. The community story changes shape at once: not a movement, perhaps, but a company with a Discord server and a very committed engineering team. That is not shameful. It is a different operating fact, and it asks for different work.

Geography is not kinder. “Global community” sounds generous until the developer map shows where commits actually come from. Sometimes the next dollar should move away from San Francisco and toward developers in India, which has become the second-largest source of crypto developers globally. Sometimes the honest move is the opposite: admit the community is concentrated in three cities and stop pretending thin coverage is a strategy.

Working-hour heatmaps remove another romance. Most developers are not committing at 2 AM under blue monitor light. They write during business hours in developer-heavy time zones. Launches, announcements, support coverage, and office hours can now answer to the keyboard, not the myth.

Decisions the dashboard changed

Before the next hackathon, pull the baseline: monthly active developers, retention rate, new developer acquisition trend. After the event, measure the delta. Did active developers increase? Did retention improve? Did new developers stick around?

If the line does not move, the event did not work, regardless of how much affection the swag earned.

Participation funnels show where the break happened. Signups without activation point to onboarding. Activation without 28-day retention points to a platform cliff. Churn risk turns “community health” into a to-do list: write to the developer with 50 commits who is slowing down before sending a generic newsletter to 10,000 people who may never build anything.

Budget comparison becomes pleasantly unfair. Was the $50K hackathon more effective than the $5K meetup series? Count new developers acquired per event, activation rate per event, and cost per activated developer. The cheaper thing does not always win. The room with better retention does.

From room count to builder proof

DevRel is stabilizing: median compensation is $193K, job security is steady, and 78% of professionals now use AI in their workflows. Stable functions get stable-function questions. Where did the money go? Which decision did it improve? What do we repeat?

Electric Capital provided the data infrastructure. The dashboard turns it into a working instrument: event participants resolved to GitHub identities, cohorts tracked over time, packages linked back to repositories, employee activity separated from community activity.

Those comparisons changed the internal conversation. A conference no longer had to be defended because the room was full. I could compare the $50K hackathon with the $5K meetup series, show which developers kept committing 28 or 60 days later, and decide where the next dollar went.

I still believe in being present: handshakes, whiteboard sessions, and hallway conversations that produce sharper questions than the agenda did. But presence without measurement is just expensive travel.

When someone asks “What’s the ROI of that conference?”, the answer cannot depend on how full the room felt.

Rooms do not show up in the investor deck. Developer activation does.

How the numbers were built

Data comes from Electric Capital’s Developer Report, enriched with GitHub profile data, Sui blockchain package analytics, and custom retention modeling. The dashboard tracks three ecosystems (Sui, Walrus, Sui Name Service) with daily data updates.

Methodology:

  • MADs: 28-day rolling window of commit activity
  • Retention cohorts: Monthly cohort tracking with 30/60/90-day windows
  • Event attribution: Temporal matching (14 days before to 28 days after event)
  • Package linking: Hybrid MVR + Blockberry data with confidence scoring

For the technically curious, the full methodology is documented in the repository. For the strategically curious, the answer is simpler: the dashboard is built for the Sui ecosystem, but the method applies anywhere developers ship code.

Measure the thing you say changed.

Sources behind the numbers

Chris Chabot · December 2025
technical blog