37 points par GN⁺ 2025-03-17 | 1 commentaires | Partager sur WhatsApp

Ce qu’il faut savoir avant d’essayer de rendre un projet open source célèbre

  • Si vous voulez devenir célèbre ou riche grâce à l’open source, c’est une mauvaise approche
  • Écrire un blog ou donner une conférence est plus efficace que de créer un projet populaire
  • Redux et React Router sont des projets populaires, mais leurs mainteneurs n’ont pas énormément d’abonnés sur les réseaux sociaux → la popularité d’un projet ne se transforme pas en popularité personnelle

Ne créez pas un projet open source uniquement pour le mettre sur votre CV

  • L’idée selon laquelle contribuer à l’open source est indispensable est fausse
  • Même si vous commencez l’open source pour devenir connu, rien ne garantit le succès
  • Même un bon projet peut vous déprimer s’il n’a qu’une seule étoile
  • L’activité open source peut aider dans le recrutement, mais il est plus efficace de contribuer à des projets connus existants que de créer directement votre propre projet

Commencez d’abord par contribuer

  • Dans les grands projets open source, commencez par corriger la documentation ou corriger des bugs
  • Rédiger une PR est bien plus facile qu’écrire du code
  • La meilleure raison de créer un bon projet open source, c’est l’envie de changer le monde

Comment changer le monde grâce à l’open source

  • PostCSS a été créé pour diversifier l’écosystème des outils CSS et rendre le traitement CSS plus simple → objectif atteint
  • La popularité et le succès restent des éléments importants

Le secret des projets populaires

Popularité d’un projet = notoriété + promotion + bénéfice apporté aux utilisateurs + chance

  • Les projets créés par des développeurs déjà populaires ont tendance à devenir populaires plus facilement → cela peut sembler injuste, mais c’est la réalité
  • Il faut comprendre les causes de la popularité et adopter une approche stratégique

Comment les gens choisissent l’open source

  • Les gens ne choisissent pas leurs outils de manière rationnelle
  • La plupart décident en regardant le nombre d’étoiles sur GitHub
  • Ou bien ils suivent souvent les frameworks mentionnés dans les conférences

Comment les gens lisent réellement l’information

  • Les utilisateurs ne lisent ni le README ni la documentation du début à la fin
  • Il faut présenter l’information de manière simple et progressive, comme un « progressive JPEG »
  • Le premier bloc doit expliquer clairement les bénéfices

Stratégie pour gagner en popularité

  • Il faut bien structurer ses comptes sur les réseaux sociaux
    • L’auteur n’avait pas créé de comptes sociaux en anglais au début, ce qui rendait difficile le fait de le trouver
    • Pour les développeurs non anglophones, créer un compte sur les réseaux sociaux en anglais est un avantage
    • Quand le projet est mentionné, il faut fournir un lien vers le profil pour faciliter la connexion avec les utilisateurs
  • Adopter un état d’esprit réaliste
    • La chance est importante, mais ce n’est pas tout
    • L’auteur n’a vu réussir que 4 projets sur 56
    • Il a connu de nombreux échecs avant de créer un projet populaire
    • Les projets qui réussissent sont le résultat d’essais constants et d’échecs répétés
  • Accepter l’échec comme normal
    • Un projet populaire demande un effort de long terme, comme un marathon
    • L’échec fait partie du processus → il faut améliorer et réessayer en continu
    • Il faut prévoir l’échec dès le départ, sans pour autant sacrifier la qualité du travail

Comment rendre un projet open source populaire : le README

  • Le README et la documentation déterminent la première impression du projet
  • L’utilisateur doit pouvoir comprendre rapidement la valeur du projet grâce au README
  • Le README peut être exposé à l’utilisateur par plusieurs canaux
    • présentation, billet de blog, podcast et autres canaux de promotion
    • au final, tout renvoie vers le README, il faut donc le rédiger avec soin
  • Les lecteurs ne lisent pas attentivement le README du début à la fin
  • Il faut donc communiquer clairement la valeur du projet dès la première partie du README
  • Le premier bloc doit permettre de comprendre rapidement les bénéfices du projet

Question : transmettez-vous efficacement la valeur du projet ?

  • Les gens ne prennent pas le temps de lire la documentation en détail
  • Il faut donc organiser les informations essentielles et les bénéfices de façon claire et concise
  • Une documentation bien structurée améliore l’expérience utilisateur et peut accroître la popularité du projet

1. Transmettre efficacement les bénéfices aux utilisateurs

  • Expliquer les bénéfices du projet aux utilisateurs est directement lié à la promotion
  • Dans la formule du succès évoquée plus haut, apporter un bénéfice aux utilisateurs est un facteur essentiel

Popularité d’un projet = notoriété + promotion + bénéfice apporté aux utilisateurs + chance

  • Il faut exprimer clairement les bénéfices pour l’utilisateur dans le README, la documentation ou une courte présentation
  • Pour attirer l’attention grâce à la valeur réelle du projet plutôt qu’à sa popularité ou à sa réputation, il faut prendre en compte les points suivants
    • Lisibilité de l’information : l’utilisateur doit pouvoir saisir rapidement l’essentiel
    • Facilité de balayage visuel : les informations importantes doivent sauter aux yeux
    • Première impression : la valeur du projet doit être évidente dans les premières secondes

2. Faire passer le message rapidement et efficacement

  • Le premier bloc du README doit absolument contenir ces trois éléments
    1. Une explication claire
    2. Une indication claire de l’aide apportée à l’utilisateur
    3. Ce qui différencie le projet des autres produits
  • Il faut expliquer dès la première phrase pourquoi l’utilisateur devrait lire la documentation
    • La première phrase est la plus importante → la plupart des utilisateurs ne lisent que celle-ci pour juger la valeur du projet
    • Le premier bloc doit donc faire apparaître clairement les bénéfices du projet
  • Il est tout à fait acceptable d’investir de quelques jours à une semaine dans la rédaction du premier bloc du README
  • Il a fallu environ une semaine pour rédiger le premier bloc de PostCSS
  • Plus ce premier bloc reçoit d’attention, plus les chances de succès du projet augmentent

3. Expliquer le produit pour que les gens le comprennent facilement

  • La description du projet doit être claire et intuitive
  • Une explication concrète est plus importante qu’une formule qui a l’air cool
  • "Svelte is cybernetically enhanced web apps"
    • Trop vague → on ne comprend pas clairement quel avantage concret cela apporte
  • "Svelte is a web UI framework with a unique compiler which generates smaller JS fixes."
    • C’est concret et clair → cela explique quel problème est résolu et quels bénéfices sont apportés
  • Rédigez comme si vous en parliez à un collègue dans un bar
    • « Tu as créé un nouvel outil ? Il fait quoi ? » → expliquez-le naturellement
  • Une fois l’explication posée, raccourcissez-la encore
    • Après l’avoir rédigée, retravailler 2 à 4 fois de plus pour la rendre plus courte et plus claire

4. Faire passer rapidement l’information avec des listes et du texte en gras

  • Pour transmettre clairement l’information, il faut utiliser activement les listes et le texte en gras
  • Description initiale de Nano Stores (sous forme de bloc de texte)
    • Nano Stores est un gestionnaire d’état utilisable avec divers frameworks front-end
    • Il est petit et n’a aucune dépendance
  • Description révisée (avec listes et mise en gras)
    • Nano Stores présente les caractéristiques suivantes :
      • Petite taille : 286 à 818 octets (minified et brotlied)
      • Prise en charge de nombreux frameworks : React, Vue, Svelte, Angular, etc.
      • Aucune dépendance
  • Points clés pour améliorer la lisibilité

    • Utiliser des listes : elles structurent l’information et permettent une compréhension immédiate
    • Utiliser le gras : il met les informations essentielles en avant et les rend immédiatement perceptibles
    • Faire des phrases concises : garder uniquement les informations importantes et supprimer le superflu
      • Même en réduisant le texte, le message doit rester clair

5. Utiliser des exemples de code et des images

  • Les concepts complexes peuvent être expliqués facilement grâce à du code d’exemple ou des images
    • Comme le dit l’expression, « une image vaut mieux que cent mots » : les supports visuels sont de puissants outils de compréhension

6. Utiliser des statistiques réelles

  • Les formulations vagues ou les promesses abstraites inspirent difficilement confiance
    • Il faut présenter des statistiques concrètes sur les performances réelles, la taille, la vitesse, etc.
  • Exemple : utilisation de statistiques réelles pour Nano ID

    • Preuve de taille : Nano ID est petit, avec 141 octets → une donnée chiffrée claire
    • Preuve de vitesse : Nano ID est 16 % plus rapide que UUID → résultat de benchmark à l’appui
  • Conseils pour utiliser efficacement les statistiques
    • Fournir des données de performance quantifiées → cela renforce la crédibilité
    • Indiquer les résultats de benchmark → cela souligne la différenciation vis-à-vis des autres produits
    • Présenter clairement les performances de l’API ou son utilisation avec des exemples réels
      • Les performances, la taille, la vitesse, etc. doivent être prouvées par des chiffres et des données concrètes

7. Fournir un guide de démarrage étape par étape

  • Une fois les avantages du projet clairement présentés, l’étape suivante consiste à fournir une méthode d’utilisation concrète
  • Si l’utilisateur s’intéresse au projet après avoir lu le README, la suite doit venir naturellement
  • Conseils pour rédiger un guide de démarrage efficace

    • Fournir un guide détaillé, étape par étape
      • Au lieu d’une explication vague comme « utilisez PostCSS », présentez des étapes claires et concrètes
      • Indiquez les commandes et la méthode de configuration nécessaires à chaque étape
    • Proposer des chemins alternatifs
      • Présentez différentes approches selon la situation de l’utilisateur
      • Exemple : ajouter une méthode à suivre si PostCSS n’est pas installé
    • Créer des sections selon le type d’utilisateur
      • Proposez des guides adaptés, par exemple, aux utilisateurs de grandes bibliothèques comme à ceux de petites bibliothèques
  • Tester est indispensable

    • Il faut suivre soi-même le guide rédigé afin de vérifier qu’il fonctionne réellement
      • Si possible, oubliez vos connaissances préalables sur le projet et refaites tout depuis le début
      • En cas de problème, corrigez et complétez immédiatement

Stratégie efficace de promotion d’un projet open source

1. L’importance de la promotion répétée

  • Beaucoup de gens commettent l’erreur suivante
    1. publier une seule fois sur les réseaux sociaux
    2. ne voir aucune réaction
    3. se décourager
    4. abandonner le projet
  • Une seule grande opération de promotion n’est pas efficace → il faut une promotion progressive et répétée
  • Cycle de promotion répétée efficace
    1. créer du contenu : nouvelle fonctionnalité, billet de blog, publication sur les réseaux sociaux, etc.
    2. recueillir les retours des utilisateurs
    3. modifier le projet à partir de ces retours
    4. créer un nouveau contenu à propos des changements → puis recommencer
  • Au début, avoir peu d’utilisateurs est même un avantage → cela permet d’ajuster sans stress
  • Une amélioration continue et une promotion répétée font monter la notoriété

2. Stratégie efficace de promotion sur les réseaux sociaux

  • Ne vous contentez pas de partager un lien ou une courte description
  • Incluez systématiquement ces deux éléments
    • Un exemple de code ou une image → cela aide les gens à comprendre facilement
    • Une description claire du projet → même les nouveaux utilisateurs peuvent comprendre
  • Exemple de modèle de publication promotionnelle

    • annonce d’une nouvelle fonctionnalité → explication claire → ajout d’un exemple de code → partage sur les réseaux sociaux
    • publication sur le subreddit concerné sur Reddit (en vérifiant les règles de chaque subreddit)
    • publication sur Hacker News → permet d’obtenir une traction initiale
    • rédaction d’articles sur Dev.to, Smashing Magazine, CSS-Tricks, etc. → élargir la visibilité

3. Stratégie de promotion via les PR

  • Soumettre des PR à d’autres projets pour y introduire son propre outil open source
    • Exemple : PostCSS a réussi sa promotion grâce à des PR vers d’autres projets
    • « Si vous avez besoin d’aide, je peux essayer d’appliquer cet outil. »
  • Si la PR est acceptée, indiquez ce cas d’usage dans le README → cela renforce la crédibilité
  • Mentionner que son outil est utilisé dans des projets populaires renforce encore la confiance

4. Répétez, mais sans spammer

  • Une promotion répétée reste nécessaire
  • Mais le spam est absolument à proscrire
    • Ne répétez pas le même message ; apportez une nouvelle valeur
    • Il faut inclure des changements et des améliorations concrètes
  • Tous les utilisateurs ne voient pas tous les messages → il faut donc répéter régulièrement la promotion sous différentes formes

Pourquoi répéter la promotion

  • Les gens ne choisissent pas leurs outils de façon rationnelle
  • La répétition de la promotion construit naturellement la notoriété
  • Il faut accumuler cette notoriété sur la durée pour augmenter les chances de succès

Bonus

1. Comment gérer les problèmes quand le projet devient célèbre

  • Quand un projet devient populaire, le nombre d’issues à traiter peut exploser
  • Si vous essayez de tout résoudre vous-même, la charge devient lourde et peut entraîner du découragement ainsi qu’une baisse de productivité
  • Solutions

    • N’essayez pas de tout résoudre vous-même → encouragez les utilisateurs à rédiger des PR
    • Demandez : « Si vous voulez résoudre ce problème, pouvez-vous envoyer une PR ? »
    • Définissez un temps dédié au traitement des problèmes (par exemple 15 minutes par jour) et limitez-vous à ce créneau
    • Pour les problèmes difficiles, ne cherchez pas à les régler immédiatement ; répondez plutôt « j’examine les solutions possibles » → le simple fait de savoir que le problème est pris en compte rassure déjà les utilisateurs
    • Vous pouvez aussi confier les corrections de documentation aux utilisateurs → demandez : « Pouvez-vous corriger cette partie ? »

2. Comment réagir aux retours négatifs

  • Les retours négatifs peuvent faire baisser la motivation
  • Au début du projet, ils peuvent casser l’élan ; quand le projet devient populaire, ils peuvent aussi fragiliser la confiance en soi
  • Stratégie de réponse

    • Ne réagissez pas de façon émotionnelle
    • Répondez à la critique par une question → « Pourquoi pensez-vous que B est meilleur que A ? »
    • La critique n’est souvent qu’une expression émotionnelle → essayez de dialoguer avec l’utilisateur pour construire une relation de confiance
    • La critique peut aussi devenir une occasion d’amélioration

3. Comment réagir à l’apparition d’un projet concurrent

  • Il n’y a pas lieu de s’inquiéter si un projet concurrent apparaît
  • L’arrivée d’un concurrent peut même avoir les avantages suivants
    • vous libérer de la charge de maintenance du projet
    • faire émerger de meilleures solutions grâce à la concurrence → au final, les utilisateurs y gagnent aussi
  • Le but ultime de l’open source est de changer le monde, pas de monopoliser ou de dominer
  • Apparition d’un projet concurrent → naissance d’un meilleur outil → situation gagnant-gagnant

Résumé final

Comment créer un projet open source populaire et gagner en visibilité

  1. La meilleure raison de créer de l’open source n’est ni la célébrité ni l’amélioration du CV, mais de changer le monde
  2. Une bonne idée ne devient pas forcément un projet populaire
  3. La formule de popularité d’un projet open source = popularité + promotion + bénéfice utilisateur + chance
  4. Les comptes sur les réseaux sociaux doivent être actifs, faciles à trouver, et rédigés dans une langue largement utilisée comme l’anglais

Comment rédiger une documentation efficace

  1. Le README et la documentation doivent être rédigés clairement et naturellement, comme si vous expliquiez le projet à un ami
  2. Utilisez du texte mis en avant, des listes et une structure claire pour transmettre progressivement les informations complexes
  3. Il faut fournir des preuves concrètes comme de vrais benchmarks et des exemples de code
  4. Si possible, proposez des guides de démarrage concrets adaptés aux débutants comme aux utilisateurs avancés

Stratégie de promotion

  1. Une promotion répétée est plus efficace qu’une seule grande campagne → lancement → retours → amélioration → répétition
  2. Publiez régulièrement, mais évitez le spam
  3. Créez des publications incluant des exemples de code et des images
  4. Soumettez des PR à d’autres projets pour maximiser l’effet de promotion

Conseils quand le projet devient célèbre

  1. N’essayez pas de résoudre tous les problèmes seul ; incitez les utilisateurs à soumettre des PR
  2. Réservez un créneau de temps fixe pour gérer les problèmes (par exemple 15 minutes par jour)
  3. En cas de retours négatifs, essayez d’ouvrir le dialogue par des questions
  4. N’ayez pas peur des projets concurrents → la concurrence peut au contraire vous libérer d’une partie des responsabilités

1 commentaires

 
roxie 2025-03-28

Il semble également important de trouver des endroits où une promotion au contenu légèrement différent, mais répétitif vue de loin, est tolérée. Par exemple, Twitter.