Trabajando con proyectos de Software Libre |
---|
Muchos programadores quieren empezar a trabajar en un proyecto de Software Libre, pero no están muy seguros de cómo funcionan las cosas. Esta página es una colección informal de «reglas no escritas y consejos» para gente que le gustaría participar de voluntario. He aprendido alguna de estas reglas comentiendo errores, y algunas veces incluso incumplo flagrantemente mis consejos; Es sólo una guía :) Seguro que otra gente ofrece otra panorámica sobre el asunto.
Mucha gente quiere escribir Software Libre y lo primero que hacen es escribir algo de código, adosarle la GPL y liberar la versión 0.0.1 alpha. Aunque sea divertido y posiblemente educativo, esto es totalmente improductivo. Veamos por qué:
Es mas instructivo leer y aprender del código de otra gente, añadiendo pequeñas funcionalidades aquí y allá, o arreglando algunos fallos. La mayoría de los proyectos tienen un sistema de seguimiento de fallos; por ejemplo, en el proyecto GNOME tenemos bugzilla.gnome.org, Debian tiene el mismo sistema, bugs.debian.org, etc. Encuentra un fallo en el sistema y corrígelo. O añade la funcionalidad que estabas deseando.
Obviamente, es mucho más útil limpiar el código existente que empezar un proyecto en solitario que nunca va a ser finalizado.
Casi seguro, algún otro ya está trabajando en lo que quieras escribir; es mejor terminar un proyecto que tener dos proyectos sin terminar. Te prometo que el 95% de los proyectos de Software Libre caen en el olvido antes de que se conviertan en útiles. Tanto desde el punto de vista de tu propio aprendizaje como desde el punto de ganar fama y mejorar tu ego, necesitas gente que te ayude a entrar en el 5% ganador.
Si no has estado curioseando y participando en un proyecto de Software Libre, no sabrás como se hacen las cosas y pasarás unos malos ratos intentando llevar el tuyo adelante.
Una vez dicho todo esto, si tienes una idea genial y piensas que sería divertido programarla, hazlo por todo los medios. Todos lo hemos hecho. :-) Algunos de estos proyectos llegan a algún lado. Y si tienes alguna experiencia codificando y hay una aplicación interesante en la que nadie está trabajando, definitivamente, ve por ella.
Si empiezas un proyecto, lo más importante es escribir código. Tienes que escribir suficiente para hacer que la aplicación sea útil; esto puede llevar meses o años de trabajo solitario, a menos que algún alma caritativa decida ayudarte con tu aplicación en vez de empezar la suya. :-) Tienes que liberar versiones a menudo, arreglar los fallos rápidamente y, generalmente, mantener el proyecto excitante. Luego te darás cuenta que escribir una aplicación libre supone una cantidad enorme de trabajo. Si estás programando por tu cuenta, dedica unas 10-20 horas cada semana, previendo el futuro. Si no puedes dedicar todo este tiempo, no te molestes siquiera en empezar el proyecto. Si ni siquiera sabes programar, lo dicho.
Mucha gente envía un mensaje diciendo que va a escribir la aplicación X, o anuncia la versión 0.0.1 alpha y entonces lo abandona cuando no encuentra ninguna respuesta. Aceptalo: No habrá mucha respuesta hasta que tengas usuarios. Y no tendrás usuarios hasta que escribas código. Estarás tu y tu determinación por escribir ese software.
Ocurre el mismo fenómeno cuando se pide ayuda. En última instancia, si un fallo, una característica que falta o una falta en la documentación se cruza en tu camino, probablemente tendrás que arreglarla por ti mismo. Los hackers son suficientemente amables con los novatos que no saben dónde empezar, pero tarde o temprano esperan que seas capaz de solventar tus propios problemas.
Si tienes una pregunta, hazla en la lista de correo. Es un poco maleducado enviar mensajes privados a los desarrolladores, a menos que tengas una razón para creer que es la única persona que pueda responder a la pregunta. (Si usas el correo privado, lo más probable es que se lo envíes al desarrollador equivocado y termines sin tener una respuesta porque quizás la persona a la que escribiste no sepa del asunto.)
Las listas de correo y la documentación las escriben los programadores para hacer posible ayudar a un gran número de usuarios. Recuerda que todo el mundo es un voluntario, y que si necesitas consultoría pagada, probablemente esté disponible.
La gente suele esperar que alguien esté a cargo de un proyecto de Software Libre, o esperan que alguien les asigne algún trabajo a realizar y una fecha límite. No funciona de esa manera. No puedes controlar sobre lo que otra gente trabaja, y nadie va a decirte sobre qué tienes que trabajar, aunque habrá muchos consejos. Tendrás que involucrarte un poco y hacer que algo ocurra.
Si pasas 3 meses escribiendo alguna funcionalidad interesante, y luego descubres que el mantenedor odia esa idea y que no aceptará el parche, o encuentras que tu parche no se puede aplicar a la última versión en desarrollo, o ves que alguien ya hizo el mismo trabajo, estarás frustrado. Si tienes intención de trabajar sobre algo, envía una pequeña nota al mantenedor para que lo sepa. La mayoría serán escepticos (reciben muchas notas y nunca ven los resultados) pero harán una nota mental y quizá te den algún consejo.
Si acabas fuertemente involucrado en un proyecto, se puede tener una coordinación más fina usando una combinación de email, CVS e IRC. El CVS hace un gran trabajo uniendo los cambios cuando la comunicación se rompe.
La respuesta a ambas preguntas es «cuando alguien haga el trabajo». Si ese alguien eres tú, entonces sabes la respuesta. Si ese alguien no eres tú, entonces tendrás que esperar y ver qué pasa. :-) No hay ningún coordinador ni nadie que se asegure de que los eventos ocurran.
Un programador de sillón parece tener un flujo incesante de ideas brillantes cuando escribe en las listas de correo, pero o bien no programa o no sabe cómo programar. Si no sabes programar, no sabes como diseñar software tampoco. Punto. Solo causarás problemas.
Hay un montón de cosas que los no programadores pueden hacer de todas formas: enviar informes de errores, petición de características (siempre que no sean muy especulativas y no estén relacionadas con el código existente), escribir documentación, ayudar a los usuarios con sus preguntas y la instalación, grupos de usuarios, mantenimiento de páginas web, administracion de servidores, hacer paquetes para distribuciones, etc. Los hackers aprecian el interés por su trabajo y tu ayuda.
La tentación de apuntarte a una lista de correo y empezar a comentar sobre todo suele ser fuerte. Pero no te conviertas en un programador de sillón. Escribe si tienes cosas relevantes que contar, si descubres cómo reproducir un fallo, si sabes como obtener experiencia en el tema, si conoces las respuestas a las preguntas. Si no es así, no envíes mensajes. Además, siempre es buena idea curiosear durante un tiempo antes que empieces a escribir, simplemente para ver de qué va el tema. [*] Lurk es la palabra utilizada en inglés (Nota del Traductor)
Tienes que ser algo de abogado para involucrarte en Software Libre. Esto significa que tienes una reponsabilidad para contigo para aprender sobre ello. Tradicionalmente, una manera de aprender es observar las mismas peleas de siempre que ocurren semana tras semana en el grupo de noticias gnu.misc.discuss. Una manera más rápida es leer la web de GNU, en particular su análisis de la terminología. No envies correos sobre temas legales si no los comprendes. Pero deberías comprenderlos si vas a escribir software y aplicarle una licencia al mismo.
Es siempre bueno usar la misma licencia, el estilo de código, etc. que el que utiliza el mantenedor del paquete al que le estás mandando un parche. Si usas CVS, no apliques tus parches sin pedir primero permiso al mantenedor del paquete.
Un punto de menor importancia, pero, casi siempre, todo el mundo prefiere este formato.
Trátalos con el respeto que merecen. Sólo están trabajando en ello porque disfrutan. Es de desagradecidos maltratar a alguien que te ha dado algo gratis.
Muchos tenemos problemas con esto, pero cuanto más te centres en una tarea y la termines, tus resultados serán más útiles. Yo encuentro que tengo que seleccionar pequeñas tareas para llevar esto adelante. Otra gente es mejor en los proyectos de más largo plazo. Organiza tus esfuerzos en concordancia con tu personalidad. Intenta terminar proyectos antes de empezar 100 proyectos superambiciosos.
Es una buena idea mantenerte informado en los sitios de noticias como LinuxToday, LWN o Slashdot y también los sitios relacionados con los proyectos con los que estés trabajando. (Los tres que he mencionado son tres que yo leo). Un buen libro sobre la historia de la comunidad es «Hackers», escrito por Steven Levy. www.gnu.org tiene mucha información también y curioseando en las listas de correo aprenderás un montón.
De cualquier manera, hagas lo que hagas, alguién te atacará y te verás envuelto en una pelea o flame. Internet es así. Algunas personas no han aprendido esta lección todavía y se cabrean y responden virulentamente cuando pasa; No lo hagas. Si lees las listas de correo, pronto aprenderás qué gente es más propensa a tener puntos de vista válidos y cuáles son flamers habituales. (Date cuenta que ambos no son mútuamente excluyentes; algunos de los hackers más productivos son también flamers). Desarrolla una piel resistente, la vas a necesitar.
Programar es, al fin y al cabo, trabajar. Es sentarse y dedicar tiempo a escribir código o documentación. Pero hay muchas oportunidades de socializar, en conferencias, en IRC, a través del email. Escribir código es divertido durante la mayoría del tiempo. Así que disfrutalo. Eso es parte del motivo. No tomes demasiado en serio este documento o alguna de sus reglas.
Las ideas de Eric Raymond sobre este tema están en aquí [traducción Aquí]; Su HOWTO describe como unirte a la "cultura hacker". La cultura no es realmente necesaria para participar en proyectos de Software Libre, en mi opinión. Mientras sigas la manera de trabajar que sigue la comunidad no tienes que meterte en los temas sociales de la misma (a menos que quieras). Advogato (el alter ego de Raph Levien) también tiene un ensayo aquí. Después de leer todos estos consejos, en las palabras de RMS, happy hacking!.
<< Trabajando con proyectos de Software Libre |