Conseils pour créer un projet open source populaire
(skerritt.blog)<p>"Effet de réseau : plus les gens viennent le chercher, plus il y a d’utilisateurs, plus ils participent, plus les fonctionnalités s’améliorent, et plus il devient connu"<br />
Comment faire pour gagner en popularité ?<br />
<br />
#1. Un README bien conçu <br />
- L’expliquer de façon concise dès le début <br />
→ À quoi ça sert ?<br />
→ Est-ce que ça résout mon problème ?<br />
→ Est-ce que ça résout mon problème mieux que les concurrents ?<br />
→ Comment l’installer ?<br />
→ Quelles sont les commandes de base à connaître ?<br />
→ Où aller pour obtenir de l’aide ?<br />
<br />
1.1 Créer un en-tête qui résume le projet <br />
→ Logo : créer un logo GIF avec un outil comme Canva <br />
→ Slogan : décrire le projet en une seule ligne. À utiliser dans la description GitHub<br />
⇨ Il doit sauter aux yeux<br />
⇨ Pourquoi l’utilisateur en a besoin <br />
⇨ Pourquoi c’est mieux que les autres <br />
⇨ Facile à comprendre <br />
⇨ Ex.) hugo : The world’s fastest framework for building websites<br />
→ Badges : petits éléments visuels/liens pour présenter le projet <br />
⇨ activité récente, nombre de téléchargements, nombre de personnes sur le chat, versions prises en charge, licence, etc. <br />
→ Installation rapide : afficher immédiatement les commandes pour une installation simple et rapide<br />
⇨ Pour que ceux qui connaissent déjà le projet puissent l’essayer vite <br />
⇨ Mettre très tôt en avant des choses comme l’installation en une ligne via Docker/PIP <br />
⇨ docker run -it --rm remnux/ciphey<br />
→ Liens rapides (optionnel)<br />
⇨ site web, forum, documentation, guide d’installation, guide de contribution, Twitter, etc.<br />
<br />
1.2 Expliquer brièvement le projet dans « What is This? » <br />
→ Une courte description + un GIF montrant le fonctionnement du projet + les fonctionnalités essentielles que les gens voudront voir <br />
→ Ex.) Starship : deux colonnes avec, à gauche, les fonctionnalités essentielles, et à droite, un GIF de démonstration <br />
→ Pas besoin de montrer toutes les fonctionnalités. Ne lister que celles que les utilisateurs veulent voir et les expliquer clairement <br />
<br />
1.3 Comparer avec les concurrents dans « X vs Y » <br />
→ Il faut montrer pourquoi choisir ce projet plutôt que les concurrents <br />
→ Faire en sorte que les avantages soient visibles d’un coup d’œil<br />
→ C’est comme en lean startup, où il faut d’abord trouver des « early adopters » plutôt que des « utilisateurs moyens » <br />
⇨ des personnes qui, si vous avez de meilleures fonctionnalités, n’hésiteront pas à changer d’outil <br />
→ Ne viser les « utilisateurs moyens » que s’il n’existe aucun concurrent, ou si les solutions actuelles sont extrêmement complexes par rapport à la vôtre <br />
→ Le plus simple est de créer un tableau comparatif des fonctionnalités principales<br />
⇨ Mieux vaut l’exprimer en chiffres qu’en mots <br />
⇨ Il est aussi utile de comparer le fonctionnement avec des GIF <br />
<br />
1.4 Créer une excellente documentation <br />
→ Il n’est pas nécessaire de mettre toute la documentation dans le README. Cela complique les mises à jour, la recherche, et rend le README plus difficile à lire <br />
→ Comme la méthode d’installation a déjà été indiquée plus haut, ce qu’il faut montrer en plus est : <br />
⇨ comment l’exécuter<br />
⇨ où trouver la documentation<br />
⇨ comment obtenir du support <br />
→ Montrer l’exécution avec un GIF est aussi une bonne idée <br />
<br />
1.5 Expliquer comment contribuer, remercier et accueillir les contributeurs <br />
→ Comment contribuer au projet<br />
→ Remercier les anciens contributeurs <br />
→ Utiliser un bot comme all-contributors <br />
<br />
#2. Construire ce que les gens veulent <br />
→ Un bon README attire l’attention, mais un projet qui « résout un problème » fait parler de lui <br />
<br />
2.1 Le problème d’abord, le produit ensuite<br />
→ Ne cherchez pas à créer un produit pour lui-même, résolvez un problème <br />
→ "Le progrès ne vient pas seulement de grands bonds, mais aussi de centaines de petites étapes"<br />
<br />
2.2 Vivre avec le problème <br />
→ Sans problème concret, on ne peut pas le résoudre efficacement <br />
→ Il est bien plus facile d’observer les problèmes présents dans sa propre vie que de générer des idées au hasard <br />
→ Quand on réalise qu’il y a un problème, on apprend deux choses : qu’il est réel, et que d’autres personnes l’ont aussi.<br />
<br />
2.3 Trouver des problèmes dans la communauté <br />
→ En observant une communauté, on voit souvent les gens exposer les problèmes qu’on leur a laissés <br />
→ Plus il y a de monde, et plus on écoute, plus on peut faire émerger d’idées qu’en réfléchissant seul <br />
→ Essayez de créer un MVP (Minimum Viable Product) qui résout un problème de la communauté <br />
→ Partagez-le avec la communauté, mesurez son impact, apprenez à l’améliorer, puis refaites, ajoutez et améliorez encore <br />
<br />
#3. Le faire savoir <br />
→ Même bien fait, si vous ne le rendez pas public, personne ne le verra <br />
→ Si vous avez utilisé une communauté plus haut, bonne nouvelle : elle le connaîtra déjà et l’utilisera <br />
→ Faire passer un GitHub Star de 0 à 1 est difficile, mais de 10 à 100 est plus facile <br />
<br />
3.1 Le partager avec la communauté <br />
→ Boucle Build, Measure, Learn <br />
→ Lors de la première vraie release, assurez-vous que la communauté soit au courant. Elle le partagera avec ses amis<br />
<br />
3.2 Agrégateurs d’actualités <br />
→ Le Subreddit visé <br />
→ HackerNews (note du traducteur d’origine : GeekNews aussi !)<br />
→ Lobste.rs <br />
<br />
3.3 Awesome List <br />
→ Trouver une liste liée au sujet et envoyer une PR </p>
2 commentaires