Como crear un proyecto open source

El software open source va tomando popularidad gracias a las grandes ventajas que ofrece como modelo de desarrollo, y debido a esto posiblemente has pensado en crear un proyecto de este tipo o hacer open source aquel proyecto que tienes parcialmente olvidado y que quieres retomar.

Si vas a tomar esta decisión, aquí te explico el cómo hacerlo bien.

Licencia

El primer paso y que a su vez es el más elemental es seleccionar la licencia de tu proyecto, puede parecer una tarea trivial ya que muchas veces no tomamos en cuenta la licencia de un software antes de usarlo, pero si vas a ser el encargado de mantener tu proyecto, esto es muy importante, ya que la licencia es lo que dictará que puede y que no puede hacer un individuo con él, sea redistribuirlo, no atribuirle el autor original o usarlo para crear y distribuir un software de código cerrado.

Como guía básica, las tres licencias de software más comunes son la Apache, la MIT y la GNU (en sus diferentes versiones), si quieres una licencia simple y permisiva te recomiendo personalmente la MIT, esta es la que uso en la mayoría de mis proyectos actuales, en cambio, si te preocupas mucho sobre compartir mejoras y la filosofía open source la GNU puede ser la más indicada, en esta página puedes leer y orientarte más al respecto, solo toma en cuenta que está en inglés.

Documentación

Ahora llegamos a la etapa del proyecto como tal, puede parecer una locura, pero la mayor parte del tiempo el mantenedor o creador de un software open source no está escribiendo ni leyendo código fuente, sino que está trabajando en su documentación.

Lamentablemente la documentación, es algo un poco infravalorado en estos tiempos, por una parte se entiende el caso, ya que un buen número de proyectos tienen una documentación pésima, la cual obliga a muchos a ignorarla y aprender por medio de alternativas como tutoriales o cursos, pero la documentación es la que define el cómo se usara y como deber ser visto un proyecto, escribirla y mantenerla es un arduo trabajo que nunca termina y es lo que define el éxito o fracaso de un proyecto que está iniciando.

Si publicas tu proyecto y la documentación es de pobre calidad, es casi seguro que fracasará, las personas no seguirán leyendo y dejarán el proyecto al ver que no hay alternativas como tutoriales o guías de terceros, así que dedícale un buen tiempo a escribir una documentación sólida, ¿cómo? Pues tratando todos los casos de uso, escribiendo explicaciones que sean simples y concisas, dando ejemplos descriptivos y asegurándote de que lo que escribes va acorde al uso, si en los textos está escrito que El método foo retorna el numero entero 1 entonces asegúrate de que sea así y solo así. Tambien toma en cuenta una frase muy cierta la cual es "Si no está documentado no existe".

Pruebas

Otro factor muy importante son las pruebas unitarias, este fue un error grandísimo que llegue a cometer al publicar las primeras versiones de mis proyectos. Si un proyecto no tiene pruebas unitarias o alguna forma de demostrar con facilidad que realmente funciona, entonces ¿que asegura a las personas que el día de mañana el proyecto deje de funcionar repentinamente y todo el trabajo que han hecho en base a él se vuelva inservible? Claro, puedes llegar al rescate y ayudarlos en estos casos, pero nadie toma por seguro que esto sea así, un software sin pruebas unitarias será ignorado por casi cualquier programador o empresa seria.

Por suerte existen muchas librerías excelentes para realizar pruebas unitarias en diversos lenguajes, como PHPUnit en PHP, Mocha en JavaScript o JUnit en Java.

Otro aspecto a tratar es la cobertura del código, ¿qué porcentaje del código deberían cubrir las pruebas? Pues, lo siento, no existe una respuesta simple ya que depende de aspectos como el lenguaje, la plataforma y la naturaleza del proyecto (recuerda que Google es tu amigo), pero siempre apunta a que sea del 100% o cercano al 100%, si en tu caso no es posible, al menos asegúrate de que la cobertura supere el 50%.

Comunidad

Por último, una vez tengas listo tu proyecto, su documentación y sus pruebas, queda mantenerlo, aquí viene a tomar protagonismo el factor humano, evita un ambiente toxico, trata a los usuarios con amabilidad y asume siempre buenas intenciones, puede que no sea fácil tratar bien a todas las personas sobre todo en días difíciles, pero recuerda que estás dando el rostro por tu software y lo último que quieres es perder potenciales usuarios o terminar rayado con una mala reputación en la comunidad.

Para simplificar el trato futuro con terceros, puedes dejar una guía, como un archivo de texto en la raíz de tu proyecto o una página en tu documentación explicando a los demás como deben acercarse a ti y como pueden (o deben) contribuir con el proyecto si así lo desean, esto ahorraría el responder preguntas repetidas o problemas iniciales de comunicación.

En mi caso, tengo un archivo en la raíz de mis proyectos llamado CONTRIBUTING.md en el cual explico el código de conducta y los pasos que deben de seguir si quieren publicar un issue o un merge request en el repositorio.

El publicar un proyecto open source es una experiencia única y muy recomendada, sobre todo por el aprendizaje que obtienes al final, como consejos rápidos recomiendo leer y seguir el versionamiento semántico y compartir en redes sociales o foros sobre tu proyecto, ya sabes, un poco de publicidad no le hace daño a nadie.