21
Analysis of the relationship of the level of maturity process with the Success of
Open Source Projects
Análisis a la Relación del Nivel de Madurez de los Procesos con el Éxito de los
Proyectos de Código Abierto
Gina Pintendi
Tecnologías HCL. Gina.P(AT)hcl.com
INFORMACIÓN DEL ARTÍCULO
Tipo de artículo: Investigación.
Historia del artículo Recibido: 19-07-2012 Correcciones: Aceptado: 25-10-2012
Categories and Subject Descriptors D.2.9 [Software Engineering]: Management – Software process models.
General Terms
Software Engineering, Logic or Abstraction.
Keywords
Maturity level, improved quality, free software, open source.
Palabras clave
Nivel de madurez, mejoramiento de la calidad, software libre, código abierto.
ABSTRACT
The success of free software and open source projects has sparked interest in the use of his model to develop mature software. However, its ad hoc nature can also produce poor quality software or failures in projects. In this article it is analyze the SourceForge.net projects described in order to test the hypothesis that under the open source model there is a relationship between the levels of maturity of process with success of the projects. The processes are identified as key factors in the success of free software projects and this study addresses the question of whether their level of maturity differs notably between successful and unsuccessful projects. The knowledge gained can be applied to improve the processes used in both projects free software as in software engineering in general.
RESUMEN
El éxito del software libre y de los proyectos de código abierto ha despertado el interés en la utilización de su modelo para desarrollar software maduro. Sin embargo, su naturaleza ad hoc también puede producir software de mala calidad o fracasos en los proyectos. En este artículo se hace un análisis a los proyectos descritos en SourceForge.net con el objetivo de probar la hipótesis de que bajo el modelo de código abierto existe una relación entre el nivel de madurez de los procesos con el éxito de los proyectos. Los procesos se identifican como factores clave para el éxito de los proyectos de software libre y en este estudio se aborda la cuestión de si su nivel de madurez particular difiere entre proyectos exitosos y no exitosos. Los conocimientos obtenidos se pueden aplicar para mejorar los procesos utilizados tanto en los proyectos de software libre como en los de Ingeniería de Software en general.
© 2012 IAI. All rights reserved.
1. INTRODUCCIÓN
El modelo de desarrollo utilizado en los proyectos de software libre y de código abierto es único en muchos aspectos. Tradicionalmente, estos proyectos se caracterizan por dos factores que tienen impacto en su calidad y gestión [1, 2]: (1) los llevan a cabo voluntarios y (2) los participantes están distribuidos globalmente.
Además, el modelo está determinado por la naturaleza del software libre en sí, porque todo el código fuente está disponible y se comparte con otros. Raymond [3, 4] sugiere que este intercambio conduce a un alto nivel de revisión por pares e incentiva la participación del usuario. En la investigación de la Ingeniería de Software [5] se ha demostrado que esta revisión contribuye a mejorar la calidad del software, lo que puede ofrecer una explicación a los niveles de calidad encontrados en algunos proyectos exitosos, como Linux, Apache y Debian.
Si bien ha habido un incremento en la investigación alrededor del método del software libre y del código abierto, se ha prestado poca atención a cómo incorporarle los principios de la Ingeniería de Software tradicional [6]. Dado que los voluntarios que trabajan en software libre a menudo lo hacen impulsados por motivaciones diferentes a las de las compañías que desarrollan software propietario [7], no está claro si todas las estrategias postuladas en la Ingeniería de Software se pueden aplicar en los proyectos de código abierto. Sin embargo, esta cuestión es importante si se encuentran técnicas que incrementen el éxito del modelo de desarrollo de código abierto.
El proyecto del que se origina este artículo tiene como objetivo investigar si el nivel de madurez de los procesos utilizados en los proyectos de código y aplicados por los voluntarios está conectado con su éxito. Aunque la mayor parte de la investigación en Ingeniería de Software acerca RACCIS, 2(2), 21-27, 2012.
Revista Antioqueña de las
Ciencias Computacionales y la Ingeniería de Software
ISSN: 2248-7441
www.fundacioniai.org/raccis
22 del código abierto se ha concentrado en los proyectos
exitosos ―Apache [8], Debian [9, 10], GNOME [11] y Linux [12]―, se puede afirmar que existe igualmente un alto número de estos proyectos que han fallado y que hasta el momento no se han estudiado en detalle [13]. La hipótesis es que existe una relación entre el nivel de madurez de los procesos y el éxito del proyecto, especialmente en lo relacionado con la coordinación y la comunicación. En el proceso de investigación se identificaron las áreas clave del proceso de software relacionadas con el éxito de los proyectos. Factores que dan una idea de la importancia de los distintos procesos y contribuirá al desarrollo de más proyectos exitosos.
2. METODOLOGÍA
Este artículo se basa en un estudio de caso empírico que involucró 80 proyectos alojados en SourceForge.net. Actualmente, este sitio aloja más de 95.000 proyectos de software libre y de código abierto, y tiene más de un millón de desarrolladores registrados. El nivel de madurez de los proyectos seleccionados aleatoriamente fue evaluado utilizando una valoración simple diseñada para este propósito. El objetivo central en el desarrollo de esta valoración fue la creación de un mecanismo general para la evaluación del nivel de madurez de los procesos, en lugar de uno específico para la pregunta de investigación. Por tanto, el formulario de evaluación puede ser utilizado por otros investigadores y profesionales para juzgar el nivel de madurez de todo tipo de proyectos de código abierto.
2.1 Evaluación de los proyectos
La evaluación aplicada se puede utilizar para evaluar aspectos importantes del nivel de madurez de los proyectos de software libre y de código abierto. Se centra en el nivel de madurez de los procesos relacionados con la coordinación y la comunicación debido a su valor en los proyectos distribuidos [1]. Para hacerlo se utilizaron los datos empíricos que típicamente están disponibles en los proyectos de código abierto; su validez se supone alta, porque la mayoría de preguntas del instrumento se pueden responder de forma objetiva y sólo requieren un poco de juicio personal. Aunque la inter-evaluación y la fiabilidad de repetición de la prueba han sido comprobadas estadísticamente, ambas mostraron resultados fiables en este estudio de caso.
El proceso de la evaluación incorporó ideas de Ingeniería de Software y de código abierto y se basó en los modelos que postulan la importancia de una calidad alta y de procesos disciplinados. Se hizo hincapié en los procesos que pueden ser importantes en los proyectos de código abierto y específicamente se tuvo en cuenta la naturaleza distribuida y voluntaria del software libre y de estos proyectos. Debido a que el software libre y el código abierto benefician en gran medida a la comunidad alrededor de un proyecto [3, 14], los procesos para atraer voluntarios e integrarlos al mismo son de mucha importancia.
La evaluación se agrupó en cinco categorías teniendo en cuenta los diferentes aspectos de los proyectos de
software libre. La mayoría de preguntas fueron de tipo cerradas, es decir, se podían responder con un simple sí o no porque se referían a la presencia o a la disponibilidad de un proceso o parte de una infraestructura. Algunas preguntas tenían un grado de medida más preciso porque evaluaban el nivel de madurez de los procesos.
Control de versiones. La primera pregunta de la
encuesta se refiere al control de versiones y a la gestión de la configuración del proyecto. El uso de herramientas de control de versiones, como CVS [15], les permite a múltiples voluntarios trabajar con poca coordinación en el mismo código. Por otra parte, la amplia disponibilidad de repositorios de código los alienta a revisar el código, a eliminar los defectos, o a añadir nuevas funcionalidades. Por lo tanto, esta pregunta indaga si se utiliza un sistema de control de versiones y si está o no disponible públicamente.
Listas de correo. Las listas de correo son importantes en los proyectos de software libre porque crean un medio eficaz y rápido para la comunicación y la coordinación. Además, a menudo se utilizan para responder a las preguntas que plantean usuarios y desarrolladores, y por lo tanto alientan a que más personas participen y contribuyan al proyecto. Esta pregunta consulta si existen una o varias listas de correo especializadas o si no existen. Las listas dedicadas a diferentes temas ayudan a mantener el enfoque y pueden existir de usuarios, de desarrolladores y de anunciantes. En la encuesta también se tiene una pregunta acerca de la disponibilidad de archivos de listas de correo, porque ofrecen la posibilidad de seguir los debates anteriores y encontrar respuestas ofrecidas previamente. Esto reduce el tiempo que dedican los desarrolladores a responder preguntas ya tratadas, y se reduce la barrera de ingreso para desarrolladores potenciales.
Documentación. La tercera categoría indaga por la
disponibilidad de documentación para usuarios y desarrolladores. Puede haber una relación importante entre la documentación del usuario y el éxito de un proyecto, porque es posible que no sean capaces de utilizar el software si no está bien documentado. La documentación de un desarrollo dedicado podría alentar a nuevos voluntarios a contribuir, con lo que se reduce la curva de aprendizaje asociada cuando un integrante se involucra en el proyecto. Si todos se adhieren a los estándares de codificación, que se describen en la documentación para los desarrolladores, se podría incrementar la capacidad de mantenimiento y la calidad del código fuente.
23 pruebas unitarias, y la tercera comprueba la presencia
de un sistema de seguimiento de defectos o de rastreo de problemas. Este sistema podría alentar a los usuarios a que informen los defectos, para que los desarrolladores los eliminen y así mejorar la calidad del software. También puede ser un buen mecanismo para capturar retroalimentación y garantizar que no se pierda la posible entrada.
Portabilidad. La última pregunta indaga por la
portabilidad del software, porque un producto puede ser convertido a una amplia variedad de plataformas, lo que atrae a más usuarios que puedan contribuir al proyecto. Por otra parte, convertir software a una nueva plataforma a menudo pone de relieve los defectos que se manifiestan sólo en circunstancias especiales. Esta pregunta diferencia la portabilidad entre tres niveles: (1) dirigida específicamente a una plataforma, (2) soporta un conjunto de plataformas o (3) soporta múltiples plataformas a través de un proceso que identifica automáticamente las características de un sistema.
2.2 Estudio de caso
Se seleccionaron 80 proyectos de SourceForge.net y se aplicó un proceso de valoración para evaluar el nivel de madurez. Este sitio presenta una alta popularidad para alojar proyectos de software libre y de código abierto y tiene una base de datos de más de 95.000 proyectos; cuenta con más de un millón de desarrolladores registrados y ofrece diversos tipos de infraestructura, como CVS, listas de correo y sistemas de seguimiento a problemas. Aunque la investigación se aplicó sobre proyectos alojados en este sitio los resultados obtenidos también se pueden replicar a proyectos open source alojados en otros portales. Lo mismo se puede hacer con la valoración aplicada al estudio de caso, porque el detalle con que se describe permite que otros investigadores la utilicen.
Para alcanzar el objetivo de investigar si el nivel de madurez de los procesos empleados está relacionado con el éxito de un proyecto se seleccionaron al azar 40 proyectos exitosos y 40 fracasados. SourceForge.net proporciona estadísticas elaboradas que permiten contrastar los resultados obtenidos. Aunque el número de descargas no equivale ni implica necesariamente calidad o incluso éxito [13], es una métrica del nivel de uso, porque los usuarios de software de código abierto lo
deben descargar activamente en lugar de utilizar aplicaciones pre-instaladas. Además, la ventaja de utilizar esta métrica es que es objetiva e independiente, porque son los usuarios quienes la determinan y no el investigador.
Primero se seleccionaron 40 proyectos que estuvieran en la lista de los 100 más descargados. Dado que en este estudio de caso la métrica de comparación es un criterio importante, no se seleccionaron proyectos que no crearan componentes software, pero sí se tuvieron en cuenta los que reunieran programas creados en otros lugares. Tampoco se seleccionaron los que no disponían de código fuente, porque esta característica permite una evaluación más completa. De acuerdo con estos criterios se excluyeron 33 proyectos que estaban por fuera del top 100 y, de los proyectos restantes, se seleccionaron 40 al azar.
Para seleccionar los proyectos fallidos se empleó la métrica de descarga. El valor del percentil se tomó desde septiembre de 2003, porque esto indica cómo se ubica un proyecto con relación a los demás. Los proyectos exitosos seleccionados presentaron un percentil promedio de 97,66% (σ = 2,78). Teniendo en cuenta este valor se eligió de forma arbitraria un límite superior de 75% como el criterio para un proyecto fallido, porque es considerablemente menor que el promedio de colocación de un proyectos exitoso. En el proceso de selección de los proyectos fallidos se hizo evidente que el número promedio era mucho más pequeño que el de los que tienen éxito. Aunque esta observación es interesante y debería ser corroborada con mayor detalle en el futuro, para este estudio de caso es problemática porque los dos grupos tenían que poseer características similares y sólo diferir en su éxito. Si los grupos diferían en otras formas no fue posible ver claramente su relaciona sólo con el éxito del proyecto. Por lo tanto, los fallidos fueron seleccionados al azar hasta que este grupo tuviera características similares a las de los proyectos exitosos. En particular, se tuvieron en cuenta los factores de edad, líneas de código y estado de desarrollo, como se puede observar en la Tabla 1. El estado de desarrollo se basó en la categorización que hace SourceForge.net y las líneas de código se determinaron con el programa SLOCCount [9, 16]. Al final, los grupos se compararon de acuerdo con estas variables sin una diferencia significativa. Sin embargo, diferían altamente en cuanto a su éxito.
Tabla 1 Media y desviación estándar de los proyectos exitosos y fracasados
Edad LOC Estado Categorización
Media Exitosos 1163 126500 4.43 97.66%
Fracasados 1066 78140 4.11 41.18%
Desviación estándar Exitosos 298 167995 1.06 2.78% Fracasados 291 123109 0.98 22.09%
Los 80 proyectos fueron evaluados por dos investigadores, cada uno seleccionó 40 proyectos al azar. La evaluación se realizó a ciegas, es decir, no sabían si un proyecto se consideraba exitoso o no. Los investigadores eran estudiantes de posgrado de Ciencias
24 diseñó de forma que se garantizara una buena validez, el
hecho de que los investigadores tuvieran poca familiaridad con el código abierto fortalece las bases metodológicas de este estudio.
Luego de reunir y verificar los datos y de culminar y verificar las evaluación, se realizaron diversas pruebas estadísticas. La prueba de chi-cuadrado se utilizó para los datos nominales y la de Wilcoxon para los datos ordinales. Todas las pruebas se realizaron con el programa GNU R versión 1.8.0 y se llevaron a cabo con α =
0,05 ―la probabilidad de rechazar la hipótesis estadística
prueba cuánto, de hecho, esa hipótesis es verdadera―. La hipótesis nula para todas las pruebas fue que no existe diferencia entre los proyectos exitosos y los fracasados, además, todas las pruebas fueron de dos caras.
3. RESULTADOS Y CONCLUSIONES
Se analizaron los datos para cada pregunta del formato de valoración. A continuación se presentan los resultados individuales, seguidos por una discusión y un estudio prospectivo para futuras investigaciones.
3.1 Resultados
En total se llevaron a cabo nueve pruebas estadísticas correspondientes a las preguntas que conforman la evaluación. Como era de esperar debido al número, algunas pruebas revelaron diferencias significativas en los dos grupos, mientras que otras no lo hicieron. El control de versiones es uno de los aspectos en los que estos grupos difieren significativamente: mientras que los proyectos exitosos muestran 1,75 puntos en promedio,
los fallidos tiene 1,275. Así mismo, en la disponibilidad de listas de distribución también difieren: los exitosos no sólo hacen mejor uso de estas listas, obteniendo 1,55 puntos en promedio, en comparación con los 0,925 de los fracasados, sino que también proporcionan archivos de sus discusiones en más casos; el 80% de los proyectos exitosos ofrecen archivos de correo, mientras que sólo la mitad de los fallidos lo hace. La tercera categoría de la evaluación se relaciona con la documentación, como se observa en la Tabla 2.
Tabla 2 Disponibilidad de la documentación
Usuario Desarrollador
Exitosos Disponible 23 (57.5%) 10 (25.0%) No disponible 17 (42.5%) 30 (75.0%)
Fallidos Disponible 24 (60.0%) 5 (12.5%) No disponible 16 (40.0%) 35 (87.5%)
Los grupos no difieren significativamente en la disponibilidad de documentación para el usuario o para los desarrolladores. Alrededor del 60% de los proyectos ofrece documentación para el usuario y sólo el 25% de los exitosos y el 12,5% de los fracasados la ofrecen para los desarrolladores. La cuarta categoría, pruebas, muestra resultados combinados. Los proyectos significativamente más exitosos ofrecen versiones candidatas y hacen uso de un sistema de seguimiento de defectos. Sin embargo, los grupos no difieren mucho en el uso de pruebas unitarias o de regresión. En la Tabla 3 se puede observar estas diferencias.
Tabla 3 Presencia de facilidades de pruebas
Versiones candidatas
Pruebas automáticas
Seguimiento a defectos
Exitosos Utilizan 22 (55.0%) 5 (12.5%) 35 (87.5%) No utilizan 18 (45.0%) 35 (87.5%) 5 (12.5%)
Fallidos Utilizan 11 (27.5%) 8 (20.0%) 12 (30.0%) No utilizan 29 (72.5%) 32 (80.0%) 28 (70.0%)
En resumen, los proyectos más exitosos usan un sistema de seguimiento de defectos y más de la mitad ofrece versiones candidatas, pero pocos utilizan conjuntos de pruebas. Por otro lado, sólo el 30% de los proyectos fracasados utiliza un sistema de seguimiento de defectos y tienen versiones candidatas disponibles. Finalmente, no se encontraron diferencias importantes entre los grupos con respecto a la portabilidad. Los dos grupos tienen cifras casi iguales: los exitosos tienen un promedio de 1,325 puntos y los fallidos 1,375.
3.2 Discusión
El análisis estadístico de los datos obtenidos en la evaluación de los grupos de proyectos muestra que en 5 de las 9 pruebas se encontraron diferencias significativas. En los casos en los que se encontraron mayores diferencias se debe a que los exitosos emplean un proceso más maduro que los fracasados. Debido al número de pruebas en las que difieren se puede concluir que el nivel de madurez de los procesos empleados por un proyecto sí está vinculado a su éxito. Por lo tanto, con los resultados se demuestra la existencia de una relación entre los
procesos utilizados por un proyecto y su éxito, pero en este estudio no se investigó la naturaleza de esta relación. Particularmente, no se puede hacer conclusiones sobre una posible causalidad entre los procesos de madurez y el éxito. Además, se debe llevar a cabo una amplia investigación acerca de los aspectos cualitativos de la relación entre el nivel de madurez de los procesos y el éxito. Finalmente, aunque esta investigación demuestra que el nivel de madurez de los procesos desempeña un papel importante, puede haber otros factores que no se consideraron en el estudio.
25 privado limita el acceso de los colaboradores
potenciales. Además, un repositorio CVS disponible al público les permite a los colaboradores monitorear lo que otras personas están trabajando, lo que permite que múltiples personas puedan trabajar juntas de manera eficiente y de forma distribuida. Así como para los sistemas de seguimiento de defectos, los sistemas de control de versiones públicas pueden atraer a más voluntarios porque los usuarios pueden ver qué se necesita y cómo involucrarse.
Listas de distribución. De manera similar a las
herramientas de control de versiones, las listas de correo tienen una importante función para la coordinación de un proyecto. Las listas archivadas pueden remplazar hasta cierto punto la documentación, porque en ellas los usuarios encuentran respuesta a las preguntas que se ya han formulado. Los potenciales voluntarios pueden seguir los debates anteriores y aprender fácilmente para participar en el proyecto. De acuerdo con los resultados de este estudio, tanto para las herramientas de control de versiones como para las listas de correo, no es claro si un proyecto exitoso requiere de este tipo de infraestructura para prosperar, o si la implementación de la misma atrae a más voluntarios y lograr mayor éxito. La hipótesis a la que se llega aquí es que no existe una causalidad clara y que ambos se
condicionan mutuamente. Sin embargo, es claro que las
listas y las herramientas son factores clave para el éxito de los proyectos de código abierto.
Documentación. La presencia de documentación para
el usuario y el desarrollador no es un buen indicador para el éxito de un proyecto. Mientras que más de la mitad de los proyectos de este estudio ofrecen documentación a los usuarios, un número mucho más pequeño proporciona documentación para los desarrolladores. Esta diferencia sugiere que los hallazgos se deben interpretar de manera diferente. Debido a que un alto número de proyectos ofrece documentación para los usuarios se puede afirmar que éste es un factor importante en los proyectos de software libre, sin embargo, por sí solo no determina el éxito. Por otra parte, la documentación para los desarrolladores no es muy común en los proyectos de software libre. Una razón puede ser que los potenciales interesados encuentran más respuestas a sus preguntas en otras fuentes, como en los archivos de listas de correo o en el mismo código fuente. Si no existe una guía acerca del estilo y la lógica de codificación, ellos las pueden derivar utilizando directamente el código fuente del proyecto y luego seguir el proceso de desarrollo en las listas de correo, y pueden aprender las reglas observándolos en acción [17]. Esto sugiere que la documentación escrita no es necesaria, porque ya está indirectamente disponible. Los desarrolladores competentes podrán encontrar toda la información desde otras fuentes o mediante la observación directa del proceso. Aunque esta explicación no parece muy plausible queda latente una cuestión: sería interesante estudiar la calidad del
código de los proyectos de software libre y de código abierto para investigar si la disponibilidad de la documentación para los desarrolladores repercute en una mayor calidad del código. También es posible que la disponibilidad de una buena documentación atraiga un número mayor de potenciales desarrolladores que contribuyan al proyecto.
Pruebas sistemáticas. El análisis de los procesos que implican pruebas demuestra que los proyectos exitosos hacen más uso de versiones candidatas y de sistemas de seguimiento de defectos que los proyectos fallidos. No se encontraron diferencias en la presencia de conjuntos de pruebas automatizadas. La disponibilidad de versiones candidatas se toma como un indicador de un plan de liberación bien definido y, aunque puede servir para revelar la calidad cualitativa del estudio y para comparar las estrategias de lanzamiento de los diferentes proyectos, los hallazgos sugieren que una estrategia de liberación clara unida a un buen plan de pruebas contribuye al éxito del proyecto. Además, los sistemas de seguimiento de defectos juegan un papel importante. Mientras que los exitosos y fallidos en este estudio no difieren significativamente en tamaño, los exitosos son más propensos a recibir retroalimentación de los usuarios. Esta información se debe capturar adecuadamente para luego analizarla y priorizarla. Ninguno de los dos grupos hace mucho uso de conjuntos de pruebas automatizadas. Una razón puede ser la naturaleza misma del código abierto. Raymond [3] afirma que este tipo de proyectos se beneficia de la amplia comunidad que los rodea y que proporciona informes de defectos. Una vez que se produce una regresión es muy probable que alguno de los usuarios se dé cuenta rápidamente y la reporte. Esto podría ser una razón por la que se invierte poco tiempo en aplicar pruebas automatizadas, sin embargo, queda por ver si su uso podría incrementar la calidad del producto. Las pruebas automatizadas les permitirían a los voluntarios dedicar menos tiempo a rastrear regresiones y dedicarse a eliminar otros defectos o a implementar nuevas características.
Portabilidad. Este factor es representativo en ambos grupos. Una probable razón es que la filosofía Unix siempre ha promovido la portabilidad [18]. Conectado a esto se encuentra la disponibilidad del software, como autoconf [19, 20], lo que hace que sea relativamente fácil para una pieza de software determinar automáticamente las características de una plataforma y adaptarse a ella. Otro factor que podría contribuir a la portabilidad es la naturaleza diversa de los voluntarios que participan en proyectos de software libre.
26 proyectos de software libre y de código abierto se
benefician del uso de procesos maduros. Aunque este
estudio se centra en procesos relacionados con la coordinación y la comunicación ―factores importantes en los proyectos distribuidos― el proceso de código abierto también se podría beneficiar de otros que utilizan los proyectos tradicionales de Ingeniería de Software. Este hallazgo contrasta con la sugerencia de algunos desarrolladores de código abierto de que su modelo de desarrollo es único y que no se beneficiarán del nivel de madurez de los procesos o las ideas tradicionales [6].
3.3 Trabajo Futuro
Los resultados en esta investigación corroboran la hipótesis de que los proyectos de software libre y de código abierto se benefician de procesos maduros. Además, apoyan la noción de que algunas ideas de la Ingeniería de Software se pueden aplicar a este modelo de desarrollo. Estos resultados tienen especial valor para demostrar la importancia de continuar con la investigación en esta área y abordar algunas de las cuestiones que quedaron planteadas en este artículo.
Si bien se pudo demostrar que la documentación para el desarrollador no contribuye al éxito de un proyecto, se acepta que su solidez puede llevar a una mayor calidad del código fuente. Un futuro estudio que compare la calidad del código de proyectos con y sin buena documentación podría arrojar más luz acerca de esta cuestión.
Por otra parte, mientras que en los proyectos de software libre no es tan común el uso de conjuntos de pruebas automatizadas, pueden ofrecer ciertos beneficios a los participantes voluntarios en un proyecto. Otra cuestión relacionada con la prueba es si los proyectos que utilizan sistemas de seguimiento de defectos tienen una mayor tasa de eliminación que los proyectos que utilizan técnicas menos fiables. Por último, un enfoque cualitativo comparando diferentes estrategias de liberación podría conducir a directrices específicas en desarrollo que promuevan estrategias exitosas para la distribución de software de código abierto, probado y estable para usuarios finales
4. CONCLUSIONES
Se ha observado en este trabajo que en muchos aspectos el software libre y los proyectos de código abierto son diferentes a los proyectos tradicionales de Ingeniería de Software. Esto se debe principalmente a que los primeros normalmente los realizan voluntarios distribuidos por todo el mundo. Esta diferencia plantea la cuestión de si las ideas tradicionales se pueden aplicar a los proyectos de código abierto. Se ha propuesto que algunos conocimientos de los modelos de calidad de software, como la demanda por procesos maduros, también se podrían aplicar a estos proyectos. Algunos procesos enraizados en la Ingeniería de Software, como la exigencia de especificaciones de requisitos y otras guías formales, podrían ser incompatibles con la motivación de los participantes voluntarios. Sin embargo, otros pueden ser unificados en el modelo de desarrollo de código abierto y
contribuir a su éxito y calidad. En particular, los procesos relacionados con la coordinación y la comunicación parecen ser necesarios para los proyectos de software libre.
Para investigar esta hipótesis se llevó a cabo un estudio de caso con la participación de 80 proyectos elegidos al azar en SourceForge.net. Se tomaron 40 proyectos exitosos y 40 fracasados y se evaluaron en cuanto al nivel de madurez en varios aspectos. Los resultados de los análisis estadísticos mostraron que la madurez de algunos procesos se relaciona con el éxito del proyecto. Además, se identificó la importancia de utilizar herramientas de control de versiones y de una comunicación efectiva a través de listas de correo, y se encontraron varias estrategias eficaces relacionadas con las pruebas. Estos resultados aportan valor para los profesionales, porque les indican cuáles áreas merecen más atención.
Los hallazgos de este estudio destacan la importancia de aplicar conocimientos de Ingeniería de Software en el modelo de desarrollo de código abierto. Se sugieren otras investigaciones para explorar con mayor detalle algunos de los resultados de este trabajo, como una comparación exhaustiva de la calidad del código y una evaluación cualitativa de las estrategias de liberación. Esto contribuirá a incrementar la calidad y el éxito de los proyectos de software libre y de código abierto.
5. REFERENCIAS
[1] Michlmayr, M. (2004). Managing volunteer activity in free
software projects. Proceedings of the 2004 USENIX Annual
Technical Conference, FREENIX Track, pp. 93-102. Boston, USA.
[2] Michlmayr, M. & Mako, H.B. (2003). Quality and the
reliance on individuals in free software projects.
Proceedings of the 3rd Workshop on Open Source Software Engineering, pp. 105-109. Portland, OR, USA. [3] Raymond, E.S. (2010). The Cathedral and the Bazaar.
Snowball Publishing.
[4] Raymond, E.S. (1999). Linux and open-source success. IEEE Software, 16(1), pp. 85-89.
[5] Fagan, M.E. (1976). Design and code inspections to reduce
errors in program development. IBM Systems Journal,
15(3), pp.182-211.
[6] Massey,B. (2003). Why OSS folks think SE folks are
clue-impaired. Proceedings 3rd Workshop on Open Source
Software Engineering, pp. 91-97. University College Cork, Ireland.
[7] Hars, A. & Ou, S. (2000). Why is open source software viable? A study of intrinsic motivation, personal needs, and
future returns. Proceedings of the Sixth Americas
Conference on Information Systems (AMCIS), pp. 486-490. Long Beach, California.
[8] Mockus, A.; Fielding, R.T. & Herbsleb, J.D. (2002). Two case studies of open source software development: Apache and
Mozilla. ACM Transactions on Software Engineering and
Methodology, 11(3), pp. 309-346.
[9] González-Barahona, J.M. (2001). Counting Potatoes: The
Size of Debian 2.2. Upgrade, 2(6), pp. 60-66.
[10] Robles, G.; Gonzalez-Barahona, J.M. & Michlmayr, M. (2005). Evolution of volunteer participation in libre
27 the First International Conference on Open Source
Systems, pp. 100-107. Genova, Italy.
[11] Koch, S. & Schneider, G. (2002). Effort, cooperation and
coordination in an open source software project: GNOME.
Information Systems Journal, 12(1), pp. 27-42.
[12] Schach, S.R. et al. (2002). Maintainability of the Linux
kernel. IEE Proceedings – Software, 149(1), pp. 18-23.
[13] Howison, J. & Crowston, K. (2004). The perils and pitfalls
of mining Source-Forge. Proceedings of the International
Workshop on Mining Software Repositories (MSR), pp. 7-11. Edinburgh, UK.
[14] Senyard, A. & Michlmayr, M. (2004). How to have a
successful free software project. Proceedings of the 11th
Asia-Pacific Software Engineering Conference, pp. 84-91. Busan, Korea.
[15] Vesperman, J. (2003). Essential CVS. O’Reilly & Associates.
[16] Wheeler, D.A. (2001). More than a gigabuck: Estimating
GNU/Linux’s size. Online [Mar. 2012].
[17] Krogh, G.; Spaeth, S. & Lakhani, K.R. (2003). Community, joining, and specialization in open source software
innovation: a case study. Research Policy, 32(7), pp.
1217-1241.
[18] Raymond, E.S. (2003). The Art of Unix Programming. Addison-Wesley.
[19] Vaughan, G.V. (2000). GNU Autoconf, Automake, and
Libtool. SAMS Publishing.
[20] Oram, A. & Loukides, M. (1996). Programming With GNU
