How it works
- Apply. Share your email, exact GitHub username and project proposal. Include optional notes about collaborators or tools if you would like help.
- Get reviewed. OpenRoot manually reviews membership, project fit, rights and any repository-transfer proposal.
- Join and verify. Applicants receive a manual GitHub invitation before portal approval. Approval then sends one welcome email with the steps to accept it, create an organization repository and sign in. Signing in alone cannot bypass approval.
- Build and grow. Build inside the organization, maintain the project and attract real users. OpenRoot helps promote member projects through its publication and socials, completely free of charge and as much as it can; builders manage broader marketing.
- Submit evidence. Request review against your agreed cohort milestones. Reward eligibility and fulfillment are separate decisions.
Keep building. We can keep sharing.
Promotion is not limited to one feature. Projects may appear multiple times in the newsletter and on social channels through project highlights, showcases and deep dives. 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.
To suggest a feature, email hello@openroot.dev with your project or release link, who it helps, what changed, the specific points you would like highlighted, and optional screenshots or a demo you have permission to share.
OpenRoot manually drafts the final post to fit its editorial standards and each platform. A request is not required: OpenRoot may also feature public member-project updates on its own initiative. Do not send credentials, confidential material or other people's personal data. This is an email process; a dedicated portal request form is not available yet.
Builders manage wider marketing and growth. A release or milestone can give us a fresh story; no fixed posting quota is promised.
Your idea. Your language. Your direction.
We are looking for builders creating, or exploring, projects intended for other people to use: useful tools, software that solves a problem or helps its users do something. New ideas, existing projects and undecided applicants are welcome; your project does not need existing users.
Any programming language. Any project category. Any language for your repository and documentation. Bring an idea you already care about, or propose an existing project. Non-English repositories are welcome; the program is not an English-only or AI-only project collection.
You choose the stack, scope, roadmap, documentation and collaborators. Your code and project remain yours, subject to agreed contributor rights, licensing and the normal safety and conduct requirements.
Hackathons and outside activities are welcome
Participation is not exclusive. Enter hackathons, collaborate elsewhere and take part in other activities with your project. Respect the event rules and project/contributor rights.
Hackathon builders are welcome, whether preparing to enter or continuing a project. Additional rewards for strong results in eligible, pre-approved hackathons are planned. Events, outcomes, evidence, funding and bonus terms must be published and agreed before a reward-bearing offer begins. A win does not automatically earn points or a reward. No specific eligible events or bonus amounts are announced yet; hackathon bonus claims are not open.
A private build phase is welcome
You can keep your repository private while developing it. Agree on the duration and any public-release requirement before joining a funded cohort. OpenRoot does not automatically make a private repository public or assign an arbitrary countdown.
Private development and public open-source milestones are different phases. A reward that depends on a public release or public adoption still needs its agreed evidence. Other builders do not automatically receive access to your private code just by joining the organization.
Your project stays yours.
You retain rights to your own code and lead your project. Your repository is hosted under OpenRootdev, with repository-level Admin for the member who creates it or brings it in through an approved transfer. This is not a work-for-hire arrangement or a blanket transfer of code rights.
Choose a suitable project license and respect existing licenses, attribution and contributor rights. Licensing and any project-specific reward details can be recorded with the submission or agreed directly when needed. A separate maintainer-rights or contribution-rules agreement is not required; contribution rules are set by the repository admin.
Bring an existing repository
You may propose an existing project, including one that already has users, downloads or GitHub stars. Submit its URL and dated evidence first. Do not transfer it before written approval.
Review covers your authority to transfer, licenses and contributor rights, security, project quality, current maintainers, dependencies and existing adoption. Approval agrees on the metric baseline, whether prior achievements count, eligible rewards and available funding. Historical-metric terms need separate agreement; the published star ladder covers eligible new growth.
An accepted existing project must be hosted under OpenRootdev, through a reviewed transfer or an approved code copy. Simply linking an external repository is not enough.
Option A: transfer the original
- Agree the project and migration with OpenRoot, accept your organization invitation and back up the repository.
- In the original repository, open Settings → General → Danger Zone → Transfer. Set the new owner to OpenRootdev, read the warnings and confirm.
- Check the new organization URL, your repo-level Admin, team access, local remotes and integrations. This route can preserve stars, issues, pull requests and Git history.
Option B: copy the existing code
- Agree the project and migration with OpenRoot and accept the organization invitation.
- Create an empty repository with Owner set to OpenRootdev. Do not initialize a README, license or .gitignore.
- Clone your original project into a new local folder, add the organization repository as a separate remote, then push the selected branch there. Continue building in the organization copy.
A code copy does not bring stars, issues, pull requests, releases or repository settings. It does not automatically copy every branch/tag, Git LFS object or submodule. Keep contributor rights, license and attribution intact; check secrets, workflows and billing before pushing. Do not delete the original or force-push to an occupied destination.
Full step-by-step instructions and Git commands →
Send us the final organization repository URL for association with your reviewed project. A transfer, invitation or existing star count never creates automatic eligibility. Membership, project migration, reward enrollment and reward claims are separate reviews; metrics across copies are not double-counted.
Your repository. Your collaborators.
The repository admin chooses collaborators, project-specific teams, repository roles and contribution rules without separate OpenRoot approval. You can organize one project across multiple repositories. Other members do not automatically receive access to private code or write access to your repository. Repository-scoped apps use GitHub's normal permission controls; organization-wide changes may need help from OpenRoot.
Create new projects as a member
Existing organization members can create new repositories without another application or separate OpenRoot approval. New repositories created from scratch automatically join the program, subject to its policies. OpenRoot manually reviews repositories and contacts the repository admin if changes or removal are needed. Policy bots are planned as the organization grows; they are not active yet. Program enrollment does not automatically approve rewards: private projects must become public and meet the agreed milestone and funding conditions before earning rewards.
Automation without shared credentials
Repository admins configure their project workflows and repository-scoped tools using GitHub's normal permission controls. Ordinary collaboration does not require a separate OpenRoot application. Some GitHub App installations or organization-wide settings may require help from OpenRoot; contact us if GitHub blocks an action.
Prefer repository-scoped GitHub Apps for automation, or narrowly scoped deploy keys and workflows for a specific task. Applications are installed or authorized, not added as ordinary human team members. Never submit API keys, tokens, passwords or private keys in the form.
No organization-wide secrets should be exposed to arbitrary project workflows. Extra automation accounts do not receive rewards or count as independent builders.
Explore the current reward pool.
Milestones with evidence, not shortcuts
The planned reward choices are subscriptions, cloud credits, AI-provider credits and developer-tool access, not direct cash. Actual options depend on confirmed partner agreements and authorized redemption terms.
Potential evidence includes daily or monthly active users (DAU/MAU), releases, package downloads, container pulls and GitHub attention. Usage requires an agreed meaningful product action, unique-user definition, source and window. Project-scoped aggregate reports may support review with the builder’s approval and appropriate end-user notices, consent where required and access controls. A repository alone does not measure product users, and overlapping usage is not double-counted. Stars alone are not proof of product adoption. Raw clones, downloads and traffic require clear definitions and anti-abuse review.
Each funded cohort must publish capacity, measurement windows, baselines, thresholds, team reward allocation, review/appeal rules and fulfillment terms. The star milestone ladder is published on the rewards page. Approved download and adoption ladders are published there too, with project-specific baselines and evidence agreed before accrual. An offer listing is not a guarantee of a reward.
Current offers reported by OpenRoot
- DeepLearning.AI: one month, with one offer available until claimed. Exact product and redemption terms are being confirmed.
- AI model API credits: $20-$10,000 budget-limited allowances. This is not an automatic $10,000 reward per person.
- More benefits coming soon.
Current partner-reported models: 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; this is not a guaranteed release-day upgrade.
Significant inference-provider pricing or terms changes can change the available models 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. Existing agreed rewards are not cancelled by a catalog update.
These are third-party allowances, not credits transferred into your own model-provider account or official sponsorships. Distribution authorization, expiry, recipient eligibility and delivery terms are confirmed for each offer before issuance. Milestone claims are open for manual review. See the points and milestone table. These offers are not confirmed referral rewards.
Partner with us to help fund a cohort.
Refer builders who ship
The planned builder referral program recognizes referrals only after the referred builder is approved and reaches a verified project milestone. An application or signup alone is not enough. Benefits, referrer eligibility, caps and funding are confirmed before enrollment, with separate referral-claim review.
Live now, with more to come
We plan to host internal community hackathons and collaborate on public events with partners and co-hosts. A focus will be reusable open-source solutions to practical community needs, such as volunteer coordination, repair initiatives and accessible community resources. These are possible themes, not announced projects or events.
We are looking for hackathon partners, co-hosts and local ambassadors around the world. Explore partnerships or help organize as an ambassador. Dates, participation terms and any funded prizes will be published before registration.
Initial applications are stored privately for manual review, with a privacy notice and 90-day retention. The private operator review workflow and approval-only email-code portal are available. GitHub invitations are sent manually before portal approval; approval then sends one combined welcome email. Licensing and funded reward terms are agreed where needed; manual milestone claims are open.
The website's application accepts submissions for review. It does not create accounts or automate approval. The partner form prepares an email draft locally, not a database submission. The newsletter is available through Beehiiv.
