| 9 min de lectura
La frase que constituye el subtítulo de este post fue alguna vez planteada por el desarrollador de software Harlan Stenn, presidente de la Network Time Foundation. Con ella, Harlan nos daba a conocer la postura habitual, generalmente tácita, de la gente frente a la penosa situación de la infraestructura digital pública y muchos de sus componentes de software de código abierto, de los que dependemos todos de una u otra forma.
Hace unos días, en el post sobre el chiste del sujeto en Nebraska, señalamos la enorme dependencia que los gigantes empresariales, así como las pequeñas y medianas empresas, los gobiernos nacionales y, en general, los usuarios de la Internet tienen de aquellos componentes o proyectos que en muchas ocasiones son mantenidos por unos pocos sujetos, con escasa o nula remuneración. Como comentábamos allí, teníamos intención de escribir un post sobre este problema de la poca financiación —el cual hace parte de un problema más amplio: el poco soporte— y aquí lo tienes. Este texto se basa principalmente en el reporte Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure (2016), escrito por Nadia Eghbal, y surge porque trata un problema al que aún hoy no se le ha prestado suficiente atención.
Introducción
Sabemos que la comunidad de software de código abierto normalmente trabaja desde un esquema descentralizado, sin jerarquías —lo irónico es que la actual economía capitalista digital se forje y mantenga sobre muchos de sus proyectos libres. Así, ninguna organización o autoridad central concede permisos o determina lo que se va a construir, mantener y utilizar en la infraestructura. (Casos atípicos son, por ejemplo, los de IETF y W3C que establecen ciertos estándares y requisitos en las piezas más fundamentales o niveles más básicos de la web.)
Desde esta comunidad, individuos y grupos crean lenguajes de programación, frameworks y librerías, algunos más complejos que otros, y los ponen a disposición de quien quiera o necesite usarlos. Normalmente, se espera que un nuevo proyecto mejore uno existente —trayendo nuevas características o resolviendo alguno de sus problemas— para que se considere útil o incluso "la mejor opción disponible" y valga la pena su adopción. Algunos proyectos resultan ser más preferidos que otros, y algunos simplemente terminan siendo ignorados.
Los proyectos exitosos van siendo cada vez más conocidos, implementados y empleados por equipos de desarrolladores y compañías tecnológicas. Aparte de su buena funcionalidad, estos componentes se difunden gracias a factores como la reputación de los desarrolladores, el atractivo de los nombres de los productos y las campañas publicitarias realizadas. Si bien algunos proyectos de código abierto se originan dentro de una compañía y/o como parte de un negocio, aquí nos centramos más que todo en aquellos que parten de individuos o comunidades independientes.
Los consumidores, por su parte, toman provecho de estos bienes públicos para resolver sus problemas específicos. Las empresas, por ejemplo, recurren a componentes de software de código abierto para construir y soportar sus propios productos y servicios y con estos ganar dinero. A medida que más y más gente demanda componentes de software, a menudo mantenidos por unos pocos desarrolladores, empiezan a aparecer desequilibrios. Los consumidores envían constantemente solicitudes desmesuradas y escandalosas a estas personas sin ofrecerles retribución alguna.
¿Por qué generan software de código abierto?
Usualmente, son sujetos voluntarios los que trabajan en el desarrollo y mantenimiento de proyectos de código abierto. Lo hacen como un hobby, un arte que aman y les satisface, y como una forma de resolver sus problemas. Estos propósitos pueden estar relacionados con el deseo de influir positivamente en la vida de los demás, pero, en general, no hablamos de "altruismo". Muchos desarrolladores y mantenedores de proyectos de código abierto necesitan pensar en su futura prosperidad económica, incluso cuando el dinero puede seguir siendo un tema tabú en la comunidad del código abierto.
El dinero puede seguir viéndose por muchos como una perversión de la idea original de la comunidad de código abierto, pero seamos realistas: Dichosos aquellos pocos que trabajan a tiempo completo como voluntarios en estos proyectos y no tienen necesidad de recibir un centavo. Lo cierto es que una de las intenciones más comunes de los desarrolladores contribuyentes es ganarse una reputación. Suelen tener la intención de ser reconocidos en las comunidades, demostrar su valía y construir su portafolio de trabajo (a veces con varias pequeñas contribuciones), para luego tener la oportunidad de lograr compensaciones para sostener sus proyectos o meramente ser contratados en grandes empresas donde sean bien remunerados.
Cuando los desarrolladores se encuentran, por una u otra razón, atados a estos proyectos, van sintiendo la carga pesada, que a veces, cuando un proyecto ha sido popular, es como si se transformara en una "obligación ética" para con el mundo. Dicha carga refleja injusticia, sobre todo en la desigualdad de la retribución económica. Los desarrolladores que mantienen proyectos de código abierto, a menudo a tiempo completo, de los que dependen compañías, entidades gubernamentales, y demás, ganan nada o muy poco en comparación con quienes forman parte de estas organizaciones.
Problemas para los desarrolladores y mantenedores
Como comenta Nadia, cada vez rondan por la web más y más posts y conversaciones públicas sobre el cansancio y el estrés que sufren estos voluntarios. Muchas veces, solo una o dos personas se encargan de la supervivencia de un proyecto. El apoyo de otras personas suele ser casual o infrecuente. En base a lo anteriormente mencionado, algunos colaboradores llegan, echan una mano durante un tiempo, son reconocidos y luego, afortunadamente, son contratados por una empresa, por lo que retiran su apoyo al proyecto sin pensárselo dos veces.
A veces, los proyectos de código abierto que son antiguos tienen problemas incluso para encontrar contribuyentes dentro de la comunidad. La mayoría de los desarrolladores prefieren ponerse a trabajar en proyectos nuevos y populares que les llaman la atención y que puedan servirles más a su propósito de ganar reputación, y no en aquellos que son sólidos, fundamentales, "suficientemente consolidados" y han funcionado bien hasta el momento para los usuarios o consumidores.
Es cierto que algunos desarrolladores y mantenedores de proyectos de código abierto logran ingresos por consultoría y apoyo a los consumidores en el uso de su software, sobre todo cuando los proyectos son ampliamente usados y la gente está dispuesta a pagar por ellos. Sin embargo, los ingresos resultantes no suelen ser suficientes para cubrir salarios decentes y, al mismo tiempo, inversiones en seguridad y servidores, por ejemplo. Además, cuando hay pocas personas implicadas, la prestación de un servicio puede representar un obstáculo para el progreso del proyecto, ya que es necesario invertir mucho tiempo en actividades distintas al desarrollo y mantenimiento del software.
Lo que comienza como un entretenido proyecto de desarrollo de software puede convertirse en un calvario para los desarrolladores cuando tienen que reparar bugs o vulnerabilidades que les han sido reportados (algunos derivados de contribuciones de baja calidad), realizar controles de calidad de las contribuciones y hacer frente a críticas o comentarios de reclamación. A veces, las críticas proceden de los mismos colaboradores o de individuos que se limitan a señalar los defectos de los proyectos pero no aportan nada. Y las reclamaciones de nuevas funcionalidades o consultoría proceden de los usuarios de ese software libre, a veces incluso de empresas de gran calibre, bien establecidas y con enormes ingresos, que descaradamente tienen ciertas expectativas puestas en esos proyectos de los cuales dependen.
Es aquí donde se hace necesario el apoyo institucional. Como en el caso de OpenSSL, algunas personas simpatizantes crean fundaciones y nuevos roles no orientados tanto hacia lo técnico sino hacia la gestión, diseño, mercadeo, comunicación y sostenibilidad de estos proyectos. Algunas organizaciones proporcionan esta asistencia, pero no se meten con el soporte financiero. Otras instituciones, como la Fundación Linux y la Fundación Mozilla, han obtenido apoyo para proyectos específicos desde diversas empresas y organizaciones. Las compañías de software, por ejemplo, a veces contribuyen reportando problemas de seguridad, sugiriendo cambios y aportando retroalimentación. No obstante, la fuerza y la cobertura de este apoyo siguen siendo bastante limitadas.
Problemas para todos nosotros
Cansados, agotados de gestionar estos proyectos (quizá ya con otras prioridades en mente) y de no obtener retribuciones más que el placer de programar, estos desarrolladores pueden en cualquier momento abandonar sus proyectos, a veces con la esperanza de que alguien más lo mantenga en marcha. Esto puede representar una pérdida de mano de obra cualificada y una ralentización del crecimiento de la innovación. De no resultar voluntarios para la manutención, cada consumidor tendría que buscar componentes de software de código abierto similares o tomar los proyectos y conservarlos de forma independiente, entre otras posibles soluciones.
Por otro lado, ya sea por la carga que recae sobre los desarrolladores o por la intervención de desarrolladores aficionados —sin una formación adecuada en ciberseguridad o sin prestarle mucha atención a ella— la infraestructura queda vulnerable, más propensa a sufrir abusos y ataques que supondrían incidentes como las interrupciones de servicios. Que un proyecto sea abandonado o sufra violaciones de su seguridad, seguramente ha de regalarle algo de fama y, como consecuencia, tal vez por un tiempo, algo más de apoyo. Pero ¿qué hay de aquellos proyectos similares que siguen siendo impopulares y carecen de apoyo, pero aún así son pilares de nuestra infraestructura?
Falta de conciencia y apoyo
A menudo, los desarrolladores o mantenedores no tienen ni idea de quiénes están utilizando su software, y muchos consumidores no tienen una visibilidad clara de los componentes de software que emplean o no saben de quiénes dependen esas librerías ni cuál es su estado o situación. Adicionalmente, suelen haber ideas erróneas como la de que esta labor de los desarrolladores de software de código abierto está bien financiada y cuenta con equipos amplios y constantemente activos. De hecho, los que suelen ser casos excepcionales de financiación suficiente pueden ser vistos como si fueran la norma.
Ciertamente, existe patrocinio de empresas de software y grupos de desarrollo y donaciones de fundaciones, instituciones académicas y corporaciones, pero estas no son suficientes. Han surgido plataformas para hacer donaciones a los mantenedores para apoyar su trabajo, pero, como se menciona en el informe de Nadia, acaba siendo, en sentido figurado, dinero para un par de cervezas pero no para pagar la renta. Confiar en la buena voluntad de la gente en donaciones no recurrentes no es nada prometedor.
Asimismo, no es fácil encontrar cooperación entre empresas que compiten en un mercado. Una compañía puede no querer patrocinar un proyecto que también beneficia a sus competidores cuando estos no contribuyen en absoluto. También hay problemas cuando un benefactor privado desea privilegios especiales (sobre todo si se demuestra que es el único o principal contribuyente financiero) o cuando hay apoyo desde un gobierno con intereses políticos, lo que pone en peligro la neutralidad del proyecto. La intención de preservar dicha neutralidad, al tiempo que la descentralización, puede entonces limitar muchos apoyos financieros potenciales.
Es necesario más apoyo
El mantenimiento de algunos proyectos es mucho más dispendioso que el de otros. Cuando son muy pequeños, el mantenimiento requerido no es significativamente alto. En otros casos (usualmente proyectos de gran tamaño), compañías grandes que dependen de ciertos paquetes, asignan personal propio para estar pendiente de contribuir en su mantenimiento, liberando carga a esos individuos originalmente responsables (incluso llega apoyo monetario), o también contratan a algunos de los contribuyentes para trabajar en el proyecto a tiempo completo. La mayor preocupación se centra en los proyectos lo suficientemente grandes como para requerir un mantenimiento significativo, pero no lo suficientemente grandes como para recibir la atención y el apoyo de las corporaciones.
Actualmente necesitamos un trabajo más colaborativo para mantener nuestra infraestructura digital. Deberíamos ver ese apoyo como una responsabilidad compartida. Pero para ello, primero necesitamos una comprensión más amplia y precisa de la situación. A partir de ahí, podríamos esperar la aparición de más defensores, sin limitaciones políticas o comerciales, de este enfoque que no deberíamos permitirnos perder. La innovación y el progreso global que nos ha aportado este enfoque no tiene parangón, por lo que no sería conveniente terminar en una "sociedad de software de código cerrado".
Parte de la solución podría consistir en intentar hacer un reconocimiento completo, desde cada empresa u organización, de todas aquellas librerías, frameworks y otros componentes de software de código abierto que estamos utilizando y de los que dependemos. A partir de ahí, podríamos tratar de catalogar esos proyectos y averiguar cuáles de ellos realmente necesitan apoyo. En función de lo que definamos y de nuestras capacidades, podríamos empezar a proporcionar distintos tipos de recursos. Incluso podríamos involucrarnos en fundaciones orientadas a apoyar esos proyectos y cooperar con nuestros socios que también necesiten de ellos.
Al tiempo que escribo estas palabras, me van sonando tan idealistas, tan utópicas. Bien decía Nadia que este problema no es fácil de resolver. Pero recolectar y compartir datos y métricas sobre el estado actual de muchos proyectos esenciales y el impacto que tienen en nuestra economía puede impulsar a muchos de nosotros que estamos dispuestos ayudar. Sin embargo, no todo el mundo quiere contribuir, y, tal vez, estropearía aún más las cosas buscar forzarles a que lo hagan.
Tal como hemos podido evidenciar directamente, o al menos ver en experimentos de psicología social, hay casos en los que puede haber mucha gente alrededor de una persona que sufre y necesita ayuda, y todos nos quedamos sin hacer nada, normalmente esperando que alguien más dé el primer paso. En este caso, sabemos que ya algunos hemos intervenido de una u otra forma. Aún así, necesitamos que el problema y nuestra contribución a su solución sean visibles para todos y así podamos ayudar a evitar tragedias en nuestra infraestructura digital.
Blog posts recomendados
Quizá te interesen los siguientes posts similares.
¿Por qué calcular riesgos de ciberseguridad con nuestra métrica CVSSF?
Los siete ciberataques más exitosos contra esta industria
