1. INDICE DE CONTERNIDO
SOFTWARE LIBRE 1
HISTORIA DEL SOFTEARE...........(1)
LIBERTADES DE SOFTWARE LIBRE.............................(2)
QUE ES EL SOFTWARE LIBRE LA HISTORIA DE LA INGENIERIA Y SUS HERRAMIENTAS
APLICADAS..........................................(3)
LA CRISI DE LA INGENIERIA Y EL SOFTWARE TRADICIONA....................(4)
Ingeniería del software tradicional e ingeniería del software libre...........(5)
Software libre e ingeniería del software libre(6)
Hacia un sistema de medición y análisis de software libre (7)
Extracción de datos (Primera fase)..........(8)
CODD.........................................................(8.1)

2. 1.SOFTWARE LIBRE
HISTORIA DEL SOFTWARE LIBRE
El software libre es una secuencia de instrucciones interpretadas por un ordenador, cuya
distribución y aplicación es libre, bajo las cuatro libertades.
El software libre y el código abierto representan una filosofía distinta dentro de la informática,
diferente de la que guiaba a las primeras compañías que buscaban monopolizar el naciente mercado
de los ordenadores. La presente infografía hace un repaso a la historia del software, desde la óptica
del código abierto, que lleva mucho tiempo compitiendo con los “productos cerrados”.
Haciendo una comparación histórica, con ilustraciones que recuerdan a la Guerra de la
Independencia de los Estados Unidos, el gráfico arranca con el despotismo de la monarquía de
finales del siglo XVIII, identificado con las grandes compañías que emergían con poder en el
mundo de la informática. Poco a poco, la barra de “libertad” (software libre) va aumentando.
La infografía comienza en los años sesenta, cuando las compañías de ‘software cerrado’ dominaban
completamente el mercado, repasa los hitos de Linux, así como la creación de Apache, terminando
con lo que se califica como “la revolución del código abierto” en la década del año 2000. El
gráfico da una visión general sobre la incidencia de una filosofía informática que ofrece grandes
oportunidades para las empresas alejadas del ámbito de la gran cuenta. El progresivo avance del
código abierto representa una tendencia a tener en cuenta para el futuro.
LIBERTADES DE SOFTWARE LIBRE
De acuerdo con tal definición, un software es "libre" cuando garantiza las siguientes libertades:
libertades de ejecución del software libre
libertad de estudiar el programa
libertad de acceder al código fuente
libertad de mejorar y publicar
LICENCIAS DEL SOFTWARE LIBRE
Una licencia de software es un contrato entre el licenciante (autor/titular de los derechos de
explotación/distribuidor) y el licenciatario del programa informático (usuario consumidor /usuario
profesional o empresa), para utilizar el software cumpliendo una serie de términos y condiciones
establecidas dentro de sus cláusulas.
Las licencias de software pueden establecer entre otras cosas: la cesión de determinados derechos
del propietario al usuario final sobre una o varias copias del programa informático, los límites en la
responsabilidad por fallos, el plazo de cesión de los derechos, el ámbito geográfico de validez del
contrato e incluso pueden establecer determinados compromisos del usuario final hacia el
propietario, tales como la no cesión del programa a terceros o la no reinstalación del programa en
equipos distintos al que se instaló originalmente.

3. APLICACIONES
2.Historia del software Libre
En el año de 1979, cuando la Universidad de Berkeley distribuyó código de programas que ha
desarrollado para el sistema operativo UNIX bajo una licencia denominada BSD (Berkeley
Software Distribution), es la primera aparición en escena de lo que más tarde se denominará
software libre. Estos primeros programas distribuidos bajo licencia BSD son utilidades para UNIX
y entre ellas se encuentra una implementación de un protocolo de comunicaciones, el TCP/IP.
En 1980 la NSF (National Science Foundation) mejora el protocolo TCP/IP y comienza a utilizarlo
para el intercambio de información entre ordenadores de universidades e investigadores de todo el
mundo. Esta mejora de TCP/IP era abierta y se distribuía con el código fuente de su
implementación, es el nacimiento de la red de Internet.
En 1984 aparece en escena una de las figuras más importante dentro del software libre, Richard
Stallman, que lidera en este año un proyecto científico denominado GNU dentro del Instituto
Tecnológico de Massachussets. Al año siguiente, aparece la primera versión de un sistema operativo
denominado igual que el proyecto lanzado, GNU (Gnu’s not Unix). Este sistema operativo es
gratuito y se distribuye junto con su código fuente bajo una licencia denominada Gnu Public
License (GPL).
En 1991, Linus Torvalds, un estudiante sueco de la universidad de Helsinky crea un kernel de
sistema operativo denominado Linux, y un año más tarde, fruto de la colaboración con el proyecto
GNU, aparece el sistema operativo GNU/Linux, que se denominó Linux, si bien, la mayor parte del
código procedía del proyecto GNU de Stallman.
1.1.Que es el software libre?
Software Libre
El Software Libre es el software que se caracteriza por proporcionar en sus licencias el permiso para
usarlo en cualquier máquina y en cualquier situación, para modificarlo, mejorarlo o corregirlo y
para redistribuirlo libremente.
Software libre no es software gratis, sino aquel que cumple con estas condiciones, si bien, no parece
posible obtener contraprestación económica por él, como de hecho ocurre, siendo de coste cero la
obtención de la práctica totalidad del software libre. Así pues, tenemos un concepto de software
opuesto al software propietario con el que no se distribuye el código fuente, impidiendo así su
modificación, y en cuyas licencias se indican los términos y las restricciones de uso y distribución,
en ocasiones bastantes fuertes.
Al respecto de la ingeniería de software y su aplicación en entornos de software libre, se han escrito
cierta cantidad de publicaciones. Dos de ellas llamaron mi atención, por lo que les presento un
extracto de cada una de ellas.
La Ingeniería de Software Libre y sus Herramientas Aplicadas.
La Ingeniería de Software Libre (ISL) permite que la metodología para el desarrollo de aplicaciones
se lleve a cabo de manera amplia, ya sea utilizando un enfoque estructurado de análisis y diseño
[Witten et al, 1996], [Yourdon, 1990], [Kendall & Kendall, 1998], un enfoque orientado por objetos

4. [Meyer, 1998] o algún otro tipo de paradigma; además no limita a los analistas y diseñadores a
utilizar una técnica de modelado y diagramación, como UML[Jacobson et al, 1999] o el modelado
estructurado, ni ofrece recomendaciones que permitan evaluar el nivel de calidad de una
organización, como lo promueve The Capability Maturity Model, CMM [Paulk et al, 1993]. Más
bien se fundamenta en que se debe trabajar en equipo, con el fin de fomentar una mayor
participación de elementos para el desarrollo óptimo de aplicaciones, sin dejar de lado la utilización
de técnicas y herramientas que aquí se mencionan. Además, se debe tener en cuenta el tiempo y los
recursos asignados para cumplir con las tareas involucradas, evitando la pérdida de tiempo o
abandono de los proyectos.
Con la ISL se pretende promover el uso de sistemas operativos, lenguajes de programación, bases
de datos y demás herramientas de software de carácter libre para la creación de aplicaciones.
En cierta medida, la ingeniería del software libre pretende desposeer de esa "magia" que parece que
es intrínseca a los desarrollos de software libre y cuantificar unos parámetros que nos permitan
predecir con exactitud costes, plazos y recursos humanos. Como consecuencia, aunque podemos
considerar que en la actualidad el software libre adolece de estos métodos en contraposición a las
formas de desarrollo tradicionales, también es cierto que, por los motivos que se están desarrollando
en este artículo, no le falta precisamente potencial para que esta situación cambie en el futuro.
Igualmente pretende ser una forma de introducir las virtudes de la ingeniería del software en el
desarrollo a veces demasiado anárquico de software libre. Será tarea de la ingeniería del software
encontrar formas para que los desarrolladores de software libre produzcan software de gran calidad
siguiendo paradigmas de creación, producción y mantenimiento que así lo certifiquen.
La ingeniería del software libre cuenta como objetivo a corto plazo poder realizar un análisis
completo al desarrollo de software libre que permita indagar profundamente en los procesos que
están involucrados, así como en las consecuencias que ciertas acciones tienen sobre el conjunto del
desarrollo.
...Utilizando símiles históricos, la situación que se vive en la actualidad en la generación de
software libre concuerda con la que describió de la economía Adam Smith hace casi tres siglos.
Smith constató que existían unos parámetros económicos claros (oferta y demanda), unas formas de
interaccionar (transacciones) y consecuencias económicas palpables. Sin embargo, no entendía el
modelo general que hacía que todo tuviera sentido y funcionara conjuntamente. Lo que hacía que
oferta y demanda cuadrasen era para él literalmente una "mano negra", que más tarde se dio a
llamar mercado. Hoy en día todos los ciudadanos, aún sin comprenderlo completamente, tenemos
más o menos una idea intuitiva de lo que es un mercado.
Gracias a la definición de mercado y a la investigación de los elementos que lo componen, las
ciencias económicas han dado un paso de gigante que junto con la revolución industrial ha llevado a
un bienestar en los países industrializados nunca imaginado.
En cierto sentido, esta situación se vive hoy en día en el software libre, donde nos encontramos con
que existe una especie de "mano negra" que hace que mágicamente se genere software libre. Sin
embargo, es necesario llegar a conocer con mayor profundidad las complejas interacciones para
poder comprender lo que está sucediendo y llegar a predecir el futuro. También debe servir como
punto de partida de acumulación de experiencia, ya que la ingeniería en realidad no es otra cosa que
un conjunto de experiencias exitosas debidamente empaquetadas para poder ser reproducidas una y
otra vez.
Desde hace cuatro décadas, la ingeniería del software se ha venido consolidando como una
rama importante dentro del campo de la informática en busca de métodos de desarrollo y
técnicas que permitan producir software de gran calidad con unos recursos limitados. Según la
definición del IEEE, la ingeniería del software es "un enfoque sistemático y cuantificable al

5. desarrollo, operación (funcionamiento) y mantenimiento del software: es decir, la aplicación de
la ingeniería del software". [IEEE 1993]
A pesar de que la ingeniería del software ha conseguido indudablemente notables éxitos,
también es cierto que ha sucumbido a lo que se ha venido a llamar la "crisis del software". A
día de hoy todavía sigue sin ser posible cuantificar con exactitud los plazos, costes, recursos
humanos y técnicas que lleven a un desarrollo exitoso del software, tal y como otras ramas de la
ingeniería en otros campos sí han sido capaces de hacer. Es más, incluso en los últimos años,
parece ser que la tendencia es volver a retomar viejos caminos bajo nuevas fórmulas. Ejemplo
de ello es la incipiente expansión de las técnicas de programación evolutiva (o extrema), que se
basan en gran parte en principios y técnicas ya conocidos y usados en la década de los 70.
Argumentar que la ingeniería del software se encuentra estancada es una consideración que, por
lo tanto, podemos tomar como muy válida.
Uno de los grandes problemas de la ingenería del software ha sido y es que no ha sabido
adaptarse consecuentemente a su propia definición. Esto es algo que se puede considerar como
una especie de traición a sí misma, a sus propios fundamentos. El enfoque sistemático y
cuantificable ha tenido siempre como barreras las propias de las formas en las que el software
se ha publicado y distribuido. El formato binario del software, la opacidad en los modelos de
negocios, los secretos y barreras comerciales, entre otros aspectos, han imposibilitado que
equipos independientes puedan, en demasiadas ocasiones, verificar de manera sistemática los
resultados obtenidos. Las "verdades" enunciadas son con frecuencia experiencias puntuales que
han sido generalizadas y dadas por válidas ante la falta de alternativas. En definitiva: la propia
forma de desarrollar, distribuir y comerciarlizar software ha sido la que ha llevado a la
ingeniería del software a la crisis.
Y es aquí donde el software libre puede dar nuevos aires a la ingeniería del software. Desde
hace más de una década, el software libre ha venido experimentando un gran auge en cuanto a
uso, aceptación y, por supuesto, desarrollo. Una idea de este crecimiento nos la puede dar el
hecho de que se haya calculado que el número de líneas de código de software libre se duplica
cada 18 meses. La implantación de Internet junto con las características de las licencias que
"invitan" a todo el mundo a formar parte del equipo de desarrollo, han propiciado que a día de
hoy no sólo podamos contar con el código fuente (un gran avance ya de por sí frente al software
propietario a la hora de ser abordado de manera sistemática), sino de los archivos de las listas
de correo donde viene plasmada la comunicación del proyecto, los repositorios de versiones
gracias a los cuales podemos ver la evolución, etc. De todas estas fuentes se puede extraer una
gran cantidad de datos de gran valor, en la mayoría de casos incluso de forma automática.
Podemos concluir, por tanto, que la apertura tanto del código como de la información asociada
al proceso de desarrollo que ofrece el software libre es clave para poder ser analizado, estudiado
y discutido de manera totalmente contrastable y abierta. La ingeniería del software sólo puede
salir ganando.
2.1. Ingeniería del software tradicional e ingeniería del software libre
Mediante el análisis del software libre se ganan, además, una serie de factores que difícilmente
ha podido conseguir la ingeniería del software tradicional que se discutirán en este punto.
El primero de ellos es la vertiente temporal que se añade al análisis. Y es que no se puede
olvidar que el proceso de creación de software cambia según cambian los paradigmas
tecnológicos, de educación, de programación, etc. Algo que ha sido enunciado hace 30 años
puede ser muy válido en la actualidad, aunque no cabe duda de que es muy probable que
necesite ser adaptado e incluso mejorado. De la evolución histórica se puede sacar mucha e
interesante información. Para muchas decisiones es de gran importancia sabear los lenguajes de
programación en alza, la evolución en cuanto a colaboradores de los proyectos (o, pongamos un

6. ejemplo, de proyectos que se dediquen a crear aplicaciones p2p), etc. Mediante un análisis
temporal continuo estaremos en disposición de tener un termómetro permanente de lo que está
ocurriendo en el mundo del software (libre).
Por otro lado, el análisis de software libre no plantea problemas de granularidad. La ingeniería
del software se ha basado con frecuencia en el análisis de unos pocos proyectos de software
debido en gran parte a la facilidad de acumular experiencias en entornos corporativos propios.
COCOMO, un modelo de cálculo de costes y tiempos para proyectos software, es un claro
ejemplo de esto, ya que fue creado en un departamento de la NASA a raíz de la experiencia en
poco más de un centenar de proyectos. Tomando como analogía las ciencias económicas,
podríamos decir que estamos hablando de un microanálisis. Por otra parte deberíamos tener, por
tanto, el macroanálisis, que trataría de cuantificar y estudiar la totalidad del software existente.
Mientras el macroanálisis ha sido históricamente ignorado por la ingeniería del software
tradicional (básicamente por los impedimentos descritos con anterioridad), el software libre da
la posiblidad de que se pueda ver la evolución a gran escala de muchos parámetros que faciliten
información relevante a la hora de tomar decisiones en entornos empresariales y proyectos de
software libre. Gracias a la ingeniería del software libre será posible, por consiguiente, medir un
proyecto dentro de entornos cerrados (microanálisis) y globales (macroanálisis), lo que puede
ser de gran ayuda para medir la salud del mismo. Por ejemplo, se podría analizar Evolution
dentro de GNOME y dentro del resto de software libre en general, obteniendo información
desde dos puntos de vista que, a buen seguro, enriquecerán a los que tengan que tomar
decisiones o quieran cuantificar ciertos parámetros.
2.2. Software libre e ingeniería del software libre
Cabe añadir, sin embargo, que la ingeniería del software libre no sólo pretende ser beneficiosa
para la ingeniería del software; también lo pretende ser, en gran medida, para el software libre.
Si los cálculo de plazos y de costes en los proyectos de software estudiados tradicionalmente
(en su gran mayoría de software propietario) son difícilmente cuantificables, en la actualidad en
el mundo del software libre son prácticamente utópicos. En cierta medida, la ingeniería del
software libre pretende desposeer de esa "magia" que parece que es intrínseca a los desarrollos
de software libre y cuantificar unos parámetros que nos permitan predecir con exactitud costes,
plazos y recursos humanos. Como consecuencia, aunque podemos considerar que en la
actualidad el software libre adolece de estos métodos en contraposición a las formas de
desarrollo tradicionales, también es cierto que, por los motivos que se están desarrollando en
este artículo, no le falta precisamente potencial para que esta situación cambie en el futuro.
Igualmente pretende ser una forma de introducir las virtudes de la ingeniería del software en el
desarrollo a veces demasiado anárquico de software libre. Será tarea de la ingeniería del
software encontrar formas para que los desarrolladores de software libre produzcan software de
gran calidad siguiendo paradigmas de creación, producción y mantenimiento que así lo
certifiquen. Discusiones sobre la recomendación sobre si el software libre debería adoptar UML
para la especificación de documentos, debería seguir metodologías evolutivas o formas de
desarrollo que desemboquen en software con calidad ISO 9000, son interesantes pero van más
allá de lo que este artículo pretende abarcar. Aún así, el autor está seguro de que en un futuro
serán parte indispensable dentro de la ingeniería del software libre.
La ingeniería del software libre también pretende acabar con muchas afirmaciones
pseudo-científicas, casi bordeando la fantasía, de muchos ensayos sobre software libre. A la vez
se busca poner fin a muchas teorías especulativas y prejuicios fundamentados en apreciaciones
propias y/u opiniones personales difícilmente contrastables y, generalmente, con escasa
finalidad práctica. Estamos ante la posibilidad de analizar el pasado y el presente para poder
predecir el futuro con mayor precisión. Las discusiones se deben basar en datos objetivos y
contrastables y no en elucubraciones o percepciones parciales de la realidad. Si retomamos el
símil de la economía, lo que se está haciendo en demasiadas ocasiones es hablar de la economía

7. de un país sin ni siquiera mirar los datos macroeconómicos. Esto, por lo que cualquier
economista se llevaría las manos a la cabeza, es bastante común en la actualidad en las
previsiones sobre las tendencias del software en general y del software libre en particular.
La ingeniería del software libre cuenta como objetivo a corto plazo poder realizar un análisis
completo al desarrollo de software libre que permita indagar profundamente en los procesos
que están involucrados, así como en las consecuencias que ciertas acciones tienen sobre el
conjunto del desarrollo. Por otra parte, se pretende tener en un espacio de tiempo corto una
adaptación de modelos de previsión de costes como lo es COCOMO en el software propietario.
En estos primeros pasos también se quiere llamar la atención de otros grupos de investigación
para que se den cuenta de la importancia que puede llegar a tener y ayuden en el avance de la
misma. Asimismo, muchos investigadores de los campos de la economía, sociología o
psicología seguro que pueden estar interesados en estudiar esta forma tan vanguardista de
desarrollo software en la que no están del todo claras las relaciones sociales y económicas que
se establecen.
Aunque hablar de objetivos a largo plazo en este momento puede parecer premeditado, me
atrevo a decir que, en mi opinión, la ingeniería del software libre tiene tanto que ofrecer que
puede resultar una rama clave para sacar de la crisis a toda la ingeniería del software
tradicional.
Utilizando símiles históricos, la situación que se vive en la actualidad en la generación de
software libre concuerda con la que describió de la economía Adam Smith hace casi tres siglos.
Smith constató que existían unos parámetros económicos claros (oferta y demanda), unas
formas de interaccionar (transacciones) y consecuencias económicas palpables. Sin embargo,
no entendía el modelo general que hacía que todo tuviera sentido y funcionara conjuntamente.
Lo que hacía que oferta y demanda cuadrasen era para él literalmente una "mano negra", que
más tarde se dio a llamar mercado. Hoy en día todos los ciudadanos, aún sin comprenderlo
completamente, tenemos más o menos una idea intuitiva de lo que es un mercado.
Gracias a la definición de mercado y a la investigación de los elementos que lo componen, las
ciencias económicas han dado un paso de gigante que junto con la revolución industrial ha
llevado a un bienestar en los países industrializados nunca imaginado.
En cierto sentido, esta situación se vive hoy en día en el software libre, donde nos encontramos
con que existe una especie de "mano negra" que hace que mágicamente se genere software
libre. Sin embargo, es necesario llegar a conocer con mayor profundidad las complejas
interacciones para poder comprender lo que está sucendiendo y llegar a predecir el futuro.
También debe servir como punto de partida de acumulación de experiencia, ya que la ingeniería
en realidad no es otra cosa que un conjunto de experiencias exitosas debidamente empaquetadas
para poder ser reproducidas una y otra vez.
3. Hacia un sistema de medición y análisis de
software libre
La medición y el análisis de datos relacionados con el desarrollo de software libre se hace
imprescindible para alcanzar los objetivos que la ingeniería del software libre persigue.
Además, es de capital importancia que los procesos que se desarrollen puedan ser verificados
por terceras personas, por lo que las herramientas utilizadas deberían tener una licencia de
software libre.
Para hacer la medición y el análisis lo más versátil posible, se han diferenciado varias etapas,
tal y como se puede observar en la (gran) figura al final de este punto.
Es importante denotar que todos los datos provienen directa o indirectamente de parámetros y
características de software libre. Esto se debe a que suelen ser accesibles gracias a que se tiende
a seguir un modelo de desarrollo lo más abierto posible. Mediante el uso de varias herramientas
independientes entre sí se pretende obtener los datos de diferentes fuentes.

8. Es importante que los resultados de las diferentes herramientas se almacenen en un formato
intermedio e independiente de las mismas. De esta forma, la segunda fase se facilita
sobremanera, ya que los datos almacenados en ese formato intermedio podrán analizarse
convenientemente por medio de herramientas realizadas al efecto o, si es necesario, pueden ser
fácilmente convertidos en otro tipo de formatos.
Mientras que el objetivo de la primera fase era extraer el mayor número de parámetros
cuantificables, la segunda fase es un terreno aún por explorar; desde el simple análisis directo
de los datos hasta la utilización de complejos algoritmos estadísticos que permitan ir
conociendo más a fondo el software libre.
Antes de mostrar pormenorizadamente las herramientas existentes para las cada una de las
fases, se debe mencionar que aún cuando la arquitectura completa del sistema puede parecer
compleja, esto no es así. Existe una gran modularidad e independencia y el "pegamento" que da
sentido a todo esto es la capa donde viene especificado que los datos se almacenarán en un
formato intermedio e independiente. Esto quiere decir que una aplicación de extracción de
parámetros de código fuente es totalmente independiente de otra que toma datos debidos al
desarrollo distribuido. Es más incluso lo es de otra que también se encarga de estudiar el código
fuente. Lo que debe preocupar a las aplicaciones es ofrecer sus resultados en el formato
intermedio, haciendo uso de filtros si es conveniente.
4. Extracción de datos (Primera fase)
El primer paso engloba agrupar, ordenar y analizar convenientemente el código fuente y los
flujos de información existentes en los proyectos de software libre. La finalidad principal es
conseguir que todo esto se haga lo más automáticamente posible. En realidad, se pretende
recabar todo tipo de información para poder ser analizada y estudiada detenidamente con
posterioridad. Como se ve, se trata de un proceso iterativo, ya que los resultados de los
primeros análisis nos dirán por dónde seguir buscando y cuáles deben ser los siguientes pasos
lógicos dentro del estudio del software libre.
A continuación, se muestran las diferentes fuentes que se pueden analizar, así como las diversas
herramientas que existen para obtener resultados a partir de esas fuentes.
4.1. Código Fuente
El código fuente es, con diferencia, el mayor continente de información en cuanto al desarrollo
de proyectos de software libre se refiere. De él se pueden extraer no sólo parámetros globales
como el tamaño, el número de ficheros, sino que puede ser investigado con la finalidad de
encontrar parámetros de participación (número de desarrolladores), de programación (lenguaje
de programación, además de la posibildad de utilizar diferentes métricas de programación), de
líneas de código (tanto lógicas como físicas), número de comentarios, etc. etc. Una de las
primeras aproximaciones existentes a día de hoy es el cálculo del número de líneas físicas de
proyectos de software libre y el uso del modelo COCOMO (clásico) para obtener resultados en
cuanto al tiempo, al coste y a los recursos humanos necesarios para su desarrollo.
Evidentemente, este primer análisis se encuentra en una fase bastante primitiva, pero la
correlación con otras fuentes permitirá mejorar (y/o adaptar) los resultados en el futuro.
4.1.1. CODD
CODD es una herramienta diseñada por Vipul Ved Prakash y Rishab Aiyer Ghosh que analiza
el código fuente de los paquetes de software libre y asigna cuotas de autoría (en bytes) a los que
han participado en el desarrollo. También ha sido diseñada e implementada para extraer y
resolver dependencias entre paquetes como se verá a continuación.
CODD consta de una serie de procesos que han de ejecutarse de manera consecutiva y que
guardan sus resultados en ficheros denominados codds (en minúsculas). Para cada paquete de
software libre se generará un codd, que contendrá información sobre el mismo, ya sea extraida
del propio paquete o de la correlación con codds de otros paquetes.

9. Al final del proceso, cada codd debería contener la siguiente información:
nombre del paquete, generalmente más versión (p.ej. evolution-0.13)
créditos de autoría (y bytes de contribución)
archivos de código
archivos de documentación
interfaces
código compartido
implementaciones externas o no resueltas
implementaciones resueltas
metainformación
Es importante ver que los codds se crean en la primera iteración con información que extraen
directamente de los paquetes. Como todos los resultados de los procesos intermedios se
guardan en el mismo codd, no podremos saber a simple vista en qué paso dentro del algoritmo
de CODD nos encontramos. La única forma de saber esto es por inspección del contenido del
codd.
El proceso que sigue CODD para obtener estos datos es la que se muestra en la siguiente figura:
Extracción de ficheros: La subrutina init toma el paquete (o paquetes) que se le ha pasado por
la línea de instrucciones, lo descomprime y explota si es necesario, e intenta identificar
recursivamente el tipo de ficheros que contiene el paquete.
Selección de ficheros: Se toman los archivos de código, de documentación, interfaces e
implementaciones no resueltas junto con su tamaño en bytes, su suma MD5 y su ruta relativa
dentro del paquete. Esto se hace comparando las extensiones de los archivos del paquete.
CODD contiene una serie de arrays en los que están almacenadas las extensiones que pueden
tener los archivos de código (p.ej. ".c" para C o ".pl" para Perl), de documentación, etc. CODD
almacena como interfaces aquéllos archivos ".h" que tienen un archivo ".c" en el paquete (el
algoritmo que se usa aquí depende parcialmente del lenguaje de programación que se esté
analizando). Las llamadas a interfaces en archivos de código (p.ej. ".c" para C) que no tengan
su correspondiente interfaz en el paquete (p.ej. ".h" para C) pasarán a englobar la categoría de
implementaciones no resueltas, que en futuros pasos dará pie a la resolución de dependencias.
Base de datos de dependencias: En el tercer paso se crean dos bases de datos para encontrar
código compartido y dependencias. En la primera, de nombre ’codefile_signatures’, se
almacenan todas las sumas MD5 de los ficheros de código. Para ello, CODD se recorre todos
los codds, mira en las entradas correspondientes a los ficheros de código y añade un par (suma
MD5 y nombre de fichero, paquete). Del mismo modo insertará pares para los interfaces en la
base de datos de nombre ’interfaces’. En este caso, los pares son del tipo (nombre de fichero,
paquete).
Código compartido: En el siguiente paso, CODD recorre otra vez todo los codds y mira si los
archivos de código aparecen más de una vez en la base de datos (en realidad, si coinciden su
nombre y su suma MD5). Si esto ocurre, el archivo se encuentra como mínimo en dos paquetes,
por lo que se añadirá en la sección del codd dedicada al código compartido (’shared’) la
siguiente información por cada paquete que también contenga el fichero: (fichero de código,
ruta, MD5, tamaño) => nombre del paquete.
Resolución de dependencias: CODD realizará un proceso parecido al punto anterior para la
resolución de dependencias. Buscará las implementaciones no resueltas en los codds y
comparará sus sumas MD5 con las que hay en la base de datos de interfaces. Si hay
coincidencia, el interfaz se borrará de la sección de interfaces no resueltas (’unresolved
interfaces’) a la de interfaces resueltas (’resolved’). Además, se proporcionará una lista con
todos los paquetes en los que está implementada.
Búsqueda de autores: Es entonces cuando CODD realiza la tarea que ha hecho que sea
conocido: la búsqueda de autoría (’ownergrep’). Para ello, recorre todos los ficheros de código

10. y documentación cuya ruta está almacenada en cada codd y extrae, siguiendo ciertos algoritmos
de comparación de patrones, a los autores. La información sobre los autores se almacenan en la
sección de créditos (’credits’) del codd.
Resolución de código compartido: En la sección del código compartido (’shared’) del codd
tenemos todavía ficheros y una lista de paquetes que también lo tienen. Como este fichero sólo
puede ser asignado a un paquete, lo que hace CODD es buscar por su autor (’ownergrep’) en el
propio fichero y asignarlo al paquete del cual el autor es el autor principal.
Los últimos bloques de la figura muestran que los codds deberán ser entonces transformados a
un formato intermedio e independiente en XML a partir del cual se pueden realizar ya técnicas
de análisis, correlación o clustering como veremos más adelante en este artículo. Como se
puede ver de la figura, existe una herramienta de transformación de codds a SQL, que realiza
también tareas de normalización de las tablas. Esta herramienta ha sido concebida para crear
CODDWeb, una interfaz web para poder visualizar los resultados de CODD a través del
navegador.
CODD es una herramienta muy potente, aunque tiene algunos puntos flacos. El más importante
es que todavía no tiene ninguna forma de agrupar las diferentes formas en las que aparece un
autor. Por ejemplo, Miguel de Icaza aparece varias veces con diferentes nombres o direcciones
de correo. Aglutinar todas sus referencias en una única sería lo más correcto. En este sentido, se
está creando una base de datos con relaciones 1 a N por autor.
Por otra parte, el proceso de ejecución de CODD no es lo más simple que podría ser. Carece de
un buen sistema de configuración, hay que ejecutarlo como superusuario y la secuencia de
procesos que hay que ejecutar no está agrupada bajo un único guión de shell, sino que hay que
correrla de manera manual.
4.1.2. SLOCcount
SLOCcount, una herramienta creada por David A. Wheeler, cuenta el número de líneas físicas
ofreciendo como resultado básicamente el lenguaje de programación utilizado. Además, utiliza
el modelo COCOMO clásico para, a partir de una serie parámetros y algoritmos
preconfigurados, obtener el coste, los plazos y los recursos humanos necesarios para haber
realizado una (única) entrega del software.
El algoritmo que utiliza SLOCcount consta de una serie de fases: en un primer paso
SLOCCount busca ficheros de código por su extensión dentro del árbol de archivos del
proyecto. Cuando encuentra un archivo con código, utiliza una serie de métricas para
determinar si de verdad lo que contiene el archivo es código y está en el lenguaje de
programación que se determina de su extensión. En caso de ser así, contará las líneas de código
que no sean comentarios ni espacios en blanco (líneas físicas) e incrementará el contador para
dicho lenguaje en su número.
Los datos que devuelve SLOCcount son los siguientes:
Nombre del proyecto
Número de líneas del proyecto
Número de líneas en un lenguaje de programación
Tiempo estimado de esfuerzo de desarrollo (COCOMO básico)
Estimación de tiempo de desarrollo (COCOMO básico)
Número estimado de desarrolladores (COCOMO básico)
Estimación del coste de desarrollo (COCOMO básico)
Siendo estrictos, las estimaciones realizadas a partir de COCOMO básico no deberían
corresponder a la fase de extracción de datos, sino a una posterior de análisis.
En la actualidad, SLOCCount devuelve los resultados en texto plano, aunque existe la
posiblidad de que los devuelva entre tabuladores para que puedan ser introducidos en una base
de datos. Existe una herramienta, de nombre sloc2html, que permite transformar los resultados
a vistosas páginas HTML.

11. 4.1.3. Métricas de software
La disponibilidad de todo el código permite que se le puedan pasar todo tipo de métricas de
software, como por ejemplo el cálculo de puntos de función. Este aspecto todavía no ha sido
estudiado con mucho detenimiento, pero parece que de la información que se puede obtener
mediante estos métodos se podrán realizar comparaciones entre proyectos, lenguajes de
programación, etc. etc.
4.2. Intercambio de información directa entre
desarrolladores
El intercambio más importante de información no incluido en el código corre a cargo de listas
de correo electrónico, canales IRC y documentación. En el caso de las listas de correo-e, los
mensajes son almacenados en archivos que deben ser analizados. En cuanto a la documentación
y al IRC todavía no está muy claro lo que buscamos y sobre todo, cómo hacerlo de forma
automática.
4.2.1. MailListStats
MailListStats toma los archivos de texto que generan GNU Mailman, majordomo u otros
gestores de listas de correo-e. Este tipo de archivos suelen estar accesibles mediante HTTP.
MailListStats se descarga el archivo con los mensajes durante un cierto espacio temporal
(generalmente un mes) de la lista y toma de las cabeceras de los mensajes tanto el autor como la
fecha de envío.
Datos que se pueden extraer de las estadísticas de las listas de correo-e:
Nombre (y dirección) del autor
Fecha
Nombre de la lista (de forma que podamos adjudicar las estadísticas a un proyecto o
metaproyecto)
En un futuro se pretende añadir la capacidad de seguir el hilo de la discusión o incluso alguna
forma de cuantificar la longitud del mensaje, aunque para ello habrá que buscar métodos para
eliminar las líneas que corresponden a un mensaje original al que se está respondiendo o a las
firmas PGP.
4.2.2. Estadísticas del IRC (perlbot + IRC stats)
Más allá del número de personas que se congregan en un canal, no parece muy claro qué otros
parámetros interesantes se pueden extraer de las estadísticas del IRC. Sin embargo, también es
verdad que la existencia de muchos bots que las generan semiautomáticamente hace que no
haya que molestarse mucho en su implementación.
En las pruebas que he hecho por ahora, la toma de datos no ha sido posible. Muchos canales no
quieren tener un bot que les "espíe", por lo que hay que ir con sumo cuidado y pedir en primer
lugar permiso.
4.3. Herramientas de desarrollo distribuido
El desarrollo de software libre se basa en gran parte en unas herramientas que permiten
sincronizarse con el trabajo de los diferentes desarrolladores del proyecto, de manera que la
distribución geográfica no suponga un problema. Los sistemas de control de versiones y los
gestores de erratas (también usados ocasionalmente para tareas de planificación) se han
convertido en herramientas imprescindibles para proyectos de software libre grandes, y no tan
grandes. Estos sistemas suelen registrar las interacciones con los desarrolladores y, por tanto,
una vez que se consiguen estos registros puede monitorizarse de manera bastante sencilla todo
el proceso de desarrollo.
4.3.1. Sistema de control de versiones: cvstat2
El desarrollo distribuido (y a veces simultáneo) en proyectos de software libre se organiza
mediante el uso de un sistema de control de versiones. El más utilizado en la actualidad por los
proyectos de software libre es el CVS. Un análisis de los cambios que se van realizando al
repositorio que estos sistemas mantienen, nos dará mucha información acerca de la

12. participación de desarrolladores, además de la posibilidad de ver si existen ciclos de
desarrollos. El estudio de los resultados obtenidos por esta vía se puede extender de manera
notable si los datos obtenidos los podemos correlar con las inspecciones de código y la
actividad en las listas de correo, así como con datos socio-laborales de los desarrolladores.
Cvstat2 es una extensión del cvstat de J.Mallet que ha sido concebido para poder funcionar de
manera distribuida. El objetivo es que junto con la aplicación de extracción de datos, se
distribuya un interfaz web simple e intuitiva a través de la cual se pueda ver la evolución del
proyecto en el CVS. De esta manera, cualquier equipo de desarrollo podrá descargarse,
instalarse y configurarse el software y medir sus interacciones con el repositorio CVS. Además,
estos datos serán exportados, de manera que se descarga el procesamiento de un repostorio
central de datos en formato intermedio.
El objetivo de la distribución hace que el software que se tenga que generar sea lo más fácil de
conseguir e instalar. En un principio, la idea es que una vez instalado mediante procesos
automáticos, sea la propia aplicación la que se encargue de actualizar sus datos y exportarlos,
de manera que la manipulación humana sólo se tenga que dar en los pasos de instalación y
configuración.
Por otro lado, la distribución de esta herramienta puede ser una buena forma de promocionar la
investigación que se va a realizar, ya que todo el mundo puede contar con cvstat2 para su
propio proyecto y, si exporta sus datos, se sentirá parte de una gran comunidad que aporta para
la investigación del fenómeno del software libre.
Datos que podemos obtener vía cvstat2:
fecha del commit (acción por la cual un desarrollador sincroniza su versión local con la
existente en el repositorio)
fichero modificado
desarrollador
número de versión (CVS)
número de líneas añadidas
número de líneas borradas
En el apéndice de este trabajo se detalla el proceso de implementación de esta aplicación, ya
que ha sido generada como parte del trabajo para la asignatura de doctorado "Programas
Libres". Como se podrá observar, se ha hecho hincapié en que todas las acciones manuales se
hagan en el momento de instalación y el resto del proceso sea totalmente automático.
4.3.2. Sistema de control de erratas: BugZilla, estadísticas de errores críticos
En muchos proyectos grandes de software libre, la existencia de errores críticos propicia que la
publicación de una versión estable se retrase. Debian y GNOME son dos ejemplos de ello,
aunque seguro que hay muchos más. La incidencia de errores críticos es muy importante a la
hora de realizar la publicación definitiva en grandes proyectos de software libre. Un ejemplo de
radiante actualidad nos lo ha dado la segunda versión de la plataforma GNOME. Su publicación
definitiva se ha retrasado varias semanas, porque tenía varios errores críticos que no se había
conseguido corregir.
Datos que se pueden extraer:
fecha de apertura de una errata
catalogación de una errata
número de las interacciones
fecha de las interacciones
autor de las interacciones
fecha de cierre de una errata
En la actualidad no existe ninguna herramienta que extraiga los datos que se acaban de
mencionar. El sistema de control de erratas, BugZilla, cuenta por ahora con la funcionalidad
para extraer estadísticas del número de erratas abiertas, cerradas y existentes, pero esos datos

13. son insuficientes para nuestros propósitos. De todas formas, como BugZilla utiliza una base de
datos para almacenar los datos, no cabría desechar la idea de pedir una copia (o acceso directo)
para que pudiera ser analizada completamente.
En el último caso, se podría crear un parser que tomara de manera automática los datos
estadísticos de las páginas web con los informes de errata, aunque esto plantea siempre el
problema de que un cambio en el HTML de Bugzilla signifique que debemos adaptar el
programa que parsea esos datos.
4.5. Otras Herramientas
Además de las herramientas ya presentadas, existen otro tipo de herramientas que no entran en
la clasificación que hemos seguido y que, por tanto, serán mostradas a continuación.
4.5.1. SFparser
SFparser recorre las páginas web de todos los proyectos que se hospedan en SourceForge y
obtiene información sobre los desarrolladores que están dados de alta, las últimas publicaciones
de todas las ramas del proyecto, así como los datos que lo describen y lo ordenan dentro de
SourceForge (licencia, lenguaje de programación, destinatarios, estado...).
SFparser es un script en Perl muy sencillo que empieza por el proyecto con identificador
número 1 y, en el caso de que exista dicho proyecto, se descarga las siguientes páginas HTML:
la página principal, la de la listas de correo-e, la del CVS y la de la descarga de ficheros.
La lista de parámetros que devuelve SFparser es la siguiente:
Nombre del proyecto
Página web
Descripción
Categorización
Tipo de proyecto
Estado del desarrollo
Lenguaje(s) de programación
Lenguaje natural
Licencia(s)
Audiencia
Número de desarrolladores
Nombres de usuario
"Cargos" dentro del proyecto
Existencia de CVS
Existencia de listas de correo
Nombre de las listas
Paquetes (incluso de diferentes ramas)
Versiones
Fecha de publicación
Tamaño
Descargas
Información sobre la existencia o no de CVS y listas de correo puede ser utilizada por cvstat2 y
MailListStats para descargarse el repositorio en un caso y los archivos en el otro y proceder a su
análisis como se ha descrito con anterioridad.
Además, con el mismo software y ligeras modificaciones, se podrían extraer datos de sitios que
utilizan SourceForge con ligeras modificaciones como son BerliOS y Savannah.
4.5.2. codd-find-latest
Codd-find-latest es una aplicación que toma una lista de paquetes, se queda con las últimas
publicaciones y desecha las más antiguas. El algoritmo que sigue es el siguiente: si existen
paquete-1.2.3.tar.gz y paquete-1.3.4.tar.bz2, supondrá que el segundo es más reciente. Es una

14. herramienta muy práctica en el caso de que es estén estudiando repositorios de código que sólo
requieran las últimas versiones de los paquetes. Éste es, por ejemplo, el caso de CODD, ya que
al comprobar el código compartido entre varios aplicaciones, se confundiría de manera notable
si existieran dos versiones de la misma aplicación.
4.4. Datos de otras fuentes
A diferencia de los proyectos de software "tradicionales", con el software libre en muchos casos
se desconocen los recursos humanos. La situación socio-laboral, económica, geográfica y
cultural de los integrantes de los proyectos de software puede ser muy dispar y, a buen seguro,
tiene repercusión en la forma en la que un proyecto de software evoluciona.
4.4.1. Datos laborales (y personales) de los desarrolladores
Existen una serie de datos que no se podrán extraer de manera automática y que, sin embargo,
son muy interesantes para conocer más a fondo la comunidad de software libre. Básicamente
este tipo de datos son datos personales de los desarrolladores.
Datos personales interesantes:
Nombre
Nacionalidad
Fecha de nacimiento
Sexo
Formación
Quizás algún día, si este proyecto tiene la suficiente buena prensa y los desarrolladores se
muestran partidarios sería interesante crear una especie de contador de desarrolladores al estilo
LinuxCounter. A día de hoy esto es una idea poco práctica que se puede descartar.
Además de los datos de carácter personal, los datos laborales aportarían una visión muy rica al
conjunto. El hecho de poder saber qué desarrolladores se dedican profesionalmente al
desarrollo de un proyecto de software libre, nos permitirá hacer correlaciones y sacar
conclusiones no menos interesantes. Por eso, para entornos reducidos y conocidos, se debería
poder contar con una base de datos con los nombres, nombres de usuario, número de horas a la
semana y fechas en la que estuvo contratado.
Los resultados obtenidos pueden ser utilizados para, en conjunción con otras fuentes, poder
calcular costes y tiempos de desarrollo. Una de las primeras acciones que podrían llevar a cabo
es integrar estos resultados en la algoritmia de SLOCcount para ponderar convenientemente el
modelo de COCOMO (o incluso realizar un nuevo modelo que sea más conforme con los
desarrollos de software libre).
Datos laborales interesantes:
Nombre
Fechas en las que ha estado/estuvo empleado
Tiempo parcial/completo
Proyecto para el que estuvo empleado
En GNOME, KDE, Apache o incluso Linux estamos hablando de comunidades en las que este
tipo de datos se podría conseguir con una fiabilidad bastante aceptable.
4.4.2. Encuestas
También existe la posibildad de referirse a encuestas a desarrolladores que se han hecho hasta
la fecha. Por desgracia, las encuestas tienen la desventaja de que no pueden ser reproducidas.
Aún así, los resultados de las encuestas pueden servir de punto de partida para analizar el
software libre e interpretar los resultados que las diferentes fuentes y análisis pueden dar.
Cierto tipo de aspectos hacen necesaria la realización de encuestas. Es difícil cuantificar la
motivación, estado de ánimo u opinión de los desarrolladores de software libre. También es
siempre muy interesante observar que cierto tipo de desarrolladores tienden a agruparse en
cierto tipo de proyectos, mientras que otros lo hacen en otros.
5. Formato intermedio e independiente

15. En un principio, se intentará que todas las herramientas utilizadas devuelvan los resultados en
un formato intermedio e independiente que permita aglutinar los resultados de las diferentes
herramientas de manera sencilla. El formato elegido debe ser muy flexible, ya que puede que en
un futuro próximo se le añadan más. A día de hoy, lo mejor sería utilizar un formato XML, ya
que cumple todos los requisitos comentados con anterioridad y además permite la
compatibilidad hacia atrás. También hay que tener en cuenta que los conversores de XML a
cualquier otro tipo de formato que se desee no serán muy difícil de implementar.
5.1. Herramientas de conversión a XML
Como hemos partido de aplicaciones de extracción de datos ya existentes que utilizan sus
propias formas de almacenamiento de datos, puede ser necesario la creación de herramientas
que conviertan los datos del formato original al formato intermedio e independente en XML.
Un ejemplo de esto podría ser CODD que, como hemos visto con anterioridad, utiliza un
formato propio de ficheros. Para llevar a cabo la conversión hará falta una aplicación que bien
podría llamarse codd2xml. En el caso de SLOCcount, también será necesario una especie de
sloc2xml.
5.2. Herramientas de conversión a otra cosa
El formato intermedio e independiente en XML plantea muchas ventajas, pero puede no ser el
más idóneo para la realización de ciertas tareas. En el caso de querer generar un interfaz web
para acceder a los datos, lo más sencillo (y eficiente) es utilizar una base de datos relacional.
Será, por tanto, necesario tener alguna forma para convertir XML a SQL. En este sentido, habrá
que estudiar cómo realizar optimizaciones, como por ejemplo normalizar las tablas SQL
generadas.
Del mismo modo, muchas herramientas de estadística utilizan un formato de entrada muy
simple denominado SPSS. Estas herramientas permiten crear correlaciones y diagramas con
bastante rapidez, ya que han sido diseñadas para ser utilizadas por sociólogos y psicólogos para
el análisis de encuestas. La conversión a SPSS tiene dos vertientes interesantes: abre la
posibilidad de utilizar este tipo de herramientas y, sobre todo, puede facilitar sobremanera el
que científicos de otras ramas puedan obtener los datos en un formato con el que estén
familiarizados para proceder a su análisis. Todo lo que sea despertar interés hacia la ingeniería
del software libre en otras ciencias es de gran importancia.
6. Análisis, procesado y visualización de los datos
(Segunda fase)
Hemos visto que la primera fase trata la extracción de datos de diferentes fuentes para
almacenarlos posteriormente en un formato intermedio que sea independiente de las fuentes y
de las herramientas. Esta primera fase, aunque todavía incompleta, se encuentra mucho más
madura que la fase que se va a presentar ahora. Parece bastante claro cuáles son las fuentes que
se quieren investigar y sólo faltan algunos huecos en las implementaciones para que se dé por
acabada.
Una vez que tenemos los datos, se abre ante nosotros un mundo lleno de posibilidades. El
volumen de datos del que disponemos y la prácticamente carencia de análisis hace que se
puedan vislumbrar en un futuro próximo gran cantidad de estudios en lo que se refiere al
análisis, procesado e interpretación de los resultados.
En los siguientes apartados se presentarán diferentes propuestas que van encaminadas a tratar
los datos que tenemos y hacerlos más comprensibles. Se mostrarán varias formas de tomar los
datos y analizarlos, aunque seguro que en los próximos tiempos se crearán más.
6.1. Interfaz web
La interfaz web persigue la finalidad de captar la atención hacia el proyecto de dos maneras
diferentes: la primera, más obvia, es mostrar los resultados del mismo a todo aquél que lo
desee. La segunda es proporcionar los métodos necesarios a los desarrolladores que lo deseen
para poder participar en el proyecto. La idea es generar una serie de aplicaciones que pueda

16. ejecutar en su proyecto. Esto puede proporcionarle por una parte cierta realimentación sobre las
contribuciones al proyecto, así como estadísticas que satisfagan su curiosidad. Por otra, podrá
tener la posibilidad de exportar estos datos, de manera que se integren en el proyecto global.
Por ahora existe una arquitectura para crear diferentes interfaces web implementada en PHP y
que utiliza una base de datos relacional como almacén de datos.
6.2. Herramientas de análisis de clústers
Uno de los principios a la hora de investigar elementos desconocidos es intentar agruparlos por
sus características de manera que podamos realizar una categorización. En nuestro caso el gran
volumen de datos permite obtener núcleos reducidos que pueden ser estudiados de manera más
sencilla. Existe una amplia teoría matemática de clusters, que el autor de este documento
desconoce por el momento, pero que se podría aplicar para la resolución del problema.
6.2.1. Clusters de desarrolladores: codd-cluster
Codd-cluster es una aplicación diseñada por Rishab Aiyer Ghosh que busca agrupaciones de
desarrolladores y sus interdepencias a partir de los datos de CODD. En un documento donde se
detalla el sistema, se explica de manera gráfica la finalidad de codd-cluster:
"a, b, c y d forman un grupo de autores que trabajan conjuntamente y g, h, i y j otro grupo. El
primer grupo trabaja en los proyectos P y Q, de manera que P y Q son proyectos relacionados,
mientras que el segundo lo hacen en los proyectos J y K. J tienen dependencias de código de P,
por lo que podemos decir que el grupo 2 depende del trabajo del grupo 1." (Ghosh)
La finalidad es cuantificar este tipo de situaciones. Partiendo de los datos de CODD, que suelen
ser los siguientes {nombre de proyecto, desarrollador, contribución en porcentaje}, se pretende
crear un grafo donde los vértices sean proyectos y las líneas que los unan sean desarrolladores
en común. Los enlaces tendrán un peso que dependerá del grado de la aportación de
desarrolladores en común (algo que se ha venido a llamar comunalidad) y del grado de código
compartido.
Ghosh creó una serie de funciones para calcular el peso entre dos proyectos P y Q:
weight(P,Q) = combifunction(commonality(P,Q), sharedcontrib(P,Q))
El peso entre dos proyectos P y Q es la función combinativa entre la comunalidad y la relación
de código compartido de los proyectos P y Q. Por ahora, se ha adoptado la multiplicación para
la función combinativa, aunque si se encuentra una función que se adapte mejor a la realidad, se
modificará:
combifunction(a,b) = a * b
Que la función combinativa sea la multiplicación implica, a priori, que la comunalidad y la
relación de código compartido tienen el mismo peso en el resultado. Esto no tiene por qué ser
así en análisis futuros.
La comunalidad se calcula de la siguiente forma:
commonality(P,Q) = (numberOfAuthors(R) / numberOfAuthors(P)) *
(numberOfAuthors(R)/numberOfAuthors(Q))
donde R es el conjunto de autores en común en los proyectos P y Q.
R = intersection(P,Q)
Por tanto, la comunalidad es la multiplicación de la relación de desarrolladores comunes en los
proyectos. Si P cuenta con 7 desarrolladores y Q con 5, y hay dos desarrolladores comunes
entre P y Q, tendremos:
commonality(P,Q) = 2/7 * 2/5 = 4/35 = 0.11
La comunalidad es siempre menor que 1 ó igual a 1 si todos los autores son comunes a los
proyectos P y Q. En general, tiende a ser un número pequeño, siendo raro el caso en que supera
0.5.
La relación de código compartido entre dos aplicaciones, por su parte, se calcula con las
siguientes fórmulas:
sharedcontrib(P,Q) = contribsum(R,P) * contribsum(R,Q)

17. donde la suma de contribuciones se calcula como:
contribsum(R,P) = forall (r in R) {sum += contrib(P,r);}
contrib(P,r) es la contribución relativa del autor r al proyecto P. Recordemos que R es el
conjunto de autores que P y Q tienen en común.
En palabras, la suma contributiva es el sumatorio de todas las aportaciones (en tanto por 1 con
respecto al total del proyecto) de los autores comunes a P y Q. La suma contributiva de estos
dos proyectos se multiplicarán para obtener la relación de código compartido.
Por ejemplo, si los autores comunes han realizado la mitad del proyecto P y un tercio del
proyecto Q, la relación de código compartido será: 0.5 * 0.33 = 0.167. Como vemos, esta
relación tiene también una cota máxima de 1 que se da cuando todos los autores son comunes
(ya que entonces habrán realizado el código completo en los dos proyectos).
Concluyendo, entre dos proyectos cualquiera existirá siempre un peso entre 0 y 1 que tenderá a
ser mayor cuanto mayor sea el número de desarrolladores y código en común.
Codd-cluster permite dado un valor límite del peso, seguir un grafo para crear un cluster
alrededor de una aplicación. La aplicación seguirá todas las ramas que encuentre cuyo peso sea
mayor que el especificado y devolverá los datos de los nombres y autores involucrados.
Como curiosidad, se puede llegar a crear un sistema similar al existente en una famosa web de
cine que asegura que dados dos nombres de autores, puede relacionarlos directamente o a través
de otros actores con los que hayan trabajado conjuntamente en películas, habiendo seis saltos
como máximo. En este caso, no sabemos si existe una cota superior o no, pero podemos
demostrar que sí existe una relación más o menos grande entre proyectos, lo que da una idea de
que realmente existe una comunidad de software libre.
6.3. Herramientas de análisis estadístico
Existe una amplia gama de herramientas de análisis estadístico que facilitan la tarea de
correlación y procesado de múltiples datos. Estas herramientas suelen tener módulos gráficos
integrados que permiten analizar visualmente los resultados.
El autor de este documento no tiene mucha experiencia en el uso de las mismas, pero dada su
importancia dentro del esquema general y, sobre todo, debido a que serán de gran utilidad en el
futuro se ha incluido explícitamente una mención a las mismas en este artículo.