How it works
- Apply. Share your email, exact GitHub username and project proposal. Include collaborators or extra access requests if needed.
- 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.
Your idea. Your language. Your direction.
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.
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 get access to your private code just by joining the organization; organization owners retain their administrative access.
Your project stays yours.
OpenRoot's intended policy is that you retain ownership of your own code and lead your project. It is not a work-for-hire request or a blanket transfer of code rights. Final licensing and project agreements still need to be published and accepted before enrollment.
The GitHub repository is hosted under the OpenRoot organization. You get repository-level Admin for your approved project. GitHub organization owners retain administrative access, so this is not the same as a personally owned repository under your GitHub username.
Repository administration is separate from copyright and software licensing. The enrollment agreement must state maintainer rights, project licensing, contribution rules, departure and transfer arrangements.
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. These rules are not finalized yet.
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.
Work together without broad access
The planned structure uses one or more project-specific teams, not a shared write-access team for every builder. Repositories and builder/project associations are tracked explicitly, including multi-repository projects.
| Role | Access | Scope |
|---|---|---|
| Project lead | Admin | Their approved project repositories |
| Collaborator | Write or another reviewed role | Named project repositories |
| Other builder | No default write access | Public read access remains available |
| Organization owner | Organization administration | All organization repositories |
Project teams can work across more than one approved repository. A request identifies the GitHub accounts, repositories and roles. Parent-team inheritance must not accidentally grant unrelated project access. Team maintainer status is not the same as repository Admin.
Automation without shared credentials
Include additional GitHub accounts or GitHub App names, their purpose, the exact repositories and the access needed in your application. Extra human accounts must be linked to the correct person; machine accounts must be clearly identified. Requests are reviewed separately.
Prefer repository-scoped GitHub Apps for automation, or a reviewed deploy-key/workflow approach for a narrow 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 retained users, releases, package downloads, container pulls and GitHub attention. 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. No numerical target is announced. An offer listing is not a guarantee of a reward.
Initial 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: EUR 50-1,000 allowances for GPT, Claude, Gemini or Grok, with strict per-key budgets reported by OpenRoot. No quantity cap is announced; this does not mean unlimited spending or an automatic EUR 1,000 reward per person.
- More benefits coming soon.
These are third-party allowances, not credits transferred into your own model-provider account or official sponsorships. Permitted distribution, expiry, supported models, recipient eligibility and delivery terms must be finalized before issuance. Applications are accepted for review; reward claims are not open. These offers are not confirmed referral rewards. Explore the reward pool or read the full offer terms.
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.
What still needs to be ready
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. Enrollment terms, project/departure agreements and funded reward capacity must be settled before funded enrollment and reward claims 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.