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