por Italo Vignoli
La meritocracia es uno de los principios fundacionales del movimiento del software libre y de código abierto. También es uno de los términos más controvertidos, y la brecha entre los diferentes significados que la gente le atribuye es, en algunos proyectos, fuente de conflictos reales y perjudiciales.
Analicemos el significado de la palabra, ya que su posible ambigüedad puede influir significativamente en el debate y en los distintos puntos de vista.
La teoría de la legitimidad basada en el gráfico de commits
Una versión de la meritocracia sostiene que la autoridad de gobernanza debe seguir a la contribución, y que la mejor forma de medir la contribución es a través del código. Según este punto de vista, las personas que más han contribuido al código tienen derecho a decidir el futuro del proyecto, porque conocen el código fuente y tienen un interés personal en el sentido más literal del término.
Esta no es una postura irrazonable para un proyecto en sus primeras etapas. Aunque también es necesario considerar la infraestructura, recaudar fondos y gestionar las relaciones con los medios de comunicación y las instituciones, cuando el principal desafío es de naturaleza técnica, cuando la comunidad es pequeña y cuando hay poco en juego, tiene sentido que quienes realizan la mayor parte del trabajo también tomen la mayoría de las decisiones.
El problema surge cuando ese principio se traslada sin modificaciones a un contexto muy diferente. Un proyecto de software libre que lleva quince o veinte años en marcha, es utilizado por millones de personas, opera en un entorno normativo y legal complejo, cuenta con usuarios empresariales y tiene implicaciones políticas, ya no es lo mismo. Aplicar el mismo modelo de gobernanza de los primeros tiempos a la realidad de un proyecto de gran envergadura no produce buenos resultados, sino más bien una organización técnicamente sofisticada pero estratégicamente ciega.
Lo que no mide el gráfico de commits
La teoría de la meritocracia basada en el número de commits tiene un punto ciego: solo mide un tipo de contribución y hace que las demás sean casi invisibles.
Pensemos en lo que no aparece en el gráfico.
Los autores de la documentación, que hicieron que el software fuera accesible para usuarios que, de otro modo, habrían renunciado a utilizarlo.
El equipo de localización, que involucró a comunidades lingüísticas enteras en el proyecto.
Los revisores, que transformaron informes de errores incompletos en informes listos para su resolución.
Los moderadores de la comunidad que mantuvieron el proyecto abierto a los recién llegados a costa de un esfuerzo personal considerable.
Las personas que pasaron años forjando relaciones con los medios de comunicación, las instituciones y la esfera política, creando las condiciones para la adopción generalizada del software.
Estas contribuciones no generan commits, pero sí generan usuarios, adopción, sostenibilidad y relevancia. En un proyecto maduro, a menudo marcan la diferencia entre un software que existe y un software que importa.
Un modelo de gobernanza que excluye a estos colaboradores del proceso de toma de decisiones, o que busca marginarlos, es una meritocracia parcial, ya que solo reconoce un tipo de excelencia e ignora todos los demás.
El problema de los conflictos de intereses
Hay una segunda dimensión en este argumento que merece ser analizada.
Cuando la gobernanza de un proyecto incluye también a personas empleadas por empresas con intereses comerciales directos en la dirección del proyecto, la cuestión de la meritocracia se vuelve más compleja. La pregunta no es si esos colaboradores son capaces —porque sin duda lo son—, sino si las estructuras de gobernanza construidas en torno a sus contribuciones pueden generar de manera fiable decisiones que sirvan a la misión del proyecto en lugar de a los intereses de sus empleadores.
Esto no es una acusación, sino una simple observación. Los conflictos de intereses no están vinculados a la mala fe, sino que son inherentes a la situación. Un modelo de gobernanza que no tenga esto en cuenta deja de ser meritocrático y, además, es menos consciente de sus propias limitaciones.
Una gobernanza sana en un proyecto FOSS maduro requiere una diversidad de perspectivas: personas que aportan código, pero también personas que representan a la comunidad de usuarios, la misión institucional y la sostenibilidad a largo plazo del proyecto como un bien público más que como un activo comercial. No se trata de excluir a los desarrolladores, sino de garantizar que ningún interés individual —por muy legítimo que sea— sea el único factor que determine las decisiones.
Construir para quienes vienen después de nosotros
Todos los grandes proyectos de software libre son intergeneracionales, ya que las personas que los crearon no serán las mismas que los mantendrán dentro de diez o veinte años; por lo tanto, las decisiones que se tomen hoy en día sobre la arquitectura, la gobernanza y qué contribuciones se valoran y cuáles no, determinarán lo que heredará la próxima generación. Y debe ser algo sobre lo que se pueda construir, no algo que se deba eludir.
Esto redefine por completo la cuestión de la meritocracia. Desde esta perspectiva, de hecho, la medida de una contribución no viene determinada únicamente por su valor actual, sino también por su valor para el futuro del proyecto.
La meritocracia en un gran proyecto de código abierto no reside en la acumulación de commits como base para reclamar autoridad, sino en crear las mejores condiciones para que el proyecto siga creciendo en el futuro. La cuestión no es quién ha hecho más, sino quién está construyendo algo que la próxima generación pueda realmente usar y seguir desarrollando.
Nuestro concepto de meritocracia
El principio original en el que se basa la meritocracia del software libre sigue siendo válido: las decisiones deben tomarlas quienes realizan el trabajo, quienes comprenden las consecuencias y quienes se han ganado su lugar mediante una contribución genuina, en lugar de por políticas organizativas. Este principio debe preservarse.
Sin embargo, las contribuciones pueden adoptar muchas formas, y el mérito tiene una dimensión temporal que el gráfico de commits no logra captar. El mérito de desarrollar el código fuente es real y merece reconocimiento, pero esto también se aplica al mérito de construir una comunidad, mantener la documentación, garantizar la accesibilidad, lidiar con las complejidades legales y asegurar las relaciones institucionales que mantienen vivo el proyecto para las personas que lo heredarán.
Una verdadera meritocracia encuentra la manera de reconocer y valorar todo esto. Un proyecto que confunde la meritocracia con el dominio de un solo tipo de colaborador, por muy experto que sea, no está a la altura de sus propios valores. Y un proyecto que se pliega a los intereses de un subconjunto de colaboradores, a expensas de las generaciones futuras, no es una meritocracia, sino una forma de apropiación enmascarada por el lenguaje de la equidad.
La meritocracia es un concepto complejo y multifacético con el que vale la pena lidiar para construir algo que las generaciones futuras estarán felices de heredar.
