Vous choisissez ce que vous construisez. Toute catégorie de logiciel peut être examinée si le projet est légal, sûr à héberger, respecte les droits d'autrui et les exigences publiées de sa cohorte.
Proposez vos idées. Tous les langages de programmation et toutes les langues de dépôt ou de documentation sont acceptés, y compris les langues autres que l'anglais. Vous choisissez la pile technique, le périmètre, la feuille de route et l'orientation. Le programme n'est réservé ni à l'anglais ni à l'IA.
Un dépôt peut rester privé pendant le développement. Convenez de la durée et des éventuelles obligations de publication avant l'inscription à une cohorte financée. Aucun délai arbitraire ni publication automatique ne s'applique. Un jalon fondé sur une publication ou une adoption publique exige toujours les preuves convenues. Les autres builders n'accèdent pas automatiquement au code privé ; les propriétaires de l'organisation conservent leur accès administratif.
La candidature demande votre e-mail et votre nom d'utilisateur GitHub exact. L'approbation d'OpenRoot est obligatoire. Le portail n'est pas ouvert à tous ; une connexion Google ou e-mail ne remplace pas cette approbation.
Un compte GitHub est requis. Les builders approuvés acceptent l'invitation de l'organisation GitHub OpenRoot et y développent leurs dépôts. Le site https://openroot.dev/apply accepte les candidatures pour examen manuel. Un envoi ne crée pas de compte et n'accorde pas d'accès. Vous pouvez demander l'examen de comptes supplémentaires, GitHub Apps et équipes de projet. Ne transmettez jamais de mots de passe, tokens ou clés privées.
L’approbation crée un compte en attente dans le portail et envoie un e-mail d’instructions. Connectez-vous sur https://openroot.dev/portal avec l’adresse approuvée et saisissez le code reçu uniquement sur cette page. Kristofer envoie manuellement l’invitation GitHub avant d’approuver le compte du portail. L’approbation envoie un seul e-mail de bienvenue avec les étapes pour accepter l’invitation et créer le dépôt dans l’organisation. La liaison automatique de l’identité GitHub, les indicateurs de projet, l’inscription complète et les demandes automatiques de récompense dans le portail ne sont pas encore disponibles. Les comptes en attente conservent l’échéance initiale de 90 jours de la candidature. L’approbation seule n’accorde aucune récompense financée.
Cochez « Je ne sais pas encore ce que je vais construire » si vous n'avez pas choisi de projet. La note sur vos intérêts est facultative ; inutile d'inventer une proposition ou URL de dépôt. Il s'agit d'une candidature sans projet défini pour examen manuel, pas d'un projet approuvé ni d'une cohorte récompensée. Un projet précis et ses jalons doivent encore être approuvés avant toute admissibilité à une récompense.
Avant envoi, acceptez explicitement les Conditions de candidature actuelles et les politiques publiées des builders et des récompenses. Cette acceptation est distincte du consentement de confidentialité. Le backend exige et conserve la version actuelle 2026-10-12-1 et l'horodatage de l'envoi. Une acceptation absente, décochée ou périmée est refusée.
Règles de candidature :
- Fournissez des informations exactes et seulement des contenus que vous êtes autorisé à partager. N'incluez ni identifiants secrets, code privé ni données personnelles sensibles.
- Une candidature demande un examen manuel, sans création de compte, adhésion à l'organisation, accès au dépôt ni promesse de récompense. Vous pouvez candidater sans projet choisi.
- L'envoi ne transfère ni projet, droits du code ni dépôt. Les projets acceptés ensuite doivent respecter les droits d'autrui et les politiques publiées.
- Approbation, accès, jalons, disponibilité des récompenses et transferts exigent un examen séparé et des conditions convenues. Une inscription ne rend pas admissible à une récompense.
- Les accords d'inscription, de projet/départ et de récompenses financées sont distincts. Candidater n'accepte pas des conditions futures non publiées ni des seuils non annoncés.
Confidentialité, conservation et demandes de correction/suppression sont détaillées ci-dessous. Questions : hello@openroot.dev.
OpenRoot, exploité par Kristofer Jussmann, collecte e-mail, nom GitHub exact, proposition, preuves facultatives, demandes de collaboration/d'accès, parrainage, source de découverte facultative et consentement pour l'examen et les communications associées. La source déclarée volontairement permet de comprendre où les builders découvrent OpenRoot ; elle n'utilise pas de cookies de suivi. N'envoyez ni identifiants secrets, code privé ni données personnelles sensibles. Mentionnez d'autres comptes uniquement avec leur permission.
Les envois sont conservés de manière privée sur Google Cloud en Finlande, accessibles uniquement aux administrateurs autorisés. Leur expiration est prévue après 90 jours ; la suppression automatique est asynchrone. Les comptes approuvés du portail auront des conditions distinctes avant activation. L'infrastructure traite des journaux techniques ; le service ne journalise pas délibérément le contenu des candidatures.
Une candidature ne vous abonne pas à la newsletter. Contactez hello@openroot.dev pour consulter, corriger ou supprimer un envoi, ou retirer votre consentement. Une vérification d'identité peut être nécessaire. L'envoi ne prouve pas le contrôle de l'e-mail ou du compte GitHub indiqué.
Les builders développent, attirent des utilisateurs, maintiennent leurs projets et fournissent les preuves des jalons. OpenRoot aide à les promouvoir dans sa publication et sur ses réseaux, entièrement gratuitement et autant que possible. OpenRoot ne gère pas toutes les campagnes et ne garantit ni couverture, portée, avis favorable ou succès.
La promotion ne se limite pas à une seule publication. Les projets peuvent être présentés plusieurs fois dans la newsletter et sur les réseaux sociaux, sous forme de mises en avant, de présentations et d’articles approfondis. Les builders peuvent envoyer leurs versions, mises à jour importantes et témoignages d’utilisateurs à hello@openroot.dev pour examen éditorial. Ce soutien est entièrement gratuit et n’exige pas de gagner ou d’échanger une récompense. Le calendrier et le format dépendent de la pertinence éditoriale et des capacités disponibles ; OpenRoot ne garantit ni nouvelles publications, ni portée, ni résultats.
Nous recherchons des builders qui créent ou explorent des projets destinés à être utilisés par d’autres personnes : des logiciels qui résolvent un problème, proposent un outil utile ou aident leurs utilisateurs à accomplir quelque chose. Toutes les catégories de logiciels, tous les langages de programmation et toutes les langues de documentation sont les bienvenus. Le projet n’a pas besoin d’avoir déjà des utilisateurs ; les candidats encore sans idée définie et une phase de développement privée convenue restent les bienvenus.
Les builders de hackathons sont aussi les bienvenus, qu’ils préparent une participation ou poursuivent un projet de hackathon. Des récompenses supplémentaires pour de bons résultats dans des hackathons admissibles et préalablement approuvés sont envisagées. Les événements admissibles, résultats, preuves, financement et conditions des bonus doivent être publiés et convenus avant le début d’une offre avec récompenses. Une victoire n’attribue pas automatiquement de points ni de récompenses OpenRoot. Aucun hackathon admissible précis ni montant de bonus n’a encore été annoncé ; les demandes de bonus de hackathon ne sont pas ouvertes.
La participation n'est pas exclusive. Vous pouvez participer à des hackathons, collaborer ailleurs et exercer d'autres activités. Vérifiez les règles de l'événement et les obligations de licence ou des contributeurs ; rejoindre OpenRoot n'impose pas d'y renoncer.
Les équipes GitHub et rôles de dépôt limitent les accès au projet. L'accès à votre projet ne confère pas l'administration de toute l'organisation. Le futur portail affiche les dépôts associés, y compris les projets collectifs ; leur créateur n'est pas nécessairement le seul contributeur ni le seul bénéficiaire.
La politique envisagée prévoit que vous conservez les droits sur votre propre code et dirigez votre projet. Le dépôt est hébergé dans l'organisation OpenRoot ; le responsable approuvé reçoit le rôle Admin au niveau du dépôt. Les propriétaires de l'organisation conservent l'accès administratif. Ce rôle n'équivaut pas à la propriété personnelle de l'espace GitHub. Les modalités de licence, de départ et de transfert doivent être convenues avant inscription.
Vous pouvez proposer un dépôt ayant déjà des utilisateurs, téléchargements ou étoiles. Fournissez d'abord son URL et des preuves datées ; ne le transférez pas avant examen. L'adhésion, le transfert, l'inscription et les récompenses sont des décisions manuelles séparées. Les résultats existants ne comptent que selon les règles de référence et de cohorte convenues, pas simplement parce que le dépôt a rejoint l'organisation.
Les équipes propres à un projet peuvent couvrir plusieurs dépôts approuvés. Les responsables ont Admin dans ce périmètre ; les collaborateurs reçoivent le rôle examiné. Évitez les droits d'écriture globaux et l'héritage involontaire d'équipes parentes. Les comptes d'automatisation ne sont pas des builders indépendants récompensés.
Les droits, la licence, les responsabilités de maintenance, le départ ou transfert et le partage des récompenses doivent être expliqués et acceptés. L'accord final reste à préparer. L'adhésion à une organisation GitHub ne règle pas ces questions à elle seule.
Une cohorte doit préciser ses récompenses, capacités, seuils, périodes et règles d'examen. Sans ces conditions, manifester son intérêt ne crée pas un droit à récompense.
Voir le fonctionnement et les récompenses.
Le parrainage prévu reconnaît les builders approuvés atteignant un jalon vérifié, pas le nombre d'inscriptions. Le candidat peut indiquer le nom GitHub exact du parrain pour examen. Le financement et les règles finales doivent être publiés avant activation.
Une approbation examinée crée un compte en attente avec votre e-mail, nom GitHub et état d’intégration. Il conserve l’échéance initiale de la candidature, sans prolonger la conservation de 90 jours. La connexion utilise un cookie de session sécurisé et nécessaire, qui expire après huit heures. Les demandes de code par e-mail expirent après dix minutes ; le service conserve des empreintes, pas les codes en clair. Google Cloud traite les dossiers privés de compte et d’examen ; Resend traite les e-mails transactionnels de connexion et d’approbation. Seuls les administrateurs autorisés examinent les candidatures ; les builders accèdent uniquement à leurs propres informations dans le portail. Aucune inscription à la newsletter, aucun suivi publicitaire ni aucune invitation GitHub automatique n’est créé. L’inscription complète et la conservation des profils actifs exigent des conditions distinctes. Accès, rectification ou suppression : hello@openroot.dev.
Un projet existant accepté doit être hébergé sous OpenRootdev. Après examen, transférez le dépôt original ou copiez son code dans un nouveau dépôt de l'organisation. Un lien vers un dépôt extérieur ne suffit pas. Pour un projet existant, ces étapes remplacent la création d'un nouveau projet indiquée plus haut.
Avant les deux options : fournissez l'URL originale, confirmez votre autorité et les droits des contributeurs/licences, convenez de la migration avec OpenRoot et acceptez l'invitation. Sauvegardez le projet et vérifiez secrets, intégrations et coûts Actions avant tout transfert ou push. En cas de doute sur l'accord ou les permissions : hello@openroot.dev.
Recommandée pour conserver étoiles, issues, pull requests et historique Git.
- 1. Ouvrez le dépôt original sur GitHub, puis Settings → General → Danger Zone → Transfer. Vous devez avoir Admin sur le dépôt et pouvoir créer des dépôts dans OpenRootdev ; quitter une autre organisation peut nécessiter son propriétaire.
- 2. Choisissez OpenRootdev comme nouveau propriétaire. Vérifiez que le nom est libre, lisez les avertissements GitHub (un dépôt privé peut perdre des fonctionnalités payantes sur GitHub Free), saisissez le nom et confirmez.
- 3. Vérifiez que l'URL commence par
https://github.com/OpenRootdev/. Demandez à OpenRoot de contrôler votre rôle Admin et les accès de l'équipe ; les propriétaires de l'organisation gardent leur accès administratif. - 4. Dans chaque clone local existant, exécutez
git remote set-url origin https://github.com/OpenRootdev/YOUR-REPOSITORY.git. Vérifiez intégrations, déploiements, Pages, secrets et workflows avant de reprendre. Ne recréez pas l'ancien chemin du dépôt : cela peut casser les redirections.
Pour garder l'original à son emplacement et développer la copie approuvée dans OpenRootdev.
- 1. Ouvrez New repository. Vérifiez Owner = OpenRootdev, le nom convenu et la visibilité publique/privée. N'initialisez pas de README, licence ou .gitignore ; créez un dépôt vide.
- 2. Dans un terminal, remplacez les noms d'exemple et utilisez un nouveau dossier local :
git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY.git openroot-project, puiscd openroot-project. - 3. Ajoutez la destination sans changer le remote original :
git remote add openroot https://github.com/OpenRootdev/YOUR-REPOSITORY.git. - 4. Envoyez la branche courante :
git push openroot HEAD:main. Vérifiez les fichiers dans le dépôt de l'organisation. Pour la suite, envoyez versopenroot, pas vers l'ancienorigin. Si la destination n'est pas vide ou si le push est refusé, arrêtez et demandez de l'aide ; ne forcez pas le push. - 5. Cela copie l'historique des commits accessibles depuis la branche choisie, pas les étoiles, issues, pull requests, releases, paramètres ni toutes les branches/tags. Les objets Git LFS et sous-modules nécessitent un traitement séparé ; demandez de l'aide. Gardez les fichiers de licence/attribution et ne copiez pas de secrets.
Envoyez l'URL finale du dépôt de l'organisation à OpenRoot pour l'associer au projet examiné. L'adoption passée et les récompenses exigent une base convenue et un accord séparé ; pas de double comptage entre copies. Ne supprimez pas l'original uniquement pour participer. Vous gardez les droits sur votre code ; l'hébergement dans l'organisation ne supprime pas l'accès administratif de ses propriétaires.
Références officielles : transfert, nouveau dépôt, Git push.
La version 2026-10-14-3 de confidentialité des candidatures ajoute un code d'affiliation facultatif. Utilisez un code ou le nom GitHub du parrain, pas les deux. Le code est conservé de façon privée comme déclaration d'attribution, examinée avant rattachement au compte approuvé ; il n'approuve ni adhésion, ni projet, ni récompense. Aucun cookie de suivi d'affiliation n'est utilisé et l'affilié ne reçoit ni identité du candidat ni informations privées du projet. Votre propre récompense n'est pas réduite. Les conditions de candidature restent 2026-10-12-1 ; les consentements antérieurs ne changent pas. Voir le pilote d'affiliation distinct.