No recuerdo cuándo fue la primera vez que leí o escuché el concepto "software libre". Supongo que sería a finales de los 90, cuando empecé a trastear con Linux. Hasta ese momento, como usuario de PC MS-DOS y Windows, conocía estos tipos de distribución de software: software de pago, shareware (podías probarlo durante un tiempo y, si te gustaba, tenías que pagar) y freeware (gratuito, que no es lo mismo que libre). Los disquetes - y, posteriormente, CD-ROM - que acompañaban a las revistas especializadas, solían incluir toneladas de programas tanto shareware como freeware, pero en contadas ocasiones venía el código fuente. El sistema operativo (MS-DOS o Windows) tampoco incluía ningún compilador de serie.

Como comentaba, con el uso de Linux empezaron a cambiar las cosas. En aquel momento todavía no estaban maduros los repositorios de software, ni mucho menos las tiendas de aplicaciones. La manera habitual de instalar programas nuevos era acceder a su página web, bien buscando, bien a través de algún directorio tipo Softonic (hace 15 años no era lo que es hoy), descargar el código fuente, compilarlo e instalarlo en el sistema. Si tenías mala suerte, porque ese programa usaba librerías no estándar, tenías a su vez que descargar, compilar e instalar dichas librerías. Pero bueno, que me voy por las ramas y no era esta historia la que quería contar hoy.

Creo que uno de los argumentos que enseguida se esgrime a favor del software libre es que, como el código fuente está disponible, si el programa tiene algún fallo, o bien echas de menos alguna característica, te puedes remangar y ponerte manos a la obra para solucionar el fallo o añadir la funcionalidad por ti mismo. Evidentemente, esto es conceptualmente cierto, pero en la práctica es difícil de cumplir. Aun así, es una gran ventaja frente al software cerrado.

El público en general no es consciente de la importancia del software libre. El software libre está en todas partes, y es en gran medida responsable de la explosión de la informática de consumo. Por citar un ejemplo, el sistema operativo Android está basado en software libre (aunque la parte de los servicios de Google sea software propietario). Pero hay muchos más. Nuevamente, no es objeto de esta entrada centrarme en este asunto. Tranquilos, ya voy a donde quería llegar.

Llevo mucho tiempo usando software libre, tanto en el ámbito personal como en el profesional, y todo este tiempo he tenido la espinita clavada de querer ayudar, querer devolver algo a esa comunidad que tanto me aporta. Para poder contribuir hay que superar dos barreras principalmente. La primera de ellas: encontrar un proyecto cuyo ámbito te resulte familiar y dar con algún error o funcionalidad que nadie haya resuelto y que estés capacitado para resolver. La segunda barrera: ponerte en contacto con la persona o el equipo encargados del proyecto y coordinarte con él/ellos para definir cuál es el procedimiento a seguir para poder aportar.

Empezando por el final, la segunda barrera hoy día no lo es tanto gracias a herramientas como Git y proyectos como GitHub o Bitbucket, por citar un par. Para que nos entendamos, y sin entrar en tecnicismos, en estos portales es sencillísimo clonar un proyecto, arreglar un bug o añadir una función nueva y devolver los cambios al proyecto original para que se integren de manera casi automática.

Git + GitHub - Imagen obtenida de http://www.palermo.edu/ingenieria/eventos/git-github.html

La primera barrera es la que me ha costado más superar. Ya hace años que varios de mis proyectos, incluido este blog, son de código abierto y públicos. Y no solo el código, sino también algunos contenidos que he escrito, con mejor o peor tino, como lo que publico por aquí o los contenidos que redactábamos en la revista MagazineZX, por citar algunos ejemplos. Pero no había encontrado ningún proyecto de software libre que cumpliera los requisitos de poder colaborar, saber colaborar y tener algo con lo que colaborar.

Por fin lo he conseguido esta pasada semana. En el trabajo estamos usando la librería LswMemcache. Nos viene al pelo para lo que necesitamos salvo por dos inconvenientes: no funcionaba con Symfony 3 y no mostraba correctamente los informes estadísticos. Ahora veremos por qué he conjugado los verbos en pasado. Lo maravilloso del software libre es te permite obtener el código fuente y arreglarlo por tu cuenta, al menos como primer paso. Pero, ya que estamos, ¿por qué no enviar de vuelta la solución para que todo el mundo pueda beneficiarse? Por supuesto, y eso fue lo que hice. En este punto es donde entra la comodidad de herramientas como GitHub. De nuevo, por no entrar en detalles técnicos, lo que hice fue abrir dos solicitudes (llamadas Pull Requests en la jerga de Git) al proyecto original, una por cada cambio, en las que indicaba: esto es lo que falla (o hay que mejorar) y con estos cambios se arregla. El coordinador del proyecto puede discutir conmigo los cambios y, una vez que le parece bien la solución, aceptarlos simplemente pulsando un botón. Mola, ¿verdad? Si no le parece bien lo puede descartar, lo cual también es aceptable.

Por fin estoy empezando a devolver a la comunidad todo aquello que me ha dado. Y contribuir de esta manera me hace sentir muy bien. También quiero dejar claro que, aunque hay gente que se toma este tipo de contribuciones como una competición del tipo "a ver quién contribuye más", no es mi enfoque. Lo cuento por aquí para intentar concienciar al personal de las bondades del software libre, de ser solidarios y contribuir a la comunidad. A partir de aquí, no seguiré insistiendo cada vez que realice un aporte. Lo seguiré haciendo mientras me sea posible, simplemente por principios.