Cooperative Contribution Reward System DRAFT

Overview

A funding and distribution mechanism designed for open collaborative repositories where developers are rewarded proportionally to meaningful contribution effort without introducing competitive dynamics.

Donations fund the project as a whole, and contributors receive payouts based on continuously measured contribution share rather than task ownership or bounties.

Core Principles

  1. Non‑rival rewards — one contributor earning more does not reduce another’s payout
  2. Continuous funding pool — donors fund progress, not tasks
  3. Effort‑proportional allocation — payouts reflect validated impact
  4. Collaboration‑friendly incentives — joint work increases total value
  5. Long‑term fairness — past work matters but gradually decays in influence
  6. Anti‑gaming design — prevents spam commits and artificial activity

High Level Model

At any moment:

reward_i = total_funds × contributor_weight_i / total_weight

Where contributor weight is a time‑decayed measure of validated contribution effort.

Contribution Units (CU)

Each contributor accumulates Contribution Units over time.

Contribution Units represent impact, not activity.

Time Decay

Older contributions slowly lose influence:

CU_i(t) = ∫ effort_i(τ) × e^{-λ(t-τ)} dτ

Effects:

  • recent contributors become fairly rewarded
  • early contributors are not permanently dominant
  • inactive contributors gradually phase out

Effort Measurement Signals

Contribution score for a change is derived from multiple validated signals:

1. Merged Code Impact

Measures accepted code that survives review.

2. Code Longevity

Lines still present after N days carry higher weight. Prevents churn or refactor spam.

3. Dependency Usage

If other modules depend on the code, weight increases. Captures architectural and foundational work.

4. Maintenance Contribution

Includes:

  • reviews
  • issue triage
  • refactors
  • documentation

Scoring Formula

For each merged change c:

score(c) = (impact × longevity) + review_credit + maintenance_credit

Contributor CU is the sum of all scored changes with decay applied:

CU_i = Σ score(c) × decay(time)

Funding Distribution

Funds are distributed in epochs (recommended: weekly).

During an epoch:

  1. Record average CU for each contributor
  2. Sum incoming donations
  3. Allocate proportionally
payout_i_epoch = epoch_funds × avg(CU_i) / Σ avg(CU)

This prevents timing attacks such as merging right before payout.

Anti‑Competition Design Rules

No Task Bounties

Donations are never attached to issues or pull requests.

No Rankings

Users see only their personal contribution trend, not leaderboards.

Positive‑Sum Collaboration

Multiple contributors on the same feature increase total project value and thus total payouts.

Donor Experience

Donors fund project velocity instead of individuals.

Example display:

€3000/month currently sustains approximately 3.8 full‑time contributors

No per‑developer public payouts are shown by default.

System Guarantees

  • Contributors cannot steal share from others
  • Long‑term contributors retain credit
  • Recent work becomes progressively more important
  • Spam contributions have negligible effect
  • Collaboration maximizes collective reward

Implementation Outline

Data Sources

  • Pull requests
  • Commits
  • Reviews
  • Issue activity
  • File dependency graph

Required Components

  • Contribution ledger (append‑only)
  • Decay computation engine
  • Epoch payout calculator
  • Donation pool manager

Expected Behavioral Outcome

The system encourages:

  • cooperative development
  • architectural improvements
  • long‑term maintenance
  • meaningful review participation

While discouraging:

  • commit spam
  • ownership conflicts
  • short‑term optimization behavior

CU Calculation Model

Contribution Units (CU) are computed from scored repository events. Each scored event produces points which decay over time.

CU_i(t)=Σ points(e) · e^{-λ(t-time(e))}

Recommended decay half-life: 90 days.

Merged Pull Request Impact (Author Credit)

Step 1 — Effective Change Size (ECS)

ECS = w_lang × (additions + deletions) × (1 - churn_ratio) × file_weights

Where churn_ratio discounts recently modified lines and file_weights reduce low‑signal files (generated, vendor, lockfiles).

Step 2 — Impact Points

P_merge = B_merge × log(1 + ECS) × Q

Quality multipliers (Q):

  • merged with review + green CI required
  • revert within 14 days reduces credit
  • immediate hotfix reduces credit

Longevity Bonus (Author Credit)

After 30–60 days:

P_longevity = B_lon × log(1 + surviving_lines)

Encourages maintainable code and discourages churn.

Review Credit (Reviewer Credit)

Granted only if the PR merges.

P_review = B_rev × review_depth × merge_importance

Review depth approximations:

  • requested changes > approval with comments > approval only

Merge importance is capped log(1+ECS) to prevent farming large PRs.

Maintenance & Non‑Code Contributions

Small gated rewards for throughput improvements:

  • closing issues via merged PR
  • bug reproduction
  • triage & categorization
  • merged documentation
P_maint = Σ B_k × outcome_k

Anti‑Gaming Protections

  • Concave scoring (logarithmic)
  • Churn discount
  • Revert penalties
  • Merge‑gated review rewards
  • Time decay dominance

Summary

The system computes time‑decayed impact points from validated repository activity, producing a cooperative revenue share where compensation tracks sustained project value rather than competitive output.