Rewards help builders keep building. They are non-cash benefits supplied through confirmed partnerships or an explicitly funded cohort.
A project uses a success track appropriate to what it does:
| Track | Possible evidence |
|---|---|
| Attention | Organic GitHub stars, meaningful external interest, or coverage |
| Distribution | Release/package downloads, full clones, or container-image pulls within a defined window |
| Adoption | Daily or monthly active users (DAU/MAU), measured through an agreed meaningful product action |
| Sustained use | A relevant adoption measure maintained over time |
Usage evidence must state the event, unique-user definition, measurement window and source. A GitHub repository alone does not measure product users. Builder-approved, project-scoped aggregate reports from tools such as PostHog or an equivalent service may support review. Exclude bots, tests and artificial activity; DAU/MAU and download counts are not interchangeable and overlapping usage is not double-counted. Collect and share data only under appropriate user notices, consent where required and access controls. Metrics do not create automatic points or rewards.
Stars show interest. Downloads show distribution. Neither automatically equals active users. Repeated automated activity, purchased engagement, and self-generated inflation do not establish genuine traction. Exact exclusions will be published with each cohort.
Early milestone levels award more points per eligible new organic GitHub star, with a gradually lower rate as projects grow. Points unlock only at the reached milestones below after manual review, never at arbitrary intermediate counts. These are non-cash reward points, not model tokens or a transferable balance.
| Milestone level | Eligible stars | Total points unlocked | Additional points since previous milestone |
|---|---|---|---|
| 1 | 20 | 800 | 800 |
| 2 | 50 | 1700 | 900 |
| 3 | 100 | 3000 | 1300 |
| 4 | 250 | 6000 | 3000 |
| 5 | 500 | 10000 | 4000 |
| 6 | 1000 | 12500 | 2500 |
| 7 | 2500 | 17500 | 5000 |
| 8 | 5000 | 22500 | 5000 |
20 stars unlock 800 points. At 7 or 19 eligible stars no star award is claimable. At 30 only the 20-star milestone is unlocked. After 800 points have been credited, reaching 50 stars releases another 900 points, for 1700 total, not another full award. Skipping earlier claims does not lose eligible points; subtract everything already credited for that project and track. No further star levels are announced above 5000. Existing agreed rewards are not reduced or repriced automatically; changing an earlier schedule requires an explicit project agreement and reconciliation.
This schedule covers eligible new growth from the project's agreed baseline, not automatic conversion of a repository's displayed stars. Agree the metric, source, baseline, measurement start/window, evidence, funded maximum and offer terms before reward-bearing enrollment. Historical stars require a separate agreement; no historical discount is announced. Awards belong to the agreed project/team, not a duplicate award for each collaborator. Exclude bots, purchased engagement, self/team farming, repeated unstar/restar and double-counting across copied projects or counters. Previously credited points are never awarded twice. Valid past agreements and accepted application revisions are not changed retroactively.
Count eligible release/package downloads in a completed calendar month, not lifetime downloads. Agree the authoritative source, package/release scope, calendar timezone, baseline, exclusions and funded maximum before accrual. These are milestone awards, not a flat per-download conversion.
| Level | Monthly downloads | Total points unlocked | Additional points |
|---|---|---|---|
| 1 | 100 | 200 | 200 |
| 2 | 500 | 600 | 400 |
| 3 | 1000 | 1000 | 400 |
| 4 | 5000 | 3500 | 2500 |
| 5 | 10000 | 5500 | 2000 |
| 6 | 50000 | 10000 | 4500 |
| 7 | 100000 | 12500 | 2500 |
Raw registry downloads are not unique people. Exclude CI, mirrors, bots, tests, repeated self-downloads and purchased activity. If the source cannot distinguish relevant abuse, require corroboration or use an adoption track instead; not every registry exposes sufficient anti-bot data.
| Level | Meaningful MAU | Or average DAU | Total points unlocked | Additional points |
|---|---|---|---|---|
| 1 | 50 | 10 | 1000 | 1000 |
| 2 | 100 | 25 | 2000 | 1000 |
| 3 | 250 | 50 | 4500 | 2500 |
| 4 | 500 | 100 | 7500 | 3000 |
| 5 | 1000 | 200 | 11000 | 3500 |
| 6 | 2500 | 500 | 16000 | 5000 |
| 7 | 5000 | 1000 | 21000 | 5000 |
MAU means distinct people performing an agreed useful core product action during a completed calendar month, not visitors or signups. Average DAU is the mean of each day's distinct meaningful active users across that month, not the month's highest day. Do not round upward to reach a level. Prefer MAU for most products; average DAU is an alternative for daily-use products.
The selected threshold must hold in two consecutive full calendar months, with the same measure and definition. Use the lower monthly result: 75 and 95 MAU qualify for the 50-MAU level, not 100. MAU and DAU are alternatives, not two awards for the same activity. Choose overlapping distribution/adoption tracks in advance so the same underlying usage is not rewarded twice. Views and clones do not establish product DAU/MAU.
Submit only project-scoped aggregate evidence, with builder permission and appropriate end-user notices, consent where required and access controls. Do not send account emails or raw visitor histories to OpenRoot. An analytics connection alone does not verify activity or reward eligibility.
These are one-time cumulative high-water milestones per approved project and track, not awards paid again each month. Higher verified levels release only the difference from points already credited. Later declines create no negative points or repeat payout. For example, after 200 download points were credited, 500 eligible monthly downloads unlock another 400 points, for 600 total. No further levels above these tables are announced.
For transferred projects, eligible activity counts immediately from the agreed measurement start, not pre-start history. The existing first-claim wait remains one month. New adoption agreements additionally require two consecutive full calendar months, so an adoption claim may take longer. Existing agreed rewards and waiting periods are not changed retroactively. Moving a prior proportional download rate or project-specific usage agreement to this pilot requires an explicit migration agreement and reconciliation of points already credited.
Manual claims are open. Email hello@openroot.dev with the organization repository URL, reached milestone, dated evidence and previous claims. OpenRoot reviews the evidence, subtracts already credited points, confirms the available reward and its terms, and arranges redemption after approval. The first approved star milestone can be redeemed without waiting for another level, subject to any agreed transfer waiting period. The current API exchange is 10 points = USD 1 in non-cash API allowance, not a cash balance or a promised rate for every future reward. There is no automated portal wallet or self-service redemption yet. Never send API keys or account passwords.
Categories include AI/API access, GPU or cloud capacity, paid subscriptions, IDEs, and other useful developer tools. Builders should have a choice among eligible available options.
- DeepLearning.AI: one month, with one offer available until claimed. The exact product and redemption terms still need confirmation.
- AI model API credits: allowances valued at USD 20-10,000, with model families including GPT-6 Astra, Claude Fable 5.1 and Gemini 4 Argon. OpenRoot reports that each supplied key has a strictly enforced budget limit. There is no announced quantity cap, which does not mean unlimited spend or an automatic USD 10,000 grant for each person. Permitted distribution, expiry, supported models, recipient eligibility and delivery terms remain to be verified before issuance. This is third-party access, not a transfer of credits into a builder's own model-provider account and not an official model-provider sponsorship.
- More benefits coming soon, including paid subscriptions and developer tools. No additional product, quantity or date is promised.
Current partner-reported models are GPT-6 Astra, Claude Fable 5.1 and Gemini 4 Argon. Availability is confirmed for each approved offer. We aim to switch to successor models after their API release when partner support, provider terms and similar pricing allow; no release-day upgrade is guaranteed. Significant pricing or terms changes may change the model list or make API grants temporarily unavailable. Approved unspent points remain recorded and may be redeemed for other eligible available rewards under the agreed terms. Points are not cash; alternative inventory and immediate redemption are not guaranteed. A catalog update does not cancel existing agreed rewards.
Supplier identity is private; required recipient disclosures, distribution authorization, expiry and delivery terms are confirmed for each offer before issuance. Never post API keys, redemption codes or account credentials in public documentation, applications or GitHub issues. No shared personal account or provider-key transfer is promised. Manual builder milestone claims are open; affiliate fulfillment is a separate process and is not automatically enabled.
Each option must disclose account eligibility, service/duration or credit amount, expiry, redemption deadline, and any ongoing billing obligation. OpenRoot will not ask for your account password or distribute shared paid accounts.
After milestone and claim approval, builders choose among eligible available options for their project or cohort. Credit amount, model availability and terms are confirmed for that offer; the USD 20-10,000 range is not an automatic grant of the maximum to every builder. Free best-effort promotion is a separate member benefit, not something a builder spends a reward on.
Promotion is not limited to one feature. Projects may appear multiple times in the newsletter and on social channels through project highlights, showcases and in-depth articles. Builders can send releases, substantial updates and user stories to hello@openroot.dev for editorial consideration. This support is completely free of charge and does not require earning or redeeming a reward. Timing and format depend on editorial fit and available capacity; OpenRoot does not guarantee repeat coverage, reach or results.
We are looking for builders creating, or exploring, projects intended for other people to use: software that solves a problem, provides a useful tool or helps its users do something. Any software category, programming language and documentation language is welcome. Your project does not need existing users, and undecided applicants or an agreed private development phase remain welcome.
Hackathon builders are welcome too, whether preparing to enter or continuing a hackathon project. Additional rewards for strong results in eligible, pre-approved hackathons are planned. Eligible events, outcomes, evidence, funding and bonus terms must be published and agreed before a reward-bearing offer begins. A win does not automatically earn OpenRoot points or a reward. No specific eligible hackathons or bonus amounts are announced yet; hackathon bonus claims are not open.
Hermes, OpenClaw and OpenCode support configurable custom providers or OpenAI-compatible endpoints, but the actual reward gateway has not yet been tested with these clients. Cursor custom-key chat needs client/model/gateway verification; these credits do not buy a Cursor subscription or Tab access. Codex requires a gateway that supports the Responses API, streaming and tool-call conversations. Claude Code requires a supported gateway API format, such as Anthropic Messages. Generic OpenAI Chat Completions compatibility alone does not establish Codex or Claude Code support. Exact endpoint, model IDs, client limitations and recipient privacy terms must be confirmed before redemption.
See Codex gateway requirements and Claude Code gateway requirements. No end-to-end client compatibility is promised by this draft.
Rewards and funding are confirmed before projects enroll in a reward-bearing cohort. An unfunded interest list carries no reward promise. If inventory is limited, capacity and reservation rules must be visible from the start.
The program must distinguish guaranteed qualifying rewards from judged awards or quotas. Requirements cannot be changed retroactively to reject an otherwise valid claim. Existing-project baselines and whether past success counts will be defined before enrollment.
Rewards are allocated under the agreed project/team terms, not multiplied for every contributor by default. Claims move through submitted, reviewed, approved, and issued states. Redemption may remain unknown if the provider supplies no confirmation. Builders can request a correction or review of a decision.
Non-cash rewards still require appropriate accounting and jurisdiction-specific review before issuing rewards. This draft does not define tax treatment.