Les récompenses aident à continuer de construire. Ce sont des avantages non monétaires fournis par des partenariats confirmés ou une cohorte explicitement financée.
Chaque projet utilise un parcours adapté :
- Attention : étoiles GitHub organiques, intérêt extérieur significatif ou couverture.
- Distribution : téléchargements de versions ou de paquets, clones complets ou téléchargements d'images de conteneurs sur une période définie.
- Adoption : utilisateurs actifs quotidiens ou mensuels (DAU/MAU), mesurés par une action significative d’utilisation du produit convenue à l’avance.
- Usage durable : une mesure d'adoption pertinente maintenue dans le temps.
Les preuves doivent préciser l’événement, la définition d’un utilisateur unique, la période de mesure et la source. Un dépôt GitHub seul ne mesure pas les utilisateurs du produit. Des rapports agrégés provenant de PostHog ou d’un service équivalent, autorisés par le responsable et limités au projet, peuvent appuyer l’examen. Exclure les bots, les tests et l’activité artificielle ; DAU/MAU et téléchargements ne sont pas interchangeables, et les usages qui se chevauchent ne sont pas comptés deux fois. Collecter et partager les données uniquement avec une information adaptée des utilisateurs, leur consentement lorsque requis et des contrôles d’accès. Les métriques ne donnent pas automatiquement des points ou des récompenses.
Les étoiles montrent l'intérêt ; les téléchargements montrent la distribution. Aucun ne prouve automatiquement l'usage actif. L'activité automatisée répétée, l'engagement acheté et l'inflation artificielle ne démontrent pas une traction réelle. Les exclusions précises seront publiées pour chaque cohorte.
Les premiers niveaux accordent davantage de points par nouvelle étoile GitHub organique admissible, avec un taux progressivement plus faible à mesure que le projet grandit. Les points se débloquent uniquement aux jalons atteints ci-dessous après examen manuel, jamais à des nombres intermédiaires arbitraires. Ce sont des points non monétaires, pas des tokens de modèle ni un solde transférable.
| Niveau du jalon | Étoiles admissibles | Total de points débloqués | Points supplémentaires depuis le jalon précédent |
|---|---|---|---|
| 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 étoiles débloquent 800 points. Avec 7 ou 19, aucune récompense par étoiles ne peut être demandée ; avec 30, seul le jalon de 20 est débloqué. Après 800 points crédités, atteindre 50 libère 900 points supplémentaires, soit 1700 au total, pas une nouvelle attribution intégrale. Ne pas réclamer un jalon précédent ne fait pas perdre les points admissibles : déduire tout ce qui a déjà été crédité au même projet et parcours. Aucun niveau au-delà de 5000 étoiles n’est annoncé. Les récompenses convenues ne sont pas réduites ou réévaluées automatiquement ; changer un ancien barème exige un accord explicite et un rapprochement des points crédités.
Le barème porte sur la nouvelle croissance admissible depuis la référence convenue, pas sur la conversion automatique de toutes les étoiles affichées. Avant une participation avec récompenses, convenir de l'indicateur, de la source, de la référence, du début et de la période de mesure, des preuves, du maximum financé et des conditions. Les étoiles historiques nécessitent un accord distinct ; aucune décote historique n'est annoncée. La récompense suit l'accord projet/équipe, sans duplication par contributeur. Exclure bots, interactions achetées, gonflement par soi/l'équipe, retraits et ajouts répétés d'étoiles et doublons entre copies ou compteurs. Les points déjà crédités ne sont jamais attribués deux fois ; les accords valides et versions acceptées de candidatures ne changent pas rétroactivement.
Compter les téléchargements admissibles de versions/paquets pendant un mois civil terminé, pas leur total historique. Convenir avant accumulation de la source de référence, du périmètre, du fuseau du calendrier, de la référence initiale, des exclusions et du maximum financé. Ce sont des récompenses par jalon, pas un taux fixe par téléchargement.
| Niveau | Téléchargements mensuels | Total de points débloqués | Points supplémentaires |
|---|---|---|---|
| 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 |
Les téléchargements bruts du registre ne sont pas des personnes uniques. Exclure CI, miroirs, bots, tests, téléchargements personnels répétés et activité achetée. Si la source ne distingue pas les abus pertinents, exiger des preuves complémentaires ou utiliser un parcours d’adoption ; tous les registres ne fournissent pas assez de données antibot.
| Niveau | MAU significatif | Ou DAU moyen | Total de points débloqués | Points supplémentaires |
|---|---|---|---|---|
| 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 désigne les personnes distinctes réalisant une action centrale utile du produit convenue pendant un mois civil terminé, pas les visiteurs ou inscriptions. Le DAU moyen est la moyenne des utilisateurs actifs distincts significatifs de chaque jour du mois, pas le jour le plus élevé. Ne pas arrondir vers le haut pour atteindre un niveau. Privilégier MAU pour la plupart des produits ; le DAU moyen convient comme alternative aux produits utilisés au quotidien.
Le seuil choisi doit être atteint pendant deux mois civils complets consécutifs avec la même mesure et définition. Retenir le résultat mensuel le plus bas : 75 et 95 MAU satisfont le niveau de 50 MAU, pas 100. MAU et DAU sont des alternatives, pas deux récompenses pour la même activité. Choisir à l’avance les parcours de distribution/adoption qui se chevauchent afin de ne pas récompenser deux fois le même usage. Les vues et clones ne démontrent pas les DAU/MAU du produit.
Fournir uniquement des preuves agrégées limitées au projet, avec l’autorisation du responsable, une information adaptée des utilisateurs, leur consentement lorsque requis et des contrôles d’accès. Ne pas envoyer d’emails de comptes ni d’historiques bruts de visiteurs à OpenRoot. Une connexion analytique seule ne vérifie ni activité ni admissibilité.
Ces jalons sont cumulatifs et uniques selon le niveau maximal atteint par projet et parcours approuvés, pas des récompenses versées de nouveau chaque mois. Un niveau supérieur vérifié libère seulement la différence avec les points déjà crédités. Une baisse ultérieure ne crée ni points négatifs ni nouveau versement. Par exemple, après 200 points de téléchargements crédités, 500 téléchargements mensuels admissibles libèrent 400 points de plus, soit 600 au total. Aucun niveau supérieur à ces tableaux n’est annoncé.
Pour les projets transférés, l’activité admissible compte dès le début de mesure convenu, pas l’historique antérieur. Le délai existant pour la première demande reste d’un mois. Les nouveaux accords d’adoption exigent aussi deux mois civils complets consécutifs et peuvent donc prendre plus longtemps. Récompenses et délais convenus ne changent pas rétroactivement. Migrer un ancien taux proportionnel ou un accord d’usage propre au projet exige un accord explicite et un rapprochement des points crédités.
Les demandes manuelles sont ouvertes. Envoyer à hello@openroot.dev l'URL du dépôt de l'organisation, le jalon atteint, les preuves datées et les demandes précédentes. OpenRoot examine, déduit les points déjà crédités, confirme la récompense disponible et ses conditions, puis organise l'échange après approbation. Le premier jalon par étoiles approuvé peut être échangé sans attendre un autre niveau, sous réserve du délai convenu pour un transfert. Le taux API actuel est de 10 points = USD 1 de crédit API non monétaire, pas un solde en espèces ni un taux promis pour tout avantage futur. Il n'existe pas encore de portefeuille automatique ni d'échange en libre-service dans le portail. Ne jamais envoyer de clés API ni de mots de passe.
Les catégories incluent accès IA/API, GPU ou cloud, abonnements, IDE et outils utiles. Les builders doivent pouvoir choisir parmi les options disponibles auxquelles ils sont admissibles.
- DeepLearning.AI : un mois, une seule offre disponible jusqu'à attribution. Produit exact et modalités de remise à confirmer.
- Crédits API de modèles d'IA : budgets d'une valeur de USD 20-10,000, pour les familles de modèles GPT-6 Astra, Claude Fable 5.1 et Gemini 4 Argon. OpenRoot indique que chaque clé fournie a une limite budgétaire strictement appliquée. Aucun plafond de quantité d'offres n'est annoncé ; cela ne signifie ni dépenses illimitées ni attribution automatique de USD 10,000 à chacun. L'autorisation de distribution, l'expiration, les modèles, l'admissibilité et la livraison doivent être vérifiés avant émission. Il s'agit d'accès tiers, pas d'un transfert de crédits sur votre compte OpenAI/Anthropic/Google/xAI ni d'un sponsoring officiel de ces sociétés.
- D'autres avantages arrivent prochainement, dont des abonnements payants et outils de développement. Aucun produit supplémentaire, quantité ni date n'est promis.
Les modèles actuellement signalés par le partenaire sont GPT-6 Astra, Claude Fable 5.1 et Gemini 4 Argon. La disponibilité est confirmée pour chaque offre approuvée. Nous souhaitons adopter leurs successeurs après la sortie de leurs API si le partenaire les prend en charge et si les conditions du fournisseur et des prix similaires le permettent ; aucune mise à niveau le jour de sortie n’est garantie. Des changements importants de prix ou de conditions peuvent modifier la liste ou rendre les crédits API temporairement indisponibles. Les points approuvés non utilisés restent enregistrés et peuvent être échangés contre d’autres avantages admissibles disponibles selon l’accord. Ce ne sont pas des espèces ; aucun stock alternatif ni échange immédiat n’est garanti. Une mise à jour du catalogue n’annule pas les récompenses déjà convenues.
L'identité du fournisseur est privée ; les informations nécessaires au bénéficiaire, l'autorisation de distribution, l'expiration et la livraison sont confirmées par offre avant émission. Ne jamais publier clés API, codes ou identifiants dans les documents, candidatures ou issues. Aucun partage de compte personnel ni transfert de clé fournisseur n'est promis. Les demandes manuelles des builders par jalon sont ouvertes ; la livraison aux affiliés est distincte et n'est pas activée automatiquement.
Chaque option doit préciser l'admissibilité du compte, la prestation, durée ou montant, l'expiration, le délai d'activation et toute facturation ultérieure. OpenRoot ne demandera pas votre mot de passe et ne distribuera pas de comptes payants partagés.
Après approbation du jalon et de la demande, les builders choisissent parmi les avantages admissibles et disponibles pour leur projet ou cohorte. Montant, modèles et conditions sont confirmés pour chaque offre ; USD 20-10,000 ne signifie pas une attribution automatique du maximum à chacun. La promotion entièrement gratuite, dans la mesure de nos moyens, est un avantage distinct qui ne consomme pas une récompense.
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.
Pour proposer une mise en avant, écrivez à hello@openroot.dev avec le lien du projet ou de la version, les personnes auxquelles il est utile, les nouveautés, les points précis que vous souhaitez mettre en valeur et, si vous le souhaitez, des captures d’écran ou une démonstration que vous avez l’autorisation de partager. OpenRoot rédige manuellement la publication finale pour respecter ses critères éditoriaux et le style de chaque plateforme. Une demande n’est pas nécessaire : OpenRoot peut aussi présenter, de sa propre initiative, des mises à jour publiques de projets de membres. N’envoyez pas d’identifiants, de documents confidentiels ni de données personnelles d’autres personnes. Le processus se fait par e-mail ; aucun formulaire dédié n’est encore disponible dans le portail.
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.
Hermes, OpenClaw et OpenCode acceptent des fournisseurs personnalisés ou des endpoints compatibles OpenAI, mais la passerelle réelle des récompenses n'a pas encore été testée avec ces clients. Le chat Cursor avec clé personnelle exige une vérification du client/modèle/de la passerelle ; ces crédits n'incluent ni abonnement Cursor ni Tab. Codex exige Responses API, le streaming et des conversations avec appels d'outils. Claude Code exige un format d'API de passerelle pris en charge, tel qu'Anthropic Messages. La seule compatibilité avec OpenAI Chat Completions ne prouve pas la prise en charge de Codex ou Claude Code. Endpoint, identifiants de modèles, limites des clients et conditions de confidentialité du bénéficiaire doivent être confirmés avant activation.
Voir les exigences de passerelle Codex et Claude Code. Ce brouillon ne promet pas une compatibilité de bout en bout.
Les récompenses et le financement sont confirmés avant inscription à une cohorte récompensée. Une liste d'intérêt non financée ne promet rien. Si le stock est limité, capacités et règles de réservation doivent être visibles dès le départ.
Distinguez les récompenses garanties aux demandes admissibles des prix jugés ou soumis à quotas. Les exigences ne peuvent pas être modifiées rétroactivement pour rejeter une demande autrement valide. La référence d'un projet existant et la prise en compte du passé sont définies avant inscription.
Les récompenses suivent les modalités de projet ou d'équipe, sans multiplication automatique par contributeur. Les demandes passent par soumission, examen, approbation puis émission. L'activation peut rester inconnue sans confirmation du fournisseur. Un builder peut demander correction ou réexamen.
Les avantages non monétaires nécessitent aussi une comptabilité appropriée et un examen selon la juridiction avant la distribution des récompenses. Ce brouillon ne définit pas leur traitement fiscal.