Una comparación colaborativa del rendimiento en proyectos de software libre

This work is licensed under a Creative Commons “Attribution-NonCommercial-NoDerivatives 4.0 International” license. Una comparaci´on colaborativa del rendimiento en proyectos de software libre Jos´e-Manuel S´anchez1, Miguel Angel Olivero1, FJ Dominguez-Mayo1, and David Benavides1 Departamento de Lenguajes y Sistemas Inform´aticos, Escuela T´ecnica Superior de Ingenier´ıa Inform´atica, Seville, Spain {jsanchez7, molivero, fjdominguez, benavides}@us.es Abstract. En los ´ultimos a˜nos, los proyectos de software de c´odigo abierto (OSS) se han vuelto cada vez m´as importantes para muchas organizaciones. A medida que estos proyectos crecen en tama˜no y complejidad, aumenta la necesidad de un desarrollo de software de alta calidad. Al mismo tiempo se ha comprobado que el uso de pr´acticas de DevOps mejoran la calidad y el rendimiento organizacional. Sin embargo, es dif´ıcil medir el impacto real que supone aplicar estas pr´acticas porque los m´etodos de evaluaci´on existentes, como los informes de DORA, se centran principalmente en la implementaci´on continua y la entrega en producci´on. Esto se diferencia de las prioridades de los proyectos OSS, que enfatizan la liberaci´on continua de c´odigo y su impacto en los usuarios en lugar de en sus implementaciones o entregas en producci´on. Para abordar esta situaci´on se emplea un sistema colaborativo de evaluaci´on, Performance-Tracker (PT), dise˜nado para evaluar y comparar el rendimiento de proyectos OSS usando varios factores. PT extrae informaci´on p´ublica de proyectos OSS y ha permitido generar una base de conocimientos compartida que supone la primera base de conocimiento del marco de referencia. Esto se ha logrado evaluando el rendimiento de 50 proyectos OSS en su primera versi´on. Este enfoque permite que puedan evaluarse m´as proyectos y que comparen su rendimiento en base a los puntos de referencia de la base de conocimiento colaborativa. Usando PT y con las m´etricas propuestas, los proyectos OSS pueden analizar y comparar su rendimiento con respecto al resto de proyectos participantes. Esto, a su vez, permite que sus resultados alimenten la base de conocimiento y enriquezcan el marco de referencia. PT, junto a su base de conocimiento inicial, es una propuesta integral para la evaluaci´on de proyectos OSS, abordando los desaf´ıos propios de este tipo de proyectos. Adem´as, el entorno de aprendizje colaborativo persigue fomentar un proceso de desarrollo m´as eficiente en los proyectos OSS. Al permitir una comparaci´on de m´etricas, los equipos de desarrollo pueden identificar claramente c´omo mejorar su rendimiento. Keywords: Desarrollo software ·DevOps ·Evaluaci´on comparativa · Software delivery ·Software libre This work is licensed under a Creative Commons “Attribution-NonCommercial-NoDerivatives 4.0 International” license. 2 S´anchez et al. 1 Introducci´on y contexto Cada vez m´as son las organizaciones que comienzan a usar proyectos de software de c´odigo abierto (OSS) [3]. Esto motiva la creciente popularidad de proyectos de esta naturaleza que hace que los proyectos cuenten con m´as participaci´on. De este modo, los proyectos OSS tienen cada vez una embergadura mayor y necesitan de estrategias y t´acticas que ayuden al mantenimiento de los proyectos [2]. Pr´acticas como DevOps han ayudado a mejorar el rendimiento de la organizaci´on y la calidad de los resultados de los proyectos, aunque no permiten contrastar el impacto que implica su uso. M´etricas como DORA [1] permiten extraer informaci´on para comparar el rendimiento que obtienen las organizaciones tras el uso de las pr´acticas. Sin embargo, DORA no permite comprender el impacto de las estrategias aplicadas a proyectos OSS. Mientras que DORA se centra en la producci´on y las operaciones de servicio, los proyectos OSS persiguen la liberaci´on de c´odigo continua y evaluar el impacto en terceras partes. S´anchez-Ruiz et al. [4] explor´o las limitaciones que presentan estas m´etricas al aplicarse a proyectos OSS y propone una adaptaci´on de las m´etricas DORA para que ´estas puedan ajustarse al contexto de los proyectos OSS. Estas m´etricas, que pretenden concretar conceptos en contextos de desarrollos y operaciones, permiten comprender la frecuencia de liberaci´on de c´odigo, el tiempo que tarda un bug en resolverse y un cambio en estar disponible, y la tasa de errores que se reportan. Al considerar proyectos de c´odigo abierto, esta informaci´on puede encontrarse en las plataformas como GitHub. Para automatizar el proceso de captura de las m´etricas que permitan comprender el impacto de aplicar pr´acticas como DevOps, S´anchez-Ruiz et al. dise˜naron el sistema ”Performance-Tracker” [5] que enriquece la informaci´on disponible en GitHub. De esta forma, al visitar un proyecto de GitHub es posible observar los valores de las cuatro m´etricas y permite comparar el rendimiento de los proyecto. En este art´ıculo se usan las m´etricas y herramientas de S´anchez-Ruiz et al. [4,5] para explorar los valores medidos en varios proyectos OSS y estudiar las limitaciones actuales de las m´etricas y la herramienta propuesta. 2 Uso del benchmarking Para crear la base de conocimientos inicial que permita conocer el grado de rendimiento de los proyectos se han tomado 50 proyectos OSS: 1. Angular, 2. Kubernetes, 3. TensorFlow, 4. Visual Studio Code, 5. Vue.js, 6. Dubbo, 7. Spring Framework, 8. Matplotlib, 9. PyTorch, 10. Terraform, 11. Node.js, 12. OBS Studio, 13. Electron, 14. Docker Compose, 15. Charts.js, 16. Elasticsearch, 17. Nextcloud, 18. SQLAlchemy, 19. TypeScript, 20. Babel, 21. React Native, 22. Godot, 23. Next.js, 24. Swift, 25. Material UI, 26. Jax, 27. Windows Terminal, 28. DeepSpeed, 29. Jest, 30. NocoDB, 31. Strapi, 32. Docusaurus, 33. Directus, 34. Keycloak, 35. Grafana, 36. Sentry, 37. Prometheus, 38. Chatwoot, 39. Renovate, 40. Playwright, 41. .NET MAUI, 42. Remix, 43. Netbox, 44. CloudQuery, 45. Focalboard, 46. Matomo, 47. Bazel, 48. WooCommerce, 49. Superset, 50. Airflow. This work is licensed under a Creative Commons “Attribution-NonCommercial-NoDerivatives 4.0 International” license. Una comparaci´on colaborativa del rendimiento en proyectos de software libre 3 La extracci´on de datos, realizada en septiembre de 2023, de cada uno de estos proyectos incluye el nombre, la direcci´on donde se aloja el proyecto, la cantidad de contribuidores, el n´umero de incidencias abiertas y cerradas, la cantidad de solicitudes de incorporaci´on de c´odigo (pull requests) abiertas y completadas, la cantidad de liberaciones de c´odigo y la fecha de inicio del proyecto. Aunque todos los proyectos estudiados est´an alojados en la plataforma GitHub, cada uno de ellos se autogestiona de manera diferente. Al obtener los datos de los proyectos se observ´o que el etiquetado y clasificaci´on de las incidencias era heterog´eneo, dificultando la captura automatizada de estos datos. Por ejemplo, los valores necesarios para las m´etricas ”Time To Repair Code” y ”Bug Issues Rate” [4] se obtienen a partir de la cantidad de bugs de cada proyecto. En el caso de identificaci´on de los bugs se han encontrado etiquetas variadas como las siguientes: ’bug’, ’type: bug/fix’, ’Needs Reproduction’, ’Release critical’, entre otras muchas. A pesar de que existen diferencias en el etiquetado de las incidencias, ha sido posible recoger datos de los proyectos. Sin embargo, se han encontrado 12 proyectos en los que ha sido imposible incluir sus datos para la versi´on inicial del banco de informaci´on: 1. odoo, 2. linux, 3. mockito, 4. guava, 5. pygments, 6. express, 7. bootstrap, 8. axios, 9. geany, 10. webiny, 11. appwrite, 12. medusa. Proyectos como ’odoo’ o ’Linux’ no usan la caracter´ıstica GitHub Release, haciendo que no sea posible calcular las m´etricas que dependen de las liberaciones de c´odigo. ’Bootstrap’ o ’Axios’ no usan sistema de etiquetado para identificar las incidencias que son bug. El resto de los repositorios mencionados no tienen datos p´ublicos disponibles que puedan ser usados para alimentar las m´etricas. 3 Resultados del estudio Una vez recogidos los datos, se han estudiado y se han ordenado los proyectos en terciles (tabla 1). De esta forma se han creado tres niveles (Bajo [Low], Medio [Medium], Alto [High]) para cada una de las m´etricas. En base a estos niveles, un proyecto puede compararse con otros de su entorno para identificar en qu´e categor´ıa se encuentra para cada una de estas m´etricas, e identificar ´areas de mejora f´acilmente. Esta primera versi´on de los resultados podr´a enriquecerse con una mayor cantidad de proyectos, haciendo que los resultados y la separaci´on de los niveles sean m´as precisos. As´ı mismo, los proyectos que quieran comparar sus resultados con los de la base inicial necesitar´an enviar sus datos para ser cotejados, lo que a su vez ayudar´an a ajustar los valores de cada m´etrica. El aspecto colaborativo de la plataforma se centra en compartir informaci´on sobre el rendimiento de los proyectos entre todos los participantes, de forma que los valores de las m´etricas representen la realidad de los proyectos OSS y los participantes puedan comparar su rendimiento con el del resto. 4 Conclusiones y trabajos futuros Aplicar las m´etricas DORA adaptadas a proyectos OSS con los ajustes propuestos por S´anchez-Ruiz [4] junto a la herramienta Performance-Tracker [5], nos This work is licensed under a Creative Commons “Attribution-NonCommercial-NoDerivatives 4.0 International” license. 4 S´anchez et al. Table 1. 2022 OSS projects performance Performance Level Release Frequency Lead Time For Released Changes Time To Repair Code Bug Issues Rate Low More than 22.5 days More than 21 days More than 151 days More than 54% Medium Between 8.5 days and 22.5 days Between 7.5 days and 21 days Between 41 days and 151 days Between 10% and 54% High Less than 8.5 days Less than 7.5 days Less than 41 days Less than 10% ha permitido recoger informaci´on que eval´ua el rendimiento de cada proyecto, y ayuda a identificar ´areas de mejora. Al explorar los diferentes proyectos se han encontrado adem´as restricciones que han impedido aplicar las m´etricas en la totalidad de ellos. Uno de los mayores desaf´ıos actuales para la recogida de muestras es la normalizaci´on en la identificaci´on de bug. Al mismo tiempo, se necesita validar la cobertura de las m´etricas propuestas de forma que ´esta pueda reflejar con mayor precisi´on el rendimiento de los proyectos OSS. Como trabajo futuro se propone descubrir alternativas en la identificaci´on de bugs que ofrezcan mayor confiabilidad a los datos ofrecidos. Por otro lado, para comprender el impacto que tiene esa propuesta en el ´ambito acad´emico e industrial, se estima conveniente medir el valor que aporta la propuesta actual a las partes interesadas para identificar ´areas de mejora. Adem´as, para enriquecer la informaci´on ofrecida por la herramienta PT, se propone estudiar posibles correlaciones entre las m´etricas propuestas y las m´etricas DORA. Acknowledgments. Trabajo parcialmente financiado por FEDER/Ministerio de ciencia, innovaci´on y universidades/Junta de Andaluc´ıa/Agencia Estatal de Investigaci´on/CDTI con los proyectos: Data-pl(PID2022-138486OB-I00) y MIDAS (IDI-20230256) y la red TASOVA PLUS (RED2022-134337-T). References References 1. Cloud, D..G.: 2022 accelerate. state of devops report, https://cloud.google. com/devops/state-of-devops 2. Leite, L., Rocha, C., Kon, F., Milojicic, D., Meirelles, P.: A survey of devops concepts and challenges. ACM Computing Surveys (CSUR) 52(6), 1–35 (2019) 3. OpenLogic by Perforce, O.S.I.: 2023 state of open source report. open source usage, market trends, analysis, https://www.openlogic.com/resources/ 2023-state-open-source-report 4. Ruiz, J.M.S., Mayo, F.J.D., Oriol, X., Crespo, J.F., Benavides, D., Teniente, E.: A benchmarking proposal for devops practices on open source software projects. arXiv preprint arXiv:2304.14790 (2023) 5. S´anchez Ruiz, J.M., Olivero Gonz´alez, M.´ A., Dom´ınguez Mayo, F.J., Oriol, X., Benavides Cuevas, D.F.: Benchmarking del rendimiento de proyectos software de c´odigo abierto mediante una herramienta colaborativa. In: XXVII Jornadas de Ingenier´ıa del Software y Bases de Datos (JISBD 2023) (2023), https://hdl. handle.net/11705/JISBD/2023/7888 ,