¿Cómo hacer un proyecto Opensource de éxito?

Realizar un proyecto Opensource no es picar código y subirlo a un repositorio, a eso se le llama copia de seguridad. Si ya es complejo realizar software, solo o en compañía, añade a la formular montar un proyecto que debe ser fácil de ampliar o mantener por desconocidos. Ello no implica que desaparezcas de la formula, tan solo debes superar tu miedo escénico para abrir el código a la crítica de la comunidad. A la vez que cuidas aspectos tan obvios como la documentación, su difusión, experiencia, usos… Una manera fantástica para salir de la zona de confort y ser un desarrollador completo.

Me considero un aportador de código libre con algunos logros destacables. He tenido la fortuna de colaborar con todo tipo de proyectos: grandes, pequeños y propios. Pero como puedes suponer los realizados con mis propias manos son los que más me ha calentado el corazón. Por ejempo Maza ad bloquer (un bloqueador de publicidad de alto rendimiento) que vivió primeros puestos en Hacker News y Reddit. Con sus respectivas sorpresas al encontralo en Newsletters o blogs que estoy suscrito. Es una de las recompensas que te puedes encontrar.

En esta ocasión quería compartir el conocimiento, o secretos, que he ido acumulando con los años para conseguir un proyecto Opensource redondo. Patrones que han resultado funcionar después de muchas pruebas. Desde la concepción hasta el mantenimiento, básicamente un camino para mimar un proyecto con reconocimiento, visibilidad y futura ayuda. No te puedo asegurar que la idea sea tan buena que se construyan pirámides en nombre del software, pero si que puedo enseñarte cual es la mejor forma de allanar el terreno.

1. Estudio de mercado

Antes de crear el repositorio deberías hacerte las siguientes preguntas:

¿Existe un proyecto similar?

Casi es una lotería disponer de una idea virgen que nadie ha intentado sacar adelante. El primer paso es tomar tiempo para rastrear en la red. Si encuentras que ya existe, y es Opensource, estas en un compromiso. Colaborar puede enriquecer el proyecto, ayudarte a acelerar tus objetivos, además de conocer a un grupo de desarrolladores que te impulsarán de diferentes formas. La unión hace la fuerza. En caso de que decidas aún así continuar por tu cuenta se crítico contigo mismo porque puede estar tomando el control el ego o las ganas de protagonismo.

No existe nada en internet, ¿Por qué? ¿Qué ha podido ocurrir?

En este caso hay que encontrar proyectos abandonados y seguir la pista con el sombrero de investigador. Tal vez existe una limitación técnica que no conoces, o el trabajo es tan enorme que es difícil lograrlo en solitario.

¿Es útil? ¿Merece la pena el esfuerzo? Puede ser que cuando se termine no interese a nadie, ten cuidad, o porque es una necesidad ínfima que solo lo usarían 2 personas en todo el globo, o porque hay sustitutos que no son perfectos pero funcionan. Hay que meterse en la piel de tu publico objetivo, ¿lo usaría si fuera uno de ellos? Pregunta a tus amigos.

2. Boceto

Es la hora de hacer un Wireframe, o un esqueleto visual, de como se estructurará el software. Ver cada pantalla con todas sus funcionalidades, con sus formularios y botones definitivos. De esta manera podrás pensar como un usuario y no como un programador, viendo con mas nitidez su estructura. Cualquier persona puede hacer más compleja una interfaz, pero muy pocos son capaces de simplificar. Además, nacerán características no previstas pero que serán esenciales para su uso diario.

Un folio en blanco es suficiente. También existen herramientas de diseño de UI como Figma, Adobe XD, Sketch… con el fin de bocetar. No te distraerán con temas técnicos para poder focalizar tu concentración en volcar tus ideas.

3. Objetivos cerrados

Con el boceto en una mano toca listar todas las características que quieras alcanzar y su prioridad en el desarrollo. Si puede ser empieza por las que menos te apetezcan, así no las irás postergando.

Cuando estén definidas crea un acuerdo contigo mismo donde te prometas que no vas a añadir ni a quitar nada, a no ser que sea estrictamente necesario. No habrá pereza ni dejadez por tu parte que borre ni una sola línea de la lista, su implementación será inevitable.

Antes de firmarlo añade al principio de la lista: testing y CI/CD.

4. Producción ejemplar

Cuando una persona programa sola suele caer en vicios: no comentar, simplificar el nombre de las variables, buscar un código corto a uno más explicativo, dejar líneas de código comentadas para el “futuro”, etc. Ahora piensa que cada línea que hagas será vista por miles de desarrolladores mucho más experimentados que tú, y que si hay una chapuza en algún rincón tu imagen quedará por siempre. ¿Notas la tensión? ¿Los dedos se tambalean como gelatina? Eso es bueno, vive el momento. Programa con una calidad que te represente, que al mirar el código sientas orgullo. Si es posible imprime en una hoja los primeros 10 principios del Zen Python y cuélgalo en la pared más cercana:

• Bello es mejor que feo.
• Explícito es mejor que implícito.
• Simple es mejor que complejo.
• Complejo es mejor que complicado.
• Plano es mejor que anidado.
• Espaciado es mejor que denso.
• La legibilidad es importante.
• Los casos especiales no son lo suficientemente especiales como para romper las reglas.
• Sin embargo la practicidad le gana a la pureza.
• Los errores nunca deberían pasar silenciosamente.

Por otro lado no olvides que tu código debe poseer el super poder de ampliarse, capacidad de absorver más características en el futuro y de manera sencilla. Eso implica independizar la interfaz, no casarte con una base de datos, secciones reutilizables… ¿Pero como lo hago? Te sorprendería cuantas décadas hace que este problema se ha resulto de una manera elegante. Tal vez un buen comienzo es una arquitectura de puertos y adaptadores (arquitectura hexagonal). Busca ejemplos en el lenguaje que uses, y revisa sus principios en la documentación de Microsoft.

5. Presentación

Esta es la etapa donde caen muy buenos proyecto los cuales nunca llegaron a florecer. Puedes pasar de que tu repositorio sea un incomprendido, como muchos otros, a una herramienta que se quiera utilizar a diario. Hay un gran trabajo literario que muchos evitan erróneamente por vagos. Y no, no hablo solo de la documentación.

Debes explicar con palabras sencillas, y comprensibles para un junior, que hace el software y porqué es útil. Venderlo, pero no como un charlatán sino como un profesor en un colegio lleno de niños. Ello implica crear diagramas, algún boceto, descripciones cortas pero claras, situaciones reales donde se pueda utilizar, etc. Piensa que puede ser leído por una persona que no domine ciertos tecnicismos pero que es administrador de un grupo importante en la red.

Otro punto que mejora la comprensión es crear una Demo del producto o un ejemplo que los usuarios puedan ver en funcionamiento. Si estas pensando “no hace falta porque en el README esta claro como instalar y arrancar”… te hago un spoiler: nadie lo va a hacer. Dispones de unos segundos para que un visitante entre en el sitio, haga un vistazo rápido, tal vez pulse en la Demo y evalué en el mismo tiempo del aletear de una libélula si es interesante. La competencia es demoledora, y debes ser el mejor.

Los usuarios necesitarán un lugar donde puedan transmitirte los errores, una zona de tickets o comunicación. Github, Gitlab, Bitbucket y casi cualquier repositorio web moderno ofrece algún sistema de Issues. Si no te gustan puedes usar externos, pero sea cual es tu elección debes dejar claro como pueden llegar. Y si puedes dejar un botón dentro del software también sería recomendable.

Estamos construyendo un proyecto Opensource, esperamos Pull requests. Como eres el dictador benevolente en tu mano esta llevar la dirección del proyecto, por ello debes dejar por escrito cuales son los objetivos para el futuro. Así evitarás situaciones incómodas, como denegar aportaciones o forks innecesarios.

Todo puede estar en un solo documento, como un README, pero te recomiendo una página web con un dominio único. De esta manera darán una presencia más profesional, será más sencillo encontrarlo a través de los buscadores, podrás crear un sistema multilenguaje y estará todo más ordenado.

Recuerda:

• Página web.
• Tutoriales.
• Explicación de como realizar un Pull request.
• Donde ofreces soporte.
• Dejar claro objetivos futuros.
• Ejemplos de uso.
• Diagramas del funcionamiento.
• Documentación.
• Demo en vivo.

Puede que tardes semanas en lograrlo, se paciente. Cada segundo que dediques en este apartado será recompensado en menos preguntas y mayor difusión.

6. Difusión

Es el momento de realizar la campaña publicitaria gratuita, que el mundo conozca nuestro trabajo de arriba a abajo. Lamentablemente no hay un botón que automatice esta tarea, debemos buscar donde se esconden los usuarios potenciales. Y una vez los tengamos en la mirilla, respetuosamente invitarles a que visiten el sitio.

Algunos lugares por donde empezar.

• Hacker News: el portal por excelencia que todo desarrollador debería leer por la mañanas al desayunar. Filtra las noticias o anuncios más importantes. Su algoritmo ofrece noticias frescas cada día.
• Reddit: no necesita presentación. Tal vez sea la red social más grande y abierta.
• Twitter: es un buen lugar para hacer referencia a cuentas que hagan tuits respecto al tema para que puedan retwittear.
• Canales IRC: Sí, aún existen. Los viejos lobos siguen utilizando esta comunicación tan retro pero a su vez tan rápida y eficaz.
• Slack: Esta de moda que los desarrolladores usen este chat de comunicación para equipos con objetivo de gestionar comunidades.
• Repositorios Awesome: Por toda la red existen listados que recopilan otros repositorios categorizándolos. Estar dentro es como tener un anuncio gratis.
• Blogs: Si puedes encontrar blogs especializados puede ser una gran idea pedirle al autor que revise el proyecto. Puede incluso que te haga una referencia en algún artículo o que incluso te lo dedique. Ni se te ocurra dejar un comentario, envía un mensaje directo.
• Newsletters: Estarán encantados de incluirte.
• Escritores: En el caso de disponer del email de una persona que tenga libros publicados, aprovecha la oportunidad. Podrá hacerte publicidad es sus redes sociales.

7. Suerte

Hay un apartado que he querido dejar para el final ya que no hay manera de controlar: la suerte. A pesar de seguir de arriba a abajo todo lo mencionado, de hacer bien las cosas… puede ser que publiques y exista otro tema más interesante que te haga pasar desapercibido: Chrome dejará de dar soporte a cierto formato, Apple saca su nuevo iPhone, se ha hackeado los servidores de la casa blanca… Meses de trabajo se perderán como lágrimas en la lluvia. Pero puedo ocurrir todo lo contrario. De un día para otro uno de tus repositorios empiece a subir las estrellas de 100 en 100 sin aparente razón. No es tan improbable, a mi me pasó. Tal vez una persona influyente le hiciera gracia y lo compartió en el grupo adecuado en el momento adecuado. No hay herramientas ni bolas de cristal suficientemente pulidas capaces de adelantarse a lo que pueda pasar, pero hacer bien las cosas hace que te sonría con más intensidad que a los demás.

Conclusiones

Como siempre se dice, lo importante es el camino. Es aprender durante el trayecto para ser mejor desarrollador. Exigirte ser perfeccionista, sin presiones de tiempo, solo puede traer buenos resultados ya que estudiarás temas que no abordas en el trabajo por pereza o porque estabas acomodado en otras tecnologías: mejor uso de git, despliegues automáticos, testing, algoritmos, creación de la documentación, búsqueda de mejores estrategias, conexión con APIs de terceros…. Y la lista podría continuar.

Como decía al principio, subir código a un repositorio es una copia de seguridad. El Opensource no debería ser un sinónimo de código, sino de comunidad, un lugar donde dar y recibir conocimiento.

Ahora es tu turno de ser miembro.