Comment rendre votre open source célèbre
(evilmartians.com)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
- Une explication claire
- Une indication claire de l’aide apportée à l’utilisateur
- 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
- Nano Stores présente les caractéristiques suivantes :
-
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
- Fournir un guide détaillé, étape par étape
-
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
- Il faut suivre soi-même le guide rédigé afin de vérifier qu’il fonctionne réellement
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
- publier une seule fois sur les réseaux sociaux
- ne voir aucune réaction
- se décourager
- 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
- créer du contenu : nouvelle fonctionnalité, billet de blog, publication sur les réseaux sociaux, etc.
- recueillir les retours des utilisateurs
- modifier le projet à partir de ces retours
- 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é
- 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
- Une bonne idée ne devient pas forcément un projet populaire
- La formule de popularité d’un projet open source = popularité + promotion + bénéfice utilisateur + chance
- 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
- Le README et la documentation doivent être rédigés clairement et naturellement, comme si vous expliquiez le projet à un ami
- Utilisez du texte mis en avant, des listes et une structure claire pour transmettre progressivement les informations complexes
- Il faut fournir des preuves concrètes comme de vrais benchmarks et des exemples de code
- Si possible, proposez des guides de démarrage concrets adaptés aux débutants comme aux utilisateurs avancés
Stratégie de promotion
- Une promotion répétée est plus efficace qu’une seule grande campagne → lancement → retours → amélioration → répétition
- Publiez régulièrement, mais évitez le spam
- Créez des publications incluant des exemples de code et des images
- Soumettez des PR à d’autres projets pour maximiser l’effet de promotion
Conseils quand le projet devient célèbre
- N’essayez pas de résoudre tous les problèmes seul ; incitez les utilisateurs à soumettre des PR
- Réservez un créneau de temps fixe pour gérer les problèmes (par exemple 15 minutes par jour)
- En cas de retours négatifs, essayez d’ouvrir le dialogue par des questions
- N’ayez pas peur des projets concurrents → la concurrence peut au contraire vous libérer d’une partie des responsabilités
1 commentaires
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.