Question about early contributor discovery for ContribArena

[flyoung588]

Hi — Ray here, a founder working in an adjacent open-source/devtool space. This is a genuine question, not a pitch.

I was reading ContribArena’s README and noticed the design puts the maintainer outcome directly in the loop: real PRs, explicit bot identity, quality gates before external writes, then tracking whether maintainers merge, request changes, review, or close. That feels like the right hard part to measure — not just whether an agent can produce a patch, but whether the open-source process accepts it.

One thing I’m curious about from the maintainer side: for a project like ContribArena, especially while it’s still in “Phase 0 hardening,” are you already doing manual work to find early human contributors/reviewers, or is GitHub inbound enough at this stage?

A short reply is plenty.

[qWaitCrypto]

Hi @flyoung588 — sorry for the late reply, I only just noticed this issue.

Honestly, I’m still figuring this part out. ContribArena is still very early, and I don’t have a clear playbook yet for how to get exposure for this kind of project.

So far I haven’t done much direct outreach to potential contributors, maintainers, or reviewers. My current instinct is to first get a solid first version working, then use that to approach people with something concrete instead of just an idea.

That said, I recently started sharing some project introductions in a few relevant communities to see whether the idea resonates and what kind of feedback it attracts.

Would definitely appreciate any thoughts or suggestions you have on early contributor / reviewer discovery for this kind of open-source devtool project.

[flyoung588]

Hey — appreciate the honest answer, including the "I haven't done much direct outreach yet" part. That's been the dominant pattern across the ~80 maintainers I've talked to over the last week.

Two things that might be useful:

On finding early users/contributors: from a separate spec/protocol project of mine, the mechanism that works best is research-then-question — build a list of ~60 maintainers ALREADY working on adjacent problems, ask each ONE specific technical question about THEIR project (not a survey, not "try the product"), and when someone replies substantively, adopt what they said and offer them a Co-author or Reviewer role. Hit rate: ~30% engaged, ~8-10% committed. The hard part for ContribArena is the "offer back" — spec projects have spec inclusion, which is irreplaceable. For a tool like yours, you'd have to invent it: a named design-partner credit, roadmap-input seat, something irreversible.

The harder thing, because it cuts the other way: my broader research has been whether maintainers feel the recruiting pain acutely enough to seek tools for it. From ~80 conversations the answer trends toward no — most aren't ready to prioritize it; the few who actively recruit use free GitHub labels and personal networks. Telling you this because we're in similar territory — if ContribArena is a channel/discovery layer, the demand side may be weaker than the product side. Worth pressure-testing "would maintainers actually pay/use this once it works?" before going much further.

Not a pitch, not advice from someone who solved it. Just the honest pattern from the same week you're asking about.

[qWaitCrypto]

Hey — appreciate the honest answer, including the "I haven't done much direct outreach yet" part. That's been the dominant pattern across the ~80 maintainers I've talked to over the last week.

Two things that might be useful:

On finding early users/contributors: from a separate spec/protocol project of mine, the mechanism that works best is research-then-question — build a list of ~60 maintainers ALREADY working on adjacent problems, ask each ONE specific technical question about THEIR project (not a survey, not "try the product"), and when someone replies substantively, adopt what they said and offer them a Co-author or Reviewer role. Hit rate: ~30% engaged, ~8-10% committed. The hard part for ContribArena is the "offer back" — spec projects have spec inclusion, which is irreplaceable. For a tool like yours, you'd have to invent it: a named design-partner credit, roadmap-input seat, something irreversible.

The harder thing, because it cuts the other way: my broader research has been whether maintainers feel the recruiting pain acutely enough to seek tools for it. From ~80 conversations the answer trends toward no — most aren't ready to prioritize it; the few who actively recruit use free GitHub labels and personal networks. Telling you this because we're in similar territory — if ContribArena is a channel/discovery layer, the demand side may be weaker than the product side. Worth pressure-testing "would maintainers actually pay/use this once it works?" before going much further.

Not a pitch, not advice from someone who solved it. Just the honest pattern from the same week you're asking about.

Wow, thanks for sharing this — that’s a pretty interesting and unexpected angle.

Are you mainly researching early-stage project discovery / contributor onboarding, or is this part of a broader open-source tooling project you’re working on?

[flyoung588]

Quick update — verdict is in.

Both, to answer your structure question. There's first5 (the tool) and Wedgetest (the methodology I built to run it through). first5's wedge came back NO after 14 days. Full case study: https://gist.github.com/flyoung588/9edcb650db3f1699e8efd75a9786a8f2

Relevant for ContribArena: the demand-weakness I flagged in my last reply isn't a first5-specific finding — it shows up across the whole 83-maintainer pool. Three other people building the same shape product as you (IssueCompass / cluu / yours) all said the same thing: GTM isn't solved by anyone in this space, including the builders.

If pressure-testing ContribArena's wedge would be useful, that's what Wedgetest does — same 14-day cycle, same honest public verdict. Reply if you want to know more; no pitch otherwise.