Ahora que estamos viendo una explosión en el número de proyectos software que se lanzan cada día (en parte gracias al auge del vibe coding / vibe engineering), es más importante que nunca aclarar quién hizo qué dentro del proyecto. A todos los niveles (programación, testing, validación con usuarios…). Y no solo aclarar si el autor fue un humano o una máquina, sino profundizar en sus perfiles para entender hasta qué punto podemos confiar en que el software satisface las necesidades de los usuarios a los que intenta ayudar. Por ejemplo, una app de seguimiento del ciclo menstrual diseñada para mujeres puede inspirar mayor confianza en las usuarias si entre quienes la desarrollan y la prueban hay mujeres.
Informar sobre la diversidad en proyectos de software puede aumentar la confianza de los usuarios y ayudar a los reguladores a evaluar su adopción. Las directivas recientes sobre IA incluyen cláusulas que obligan a aportar información de diversidad durante el desarrollo, lo que refleja el creciente interés de los reguladores públicos. Sin embargo, la documentación actual a menudo ignora la diversidad en favor de las características técnicas, en parte por falta de herramientas para describirla y anotarla.
Como posible solución, presentamos la Software Diversity Card, un enfoque estructurado para documentar y compartir aspectos relacionados con la diversidad dentro de proyectos software. Su objetivo es perfilar a los distintos equipos implicados en el desarrollo y la gobernanza del software, incluyendo los grupos de usuarios que participan en las pruebas y las adaptaciones del software para distintos grupos sociales.
Las siguientes secciones describen con más detalle nuestra propuesta de software diversity card y cómo puedes crear la tuya con las herramientas que proporcionamos. Puedes leer todos los detalles en nuestro artículo, publicado en la revista Information and Software Technology Journal.
Prácticas actuales de documentación en el desarrollo OSS
Estudiamos los 200 repositorios con más estrellas en GitHub para los 5 lenguajes de programación más populares. Solo encontramos información sobre el equipo de desarrollo y los contribuidores no relacionados con el código en menos de un tercio de los proyectos analizados. Especialmente baja son las referencias a las pruebas con los usuarios, con evidencias en solo un 3.5% en los proyectos.
Table 1. Presencia de documentación sobre diversidad en 1000 proyectos OSS.
| Área | C# | Java | JS | Python | TS | Avg |
|---|---|---|---|---|---|---|
| A1 – Referirse al equipo de desarrollo | 28.0% | 31.5% | 28.0% | 27.5% | 33.0% | 29.6% |
| …y mencionar aspectos del perfil | 22.0% | 20.5% | 22.0% | 21.5% | 26.0% | 22.4% |
| A2 – Describir a los contribuidores no relacionados con el código | 30.5% | 27.0% | 32.0% | 27.5% | 31.5% | 29.7% |
| …y explicar los roles no relacionados con el código | 24.0% | 20.5% | 26.0% | 18.5% | 24.4% | 22.7% |
| A3 – Pruebas con usuarios | 3.5% | 3.5% | 1.5% | 5.0% | 4.0% | 3.5% |
| …y mencionar mano de obra | 0.0% | 0.5% | 0.0% | 0.5% | 0.5% | 0.3% |
| …y reportar plataformas | 0.2% | 0.2% | 0.0% | 0.3% | 0.1% | 0.2% |
| A4 – Definir un caso de uso específico | 84.0% | 74.5% | 78.5% | 83.0% | 68.0% | 77.6% |
| Especificar población objetivo | 34.0% | 28.5% | 32.0% | 36.5% | 30.0% | 32.2% |
| Describir una adaptación específica | 15.0% | 13.5% | 17.0% | 21.5% | 15.5% | 16.5% |
| A5 – Definir participantes en la gobernanza | 28.5% | 31.5% | 27.0% | 27.0% | 30.0% | 28.8% |
| Indicar financiadores | 27.0% | 15.0% | 32.0% | 19.5% | 30.0% | 24.7% |
¿Qué cubre la Diversity Card?
Como solución, proponemos que todos los proyectos vengan con su “ficha” de diversidad incorporada. La ficha se organiza en tres partes principales:
1. Participantes
No solo el equipo de desarrollo. Incluimos:
- Perfiles del equipo de desarrollo (demografía, ubicaciones, experiencia)
- Contribuidores no relacionados con el código (traductores, personas que documentan, quienes reportan incidencias)
- Testers y reporteros públicos (incluyendo participantes de crowd-testing)
2. Contexto de uso
¿Para quién es el software y cómo se adapta a distintos usuarios?
- Comunidades “target” y sus necesidades específicas
- Adaptaciones del software (funcionalidades de accesibilidad, localizaciones de idioma)
- Contexto social y cultural del uso previsto
3. Gobernanza
¿Quién toma decisiones y quién financia el proyecto?
- Órganos de gobernanza y procesos de toma de decisiones
- Fuentes de financiación (pública, privada, comunitaria)
- Tipo de proyecto (open source, corporativo, investigación)
Un lenguaje para especificar formalmente las diversity cards
Para promover su adopción y asegurar un uso consistente, necesitamos proporcionar recursos estructurados e integrarlos con las herramientas existentes de gestión de procesos en iniciativas de desarrollo de software.
Por esta razón, hemos creado un lenguaje específico de dominio (DSL) diseñado para documentar la diversidad en el software. Los conceptos del DSL se formalizan mediante un metamodelo, pero también proponemos una notación textual, definida como una gramática, para crear descripciones textuales de las tarjetas que se puedan añadir fácilmente a los repositorios.
Ver un extracto de la gramática
Empieza a escribir tu tarjeta hoy
Nuestro enfoque se ha implementado como un conjunto de herramientas open source. La gramática está disponible como una extensión de Visual Studio Code implementada en Langium. La extensión de Visual Studio Code ofrece capacidades para exportar software diversity cards a formatos JSON y Markdown.
Pero, para que sea todavía más fácil crear diversity cards, también ofrecemos su creación vía un formulario, donde la ficha se crea simplemente rellenando un formulario web.
Una de las principales ventajas de esta herramienta basada en formularios es que guía al usuario sobre cada uno de los campos disponibles y el formato esperado. Por ejemplo, como vemos en la figura, en la parte de gobernanza el usuario puede crear tantas estructuras como necesite, asignar el tipo de estructura mediante un selector de opciones y definir, si es necesario, información demográfica básica para cada una. Otra ventaja de esta herramienta web, en comparación con el plugin del lenguaje presentado, es que no hay que instalar nada, ya que se puede acceder directamente desde el navegador, lo cual es ideal para usuarios que no programan.
Reflexiones finales
Hemos validado la tarjeta mediante dos estudios de caso reales, analizando documentación pública y realizando entrevistas con los equipos de desarrollo. Los resultados muestran tanto los beneficios como los retos de usar la ficha en la práctica. Entre los beneficios, la ficha permitió recopilar información valiosa que no estaba documentada públicamente, como resultados internos de pruebas de usabilidad, lo que podría aumentar la transparencia y el valor del proyecto. Los retos incluyeron cuestiones de anonimato y sensibilidad, que limitaron la recopilación de datos detallados sobre los participantes; la naturaleza dinámica de los equipos de desarrollo, que complica capturar su composición completa y su evolución; y barreras de adopción, especialmente el esfuerzo adicional requerido para proyectos pequeños y medianos.
Estos resultados ponen de relieve el potencial de la Software Diversity Card como herramienta para promover la concienciación y el reporte de diversidad, y al mismo tiempo señalan áreas en las que será necesario seguir refinando y ofreciendo soporte para garantizar su aplicabilidad práctica en proyectos software diversos.
Hola Jordi.
Puedo entender hasta cierto punto, las intenciones después de leer el artículo. Pero me parece un despropósito incluir etnia, religión y orientación sexual y lo que conlleva en torno a la protección de datos, para evaluar un proyecto de software. Y ya sabemos que el camino al infierno está plagado de buenas intenciones. Al final, ¿vamos a evaluar proyectos de software si tenemos “cuota positiva” o programadores LGTBI+Plus para el salón?. Creo que el presente artículo muestra una cara y la publicación real otra. Siguiendo con la tontería de que “hay pocas ingenieras o programadoras” o pocos negros, o “marronas” como dice una estúpida sectaria conocida. Si se promueve la igualdad de oportunidades en el acceso al desarrollo de software, no tenemos que valorar a los equipos de software por cubrir cuotas de género, sino por meritocracia, y los proyectos por si cumplen su cometido, y no métricas estúpidas que lo único que hacen es añadir ruido y justificar investigaciones vacuas ante universidades e instituciones, pero que en el día a día no sirven nada más que para gastar dinero y recursos.
Saludos
Hola Diego,
Empiezo por decir que estoy de acuerdo en que toda herramienta puede ser usada de un modo “perverso”. Pero en todo caso hay dos aspectos:
– Que una aplicación declare que ha sido testeada (o incluso co-desarrollada) por miembros de un perfil parecido a la comunidad de usuarios que lo tiene que usar me parece una información útil. Luego el “comprador” puede decidir si eso es un factor determinante o no pero para mí es útil poderlo decir.
– Que una administración pública pueda llegar a decir que solo contratará software hecho por equipos con una cierta representatitvidad puede gustar o no (no voy a entrar ahora en si este tipo de discriminación positiva tiene sentido o no) pero en ese caso una herramienta como la nuestra permitiría dar esa información.