Con todo al aire
Una de las características diferenciadoras del software libre es que su código fuente está al alcance de cualquiera que desee leerlo. Pero ésta no es, ni mucho menos, la única información pública que mantiene habitualmente un proyecto de software libre. También suele haber listas de correo electrónico, sistemas de gestión de errores, documentación en páginas web, etc., etc. Esta apertura, este esfuerzo porque gran parte de la información relacionada con el proyecto sea pública, sorprende a muchos, y especialmente cuando se compara con la situación en el mundo del software propietario, donde no sólo el código fuente suele ser un secreto muy bien guardado, sino que se esconden los errores del programa o no hay detalles sobre su arquitectura o las decisiones de diseño que le afectan.
¿Por qué en el software libre es habitual poner tanta información a disposición de quien la quiera ojear? ¿Qué se gana con ello? ¿Se pierde algo?
Lo habitual es publicar
Desde hace tiempo, los proyectos de software libre suelen publicar (en el sentido de permitir el acceso de cualquiera) la mayor parte de la información que manejan. Esto incluye, por supuesto, el código fuente de las diferentes versiones de los programas que liberan. Pero habitualmente, hay mucho más.
Por ejemplo, normalmente está disponible no sólo el código de esas versiones liberadas, sino toda la historia de desarrollo: cada cambio, cada línea añadida o quitada, anotada con el momento en que se hizo, quién lo hizo... Esta información se suele mantener en un sistema de control de versiones, habitualmente CVS. Un vistazo al CVS del proyecto permite conocer, con todo detalle, su historia íntima. Se puede saber quién está haciendo más contribuciones ahora mismo, o quién las hacía hace tres años. Qué tipo de modificaciones están teniendo lugar, o qué nuevas funcionalidades se están añadiendo, y cómo. No cualquiera puede escribir en estos archivos de CVS, pero cualquiera puede usar una cuenta de sólo lectura.
También es normal que las listas de correo donde se discuten los problemas y se toman las decisiones relacionadas con el proyecto sean abiertas, en el sentido que cualquiera puede al menos leerlas, y en muchos casos apuntarse y participar en las discusiones. Quizás por este motivo hay quien tiene la idea de que en los proyectos de software libre hay muchas enemistades y muchas discusiones: porque todo tiene lugar en público, en ese escenario que supone el archivo de la lista de correo de desarrolladores. Desde luego, cada proyecto hace las cosas de una forma, pero no es raro poder asistir, en primera fila, a los debates sobre qué funcionalidad añadir a un programa, cómo corregir un error, o si tal código es o no es de la calidad suficiente como para poder ser incluido.
Otro tipo de información muy habitual entre la que proporciona cualquier proyecto es la lista de errores conocidos (pasados y presentes) y de los arreglos (parches) que se han usado para corregirlos. Esta información suele almacenarse en los sistemas de control de errores (bug tracking systems), e incluye datos muy detallados sobre quién descubrió el error, en qué condiciones, qué proceso se siguió para resolverlo, si está ya resuelto o no....
Y así se puede continuar con la lista de información pública, que es diferente en cada caso, pero que habitualmente se mantiene abierta de forma completamente deliberada.
La información ha de ser libre
Desde luego, no hay una única razón para que los proyectos de software libre permitan un acceso muy completo a toda la información que generan. Por un lado tenemos razones meramente prácticas, que voy a tratar un poco más adelante. Pero por otro lado tenemos también poderosas razones éticas: la información sobre un proyecto libre debería ser libre. Por ejemplo, en el Contrato Social de Debianhttp://www.debian.org/social_contract.es.html (en el que los desarrolladores del proyecto exponen su compromiso con los usuarios) se puede leer en uno de sus apartados:
``No esconderemos Problemas. Mantendremos nuestra base de datos de informes de errores abierta a acceso público en todo momento. Los informes que los usuarios envíen en línea se harán visibles inmediatamente al resto.''
En este caso, los desarrolladores de Debian consideran esto una obligación con sus usuarios, no sólo un asunto meramente práctico, que puede tener más o menos ventajas. Es parte de la ética que les lleva a producir su distribución de GNU/Linux, y a hacerlo de una cierta manera.
En otras palabras: en el mundo del software libre es habitual encontrarse con la opinión de que {\em la información ha de ser libre}. Y eso se aplica no sólo al software que se produce, sino a todo lo que le rodea. Digamos que, de alguna manera, el libre correr de la información es algo que impregna la mayor parte del mundo del software libre de una forma casi natural. Puede sorprender al principio, pero créeme, una vez que lo has probado no es algo que quieras dejar...
Si te sientes parte, quizás participes...
Obviamente, las razones éticas no son las únicas para permitir el acceso a gran parte de la información sobre los proyectos. También hay poderosas razones prácticas. Y entre ellas, quizás la más clara es el efecto implicador que tiene discutir las cosas en público, el dejar que otros vean lo que has hecho, con todo el detalle posible.
Un día te encuentras con un problema en un programa libre que estás usando. Se te ocurre ir al sitio web que mantiene el proyecto que lo crea. Ves que se pueden enviar informes indicando errores que se hayan encontrado, y envías uno explicando ese problema. Al cabo de un tiempo, alguien te responde y te dice que el asunto se está discutiendo en la lista de desarrolladores. Te apuntas a ver qué se dice. Después de leer varias opiniones, te animas a dar la tuya. Alguien considera tu aportación y empieza a codificar un parche usando tus ideas. Tú lo ves, y le respondes refinando un poco el código. Te dice que estupendo, que lo mires en el CVS, que ya lo ha subido. Al ir a mirarlo, te das una vuelta por los fuentes y ves un sitio donde el código se podría optimizar un poquito. Como ya estás en la lista de desarrolladores, lo comentas allí... Y unas semanas después te has convertido en uno de los desarrolladores del proyecto.
Desde luego, este escenario es ideal. Muchas veces ni siquiera te animas a informar del problema que te has encontrado. Pero de vez en cuando estas cosas pasan... Si conoces a algún desarrollador de software libre, pregúntale cómo empezó. No son pocas las ocasiones en que te responderá algo como: ``Encontré un problema en un programa, fui al sitio web...'' ¿Te ha pasado a ti?
En cualquier caso, está claro que si se da cancha a la gente, muchas veces hay quien se anima a participar. Es más fácil conseguir colaboradores si permites acceso fácil a toda la información que necesiten, y si ayudas a que sea fácil sentirse parte del proyecto. Y es más fácil que haya quien se sienta parte del proyecto si le permites participar en los debates, y contribuir fácilmente con sus opiniones (y su código). Muchas veces la gente se pregunta eso de ``¿y por qué va nadie a colaborar con un proyecto de software libre?''. Sin duda, ésta es una de las respuestas posibles: porque se siente implicado en él.
Si hay problemas, mejor que se sepan
Si se quiere mantener algo seguro, hay dos opciones: esconder los problemas que presente, o arreglarlos. Por ejemplo, si no quieres que nadie entre en tu casa, pero no tienes puerta, puedes esconder la entrada (plantando un seto delante, por ejemplo), o puedes preocuparte de poner una puerta. Y en general, te encuentras a gente que prefiere plantar el seto, y a gente que sólo se queda contento con la puerta puesta... ¿Tú de cuáles eres?
Normalmente el asunto no es tan obvio. A veces no es la puerta lo que falta, sino que hay una ventana que te has dejado abierta, y no te has dado cuenta. ¿Qué es mejor, ignorarlo, hasta que alguien trate de entrar por ella, o enterarte cuanto antes, y cerrarla? Éste es habitualmente el dilema en la seguridad de los programas de ordenador. Hay quien confía en que si aparece un error, nadie se entere, y ya se solucionará cuando se pueda. Y hay quien prefiere que el problema sea público lo antes posible, de forma que la gente pueda colaborar en solucionarlo, y haya una presión real para que esa solución llegue cuanto antes. Es en este sentido en el que hay que entender el párrafo del Contrato Social de Debian que mencioné más arriba.
En general, en el mundo del software libre se considera que ocultar los problemas es una mala estrategia, y no sólo de seguridad. Es mejor airearlos, que participen en su resolución todos los que quieran, y que la propia presión que causa sobre los desarrolladores el compromiso de mantener la información pública les empuje a resolver los problemas lo antes posible.
El debate sobre qué hacer en caso de problemas (publicarlos o tratar de mantenerlos en secreto) es viejo, y hay muchas opiniones en un sentido y en otro. Pero una vez que has decidido dejar tu código fuente al aire no hay mucho donde elegir. Así que llevando al máximo la transparencia, el mundo del software libre trata de explotar las ventajas del escrutinio público. Probablemente ésta sea la razón fundamental de que un proyecto con suficiente masa crítica tenga pocos problemas de seguridad, y cuando éstos aparecen, se resuelvan de forma rápida.
Malamente se puede ayudar si no se sabe en qué
Si ya se ha decidido colaborar con un proyecto de software libre (o simplemente, después de ir aproximándose poco a poco, un día te has encontrado metido en uno de cabeza), es mucho más fácil colaborar de forma útil si se sabe mucho sobre él. Por ejemplo, si se puede buscar de forma simple, entre la lista de errores conocidos, uno que apetezca arreglar. O si ante un problema cualquiera se pueden buscar antecedentes y debates relacionados en las listas de correo del proyecto. O si mirando un fragmento de código se puede echar un vistazo a su historia, y quizás hasta a los motivos para irlo cambiando...
En general, cuando uno comienza a colaborar en un proyecto libre, si puede ponerse pronto al día, y encontrar por sí mismo toda la información que necesita, será más fácil integrarse en él, y sobre todo la colaboración será más productiva. O al menos, ésa es la idea.
La vergüenza torera
Si estás orgulloso de lo que haces, y de cómo lo haces, te gustará que todo el mundo lo vea. Por otro lado, cuando estás trabajando, normalmente no actúas de la misma forma si el fruto de tu trabajo va a ser público, y mucha gente va a tener la oportunidad de examinarlo y admirarlo (o criticarlo), que si nadie (más que quizás tu jefe) va a poder verlo. En el mundo del software propietario, sólo tus colegas más cercanos, los que están en tu propio equipo, pueden ver los resultados de tu trabajo (el código que has escrito, los errores que se han detectado en él, las decisiones de diseño que has tomado). Así que si metes la pata, no se nota tanto... Sólo lo sabrá tu entorno más cercano, que probablemente será condescendiente (ya sabes: hoy por ti, mañana por mí).
Pero en el mundo del software libre, tus vergüenzas están al aire. Si escribes un código que es manifiestamente malo, o si hay en él un error de bulto, detectado desde hace meses, y no has hecho nada por corregirlo (o lo has corregido mal), cualquiera puede verlo. De alguna manera, es como trabajar en la calle, a la vista de todo el mundo. O quizás más: trabajar a la vista de muchos profesionales, como tú, que sin duda están capacitados para juzgar tu trabajo. Por eso muchas veces se dice que en el mundo del software libre es habitual la meritocracia. Es difícil que no sea así, porque aquí todo el mundo conoce la vida y milagros de los demás: basta con ojear el CVS.
En general, este control (la vergüenza torera de saberte expuesto a los ojos de tus pares) ha mostrado ya ser muy útil para conseguir la excelencia en otros ámbitos (como por ejemplo, el trabajo científico), y probablemente está en la raíz de las altas productividades, y de la buena calidad del trabajo de tantos desarrolladores, que se observa en el mundo del software libre.
¿No será esto de aplicación en muchos otros ámbitos?
Desde luego, mucho de lo que se ha comentado hasta aquí no es exclusivo del software libre. Es más que posible que otros ámbitos, y sobre todo los relacionados con el proceso de información y con la creación de conocimiento, se beneficiarían mucho de poner gran cantidad de información interna a disposición del público en general. Pero hay que reconocer que esto supone un gran cambio en la mentalidad habitual, centrada en lavar los trapos sucios en casa, y en mostrar hacia el exterior sólo lo que es percibido como buena imagen.
Eso sí, el mundo del software libre aporta un caso de ejemplo de cómo tener paredes de cristal puede ser beneficioso para el desarrollo de un proyecto. Pero aún queda por saber si realmente hay relaciones causa-efecto (por ejemplo: los proyectos libres que son más transparentes, ¿son también los más productivos, y los de mayor calidad?), y si esta forma de funcionamiento es realmente trasladable a otros ámbitos.
Una vez más, el mundo del software libre está transitando por terreno inexplorado... pero muy prometedor.