Luc Esape es un ingeniero de software del equipo de investigación Spirals en la Universidad de Lille en Francia. Trabaja con el equipo de investigación desde enero de 2017 y su misión es encontrar bugs en software de código abierto publicado en GitHub. Es de los mejores detectando errores y proponiendo parches, pero juega con ventaja, es una máquina.
En realidad su nombre real, el que le pusieron sus creadores, es Repairnator. Repairnator fue creado con la capacidad de corregir errores mucho mejor que los humanos, para ello analiza en tiempo real el código que se compila y sube a repositorios mediante integración continua. El bot funciona en Java, utilizando la cadena de herramientas Maven, en proyectos de código abierto alojados en GitHub que usan Travis CI. Básicamente analiza los proyectos enviados a GitHub, encuentra errores, los arregla con sus conocimientos y envía la corrección a los propietarios de los proyectos.
Que sea un bot le permite estar continuamente trabajando y ser más veloz que nadie. Por ejemplo, a principios de este año encontró un error en una compilación del proyecto GeoWebCache que se había publicado en GitHub diez minutos antes. Diez minutos después de encontrarlo, ya había enviado una propuesta de corrección a los responsables del proyecto. A pesar de que Luc Esape sabe corregir errores, no puede apreciar si le dan las gracias por corregirlos.
Los perjuicios por ser un bot
Por muy bueno que sea Repairnator corrigiendo errores y proponiendo parches a la comunidad de desarrolladores, no es del todo aceptado por los de su entorno. Los investigadores detrás del bot se dieron cuenta de esto comprobando las reacciones de los desarrolladores al recibir las propuestas de corrección. Según indican, los desarrolladores no aceptan las contribuciones de los robots tan fácilmente como las contribuciones de otros humanos, incluso si son estrictamente idénticas.
¿La máquina no sabe código tan bien como un desarrollador? No exactamente, al parecer el problema está en que toleramos más fallos de un humano que de una máquina. Por lo tanto, estamos más predispuestos a aceptar un código de un humano porque "si luego está mal no pasa nada porque todos nos equivocamos" que de un bot porque "es una máquina y debe hacerlo perfecto pero no hay forma de comprobar que no se ha equivocado".
Sus creadores indican que para demostrar que es capaz de estar a la altura de sus colegas humanos, Repairnator no solamente debe crear parches de calidad, sino que debe crearlos antes que cualquier humano. Es más, tampoco puede crear un código correcto pero incomprensible para los desarrolladores, sino que debe limitarse en estilo y calidad a lo que un desarrollador humano puede hacer. En otras palabras, debe asemejarse al máximo posible con los humanos pero ser más veloz que ellos.
Con tal de que las contribuciones hechas por Repairnator fuesen juzgadas por su mérito, los investigadores le dieron una identidad secreta: Luc Esape. Ahora que los investigadores ya han comprobado este perjuicio, revelan la naturaleza del Luc Esape con cada contribución que hace. Los desarrolladores tienen también las instrucciones para bloquear a Luc Esape si no quieren recibir más correcciones de él.
El bot no tiene responsabilidades
Se dejen de lado o no los perjuicios antes las correcciones recibidas de un bot, Repairnator tiene un problema aún mayor. Puede que la comunidad de desarrolladores lo acepte, pero ante los ojos de la ley, no es igual que los demás. Repairnator ya ha experimentado esto con un parche que envió para el proyecto Ditto de Eclipse Foundation. El parche corregía un error de software correctamente, pero los desarolladores no quisieron aceptarlo porque el bot no había firmado el Acuerdo de licencia de colaborador de Eclipse Foundation.
Un bot no puede firmar un acuerdo de licencia porque la ley no lo permite. ¿Quién es el responsable si ocurre algo y es culpa del código desarrollado por el bot? ¿Es culpa del creador del bot, del que lo implementó o del que aceptó su solicitud? De momento Repairnator se está ganando la confianza en la comunidad GitHub, pero aún le queda mucho para ser considerado uno más.
Más información | Martin Monoperrus
Imagen | Unsplash