Per Ploug, líder de tecnología de código abierto en Spotify, ha trabajado en código abierto durante muchos años y, después de observar su evolución, cree que las empresas ahora son mucho más conscientes de lo que realmente significa “código abierto”. “Creo que son más claros en cuanto a los costos y también sobre lo que significa adoptar el código abierto de formas más estratégicas”, dice.
El código abierto evita el llamado “bloqueo de proveedores”, en el que las organizaciones de usuarios finales están vinculadas a complejos contratos de software comercial. La tasa de cambio de decisión de su arquitectura de TI a menudo la dicta el proveedor de este software. Pero, si bien el código abierto no tiene el mismo nivel de bloqueo, la flexibilidad que ofrece puede ser un arma de doble filo para muchas empresas. “Creo que el código abierto te da acceso a tecnología que no tendrías la capacidad de desarrollar por ti mismo”, dice.
Esto significa que las organizaciones pueden dar un salto hacia un área de la tecnología en la que pueden carecer de conocimientos técnicos suficientes. Al hacerlo, el usuario del software de código abierto está vinculado a las innovaciones tecnológicas que implementan.
“Cuando tomas estas decisiones de inversión más grandes, creo que todos deben comprender si lo que están adoptando es algo que está cerca de ser un estándar común en un área determinada, o si básicamente están creando una dependencia en algo que está perdiendo participación de mercado y posiblemente también compartir la mente”.
Si elige esta última, la organización tendrá que alejarse de esta herramienta de código abierto en algún momento, lo que puede resultar muy costoso.
Él dice que si el código abierto no existiera, las grandes empresas de tecnología monopolizarían la tecnología para servir a nichos particulares de clientes. Es probable que dichas tecnologías sean muy costosas, lo que las haría solo adecuadas para las empresas más grandes. “Las empresas más pequeñas no podrían permitirse este tipo de cosas”, dice Ploug.
Por ejemplo, Spotify comenzó a usar código abierto desde el principio y esto le ha permitido crecer. “Cuando éramos pequeños, usábamos el código abierto como un salto rápido a los mercados, y creo que hemos desarrollado un enfoque estratégico para el código abierto por encima de todo lo demás”, dice.
Tomar decisiones estratégicas de código abierto
En Spotify, los desarrolladores pueden elegir entre una amplia variedad de bibliotecas según sus propias elecciones. Pero para inversiones estratégicas más grandes, Ploug dice que Spotify evaluará rigurosamente la tecnología de código abierto si se convierte en un estándar del que la empresa puede depender durante un período de tiempo más largo, para garantizar que no se vea obligado a cambiar prematuramente a una tecnología más nueva.
Un ejemplo, que dice, en retrospectiva, es bastante divertido, es: “El día antes del lanzamiento de Kubernetes, abrimos nuestra propia capa de orquestación de contenedores”.
Un proyecto más positivo para Spotify es Backstage, que Ploug dice que ha hecho de código abierto, como una forma de crear un estándar común. Backstage es un marco de código abierto para crear portales de desarrolladores, creado en Spotify, que donó al CNCF. Ahora ha sido adoptado por cientos de empresas.
“No queríamos simplemente esperar y ver y mantenerlo interno”, dice. “Queríamos impulsar la innovación en el espacio de los portales para desarrolladores”.
Al hacerlo, Spotify Backstage se ha convertido en el líder del mercado. La compañía continúa invirtiendo internamente pero, al donarlo a CNCF, Ploug dice que Spotify también asegura que “se quedará”, lo que brinda a los usuarios internos la confianza para seguir usándolo.
Sostenibilidad financiera
Ploug cree que la idea de tener confianza en que un producto de código abierto tiene una longevidad va al corazón del problema que enfrenta actualmente la comunidad de código abierto. “Tenemos un enorme problema de sostenibilidad financiera en código abierto”, dice. “Creo que una gran cantidad de mantenedores de código abierto están mal pagados o subestimados. También están estresados por las crecientes demandas de mantenimiento de código abierto que estamos viendo”.
Las organizaciones que utilizan código fuente abierto deben comprender las implicaciones. “No tiene un acuerdo de nivel de servicio con este proveedor”, dice Ploug. “No es un vendedor. No le está pagando a la persona que mantiene el código. No hay relación con el proveedor. [contract].”
La falta de un acuerdo de nivel de servicio tiene un impacto material en la efectividad de las iniciativas de toda la industria para mejorar la seguridad de código abierto.
“Creo que gran parte del problema proviene de la falta de mantenimiento”, dice. “Esto se debe a que los mantenedores simplemente no tienen tiempo o no se les paga por su trabajo y ejecutan estos proyectos en las noches y los fines de semana”.
Como resultado, Ploug no cree que el concepto de una cadena de suministro de seguridad de software pueda funcionar en código abierto. Como a los mantenedores no se les paga, no son proveedores. “No tienes una cadena de suministro”, dice.
Todavía no es una práctica común que las empresas apoyen financieramente los proyectos, ya Ploug le gustaría ver más organizaciones que usan código abierto ofreciendo apoyo financiero para proyectos de código abierto.
Ampliando el grupo de talentos
Dado que solo ciertas personas pueden dedicar su tiempo a mantener proyectos de código abierto, le preocupa que esto limite a la comunidad a un grupo demográfico muy particular.
“Es un tipo de persona muy específico que siente pasión por pasar las tardes y los fines de semana trabajando en código abierto”, dice Ploug. “Ese es alguien que no tiene tareas domésticas, ni hijos que mantener, ni vida familiar, ni parientes enfermos”.
Él dice que el código abierto debe convertirse en un campo de juego más nivelado que pueda atraer a una comunidad diversa de colaboradores y mantenedores. Esto también está relacionado con el problema financiero y las ambiciones de la industria y los responsables políticos de implementar cadenas de suministro de seguridad de software.
Si se paga a los mantenedores y colaboradores de código abierto y se patrocinan los proyectos, es más probable que las personas vean su papel en la comunidad de código abierto como una vocación. Y el contrato que tienen con los usuarios del código que desarrollan y mantienen es financieramente vinculante, lo que otorga a esos usuarios un acuerdo de nivel de servicio y responsabilidad.