Jugando con demonios: Análisis del proyecto FreeBSD con la herramienta CVSAnalY *

Transcripción

1 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 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 , por el proyecto CICYT TIN y por la Universidad Rey Juan Carlos con el proyecto PPR

2 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á disponible 1 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) 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 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 FreeBSD 3 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

4 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 repository = :pserver:anoncvs:anoncvs@anoncvs.de.freebsd.org:/home/ncvs config modules = [. ] config dbname = freebsd config 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 CVSAnalY 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

5 5 Primer commit Último commit considerado Número de días 3805,15 Tabla 1. Datos Históricos de FreeBSD Total Por módulo Por commiter Por commit Por día Módulos , ,00342 Commiters ,08 1 0,0002 0,1 Commits , , ,83 Ficheros ,69 723,1 0,14 74,30 Líneas añadidas , ,94 16, ,82 Líneas eliminadas , ,84 11, ,37 Líneas cambiadas , ,77 27, ,18 Líneas Finales , ,1 4, ,45 Tabla 2. Estadísticas de FreeBSD 4.2. 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 commits. El módulo contiene ficheros, en los que se han cambiado 19054,788 líneas, se han añadido líneas, y se han eliminado El primer commit se realizó el día 21 de marzo de 1993, y el último que hemos considerado el 21 de agosto de 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 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 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 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 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) 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) migod/papers/icsm00.pdf.