Contribuir con el software libre
Hace unos días Antonio menciono sobre el hecho de informar a los desarrolladores acerca de fallos en los programas de software libre que utilizamos.
Ciertamente parte importante de lo que es la comunidad de software libre, es justamente la retroalimentación que existe entre usuarios, desarrolladores y personas involucradas en los proyectos, tal es el caso del proyecto Debian donde muchos desarrolladores principales (término para no confundir con «desarrollador de Debian») muestran su agrado y gusto de trabajar o tener un proyecto de software libre como es Debian, de cual sus desarrolladores envían informes de fallos, parches, traducciones, etc, de esta forma se establece una interacción productiva entre ambos. Para los desarrolladores de software libre este tipo de cosas o hechos son los que los animan a mejorar y seguir desarrollando el proyecto en el cual han puesto su esfuerzo, y muy gustosos en recibir este tipo de contribuciones. Es por eso que muchos de ellos manifiestan su gusto por Debian, tanto como proyecto y sistema operativo, tal vez esto sea una de las razones por la que algunos, erróneamente, piensan que Debian GNU/Linux es una distribución solo para desarrolladores.
El informar fallos, ya sea en software, traducciones, erratas, e incluso el simplemente solicitar añadir una nueva característica o funcionalidad a un determinado proyecto de software libre va a repercutir finalmente en que éste mejore. Muchas personas usuarios de software libre (no digo comunidad todavía, ver más adelante) muchas veces efectúan modificaciones y cambios a los programas para adaptarlos a sus necesidades o solucionar un asunto en particular, pero no reparan de que este caso (aunque parezca único, irrelevante, ridículo, sui-generis, etc.) puede servir a otra persona quien también necesite esta funcionalidad, aprender como se hacer, o simplemente para evitar la duplicidad de esfuerzos, puesto que si uno informa de una anomalía los otros usuarios sabrán que el software tiene tal problema y así se evita el que cada uno de ellos pierda tiempo en identificar el problema, cuando en el mejor de los casos podría enfocarse en buscar la solución y enviar el parche o corrección al desarrollador principal o proyecto.
Pienso que si un usuario de software libre esta en la posibilidad de enviar o efectuar cualquiera de las acciones para contribuir a mejorar el software que utiliza y no lo hace pues, en mi opinión personal, no es parte de la comunidad de software libre, no está contribuyendo a su desarrollo y simplemente ha cambiado de un modelo donde no podía hacer los cambios directamente pero igual guardaba para si el conocimiento de como efectuar tal o cual acción, a un modelo donde los puede hacer pero igual no comparte el conocimiento de como hacerlo, por consiguiente la cultura del egoísmo y falsa idea de que ocultando cierta información lo convertirá en un «guru» al ser el «único» que sabe como hacerlo, es totalmente equivocada y que este tipo de personas no ha entendido la idea del software libre.
Probablemente algunos podrán alegar que el tiempo invertido en aprender y encontrar la solución al fallo o problema ameritan el que tengan esta actitud, bueno, los desarrolladores del software en cuestión invierten mucho más tiempo (y recursos) en crearlo y ponerlo a funcionar, y además, mucho más importante, entregarlo libremente para cualquiera. Creo que el analizar cual de los tiempos es más valioso es irrelevante, aunque la respuesta sea obvia.
En nuestro medio todavía no he visto una cultura sobre el tema, precisamente por eso que escribo al respecto, si he visto algunas iniciativas individuales esporádicas, espero que esto mejore. A propósito, una de las ideas principales para la creación del grupo Debian Peru fue el incentivar este tipo de contribuciones hacia la comunidad, pues realmente muchas de ellas son demasiado triviales como para no hacerlas.
Y como tenemos que ser útiles y contribuir, aquí un minicomo de
como efectuar este tipo de contribuciones.
¿Cómo contribuir con el software que utilizo?
Primero tenemos que definir que podemos contribuir al proyecto o
software que utilizamos. Las áreas usuales son:
- informar fallos: esto es obvio, se trata de informar sobre algún defecto o problema encontrado al momento de instalar, usar o modificar el software.
- parches: se refiere a envío de mejoras, que pueden ser en el código mismo, añadir una funcionalidad (por ejm. soporte de internacionalización), o corregir algún fallo encontrado o que ha sido informado.
- traducciones: efectuar la traducción para el idioma que uno domine
- corrección de erratas (traducciones): esto es algo que realiza muy poco pero es importantísimo, se trata de enviar las erratas (errores de traducción) a los traductores para que puedan ser incluidos en la próxima versión del documento o software.
- informes de éxito: esto es algo que tampoco se acostumbra pero es útil, se refiere a informa sobre el éxito al instalar/usar una nueva versión del software, efectuar una migración desde una versión anterior, o simplemente algo como informar sobre el éxito al configurar el software con un nuevo dispositivo oficialmente no soportado.
- confirmación o nuevos datos sobre un fallo en particular: esto es similar al anterior con la diferencia de que se trata de confirmar la existencia de un fallo que ha sido informado, y ofrecer más datos los cuales puedan servir a los desarrolladores para identificar y corregir el problema.
Ahora, como efectuar cada una o alguna de ellas si se da el caso. Los proyectos de software libre usualmente tienen hasta 4 vías para recibir contribuciones, siendo el correo electrónico el más usual, seguidamente están las herramientas o sistemas de seguimiento de fallos, formularios en sitio web y finalmente canales de IRC.
Es preciso entonces identificar cual de éstas ofrece el proyecto o software que utilizamos, generalmente cuando instalamos un software determinado éste incorpora un fichero «README» o similares, en éste podemos encontrar la forma de contactar con los desarrolladores o el método para informar fallos o contribuir; en algunos casos solamente tendremos la dirección electrónica del desarrollador la cual puede estar en el fichero «AUTHORS», «INSTALL» o «ChangeLog». Por último el sitio web donde se descarga el software usualmente tiene referencias al respecto.
Identificado esto, simplemente debemos escribir el informe o directamente enviar la contribución al proyecto o desarrollador. Hay que notar que el idioma comúnmente usado para esto es el inglés, aunque esto puede significar una barrera, no es muy complicado tampoco pues los datos son en mayoría información técnica. Proyectos como Debian o GNOME tienen una infraestructura para este tema, la cual cuenta con clientes que ayudan a recolectar información pertinente respecto al problema o programa afectado y la adjuntan al informe que se envía. Si no sabia de ésto, puede hacer inmediatamente
# apt-get install reportbug bugbuddy en su
sistema Debian GNU/Linux ;)
Como recomendación final, aunque este ha sido bastante resumido y he intentado ser breve, es importante identificar y enviar la contribución al canal adecuado, me refiero a que en algunos casos una corrección de errata de una traducción se debe enviar a la última persona que revisó o efectuó la traducción y no al desarrollador(es) del proyecto.
Así que ya lo saben: «Join us now and share the software (and patches), you will be free hackers, you will be free!» / «Únetenos y comparte el software (y parches), serán libres hackers, serán libres!»
Antonio, por cierto: aspell existe desde varios años y
puede ser usado como aplicación o incorporado (empotrado) dentro de otros
programas. Creo que tendrías que haberlo activado en tu cliente de correo ;)
Rudy en modo BOFH hubiese cerrado el fallo, con respuesta: «plz» :D (j/k)
categorías
- /FreeSoftware (26)
- /chicha (13)
- /culture (1)
- /debian (41)
- /dump (13)
- /es-debian (12)
- /inspiracion (25)
- /life (23)
- /music (13)
- /vegan (5)
tag cloud
archivos
» 2008Apr (1)
Mar (1)
Jan (2)
» 2007
Oct (2)
Aug (2)
Jul (1)
Jun (4)
May (3)
Apr (1)
Feb (3)
Jan (3)
» 2006
Oct (2)
Sep (2)
Jul (2)
Jun (7)
May (8)
Apr (4)
Mar (11)
Feb (4)
Jan (2)
» 2005
Dec (8)
Nov (4)
Oct (8)
Sep (7)
Aug (9)
Jul (6)
Jun (3)
May (3)
Apr (6)
Mar (4)
Feb (4)
Jan (6)
» 2004
Dec (8)
Nov (9)
Oct (14)
Sep (5)
Aug (10)
May (1)
Apr (10)
Mar (14)
Feb (25)
» 2003
Dec (3)
Nov (4)
Oct (3)
Aug (2)
Jul (3)
Jun (4)
May (8)
Apr (4)
Mar (7)
Feb (5)
