Hace solo unos días que recogíamos la noticia de la nueva casa de Audacity, que pasa a formar parte del portafolio de soluciones de Muse Group. Un movimiento un tanto extraño, porque no es habitual que proyectos de software libre sin un modelo de negocio claro detrás sean objeto de compra. Sin embargo, el acuerdo está cerrado y el desarrollo de Audacity bajo la dirección de Muse Group, que como no podía ser de otra manera, se comprometió a mantener la aplicación con la misma licencia.

De hecho, Muse Group no solo aseguró que nada cambiaría con respecto al modelo de desarrollo abierto de Audacity, sino que anunció que trabajarían para mejorar alguno de los aspectos más descuidados del editor de audio, como lo es una interfaz que apenas ha evolucionado en años. Ni siquiera el reciente lanzamiento de Audacity 3.0 se preocupó por ello, introduciendo como principal novedad un nuevo formato de archivo que también está generando bastante rechazo entre los usuarios, a pesar de las mejoras que prometía.

La marcha de Audacity bajo Muse Group, sin embargo, no ha comenzado con buen pie, y es que una de las primeras novedades que se han propuesta nada tiene que ver con lo adelantado, sino con la introducción de telemetría en la aplicación. En concreto, telemetría que enviará datos a Google Analytics y Yandex Metrica:

• A Google Analytics, los tiempos de inicio y fin de sesión, errores, qué opciones y recursos se utilizan o qué formatos de archivo se importan y exportan, incluyendo un código de identificación único por cada instalación.
• A Yandex Metrica (para quien no lo conozca, algo así como el Google ruso), métricas para «poder estimar correctamente los usuarios activos diarios».

Dice el desarrollador que ha propuesto este cambio que utilizan Yandex Metrica por lo ajustado de las cuotas (gratuitas) de Google Analytics, por lo que se entiende que si pudieran lo harían todo con Google. Ambos servicios registran también la IP del usuario.

Así, muchos usuarios han saltado rápidamente a la yugular de Muse Group por la invasión a la privacidad que este cambio presenta, aunque según se ha asegurado desde el proyecto, se trata de una opción que estará deshabilitada por defecto. Solo si el usuario decide voluntariamente activarla, se enviarán los reportes de telemetría especificados, que es el método correcto de proceder en estos casos. Pero la cuestión en disputa no es tanto esta, como el mero hecho de introducir telemetría en una aplicación libre que en principio no la necesita.

Así se mostrará la telemetría en Audacity (se podrá activar y desactivar también en las preferencias de la aplicación)

A favor de los desarrolladores -y en contra de quienes dicen que la telemetría no tiene cabida en una aplicación libre o del tipo de Audacity- hay que señalar que es mucho el software libre que utiliza telemetría, ya que es la mejor manera de recabar datos que indiquen dónde enfocar los esfuerzos en el desarrollo: ¿qué opciones usan más y menos los usuarios? ¿Cómo las usan? ¿En qué equipo? ¿Con qué recursos? La telemetría sirve para todo esto.

En contra de los desarrolladores… Utilizar Google y Yandex era la peor idea posible a tenor del escenario y de acuerdo a alguno de los más de 500 comentarios que se agolpan en el hilo del cambio en GitHub, el código propuesto enviaría más información a ambos servicios: «este código está cargando partes de sus archivos guardados en Google y Yandex», comenta alguien. Y sí, ya hay quien habla de fork y con más de un pretendiente para mantenerlo.

Actualización: terminando de redactar este artículo, ha habido una actualización por parte del desarrollador ampliando la información:

• La telemetría es estrictamente opcional y está deshabilitada de forma predeterminada. No se comparten datos a menos que se elija.
• La telemetría solo funciona en las compilaciones realizadas por GitHub CI desde el repositorio oficial.
• Si se está compilando Audacity desde el código fuente, se proporcionará una opción para habilitar el código de telemetría. Esta opción estará desactivada de forma predeterminada.

Y con respecto al objeto de dicha telemetría, se matiza igualmente indicando:

¿Por qué tener telemetría?

Básicamente, nos ayuda a identificar los problemas de productos con anticipación:

• Audacity se usa ampliamente en varias plataformas, pero no tenemos información sobre la estabilidad de la aplicación.
• Es difícil para nosotros estimar con precisión el tamaño de la base de usuarios.
• Necesitamos una forma de tomar decisiones informadas sobre qué versiones de SO admitir. Por ejemplo, ¿podemos aumentar la versión mínima de macOS a 10.10 para actualizar los wxWidgets a la última versión?
• Tenemos un problema conocido con el nuevo formato de archivo introducido en Audacity 3.0. Lo encontramos con la gran ayuda de los miembros de la comunidad en nuestro foro. Sin embargo, no tenemos forma de estimar el impacto de estos problemas en los usuarios. ¿Es solo un caso aleatorio? ¿Necesitamos acelerar el trabajo en la herramienta de recuperación o ayudar a los usuarios uno por uno? ¿O necesitamos repensar el formato del archivo para hacerlo más seguro y más fácil de recuperar?

Respecto a las preocupaciones sobre la elección de proveedores:

• No incorporamos el seguimiento entre sitios, lo que limita la capacidad de identificar al usuario tanto por Google como por Yandex.
• Yandex solo recibiría el evento «aplicación abierta» para ayudarnos a estimar el tamaño de la base de usuarios.
• Google solo recibiría: a) eventos de inicio y finalización de la sesión; b) errores de depuración, c) formatos de archivo utilizados para importar y exportar, d) versiones OS y Audacity, e) uso de efectos, generadores y herramientas de análisis para priorizar mejoras futuras
• Consideraremos reemplazar Google y Yandex con otro servicio si encontramos uno que cumpla con nuestros requisitos; gracias por las sugerencias y sigan viniendo.