devrel-competitor-analysis

Frame a peer set of three to five competitors with explicit roles, freeze an identical scorecard field list, then collect public signals surface by surface starting with a timed quickstart. The result is a scorecard plus a gap plan where every gap carries a close, ignore, or counter verdict.

Eight surfaces reveal it: timed quickstarts, documentation mode coverage, forge release and response metrics, Q&A tag activity, content cadence over twelve months, community responsiveness, hiring signals, and event presence. Collect in order of finding per analyst hour, starting with the quickstart.

All-time totals like stars, followers, and member counts should not be scorecard rows because a number that can only rise carries no trend information. Use period deltas or rates instead, such as median time to first response on issues or staff share of community replies.

No. Prefer documented APIs over automated page extraction, since GitHub's acceptable-use policy restricts information use to research and archival. Never conceal your identity in a competitor's community; findings obtained that way are unusable once anyone asks where they came from.

Re-run on event triggers rather than a fixed clock: a competitor launch, a lost evaluator, or a planning moment. As a working default, refresh docs, content, and releases quarterly and community, events, and hiring signals twice a year, keeping dated observations so each pass is a diff.

Private numbers like budget, team size, docs traffic, and paying-developer counts are not observable from outside; only labelled proxies such as sponsor tiers or named bylines are available. Cells with no defensible proxy should read "not observable" rather than an invented estimate.