PDF de programación - GNOME como caso de estudio de Ingenieria del Software Libre

GNOME como Caso de Estudio de

Ingenier¶‡a del Software Libre*

Juan Jose Amor, Gregorio Robles y Jes¶us M. Gonz¶alez Barahona

fjjamor, grex, [email protected]

Grupo de Sistemas y Comunicaciones

Universidad Rey Juan Carlos (M¶ostoles, Madrid)

Resumen El software libre ha experimentado en los ¶ultimos años un
imparable avance en la universidad, industria y administraciones p¶ubli-
cas. Sin embargo, a¶un estando en boca de todos, todav¶‡a son pocos los
estudios que se centran en estudiar este fen¶omeno de manera pormenori-
zada. El hecho de que se pueda acceder de manera p¶ublica y no intrusiva
al c¶odigo fuente y a otros subproductos del desarrollo de software libre
(como son el repositorio de versiones, las listas de correo o el sistema de
gesti¶on de errores) ofrece la posibilidad de realizar an¶alisis cuantitativos
a gran escala. El proyecto GNOME es un interesante caso de estudio en
este sentido, ya que adem¶as de ser uno de los entornos gr¶aflcos libres
m¶as utilizados en la actualidad ha sabido aglutinar una activa comuni-
dad de desarrolladores a su alrededor. Este art¶‡culo es un repaso a los
diferentes estudios que nuestro grupo de investigaci¶on de ingenier¶‡a de
software libre ha realizado sobre GNOME desde diferentes puntos de vis-
ta como son el tamaño del software, el crecimiento de los programas, la
contribuci¶on de los desarrolladores y el tipo de contribuciones, etc.

1.

Introducci¶on

El software libre a veces tiene ciertas caracter¶‡sticas que lo hacen parecer
m¶agico. Sin negar que el hecho de que cientos, quiz¶as miles de personas distri-
buidos geogr¶aflcamente, y que probablemente nunca se hayan visto cara a cara,
consigan crear un software a la altura del estado del arte es de por s¶‡ algo que a
muchos entusiasma, para la deflnitiva implantaci¶on del software libre es necesa-
rio conocer y entender los mecanismos que llevan al desarrollo de software libre
para poder aplicarlos de manera efectiva en el futuro.

Precisamente por ello varios grupos de investigaci¶on de varias universidades
vienen realizando desde hace unos años diversos estudios sobre software libre.
Entre ellos, nuestro grupo de investigaci¶on en ingenier¶‡a del software libre [9] se
ha especializado en realizar estudios de caracterizaci¶on de proyectos de software
libre dentro de la acci¶on coordinada CALIBRE [1], impulsada por la Comisi¶on
Europea.

* Este trabajo ha sido flnanciado en parte por la Comisi¶on Europea, dentro del la
acci¶on coordinada CALIBRE dentro del programa IST, n¶umero de contrato 004337,
por el proyecto CICYT TIN2004-07296 y por la Universidad Rey Juan Carlos con
el proyecto PPR-2004-42.

1.1. El modelo de desarrollo de software libre

Aunque bien es cierto que el software libre en realidad es aqu¶el cuya licencia
permite al que lo recibe hacer uso de las cuatro libertades, hemos podido observar
en los ¶ultimos años una tendencia en los proyectos de software libre que han
tenido ¶exito (en tamaño, en n¶umero de contribuciones, en inter¶es ’medi¶atico’)
hacia un modelo de desarrollo lo m¶as abierto posible y, en deflnitiva, a trav¶es de
Internet.

Esto es as¶‡ por dos causas: la primera es por la distribuci¶on geogr¶aflca de
los desarrolladores, mientras que la segunda es para facilitar el acceso a nuevas
colaboraciones (ya sea mediante c¶odigo, informes de error, traducci¶on, documen-
taci¶on o de cualquier otro tipo).

Por eso, adem¶as de ofrecer el c¶odigo fuente, existen en paralelo diversas he-
rramientas que se utilizan para la intercomunicaci¶on y el soporte en el desarrollo
distribuido de software libre. Y debido a que para abrir al m¶aximo el proceso de
desarrollo estos datos est¶an disponibles p¶ublicamente en Internet, tambi¶en pue-
den ser obtenidos y analizados (incluso de manera semi-autom¶atica). Tenemos,
por tanto, una ingente cantidad de artefactos que en realidad son subproducto
del proceso de desarrollo que podemos analizar para conocer mejor el desarrollo
de un proyecto espec¶‡flco.

A continuaci¶on incluimos una lista, posiblemente incompleta, de elementos y
herramientas disponibles del desarrollo de software libre que nos pueden servir
como fuente p¶ublica de datos sobre un proyecto:

C¶odigo fuente: Paquetes binario y fuente (tarballs)
Sistemas de control de versiones: CVS, Subversion, etc.
Sistemas de seguimiento de fallos: Bugzilla, etc.
Documentaci¶on: P¶aginas man, documentaci¶on en Docbook, etc.
Listas de correo y foros p¶ublicos
Estad¶‡sticas de uso (como la Debian Popcon [10])
Encuestas: como por ejemplo FLOSS [7]

Todas estas fuentes de datos nos ser¶an ¶utiles para estudiar la actividad de
un proyecto: desde estudios de evoluci¶on en tamaño o en el uso de lenguajes
de programaci¶on hasta la actividad de los desarrolladores a partir de lo que se
publica en ciertas listas de correo o los registros que tienen lugar en los sistemas
de control de versiones.

En este art¶‡culo veremos ejemplos de resultados de aplicar las medidas sobre
las fuentes p¶ublicas de datos disponibles en el proyecto GNOME. En primer
lugar, veremos los resultados que se obtienen al realizar un simple an¶alisis del
n¶umero de l¶‡neas de c¶odigo fuente de algunas aplicaciones de GNOME. A con-
tinuaci¶on, presentaremos los resultados que se obtuvieron analizando los datos
disponibles en el servidor CVS de GNOME. En la siguiente parte, veremos c¶omo
la combinaci¶on de varias fuentes de datos (CVS, listas de correo y gestor de
errores a la vez) pueden sugerirnos nuevos e interesantes resultados. Por ¶ultimo,
presentaremos las conclusiones de este art¶‡culo.

2. Estudios del c¶odigo fuente de GNOME

El primer an¶alisis que vamos a ver se ha hecho con los tarballs de c¶odigo
fuente de los proyectos. Para ello, hemos utilizado m¶etricas basadas en contar
las l¶‡neas de c¶odigo fuente de los paquetes. Para contar las l¶‡neas de c¶odigo fuente
pueden utilizarse, desde simples comandos Unix wc (contando directamente las
l¶‡neas del flchero de texto) o buscando soluciones m¶as avanzadas como scripts
que detecten los comentarios (basados en awk) o incluso, utilizando contadores
como SLOCCount [13] que incluyen heur¶‡sticas bastante soflsticadas para contar
identiflcar los flcheros que contienen c¶odigo y contar las l¶‡neas de c¶odigo incluso
en los m¶as variados lenguajes de programaci¶on.

Usando SLOCCount, por ejemplo, podemos analizar la evoluci¶on del tamaño

de las versiones de GTK+ o Gnumeric en el tiempo (ver flgura 1).

300000

250000

200000

150000

100000

50000

0

-50000

gnumeric

0 10 20 30 40 50 60 70 80 90 100

450000
400000
350000
300000
250000
200000
150000
100000
50000
0

gtk+

0 10 20 30 40 50 60 70 80 90 100

Figura 1. Evoluci¶on del n¶umero de l¶‡neas de c¶odigo de Gnumeric (izquierda) y GTK+
(derecha). El eje horizontal viene dado por el tiempo (medido en meses desde que el
proyecto utiliza CVS), mientras que en el eje vertical se puede ver el tamaño en l¶‡neas
de c¶odigo fuente. La l¶‡nea recta es el ajuste lineal, que como se puede comprobar es
bastante acertado en ambos casos.

M¶as adelante veremos que esta medida tambi¶en puede hacerse a partir de
los logs que se pueden obtener de un repositorio CVS. Sin embargo, los estudios
de evoluci¶on de l¶‡neas de c¶odigo son m¶as precisos cuando se realizan con SLOC-
Count porque esta herramienta distingue lenguajes y evita contar las l¶‡neas de
flcheros tales como documentos o LEEMEs.

Una de las cosas que se suele observar en la mayor¶‡a de los proyectos de
software libre de cierto tamaño como en el caso de GNOME, es que la curva de
crecimiento tiende a la linealidad, y en algunos casos se ha observado crecimiento
super-lineal como, por ejemplo, en Linux [8]. Esto es, que el crecimiento del
software conforme pasa el tiempo rara vez se ralentiza y en ocasiones se acelera,
siendo ¶este un modelo de crecimiento que no se suele observar en proyectos que
siguen un modelo de desarrollo privativo, que suelen presentar una curva de
crecimiento sub-lineal, similar a una ra¶‡z cuadrada. Aunque todav¶‡a es pronto

para sacar conclusiones, esto puede deberse a que la forma de gesti¶on y de
organizaci¶on de los proyectos de software libre es m¶as eflciente que la de los
entornos de creaci¶on de software cl¶asico.

Quiz¶as una de los m¶etodos m¶as interesantes que se pueden aplicar a partir
del n¶umero de l¶‡neas de c¶odigo sean las estimaciones de costes con t¶ecnicas como
COCOMO [4]. La herramienta SLOCCount devuelve de forma predeterminada
el coste estimado del proyecto analizado de acuerdo con los c¶alculos del mo-
delo b¶asico de COCOMO. La tabla 1 nos muestra el esfuerzo estimado que se
necesitar¶‡a para crear algunos proyectos desde cero en hombres-año, as¶‡ como
el tiempo de desarrollo m¶‡nimo en años. Con estos dos resultados, que obtiene
el m¶etodo COCOMO aplicando algunos c¶alculos al n¶umero de l¶‡neas de c¶odigo
fuente producidas, es f¶acil obtener el esfuerzo en horas totales de trabajo estima-
do, y traducir ¶este a cantidades monetarias que nos dar¶‡an el coste de desarrollo
de un proyecto.

L¶‡neas Esfuerzo Tiempo desarrollo Coste Total

Software Fecha
Dia
Agosto 2004 122,722 31.23 a-h 1.98 años
Evolution Marzo 2005 207,507 54.19 a-h 2.44 años
Gnumeric Enero 2005
294,547 78.28 a-h 2.81 años
418,927 113.31 a-h 3.23 años
Abril 2005
Gtk+

$ 4,218,868
$ 7,320,252
$ 10,574,357
$ 15,306,888

Cuadro 1. Coste estimado de proyectos de GNOME seg¶un COCOMO. La fecha indica
el mes en el que se han tomado los datos de tamaño (en n¶umero de l¶‡neas de c¶odigo
fuente). El esfuerzo da el n¶umero de años-hombre necesarios para construir un software
de ese tamaño, mientras que el tiempo de desarrollo es el tiempo en años en el que se
estima que se puede crear el software. Finalmente el coste total en d¶olares americanos
viene dado por multiplicar el esfuerzo por el salario de los desarrolladores, as¶‡ como
otros costes que hay que tener en cuenta en el desarrollo de software (hardware, personal
de