Nunca hemos podido crear software a tanta velocidad como ahora. Las plataformas low-code y las herramientas de desarrollo con IA (agéntica) siguen acortando la distancia entre tener una idea y lanzar la aplicación que la implementa. Se recupera, una vez más, la promesa de que cualquiera podrá crear todo el software que necesite (con todas las salvedades que quieras, por supuesto)
Pero ¿de qué sirve todo este software si no mejora la vida de las personas y hace del mundo un lugar mejor?
Acelerar el desarrollo no significa que crear software salga gratis (por ejemplo, en términos de consumo energético). Y mucho menos mantenerlo. Ni que usarlo sea inocuo. Podemos generar más software, pero ese software puede seguir generando más exclusión, más consumo de recursos y más herramientas que resuelven problemas que nadie tenía realmente o que ya estaban razonablemente resueltos.
Este es el punto de partida de mi nuevo artículo de posicionamiento: Social³Source: Connecting Social Provenance, Societal Qualities, and Social Purpose on an Open-Source Software Foundation. Este es el resumen (en inglés):
The speed at which software can be created and deployed today has increased dramatically. But what is the point of all this software if it does not contribute to society? The ultimate goal of building software should be bettering human lives and society. And this goes beyond publishing the software as open source; it requires considering how it is developed, the societal qualities it embodies, and the purposes it serves. This is what I call Social3 Source. This paper presents the concept, principles, and initial discussion for the implementation of Social3 Source, illustrating how it integrates social considerations into open-source software development. We have never generated as much software as we do today. Let’s make sure it counts.
Entonces, ¿cómo nos aseguramos de que esta cantidad creciente de software aporte valor a la sociedad? Propongo partir de una base de código abierto. Pero ser de código abierto no basta; también necesitamos que el código sea social. Social por cómo se construye el software, por las cualidades que incorpora y por los objetivos a los que sirve. Déjame explicarlo.
El código abierto es la base
El open source nos da libertades esenciales: podemos inspeccionar, usar, modificar y redistribuir el software. Las comunidades pueden adaptarlo a sus circunstancias y seguir desarrollándolo aunque sus creadores originales “desaparezcan”.
Estas libertades importan. Son la base de Social³ Source.
Pero una licencia de código abierto no nos dice si las personas a las que impacta una aplicación han tenido voz en su desarrollo. Ni si realmente pueden usarla como se espera. Y tampoco nos dice si usarla les ayuda.
Por eso propongo fijarnos en tres dimensiones complementarias. El tres en el superíndice de Social³Source está ahí por algo (más allá de hacer que el nombre sea un poco más difícil de escribir 😉 y complicarme la vida con la indexación del trabajo en los repositorios científicos).
1. Procedencia social: ¿cómo y quién construye el software?
El desarrollo de software implica a muchas más personas que las que escriben código. Quienes traducen, escriben documentación, aportan conocimiento del dominio, notifican problemas o prueban las primeras versiones contribuyen al resultado.
Reconocer estas contribuciones es un primer paso. Pero también deberíamos preguntarnos qué perspectivas representan y si abarcan todos los puntos de vista y dimensiones que pretende cubrir el software y sus usuarios “target”. Y no se trata solo de formar parte del «equipo». Estas personas deben poder influir en el proyecto. Y para eso necesitan participar activamente en la gobernanza del proyecto. De poco sirve tener una comunidad diversa alrededor de tu proyecto si todas las decisiones importantes siguen en manos del mismo grupo reducido de líderes (o dictadores ;-))
Para formalizar esta dimensión, parto de nuestro trabajo previo sobre la Software Diversity Card para considerar conjuntamente a los participantes, el contexto de uso y la gobernanza. Cada proyecto de software debería especificar claramente aspectos como: ¿quién contribuye? ¿Qué perspectiva aporta en términos de diversidad? ¿A qué comunidades sirve el software? ¿Quién decide qué se implementa y cómo se resuelven los desacuerdos?
Una simple lista de colaboradores no puede responder a todas estas preguntas. Y una lista de commiters, menos aún.
2. Cualidades sociales: ¿Qué propiedades incorpora el software?
Cualquier software con vocación social debería ir más allá de ofrecer la funcionalidad esperada. Debería hacerlo de forma que también respete y promueva un buen número de cualidades sociales deseables.
La accesibilidad, el multilingüismo, la privacidad, la ausencia de sesgos y la sostenibilidad ambiental son candidatos evidentes. Pero no forman una lista cerrada, y sus prioridades (y los compromisos entre objetivos que hay que considerar al decidir implementarlas) dependen de las personas y circunstancias implicadas o a las que se dirige el software.
Necesitaremos una taxonomía de este tipo de propiedades (y para ello tendremos que unir fuerzas con expertos en ciencias sociales, como parte de un esfuerzo interdisciplinar). Y un catálogo de posibles arquitecturas, técnicas, paquetes software y estándares que permitan garantizarlas.
Además, ofrecer una propiedad no basta. Tenemos que asegurarnos de que los usuarios a los que les resulta útil puedan aprovecharla de verdad. Por ejemplo, dar soporte a varios idiomas parece una mejora. Pero imagina que el soporte para el inglés funcione en local, mientras que todos los demás idiomas requieran un servicio externo de traducción con IA. Para alguien sin una conexión fiable, la aplicación es multilingüe solo en papel (en “papel mojado” para ser más exactos!). Implementar una funcionalidad y conseguir que las personas se beneficien de ella son dos logros distintos. Deberíamos evaluar ambos.
3. Propósito social: ¿Por qué existe el software y a quién ayuda?
Casi cualquier aplicación podría, en principio, ayudar a una organización que hace un trabajo útil. Una ONG puede usar una hoja de cálculo o un programa de contabilidad. Esto tiene valor, pero una definición tan amplia permitiría que prácticamente cualquier aplicación afirmase tener un propósito social.
Me interesa una conexión más explícita con la misión: software creado o adaptado para ayudar a comunidades y organizaciones a llevar a cabo sus actividades sociales específicas. Por ejemplo, coordinar la distribución de alimentos, poner en contacto a voluntarios con personas que solicitan ayuda o facilitar el acceso a centros de acogida y servicios públicos.
Por supuesto, esto va más allá de las ONG. Los servicios públicos, las cooperativas y los grupos comunitarios también pueden beneficiarse de software adaptado a sus necesidades. La pregunta es a quién esperamos mejorarle la situación, qué actividad apoya el software y qué barrera ayuda a eliminar.
Las tres dimensiones se necesitan mutuamente
Pensemos en una aplicación de código abierto que ayude a las personas migrantes a encontrar servicios locales y orientarse en los trámites administrativos. Su propósito parece útil. Pero, por sí solos, los desarrolladores pueden pasar por alto algunos de los problemas que encuentran estas personas, porque no han vivido esa experiencia en sus propias carnes. Involucrar a personas migrantes, trabajadores sociales y traductores podría cambiar los requisitos. Su participación podría revelar que la aplicación necesita interacciones más sencillas, más idiomas o soporte para dispositivos modestos y conexiones limitadas.
Esos requisitos influirían después en las decisiones de implementación. Un servicio de traducción con IA podría ampliar el número de idiomas disponibles, pero también introducir errores, consumo de recursos y dependencia de la conexión. Para cierta información sensible, podría ser preferible mantener las traducciones localmente, aunque al principio se puedan ofrecer menos idiomas.
Por último, la evaluación debería comprobar si las personas pueden encontrar servicios y completar las tareas pertinentes con más facilidad. Haber desplegado la aplicación no demuestra que las hayamos ayudado. Si el público al que se dirige (las personas migrantes en este caso) no acaba usando la aplicación, todavía no es un ejemplo de Social³ Source.
Por eso quiero conectar la procedencia, las cualidades y el propósito. Cada dimensión puede orientar las decisiones que se toman en las otras.
¿Cómo lo ponemos en práctica?
La pregunta inmediata es cómo convertir estas ideas en algo que los equipos puedan usar de verdad al desarrollar software. En el artículo propongo un enfoque basado en modelos. Ya usamos modelos para describir los datos, el comportamiento y las interfaces de una aplicación. También podríamos usarlos para describir las comunidades que la rodean, las cualidades sociales que debería promover y los objetivos a los que debe servir.
El objetivo es hacer explícitos estos compromisos y conectarlos con el diseño, la implementación y la evaluación. Para apoyar este enfoque, podríamos ampliar las plataformas existentes de modelado y desarrollo low-code, como BESSER. Los lenguajes existentes para describir perfiles de usuario, objetivos y gobernanza ofrecen puntos de partida. El artículo muestra un modelo de perfil de usuario de BESSER como ejemplo de cómo describir competencias lingüísticas y necesidades de accesibilidad. Junto con los lenguajes de modelado, también necesitamos proporcionar generadores que transformen automáticamente esos modelos en los artefactos correspondientes. Por ejemplo, los generadores de código podrían incorporar buenas prácticas para generar automáticamente una versión accesible de una interfaz de usuario cuando éste sea uno de los requisitos sociales no funcionales del software, aunque quien la diseñe no se haya tomado el tiempo de hacerlo al modelar la interfaz.
Reutilizarlos (tanto los lenguajes como los generadores) en distintos proyectos podría reducir el esfuerzo necesario para implementar cualidades sociales, siempre que sus supuestos y limitaciones estén claros.
Y el propio proceso de desarrollo también debe ser accesible. Invitar a la gente a participar sirve de poco si no puede entender o modificar las especificaciones. Los editores gráficos, los formularios y las interfaces conversacionales podrían ofrecer distintas formas de contribuir. Aún tenemos que evaluar si estas interfaces permiten a las personas influir de forma efectiva en el software que se construye.
No sale gratis. Aun así, merece la pena. ¿Te apuntas?
Nada de esto sale gratis. Participar lleva tiempo. Las cualidades sociales suelen aumentar el coste de desarrollar y desplegar el software (porque requieren trabajo adicional de desarrollo y pruebas). Las cualidades pueden entrar en conflicto, y las comunidades pueden discrepar sobre sus prioridades. Tenemos que hacer explícitos estos compromisos entre objetivos en lugar de dar por hecho que todas las propiedades deseables pueden maximizarse a la vez.
El artículo presenta una postura inicial y una hoja de ruta de investigación. Necesitamos mejores fundamentos interdisciplinares, métricas adecuadas, lenguajes de modelado social, generadores reutilizables y métodos para negociar prioridades. Y, sobre todo, necesitamos validación con las comunidades a las que pretende servir el software.
Una posible nota social (“social score”) es una de las líneas de investigación. Pero decidir cómo calcular una nota que tenga sentido, qué evidencias debería exigir y qué comparaciones serían justas sigue siendo un problema abierto. Añadir otro badge a un repositorio sería fácil. Conseguir que resulte útil sería más difícil.
Los esfuerzos que abordan una o dos de las dimensiones ya merecen reconocimiento. Social³ Source es una propuesta para conectarlas y tenerlas en cuenta durante todo el ciclo de vida del software, en lugar de esperar a que la aplicación esté terminada.
Me interesan mucho tus comentarios y opiniones. Y estoy abierto a cualquier tipo de debate o iniciativa que permita avanzar en esta dirección. Sé que a muchos os interesa esto, y algunos ya habéis expresado ideas similares en el pasado. ¡Hagámoslo realidad!
