Ingeniería del Software Libre

Abriendo una nueva rama de la Ingeniería del software

$Id: lse.txt,v 1.6 2002/07/12 01:33:06 grex Exp $

Gregorio Robles
grex@scouts-es.org

La ingeniería del software libre viene a dar aires renovados a una ingeniería del software
tradicional que se encuentra estancada debido básicamente a que no ha sabido crear métodos
para cuantificar tiempos, costes y calidad del software de forma aceptable y contrastable. En
este artículo se introducirá al lector en los primeros pasos de la ingeniería del software libre que
se centrarán en la extracción de la ingente cantidad de datos que ofrecen sus desarrollos debido
a la tendencia a que sean lo más abiertos posibles. Se discutirán algoritmos, herramientas y
condiciones que posibiliten que en una segunda etapa todos estos datos puedan ser mostrados,
analizados y correlados por otro tipo de herramientas independientes, a ser posible incluso por
otros de equipos de investigación de otras ramas de la ciencia. Como colofón a este artículo, se
presentará en el apéndice una aplicación que ha sido desarrollada para la extracción de datos de
los sistemas de control de versiones que son utilizados en muchos de los desarrollos de software
libre.

Curso de Doctorado "Programas Libres"

Departamento de Ingeniería Telemática - Universidad Politécnica de Madrid

1
1. Introducción
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
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.

2
2. La crisis de la ingeniería del software tradicional
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

3
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
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

4
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
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.

5
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.

6
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.

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.

7
8
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

10
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
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.

11
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.

12
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.

13
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
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.

14
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
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.

15
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.

16
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
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.

17
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.

18
5. Formato intermedio e independiente
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.

19
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
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.

20
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.

21
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)

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.

22
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.

23
7. Conclusiones
Empezamos este artículo viendo los problemas que tiene la ingeniería del software tradicional,
básicamente por su falta de análisis metódicos y sistemáticos. Hemos visto que el software libre
cuenta con cualidades innatas para introducir métodos que permitan conocer más a fondo todos
los parámetros que influyen en la generación del mismo. Esta formalización es muy
prometedora, ya que el software libre es mucho más difícil de cuantificar que la ingeniería del
software tradicional. Por tanto, es probable que el conocimiento del desarrollo de software libre
se pueda también dar solución a muchos problemas de la ingeniería del software tradicional.

Después de una introducción más bien teórica en la que se ha presentado una declaración de
intenciones de la ingeniería del software, hemos visto una propuesta de metodología para
recabar información de proyectos de software libre. De esta inmensa cantidad de información
se pretende extraer experiencias con éxito que puedan ser replicadas en otros desarrollos.

Hemos visto que hay una serie de herramientas para la extracción de datos de diversas fuentes,
desde el propio código fuente hasta rastreando páginas web de portales de desarrollo de
software. Los datos se almacenarán en un formato intermedio e independiente tanto de la fuente
como de las herramientas, para que en una segunda fase, se puedan analizar, correlar, procesar
y visualizar de diversas maneras. Esto último abre un campo de consecuencias difíciles de
predecir, pero sin lugar a dudas muy ilusionante y prometedor.

La sensación de que el software libre parece que está propiciando uno de esos extraños
momentos donde una industria entera cambia de paradigma, se puede también extrapolar a la
ingeniería del software libre. Aún nos encontramos en sus comienzos y hace falta un largo
camino por andar. Esperamos poder seguir contándolo.

24
8. Bibliografía, referencias y enlaces de interés
Frederick P. Brooks Jr. "The Mythical Man-Month", Primera edición año 1975, Addison
Wesley Publishing Company

Roger Pressman "Ingeniería del Software: Un enfoque práctico", 1997, McGrawHill

Adam Smith "Investigación sobre la naturaleza y la causa de la riqueza de las naciones",

Primera edición año 1776

Jae Yun Moon & Lee Sproull "Essence of Distributed Work: The Case of the Linux Kernel",
http://www.firstmonday.dk/issues/issue5_11/moon

Sandrep Krishnamurthy "Cave or Community?",

http://www.firstmonday.dk/issues/issue7_6/krishnamurthy

David Lancashire "Code, Culture and Cash: The Fading Altruism of Open Source
Development", http://firstmonday.org/issues/issue6_12/lancashire/

Christopher M. Kelty "Free Software/Free Science",

http://firstmonday.org/issues/issue6_12/kelty/

SLOCcount - Herramienta para contar líneas de código fuente en diferentes lenguajes y cálculo
de costes y tiempos de desarrollo, http://www.dwheeler.com/sloccount/

GNOME-stats - Estadísticas (estáticas) del CVS del proyecto GNOME,

http://gnome-stats.berlios.de

KDE-stats - Estadísticas (estáticas) del CVS del proyecto KDE, http://kde-stats.berlios.de

González Barahona, Ortuño Pérez y otros "Contando Patatas: El tamaño de Debian 2.2",
http://congreso.hispalinux.es/congreso2001/actividades/ponencias/gonzalez/html/t1.html

David A. Wheeler "Why Open Source Software/Free Software (OSS/FS)? Look at the
Numbers!", http://www.dwheeler.com/oss_fs_why.html

The FLOSS Survey - Encuesta auspiciada por un proyecto de investigación de la Comisión

Europea realizada a más de 2750 desarrolladores (2002), http://floss1.infonomics.nl/stats.php

Ghosh, Glott, Krieger & Robles "Free/Libre Open Source Software: Survey and Study - Final
report", todavía no publicado en la red

25
The Widi Survey - Encuesta realizada a más de 5500 desarrolladores (2001),
http://widi.berlios.de

"Boston Consulting Group/OSDN Hacker Survey" - Encuesta a casi un millar de

desarrolladores de Sourceforge (2001), http://www.osdn.com/bcg/

Gregorio Robles "Los desarrolladores de Software Libre",

http://congreso.hispalinux.es/congreso2001/actividades/ponencias/robles/pdf/desarrolladores.pdf

Robles, Weber & otros "WIDI - Who Is Doing It?",

http://ig.cs.tu-berlin.de/s2001/ir2/ergebnisse/OSE-study.pdf

CODD - Aplicación rastreadora de autores y dependencias de código e interfaces en código

fuente, http://codd.berlios.de

CODDWeb - Interfaz web para acceder a los resultados de CODD,

http://floss1.infonomics.nl/coddweb/

Curso de doctorado "Programas Libres" - Departamento de Ingeniería Telemática UPM,

http://curso-sobre.berlios.de

Rishab Aiyer Ghosh "Clustering and Dependencies in Free/Open Source Software

Development: Methodology and Preliminary Analysis",
http://www.idei.asso.fr/Commun/Conferences/Internet/OSS2002/Papiers/Ghosh.PDF

Rishab Aiyer Ghosh & Vipul Ved Prakash "The Orbiten Free Software Survey",
http://www.firstmonday.dk/issues/issue5_7/ghosh

Eric S. Raymond "The Cathedral and the Bazaar",

http://www.tuxedo.org/~esr/writings/cathedral-bazaar/

Nikolai Bezroukov "A Second Look at the Cathedral and the Bazaar",
http://www.firstmonday.dk/issues/issue4_12/bezroukov/

Rishab Aiyer Ghosh "Cooking pot markets: an economic model for the trade in free goods and
services on the INternet", http://www.firstmonday.dk/issues/issue3_3/ghosh/

Josh Lerner & Jean Tirole "The Simple Economics of Open Source",
http://www.idei.asso.fr/Commun/Articles/Tirole/simpleeconomics-July-24-2001.pdf

Jesús M. González Barahona "Software libre, monopolios y otras yerbas",

http://sinetgy.org/~jgb/articulos/soft-libre-monopolios/

Proyecto Gestión Libre de Hispalinux, http://gestion-libre.hispalinux.es

sloc2html - Aplicación que presenta los resultados de SLOCcount a través de un interfaz web
agradable, http://halfdans.net/index.py?p=sloc2html

26
Estadísticas gráficas de GNOME con SLOCCount y sloc2html,
http://gnome-stats.berlios.de/gnome-sloc.html

Free Software Foundation Europe - Distribución geográfica de desarrolladores de software

libre, http://www.fsfeurope.org/coposys/index.en.html

Alison Luo "TPM (Trinity Participation Metric) for Open Source Developers",
http://www.cse.ucsc.edu/~alison/projects/cmpe276/index.html

Linux Study - Questionnaire on Linux kernel developers (141 desarrolladores),

http://www.psychologie.uni-kiel.de/linux-study/

Proyecto Debian - Mapa con la distribución geográfica de los desarrolladores Debian,

http://www.debian.org/devel/developers.loc

Edward Betts "Debian Developer Centre of Mass", http://people.debian.org/~edward/average/

27