Jugando con demonios: Análisis del proyecto FreeBSD con la

Transcripción

Jugando con demonios: Análisis del proyecto FreeBSD con la
Jugando con demonios:
Análisis del proyecto FreeBSD con la
herramienta CVSAnalY*
Álvaro Navarro, Israel Herraiz y Gregorio Robles
{anavarro,herraiz,grex}@gsyc.escet.urjc.es
Grupo de Sistemas y Comunicaciones (GSyC)
Universidad Rey Juan Carlos
Tulipán s/n 28933 Móstoles (Madrid), España
Resumen Los sistemas de control de versiones como CVS o Subversion
son unas de las herramientas más utilizadas en proyectos de software
libre. En ellos podemos encontrar, además del código fuente del proyecto, información relativa a los desarrolladores, las modificaciones que
éstos llevan a cabo, ası́ como las fechas de las mismas. CVSAnalY es
una herramienta que nace con el fin de recopilar toda esa información,
extendiendo su estudio al pasado, presente y futuro del proyecto. Gracias
a esta herramienta y a la información que proporciona se puede realizar
una mejor gestión del proyecto, ası́ como conocer mejor sus caracterı́sticas. En este artı́culo mostraremos cómo realizar un análisis para lo cual
utilizaremos como caso de estudio uno de los sistemas operativos libres,
FreeBSD.
1.
Introducción
Una de las principales caracterı́sticas que han hecho del software libre un
verdadero éxito es que a pesar de la diversidad geográfica y cultural de los
miembros de un proyecto cualquiera se ha sido capaz de crear un software no
sólo funcional, sino que en muchos casos estable, potente e innovador.
Esto es debido a que el modelo de desarrollo que se sigue en el software
libre tiende a ser lo más abierto posible, en parte para mitigar los efectos de
la dispersión de los desarrolladores que participan en el proyecto y debido a
que de esta forma se permite la colaboración e integración de nuevos miembros.
Gracias a este modelo, podemos estudiar los proyectos de software libre, ya que
su información está públicamente disponible en Internet.
Desde el punto de vista tecnológico, y debido a la dependencia del desarrollo
de software libre de Internet y de las herramientas que sustentan el desarrollo
colaborativo, es muy importante contar con un software que permita conocer el
*
Este trabajo ha sido financiado en parte por la Comisión Europea, dentro de la
acción coordinada CALIBRE del programa IST, número de contrato 004337, por
el proyecto CICYT TIN2004-07296 y por la Universidad Rey Juan Carlos con el
proyecto PPR-2004-42.
2
estado de un proyecto y facilite su administración y gestión. Como miembros
de un proyecto de software libre, es además interesante conocer de manera exhaustiva la evolución y el desarrollo que ha llevado nuestro proyecto desde su
nacimiento hasta el dı́a de hoy, qué personas son las más activas, qué fases del
proyecto han sido las más crı́ticas o incluso conocer qué relación puede tener un
desarrollador respecto a otro.
El análisis deberı́a ser lo menos intrusivo posible con el fin de no interferir
en el desarrollo del proyecto; en otras palabras: el proyecto no deberı́a parar ni
verse afectado por él. Por tanto nos serviremos de toda la información generada
de forma indirecta por todos los miembros del proyecto, esto es, información
relativa al sistema de control de versiones (CVS o Subversion) o al sistema de
tratamiento de bugs (Bugzilla).
En esta ponencia nos centraremos en una herramienta capaz de analizar
un repositorio de un proyecto de software libre, mostrando conclusiones y estadı́sticas sobre el mismo. La herramienta en cuestión se llama CVSAnalY y
está disponible1 de forma libre y gratuita bajo las condiciones de la licencia
GPL.
CVSAnalY [1] obtiene la mayor parte de la información acerca del proyecto
de software libre de los logs del sistema de control de versiones. Cada vez que
un desarrollador realiza un cambio en el CVS (como por ejemplo, añadir nuevo
código al proyecto) se registra el nombre del usuario que realizó el cambio, la
fecha, qué lı́neas ha añadido y cuáles ha eliminado, qué ficheros ha añadido y/o
etc. Además, el desarrollador también puede añadir un comentario al cambio.
Este artı́culo muestra el funcionamiento de CVSAnalY empleando la información almacenada en el repositorio de control de versiones del proyecto FreeBSD.
En primer lugar configuraremos la herramienta. A continuación se realizará un
acercamiento a la estructura del sistema FreeBSD y por último comentaremos
los resultados obtenidos finalizando con las conclusiones y trabajos futuros.
2.
Configurando CVSAnalY
Para emplear CVSAnalY existen una serie de prerrequisitos. A continuación
mostramos la lista de paquetes necesarios para poder ejecutar el programa 2 : cvs,
mysql-server, python (versión 2.2 o posterior), python-mysql, python-mysqldb,
python-imaging, gnuplot y ploticus (versión 2.2 o mayor si se quieren obtener
diagramas de tarta en color). Si se quiere hacer uso de las opciones avanzadas,
también se ha de tener instalado en la máquina smail (para que el sistema pueda
enviar un correo electrónico al usuario una vez haya acabado el análisis), whirlgif
(para la creación de gifs dinámicos), rsync (si se quiere tener una copia local del
repositorio CVS), cron (si se pretende actualizar periódicamente los datos) y rcs
(en el caso de emplear rsync).
1
2
http://cvsanaly.tigris.org
En la mayorı́a de sistemas los nombres de los paquetes son prácticamente idénticos. Por ejemplo, nosotros hemos probado la herramienta en Debian GNU/Linux y
FreeBSD y los paquetes necesarios eran los mismos.
3
Uno de los principales problemas con los que se encuentra el usuario novel la primera vez que utiliza CVSAnalY es la compleja configuración de los
parámetros. Estos parámetros se encuentras almacenamos en un fichero de configuración denominado config.py. Es por ello que decidimos implementar un
asistente para la creación dinámica del fichero de configuración, que se encuentra en (cvsanaly wizard.py). El asistente irá preguntando de manera intuitiva la
información necesaria para el análisis, tales como la dirección del repositorio, la
lista de módulos que se quieren descargar y analizar (por defecto analizará todos
los módulos), la información de acceso al servidor de base de datos, qué análisis
se van a realizar, qué gráficas se obtienen, dónde se guardarán los resultados, etc.
Una vez creado el fichero de configuración se nos avisará que estamos en condiciones de comenzar el proceso mediante la ejecución de la instrucción python
cvsanaly.py dentro del directorio donde tengamos instalada la herramienta.
Es importante resaltar que en el caso de no especificarse alguna opción de
configuración imprescindible, la herramienta muestra un menú que nos permite
seleccionar el valor adecuado para esa opción. Además, si el valor es simplemente
verdadero o falso, podemos seleccionar que para cualquier otra incidencia próxima se tome un valor por defecto, y no se pregunte al usuario qué valor debe
tomarse para la opción perdida. De este modo evitaremos interrupciones inesperadas en la ejecución del proceso, máxime si se trata del análisis de proyectos del
tamaño de FreeBSD como es el caso que nos atañe, ya que es costoso en tiempo.
3.
Un caso de uso: FreeBSD
FreeBSD3 es un sistema operativo libre, bajo licencia BSD, disponible para
diferentes arquitecturas. FreeBSD es un derivado de BSD UNIX, exactamente
de la versión de UNIX desarrollada en la Universidad de California en Berkeley.
FreeBSD, a diferencia de otros proyectos libres similares, posee una estructura
organizativa particular [2]:
core team: compuesto por un grupo reducido de commiters y elegidos por
votación entre todos los desarrolladores. Su principal función es la de tomar
decisiones sobre el rumbo que debe tomar el proyecto.
commiters: conjunto de desarrolladores con permisos de escritura en los repositorios de código. Cualquier commiter puede ser elegido para formar parte
del core team.
release engineer: encargados de liberar las versiones cada 6 meses (aproximadamente).
contributors: abarca el conjunto de traductores y mantenedores del árbol de
ports.
Sin duda, una diferencia notable respecto a otros sistemas operativos libres
como GNU/Linux, es la estructura interna del sistema. FreeBSD no es sólo un
kernel, es un sistema completo con su kernel, programas y bibliotecas básicas en
3
http://www.freebsd.org
4
espacio de usuario. Ası́ pues, en FreeBSD no existe el concepto de distribución
tan común en GNU/Linux; en su lugar tenemos diferentes ramas de desarrollo.
Es importante, por tanto, saber que en el repositorio encontraremos desde el
kernel hasta bibliotecas para criptografı́a.
Una vez que contamos con una visión global del proyecto que pretendemos
analizar, pasamos a la ejecución de CVSAnalY. En primer lugar, tal y como
hemos indicado en la anterior sección, debemos crear un fichero de configuración
compatible con nuestra herramienta. En el estudio que nos atañe, la configuración quedarı́a del siguiente modo:
config
config
config
config
repository = :pserver:anoncvs:[email protected]:/home/ncvs
modules = [’.’]
dbname = freebsd
graphs = 1
En la primera lı́nea hemos indicado el repositorio del que obtendremos el
código fuente, mientras que en la segunda introducimos los módulos que la herramienta analizará, en este caso todos (que viene dado por el punto). La tercera
lı́nea pregunta por el nombre de la base de datos donde se almacenarán los resultados y en la última especificamos que queremos que la herramienta genere
gráficas.
4.
Resultados obtenidos
Una vez finalizado el proceso completo, la herramienta nos enviará un correo
electrónico avisándonos de la finalización del mismo. El análisis de FreeBSD
duró alrededor de 3 dı́as, tiempo durante el cual la herramienta se descargó el
código, analizó los ficheros logs, almacenó los resultados en la base de datos
y creó gráficas ası́ como un cómodo interfaz web para su posterior consulta.
Nosotros expondremos un resumen de los resultados. Para consultar los resultados completos, se puede visitar la interfaz web creada automáticamente por
CVSAnalY4 .
4.1.
Estadı́sticas globales
Podemos obtener información sobre el comienzo y el último commit realizado en el proyecto, concluyendo ası́ el número de dı́as de actividad tal y como se
puede observar en la tabla 1.
La fecha del último commit corresponde con el último análisis realizado y
servirá como punto de partida para futuras ampliación del estudio del proyecto. En la tabla 2 se muestra el histórico de datos obtenidos del proyecto FreeBSD.
4
http://libresoft.urjc.es/cvsanal/freebsd-cvs/
5
Primer commit 1993-03-21
Último commit considerado 2003-08-21
Número de dı́as
3805,15
Tabla 1. Datos Históricos de FreeBSD
Módulos
Commiters
Commits
Ficheros
Lı́neas añadidas
Lı́neas eliminadas
Lı́neas cambiadas
Lı́neas Finales
4.2.
Total Por módulo Por commiter Por commit Por dı́a
13
1
0,03
1 · 10−5 0,00342
391
30,08
1
0,0002
0,1
2038917 156839,77
5214,62
1 535,83
282733
21748,69
723,1
0,14
74,30
32696960 2515150,77
83623,94
16,04 8592,82
23623765 1817212,69
60418,84
11,59 6208,37
56320725 4332363,46
144042,77
27,62 14801,18
9073195 697938,08
23205,1
4,45 2384,45
Tabla 2. Estadı́sticas de FreeBSD
Resultados para el módulo src
En el módulo src se incluye todo el código fuente del kernel de FreeBSD.
Vamos a mostrar y comentar algunos de los resultados obtenidos con CVSAnalY.
En ese módulo han trabajado 352 commiters, que han realizado 554764 commits.
El módulo contiene 52899 ficheros, en los que se han cambiado 19054,788 lı́neas,
se han añadido 11379308 lı́neas, y se han eliminado 7675480. El primer commit
se realizó el dı́a 21 de marzo de 1993, y el último que hemos considerado el 21
de agosto de 2003.
La primera gráfica que vamos a comentar es la evolución del número de
commiters a lo largo del tiempo, que se muestra en la figura 1. Como podemos
observar, el crecimiento ha sido casi lineal durante toda la vida del proyecto.
Obviamente, el número de commiters es mucho mayor que en el comienzo del
proyecto.
En cuanto a la evolución del número de commits, mostrada en la figura 2,
podemos comprobar que ha sido también un crecimiento prácticamente lineal.
También podemos obtener la evolución en el tamaño del proyecto en lı́neas
fı́sicas de código fuente (incluyendo comentarios y lı́neas en blanco), que se muestra en la figura 3. Esta gráfica es mucho más interesante, puesto que muestra
que el crecimiento del proyecto se ha acelerado, lo que contradice las leyes de
Lehman [3].
Otra gráfica interesante es la que muestra el coeficiente de Gini [4], que es un
indicador de desigualdad en el desarrollo del proyecto. En la figura 4 se muestra
para el módulo src. El coeficiente viene dado por la relación entre las áreas bajo
las dos curvas que se ven en la figura. Si el coeficiente es próximo a 1, todos los
desarrolladores han participado por igual. En este caso, podemos ver claramente
que existe bastante desigualdad en el desarrollo, esto es, un pequeño grupo de
desarrolladores es el responsable de la mayor parte del código de este módulo,
mientras que la aportación de la gran mayorı́a es bastante pequeña.
6
Figura 1. Evolución del número de commiters para el módulo src
Figura 2. Evolución del número de commits para el módulo src
7
Figura 3. Evolución del tamaño en lı́neas de código del módulo src
Figura 4. Indicador de desigualdad en el desarrollo del módulo src
8
Por último vamos a ver la gráfica de generaciones de desarrolladores tal y
como se muestra en la figura 5. En esta gráfica se ha divido el ciclo de vida del
proyecto en 10 intervalos; en cada intervalo se identifica al 20 % más activo de
entre todos los commiters que han participado y se mide su aportación en número
de commits sobre el total. Tenemos de esta forma 10 grupos que no tienen por
qué ser disjuntos, ya que un mismo desarrollador puede formar parte del grupo
más activo en varios intervalos. Con este método, podemos observar que los
integrantes del grupo más activo en el último intervalo, no estaba presente en el
comienzo del proyecto (ya que la aportación de los miembros que lo componen era
entonces de 0 %), y que su participación se ha ido incrementando gradualmente
durante el transcurso del proyecto. Del mismo modo, el grupo más activo al inicio
(lo hacı́a entonces con más de un 80 %) no contribuye apenas en este momento
(aparece rozando el 0 %). Por tanto, podemos concluir que se ha producido uno
o más relevos generacionales en el desarrollo del proyecto. Esto entra en conflicto
con la idea comúnmente aceptada (pero nunca validada) de que el software libre
depende de desarrolladores clave e imprescindibles [5].
Figura 5. Generaciones de desarrolladores en el módulo src
9
5.
Conclusiones y trabajo futuro
Gracias a la herramienta CVSAnalY hemos podido obtener interesantes resultados sobre el proyecto FreeBSD. Algunas de las más importantes se recogen
a continuación:
El módulo estudiado, src, nos permite afirmar que el crecimiento del kernel (medido en LOCS/tiempo) se está acelerando, es decir, el incremento
en lı́neas de código aumenta en proporción al tiempo, pese a las hipótesis
de Lehman, el cual afirma lo contrario. Esta caracterı́stica de crecimiento
superlineal también se ha observado en otros proyectos grandes de software
libre, como en el caso del kernel Linux [6]. Una lı́nea de trabajo futura nos
podrı́a llevar a estudiar la evolución únicamente del kernel.
FreeBSD posee una estructura organizativa bastante bien definida, en la todos los miembros del proyecto conocen las decisiones tomadas por el core
team, del cual sabemos que aporta la mayor parte del código del sistema.
Sin contar el número de aportaciones a otro nivel estructural como el empaquetamiento de aplicaciones realizadas por terceros.
Otra de las conclusiones importantes extraı́das del análisis, afectan a las generaciones de desarrolladores. Se puede concluir que aquellos desarrolladores
que más aportaban al principio, ya apenas aportan. Ası́ mismo, aquéllos que
más contribuyen ahora, apenas aportaban algo útil al comienzo del proyecto.
En todo caso, hemos de recalcar finalmente que la idea principal de esta
ponencia era mostrar la utilidad tecnológica de un análisis de esta ı́ndole de cara
al desarrollo, la gestión y la administración de un proyecto de software libre.
Referencias
1. Robles, G., Koch, S., Gonzalez-Barahona, J.M.: Remote analysis and measurement
of libre software systems by means of the cvsanaly tool. In: Proceedings of the
2nd ICSE Workshop on Remote Analysis and Measurement of Software Systems
(RAMSS), 26th International Conference on Software Engineering, Edinburg, Scotland, UK (2004)
2. Dinh-Trong, T., Bieman, J.M.: Open source software development: A case study
of freebsd. In: Proceedings of the 10th International Software Metrics Symposium,
Chicago, IL, USA (2004)
3. Lehman, M., Ramil, J., Wernick, P., Perry, D.: Metrics and laws of software evolution
- the nineties view. In: Proceedings of the Fourth International Software Metrics
Symposium, Portland, Oregon (1997)
4. Gini, C.: On the Measure of Concentration with Espacial Reference to Income and
Wealth. Cowles Commission (1936)
5. Raymond, E.S.: The cathedral and the bazar. First Monday (1997)
http://www.firstmonday.dk/issues/issue3 3/raymond/.
6. Godfrey, M.W., Tu, Q.: Evolution in open source software: A case study. In:
Proceedings of the International Conference in Software Maintenance, San Jose,
California, USA (2000)
http://plg.uwaterloo.ca/ migod/papers/icsm00.pdf.

Documentos relacionados