Consejos para crear un proyecto open source popular
(skerritt.blog)"Efecto de red: mientras más gente lo busca, más usuarios tiene, más participación recibe, sus funciones mejoran y se vuelve aún más conocido"
¿Cómo hacer para volverse popular?
#1. Un README bien diseñado
- Explica de forma concisa al principio
→ ¿Qué hace?
→ ¿Resuelve mi problema?
→ ¿Resuelve mi problema mejor que la competencia?
→ ¿Cómo lo instalo?
→ ¿Cuáles son los comandos básicos que debo conocer?
→ ¿A dónde voy si necesito ayuda?
1.1 Crear un encabezado que resuma el proyecto
→ Logo: crea un logo GIF en algo como Canva
→ Eslogan: describe el proyecto en una sola línea. Aplícalo en la descripción de GitHub
⇨ Que llame la atención de inmediato
⇨ Por qué el usuario necesita esto
⇨ Por qué esto es mejor que otras opciones
⇨ Que sea fácil de entender
⇨ Ej) hugo: The world’s fastest framework for building websites
→ Badges: pequeñas imágenes/enlaces que describen el proyecto
⇨ cantidad de actividad reciente, número de descargas, cuánta gente hay en el chat, versiones en uso, licencia, etc.
→ Instalación rápida: muestra de inmediato comandos de instalación fáciles y rápidos
⇨ Para que quienes ya llegan con contexto puedan probarlo rápido
⇨ Muestra lo antes posible cosas como que se puede instalar con una sola línea en Docker/PIP
⇨ docker run -it --rm remnux/ciphey
→ Enlaces rápidos (no obligatorios)
⇨ sitio web, foro, documentación, guía de instalación, guía de contribución, Twitter, etc.
1.2 Explicar de forma breve el proyecto en "What is This?"
→ una descripción corta + un GIF mostrando cómo funciona el proyecto + las funciones esenciales que la gente querrá ver
→ Ej) Starship: dos columnas, con las funciones esenciales a la izquierda y un GIF de funcionamiento a la derecha
→ No hace falta mostrar todas las funciones. Enumera solo lo que los usuarios querrán ver y explícalo de forma fácil de entender
1.3 Compararlo con la competencia en "X vs Y"
→ Debes mostrar por qué alguien debería elegir este proyecto en lugar de la competencia
→ Haz que sus ventajas se vean fácilmente
→ Es igual que en lean startup, donde primero hay que encontrar a los "early adopters" antes que al "usuario promedio"
⇨ si tienes mejores funciones, personas que no temen cambiarse a una herramienta nueva
→ Solo tiene sentido apuntar al "usuario promedio" cuando no hay competencia o cuando las soluciones actuales son muchísimo más complejas que la tuya
→ La forma más fácil es hacer una tabla comparativa de funciones principales
⇨ Muéstralo con números en vez de palabras
⇨ También es buena idea comparar el funcionamiento con GIFs
1.4 Crear una documentación excelente
→ No hace falta poner toda la documentación en el README. Es difícil de actualizar y de buscar, y hace que el README sea más difícil de leer
→ Como arriba ya se explicó la instalación, lo adicional que conviene mostrar es
⇨ cómo ejecutarlo
⇨ dónde encontrar la documentación
⇨ cómo obtener soporte
→ También es buena idea mostrar cómo se usa con un GIF
1.5 Explicar cómo contribuir, agradecer y dar la bienvenida a quienes contribuyen
→ cómo contribuir al proyecto
→ agradecer a quienes contribuyeron antes
→ usar bots como all-contributors
#2. Crear lo que la gente quiere
→ Un buen README atrae la atención de la gente, y un proyecto que "resuelve su problema" hace que la gente hable de él
2.1 Primero el problema, después el producto
→ No construyas algo para hacer un producto, sino para resolver un problema
→ "El progreso no solo viene de grandes saltos, también de cientos de pequeños pasos"
2.2 Vivir con el problema
→ Si no hay problema, no puedes resolverlo de forma efectiva
→ En vez de generar ideas al azar, es mucho más fácil observar los problemas que existen en tu propia vida
→ Cuando descubres que hay un problema, entiendes dos cosas: que el problema es real y que otras personas también lo tienen.
2.3 Encontrar problemas en la comunidad
→ Si observas la comunidad, la gente a veces expone los problemas que tiene
→ Mientras más personas haya y más escuches, más ideas podrás generar que si solo piensas por tu cuenta
→ Intenta crear un MVP (Minimum Viable Product) que resuelva un problema de la comunidad
→ Compártelo con la comunidad, mide el efecto, aprende a mejorarlo y vuelve a crearlo o añadirle cosas para seguir mejorándolo
#3. Darlo a conocer
→ Aunque esté bien hecho, si no lo publicas nadie lo verá
→ Si antes usaste una comunidad, por suerte ellos ya lo conocerán y lo usarán
→ Es difícil que un GitHub Star pase de 0 a 1, pero de 10 a 100 es más fácil
3.1 Compartirlo con la comunidad
→ ciclo Build, Measure, Learn
→ En el primer lanzamiento real, asegúrate de que la comunidad se entere. Ellos lo compartirán con sus amigos
3.2 News Aggregators
→ el Subreddit que quieras
→ HackerNews
→ Lobste.rs
3.3 Awesome List
→ busca listas relacionadas con el tema y envía un PR
2 comentarios
La historia de cómo reuní 500 estrellas en GitHub en un solo día
https://black7375.tumblr.com/post/653140399088631808/
Es un artículo que escribí hace tiempo.
Lo redacté centrándome en la estrategia de promoción.
Ahí dejé escrito cómo publiqué el post de promoción, el momento en que lo hice, y también el método con el que definí la dirección de desarrollo y los plazos de cierre.
Aunque suene obvio... el README de un proyecto open source es realmente importante.
Incluso si es un proyecto que resuelve un problema que nadie puede resolver o del que nadie se ocupa, o que tiene funciones increíbles que superan a la competencia, el resultado puede cambiar según cómo esté escrito el README.
Ojalá haya cada vez más proyectos open source que se den a conocer no solo dentro del país, sino también en el extranjero.
También vale la pena revisar el GitHub About y el README de proyectos open source creados por los desarrolladores coreanos más reconocidos en estos días.
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.