5Las ventajas de la apertura
El profesional de la información, v.17, n. 1, enero-febrero 2008
Observatorio
Las ventajas de la apertura
Por Jesús M. González-Barahona
Resumen: Una de las principales consecuencias de publicar un
programa como software libre es que su código fuente queda a
disposición de quien quiera examinarlo. Además, mucha otra
información sobre el proceso de desarrollo suele estar también
fácilmente accesible en internet. En este artículo se presentan
algunas de las consecuencias de esta “apertura” del proceso de
construcción de software libre, y se explora brevemente cómo
estos mismos mecanismos de apertura podrían comportarse en
otros campos.
Palabras clave: Software libre, Software abierto, Código abier-
to
Title: The advantages of openness
Abstract: One of the main consequences of publish-
ing a program as libre (free, open source) software is
that its source code is made available to anyone who
wants to look at it. In addition, much other informa-
tion on the development process is often easily acces-
sible on the internet. Some of the consequences of “opening up” the process of building libre software
are discussed, briefly exploring how these open mechanisms could behave in other areas.
Keywords: Free software, Open source software, Open software
González-Barahona, Jesús M. “Las ventajas de la apertura”. En: El profesional de la información, 2008, enero-febrero,
v. 17, n. 1, pp. 5-7.
DOI: 10.3145/epi.2008.ene.01
1. Software libre, código abierto
El software libre lo es porque se puede estudiar,
modificar, y también redistribuir como versión modi-
ficada1. Por lo tanto, el que un programa sea libre o
no viene marcado por la licencia bajo la cual ha sido
publicado, que es la que otorga (o no) estos permisos a
quien reciba una copia.
Una de las principales consecuencias de esta defini-
ción es que el código fuente (que viene a corresponder,
en líneas generales, con los “planos” detallados que
indican cómo está construido el programa) tiene que
estar disponible. En otras palabras, cualquier experto
puede entender, con todo el detalle, cómo está cons-
truido el programa, hasta el punto de que podrá modifi-
carlo sabiendo lo que hace. Naturalmente, este experto
podrá también reconstruir completamente el programa
a partir de ese código fuente, si así lo desea.
A primera vista, esta característica del software li-
bre parece de interés sólo para los expertos que pueden
entender el código fuente, y saben cómo modificarlo,
por ejemplo para corregir un error. Sin embargo es uno
de los aspectos del software libre con más impacto en
los usuarios finales. Veamos por qué...
2. El círculo virtuoso de la innovación
distribuida
Cuando un usuario de software libre percibe un
problema con un programa (quizás un funciona-
miento erróneo, pero también una funcionalidad que
echa de menos, por ejemplo), puede hacer algo más
que quedarse esperando a ver si la situación mejora.
Puede enviar un informe al grupo de desarrollo del
programa. Pero también puede contratar a alguien
que le arregle su problema. O puede arreglarlo él
mismo si sabe trabajar con el código fuente del pro-
grama.
El que el código fuente esté disponible es justa-
mente lo que permite que pueda elegir cualquiera de las
Jesús M. González Ba-
rahona es profesor en la
Universidad Rey Juan Carlos
(URJC) de Madrid. Comenzó
a trabajar en la promoción
del software libre en 1991 y
colabora con varios proyec-
tos de software libre (entre
ellos Debian), con asociacio-
nes como HispaLinux y Euro-
Linux. Asesora a empresas y
administraciones públicas en
sus estrategias relacionadas
con este tema. Imparte asig-
naturas de doctorado sobre
software libre en programas
de la Univ. Politécnica de
Madrid y la URJC y es miem-
bro del comité científico del
máster en software libre de
la Univ. Oberta de Catalun-
ya y codirector del master en
software libre de la URJC,
impartido en colaboración
con Igalia y Caixa Nova. Ha
participado y participa en
proyectos internacionales:
Calibre, FlossWorld, Floss-
Metrics, Qualoss, Qualipso,
FlossImpact.

6Jesús M. González-Barahona
El profesional de la información, v.17, n. 1, enero-febrero 2008
dos últimas opciones. O sea: la mejora del programa no
depende sólo del grupo que hace el desarrollo, sino que
cualquiera que sepa puede mejorar el programa, o si no
tiene conocimiento para ello pero tiene recursos puede
encargar que terceras partes realicen la mejora.
Y si algo de esto ocurre, quien realiza la mejora
está además muy motivado para contribuir con ella de
vuelta al grupo de desarrollo del programa, porque así
es muy posible que tal mejora sea incluida en nuevas
versiones, sin tener que volver a realizar el esfuerzo co-
rrespondiente. Y no hay que olvidar que estas nuevas
versiones quedan a disposición de todo el mundo, por
lo que hay un potente sentimiento de estar ayudando a
un esfuerzo colectivo, incluso si el producto lo elabora
una empresa o un grupo relativamente cerrado.
Así, gracias a que el código fuente está disponible,
cualquiera puede innovar sobre el programa. Si el gru-
po de gente interesado en él es suficientemente gran-
de, este mecanismo asegura un flujo constante y muy
activo de mejoras e innovaciones. Y cualquier usuario
del programa se beneficia de ellas (incluso si no sabe
realizar ninguna de ellas).
Naturalmente, si el código fuente no estuviera dis-
ponible, nada de esto sería posible, y tendríamos el mo-
delo de innovación centralizada clásico en la industria
del software privativo: sólo quien produce un programa
puede mejorarlo.
3. No sólo el código
El mecanismo descrito anteriormente se ve muy
potenciado si no sólo el código, sino toda la infor-
mación relacionada con el desarrollo del programa,
está disponible para terceros. Los debates de diseño,
los informes de error, la historia de modificaciones
del programa, y otras fuentes de información permi-
ten que cualquiera que se aproxime al proyecto pueda
tener con relativa rapidez una visión muy detallada y
completa de lo que está ocurriendo en él. Esto no sólo
permite hacer evaluaciones detalladas (y muy exactas)
de la “salud” de la comunidad que está manteniendo
un programa, sino que también permite obtener fácil-
mente una gran cantidad de conocimiento sobre cómo
se desarrolla.
Estos efectos son bien conocidos en la comunidad
del software libre, y por ello la idea de “apertura” nor-
malmente se extiende no sólo al código, sino a muchí-
simos otros aspectos de la producción del programa.
Es importante darse cuenta de que, aunque el caso del
código venía obligado por la licencia (si el software es
libre, el código fuente ha de estar disponible), el pu-
blicar o no más información es algo que los proyectos
pueden hacer o no, sin por eso dejar de ser software
libre.
Los proyectos de software libre suelen tomar esta
actitud abierta hacia la información hasta extremos
poco concebibles en otras disciplinas, porque con-
sideran que las ventajas de hacerlo son muchas. Son
conscientes de que eso está ayudando a que terceros
tengan más información sobre las características, y eso
potencia el que se animen a realizar innovaciones, y a
que esas innovaciones sean útiles, y en línea con las
necesidades y requisitos del proyecto.
Cuanto más abierto es el proyecto, más fácil es
captar recursos externos para tareas de mejora e inno-
vación, así como atraer personas potencialmente in-
teresadas que pueden acabar incorporándose al grupo
de desarrollo, y atraer talento externo que estudie el
programa, destaque fallos y problemas, y quizá incluso
proponga soluciones.
Así, la cultura de la mayor parte de los proyectos
de software libre incluye esta máxima apertura: “publi-
quemos toda la información que podamos, porque eso
nos beneficia”.
4. Aprender de lo que ya se sabe
Pero esto no es tan extraño. Los beneficios del es-
crutinio público son bien conocidos en otros dominios.
Uno de los que primero viene a la mente es el ámbi-
to científico. Se espera que los investigadores publi-
quen todos los detalles posibles de cualquier avance
que hayan logrado, con la idea de que otros lo puedan
reproducir, criticar, y si es posible, lo mejoren. Casi
exactamente con los mismos efectos que en el mun-
do del software libre: mejora de la calidad, innovación
distribuida, detección temprana de errores y proble-
mas, etc.
Sin embargo, en uno de los dominios donde podría
esperarse más aplicación, se encuentra todavía muy
poca. Entre los productores de obras culturales libres
(música, documentos, películas) es todavía muy poco
habitual publicar información que no sea la propia obra
liberada.
Algunos grandes proyectos, como la Wikipedia,
sí se han preocupado (y se están preocupando cada
vez más) de que toda la información relacionada con
el proceso de creación colectiva quede documentado
públicamente. Las páginas de discusión o las listas de
correo públicas, por ejemplo, son grandes pasos en este
sentido.
Pero la Wikipedia es hoy día más una excepción
que una norma. Para muchos documentos libres que
circulan por la Red es hasta difícil encontrar una ver-
sión editable (un formato que permita cambiarlo de for-
ma simple). Es casi imposible conseguir los materiales
separados (distintas pistas, por ejemplo) con los que