Conseils pour créer un projet open source populaire
(skerritt.blog)"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"
Comment faire pour gagner en popularité ?
#1. Un README bien conçu
- L’expliquer de façon concise dès le début
→ À quoi ça sert ?
→ Est-ce que ça résout mon problème ?
→ Est-ce que ça résout mon problème mieux que les concurrents ?
→ Comment l’installer ?
→ Quelles sont les commandes de base à connaître ?
→ Où aller pour obtenir de l’aide ?
1.1 Créer un en-tête qui résume le projet
→ Logo : créer un logo GIF avec un outil comme Canva
→ Slogan : décrire le projet en une seule ligne. À utiliser dans la description GitHub
⇨ Il doit sauter aux yeux
⇨ Pourquoi l’utilisateur en a besoin
⇨ Pourquoi c’est mieux que les autres
⇨ Facile à comprendre
⇨ Ex.) hugo : The world’s fastest framework for building websites
→ Badges : petits éléments visuels/liens pour présenter le projet
⇨ activité récente, nombre de téléchargements, nombre de personnes sur le chat, versions prises en charge, licence, etc.
→ Installation rapide : afficher immédiatement les commandes pour une installation simple et rapide
⇨ Pour que ceux qui connaissent déjà le projet puissent l’essayer vite
⇨ Mettre très tôt en avant des choses comme l’installation en une ligne via Docker/PIP
⇨ docker run -it --rm remnux/ciphey
→ Liens rapides (optionnel)
⇨ site web, forum, documentation, guide d’installation, guide de contribution, Twitter, etc.
1.2 Expliquer brièvement le projet dans « What is This? »
→ Une courte description + un GIF montrant le fonctionnement du projet + les fonctionnalités essentielles que les gens voudront voir
→ Ex.) Starship : deux colonnes avec, à gauche, les fonctionnalités essentielles, et à droite, un GIF de démonstration
→ Pas besoin de montrer toutes les fonctionnalités. Ne lister que celles que les utilisateurs veulent voir et les expliquer clairement
1.3 Comparer avec les concurrents dans « X vs Y »
→ Il faut montrer pourquoi choisir ce projet plutôt que les concurrents
→ Faire en sorte que les avantages soient visibles d’un coup d’œil
→ C’est comme en lean startup, où il faut d’abord trouver des « early adopters » plutôt que des « utilisateurs moyens »
⇨ des personnes qui, si vous avez de meilleures fonctionnalités, n’hésiteront pas à changer d’outil
→ 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
→ Le plus simple est de créer un tableau comparatif des fonctionnalités principales
⇨ Mieux vaut l’exprimer en chiffres qu’en mots
⇨ Il est aussi utile de comparer le fonctionnement avec des GIF
1.4 Créer une excellente documentation
→ 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
→ Comme la méthode d’installation a déjà été indiquée plus haut, ce qu’il faut montrer en plus est :
⇨ comment l’exécuter
⇨ où trouver la documentation
⇨ comment obtenir du support
→ Montrer l’exécution avec un GIF est aussi une bonne idée
1.5 Expliquer comment contribuer, remercier et accueillir les contributeurs
→ Comment contribuer au projet
→ Remercier les anciens contributeurs
→ Utiliser un bot comme all-contributors
#2. Construire ce que les gens veulent
→ Un bon README attire l’attention, mais un projet qui « résout un problème » fait parler de lui
2.1 Le problème d’abord, le produit ensuite
→ Ne cherchez pas à créer un produit pour lui-même, résolvez un problème
→ "Le progrès ne vient pas seulement de grands bonds, mais aussi de centaines de petites étapes"
2.2 Vivre avec le problème
→ Sans problème concret, on ne peut pas le résoudre efficacement
→ 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
→ 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.
2.3 Trouver des problèmes dans la communauté
→ En observant une communauté, on voit souvent les gens exposer les problèmes qu’on leur a laissés
→ Plus il y a de monde, et plus on écoute, plus on peut faire émerger d’idées qu’en réfléchissant seul
→ Essayez de créer un MVP (Minimum Viable Product) qui résout un problème de la communauté
→ Partagez-le avec la communauté, mesurez son impact, apprenez à l’améliorer, puis refaites, ajoutez et améliorez encore
#3. Le faire savoir
→ Même bien fait, si vous ne le rendez pas public, personne ne le verra
→ Si vous avez utilisé une communauté plus haut, bonne nouvelle : elle le connaîtra déjà et l’utilisera
→ Faire passer un GitHub Star de 0 à 1 est difficile, mais de 10 à 100 est plus facile
3.1 Le partager avec la communauté
→ Boucle Build, Measure, Learn
→ Lors de la première vraie release, assurez-vous que la communauté soit au courant. Elle le partagera avec ses amis
3.2 Agrégateurs d’actualités
→ Le Subreddit visé
→ HackerNews (note du traducteur d’origine : GeekNews aussi !)
→ Lobste.rs
3.3 Awesome List
→ Trouver une liste liée au sujet et envoyer une PR
2 commentaires
L’histoire de la fois où j’ai obtenu 500 étoiles GitHub en une journée
https://black7375.tumblr.com/post/653140399088631808/
C’est un article que j’ai écrit il y a quelque temps.
Je l’avais rédigé en mettant l’accent sur la stratégie de promotion.
J’y ai expliqué la manière et le moment de publier un billet promotionnel, ainsi que la façon dont j’ai défini l’orientation du développement et les échéances.
Cela va sans dire, mais le README d’un projet open source est vraiment important.
Même s’il s’agit d’un projet qui résout un problème que personne ne parvient à résoudre ou auquel personne ne s’attaque, ou qui offre des fonctionnalités étonnantes surpassant la concurrence, le résultat peut varier selon la manière dont cela est présenté dans le README.
J’aimerais qu’il y ait davantage de projets open source qui se fassent connaître non seulement en Corée, mais aussi à l’international.
N’hésitez pas à consulter aussi le GitHub About et le README d’open source créés par les développeurs coréens les plus connus du moment.
swc : "Make the web (development) faster." swc is a super-fast compiler written in rust; producing widely-supported javascript from modern standards and typescript.
fzf : fzf is a general-purpose command-line fuzzy finder.