Date: 2026-08-28 Status: research model / measurement specification
IDKMesh should not optimize only for stars, raw issue volume, or raw contributor count. The desired community is a self-sustaining network of retained contributors who produce independently verified useful work while reducing coordination burden per unit of progress.
This document turns community growth into a measurable dynamical-system problem.
Let the community state at time t be
x(t) = (V, F, A, R, S, L)
where:
V = visitors / observers;F = first-time contributors in activation/onboarding;A = active contributors;R = reviewers/maintainers/community stewards;S = AI/software agents participating with explicit provenance;L = lapsed contributors who may reactivate.Do not interpret these as permanent identities. People can move between states and can occupy multiple functional roles.
A useful discrete-time model is
x_(t+1) = M_t x_t + b_t - c_t
where M_t captures transition/retention/referral behavior, b_t external discovery, and c_t churn or blocked activation.
The matrix should be estimated from real repository events rather than selected for aesthetic reasons.
Define
R_c = E[number of new retained contributors causally generated by one retained contributor or contribution cycle].
This is a branching-process-inspired metric. It is not a claim that communities literally behave like biological epidemics.
A rough decomposition is
R_c ~= k_exposure * p_visit * p_activate * p_success * p_retain * p_refer
where each factor is measurable or estimable.
The important threshold idea is:
R_c > 1: contributor growth can be self-amplifying over some range;R_c ~= 1: roughly self-sustaining;R_c < 1: repeated external/manual recruitment is required to maintain size.This is only a local growth indicator. Resource limits, project maturity, review capacity, and finite audience eventually create saturation.
IDKMesh is multidisciplinary, so one scalar R_c is not enough.
Let contributor types be, for example:
software, AI, distributed-systems, math, physics, security, UX/art, governance, research, compute.
Define the next-generation matrix B where
B_ij = expected number of new retained type-j contributors eventually activated by one retained type-i contributor/cycle.
The dominant eigenvalue
rho(B)
is the multi-type reproduction indicator.
More interesting than raw rho(B) are the off-diagonal terms. A community where programmers recruit only programmers and physicists recruit only physicists can grow while remaining fragmented.
Therefore track:
CrossDisciplineFraction = sum_(i != j) B_ij / sum_(i,j) B_ij.
The project should experimentally create bridge WorkUnits that increase useful off-diagonal coupling.
Repository activity is event-based: an accepted PR can trigger discussion, follow-up issues, forks, experiments, and new contributors.
A Hawkes-like self-exciting intensity can be used as a descriptive model:
lambda(t) = mu(t) + sum_(t_k < t) alpha_k * exp(-beta * (t - t_k)).
Here:
mu(t) = baseline contribution-event intensity from GitHub discovery and existing awareness;k temporarily increases future event intensity;alpha_k can depend on event type and quality;beta controls how quickly attention decays.For an exponential kernel, a simplified branching/endogeneity ratio is related to integrated excitation. The project should estimate it rather than assuming viral growth.
Use this to compare which events create durable follow-on work:
The desired quantity is not “attention generated per event” but verified useful retained contribution generated per event.
Community growth can become harmful when generation outruns verification/review.
Let
lambda_w = arrival rate of proposed work;mu_v = sustainable verification/review service rate.A basic stability requirement is
lambda_w < mu_v
for the class of work that requires the same review capacity.
Little’s Law gives
L = lambda W
for average backlog L, throughput/arrival rate lambda, and average time in system W under suitable steady-state assumptions.
If contribution volume rises but W and backlog grow without bound, the community is not scaling successfully.
Define maintainer leverage:
ML = verified_useful_output / maintainer_hours.
A successful self-growing community should increase ML over time.
Early exponential-looking growth cannot continue indefinitely.
A simple phenomenological model is
dA/dt = r*A*(1 - A/K) - delta*A + Reactivation(t)
where:
A = active contributors;r = effective growth rate;K = effective carrying capacity under the current onboarding/review/product state;delta = churn.The useful interpretation is not that K is fixed. IDKMesh can raise its effective carrying capacity by:
Thus K = K(system architecture, maintainer capacity, task supply, tooling, project usefulness).
Construct a collaboration graph G_c = (V_c, E_c) where contributors/agents are connected when they meaningfully collaborate, review, co-create an artifact, or contribute to the same verified WorkUnit.
Track:
For graph Laplacian L_c = D - A, monitor
lambda_2(L_c).
Very low algebraic connectivity can indicate fragmentation or fragile bridges.
S = |largest connected useful component| / |active contributor nodes|.
High community modularity can be healthy specialization, but if cross-community edges are too sparse it becomes siloing.
The target is modular but connected: strong specialist cells plus deliberate bridge edges.
Estimate a task’s predicted cross-discipline graph benefit:
BridgeValue(T) = max(0, lambda_2(L_after_T) - lambda_2(L_before))
or use reduction in shortest-path distances between disciplinary communities.
This makes community architecture part of task prioritization.
Use an analogy to activation barriers in physics/chemistry.
Define newcomer activation cost approximately as
E_activation = setup_time + comprehension_cost + task_search_cost + uncertainty_cost + expected_review_delay + tooling_friction.
The probability of activation is not literally Boltzmann physics, but a logistic model can be empirically fitted:
P(first contribution) = sigmoid(a - b*E_activation + c*TaskClarity + d*FastFeedback).
The engineering target is to reduce measured activation cost while retaining real quality standards.
Useful metrics:
Let x_i be the active population of discipline/cell i.
A generalized interaction model is
dx_i/dt = x_i * (r_i - c_i*x_i + sum_(j != i) a_ij*x_j).
Interpretations:
a_ij > 0: discipline j increases productivity/retention of i (mutualism/complementarity);a_ij < 0: competition for scarce review/attention resources;c_i: within-cell saturation.This can test whether bridge workflows create real mutual benefit rather than merely mixed attendance.
Do not operationalize social policy from this equation alone. It is a falsifiable aggregate model, not a model of individual human worth.
Different onboarding/review/task-discovery mechanisms can compete experimentally.
Let x_i be the fraction of eligible project traffic using mechanism i and f_i its measured fitness.
dx_i/dt = x_i * (f_i - f_bar).
Candidate mechanisms:
Fitness must be multi-objective and safety-aware, for example:
f_i = verified_output + retention + newcomer_success + diversity_gain - review_cost - security_incidents - spam.
Never optimize a mechanism solely for clicks, stars, comments, or issue count.
Define target ranges rather than maximizing everything.
State variables can include:
x = [review_backlog, median_review_latency, starter_issue_supply, activation_rate, retention_rate, maintainer_load, cross_discipline_connectivity].
Controls can include:
u = [new_task_release_rate, task_size_threshold, verifier_capacity, onboarding_exposure, agent_generation_rate].
A feedback controller can implement rules such as:
A Lyapunov-inspired community stress function could be
V_c = a*review_backlog + b*review_latency + c*maintainer_overload + d*orphan_newcomers + e*unverified_volume + f*fragmentation.
A healthy controller should make V_c tend to decrease after disturbances while preserving useful progress.
Community contribution value should include information gain.
For project uncertainty Theta, current evidence D, and contribution result Y:
EIG = H(Theta | D) - E_Y[H(Theta | D,Y)].
This correctly gives value to:
A project that rewards code volume but not uncertainty reduction will accumulate complexity faster than knowledge.
Do not use one scalar permanently. Maintain a Pareto frontier over at least:
A temporary scalarized objective for experiments can be
J_community = w1*VerifiedOutput + w2*ML + w3*Retention + w4*EIG + w5*Connectivity - w6*ReviewLatency - w7*MaintainerLoad - w8*Risk.
All weights and definitions must be versioned.
R_c for accepted PRs, accepted research findings, reproducible experiments, and releases separately.The repository should aim to become supercritical in retained useful collaboration while remaining subcritical in unverified work, spam, risk, and maintainer overload.
That distinction is more important than maximizing raw growth.