Resoluciones para el código abierto en 2024: ¿qué tiene que cambiar?

En los últimos años, el código abierto se ha polarizado cada vez más. Por un lado, están aquellos comprometidos con la definición de código abierto de la Open Source Initiative (OSI). Por otro lado, ha habido varios proveedores comerciales de código abierto que han pasado a licencias que no están aprobadas por OSI.

¿Qué significa esto para el código abierto en 2024? ¿Cómo puede la comunidad de código abierto proteger su posición y garantizar que el software de código abierto siga siendo la primera opción para nuevos proyectos de software?

Resolución #1: Ha habido una pérdida de confianza en el código abierto. Tenemos que arreglar que las empresas publiquen su software bajo una licencia de código abierto para obtener masa crítica, hacer crecer sus comunidades y desarrollar una base de clientes potenciales de manera más eficiente. Sin embargo, luego ven que los competidores utilizan ese mismo software para crear sus propios productos o servicios que compiten con ellos. Muchos grandes nombres del código abierto han pasado a una licencia de código no abierto para proteger su percepción de participación de mercado y evitar la competencia. Sin embargo, también dañaron la reputación del código abierto en general. Estos proveedores quieren los beneficios que ofrece el código abierto en cuanto a comunidad, alcance de mercado y acceso de desarrolladores, pero no quieren ceder su control y quieren excluir a sus competidores.

Para aquellos de nosotros que creemos en el código abierto, esto es doloroso. El software de código abierto es valioso por el enfoque comunitario que respalda y porque mantiene el control en manos de los desarrolladores que eligen el software. Sin confianza en el código abierto como base para el desarrollo comunitario y el acceso al software, todos salen perdiendo.

La respuesta es que necesitamos más enfoques de código abierto que reflejen las necesidades de la comunidad, no de una sola empresa. Tenemos que alejarnos del modelo de financiación de capital de riesgo que exige crecimiento a toda costa seguido de una oferta pública inicial o una adquisición. Las fundaciones de código abierto representan las necesidades de la comunidad y de todos los miembros involucrados. Pueden actuar como administradores de proyectos una vez que hayan alcanzado esa masa crítica y representar a la comunidad de manera más efectiva.

Las empresas individuales también pueden mejorar la forma en que gestionan y contribuyen a la comunidad de código abierto junto con sus propias necesidades comerciales. Empresas como Confluent y DataStax son ejemplos exitosos de cómo separar el proyecto de código abierto, gestionado por y para la comunidad, y los productos dirigidos a los clientes. En 2024, más empresas de código abierto tendrán que seguir su ejemplo y construir juntos modelos de negocio y apoyo comunitario, en lugar de tratarlos como objetivos separados.

Resolución #2: Tenemos que hablar sobre nuestro enfoque para definir el código abierto. En los últimos años, ha habido muchos llamados para evolucionar la definición de código abierto (OSD), que se elaboró antes de la llegada de la computación en la nube y "como Proveedores de servicio.

Las empresas que utilizan licencias como la Licencia pública del lado del servidor (SSPL) o la Licencia elástica argumentan que están protegiendo sus proyectos y manteniéndolos viables, en lugar de permitir que sean explotados por competidores que no pagan a la comunidad. Otros argumentan que el código abierto permite a los creadores de malware y otros actores maliciosos beneficiarse del software desarrollado por la comunidad, por lo que deberíamos restringir quién podría utilizar esos proyectos. Estos argumentos tienen algunos puntos positivos, pero van en contra del espíritu principal del código abierto de que todos deberían poder utilizar el software para proyectos como mejor les parezca.

Sin embargo, el código abierto no puede quedarse quieto indefinidamente. Lo que comenzó hace décadas a partir del trabajo de un pequeño pero unido grupo de entusiastas del software libre y de código abierto ha crecido y evolucionado hasta convertirse en múltiples grupos con diferentes necesidades y diferentes visiones. Los defensores de las licencias de código fuente disponibles con restricciones éticas o de no competencia no se ven a sí mismos en el mismo grupo que el software propietario, donde no se tiene acceso al código fuente y también se le puede impedir hacer otras cosas.

El OSD proporciona claridad sobre lo que se puede considerar de código abierto y lo que no. Sin embargo, es fácil ver esto como dos bandos enfrentados, cuando la verdad es que hay muchas más opciones disponibles. Existe una gran diferencia en lo que realmente se puede hacer con el software con licencia BSD en comparación con AGPL 3.0. Cada una de estas licencias existe por una razón. La diferencia es que el código abierto es algo más que el acceso gratuito al software, aunque ese es un importante punto a favor para muchos de los que lo utilizan. Más bien, se trata de control.

El código abierto debería ser mucho más que la simple licencia utilizada para un determinado software; se trata de la comunidad, el modelo de gobernanza para el futuro del proyecto y el valor que el proyecto puede crear con el tiempo. Sin embargo, la licencia es lo que proporciona control sobre cómo se puede utilizar ese software. Sin este debate abierto y franco sobre el futuro del código abierto, corremos el riesgo de perder lo que es tan importante sobre el código abierto en primer lugar. Sin una comunidad de código abierto fuerte, corremos el riesgo de devolver el control a los proveedores sobre lo que se puede y no se puede hacer con el software.

Resolución n.º 3: Tenemos que pensar más en el futuro de los proyectos, buenos y malos. En la industria de la tecnología, los cambios se producen todo el tiempo, pero predecir dónde se producirá el próximo gran salto es difícil. Por ejemplo, la IA había estado aquí durante décadas antes del lanzamiento de ChatGPT y la IA generativa despertó tanto interés. Para un observador externo, podría haber parecido que no pasaba nada, pero luego todo cambió. Como una gallina creciendo dentro de un huevo, sucedieron muchas cosas antes del momento de ruptura, y hubo muchos avances y comienzos en falso.

¿Qué significa esto para el código abierto? Significa responder a grandes cambios en el mercado a medida que se producen, con nuevos proyectos que llegan a una audiencia mayor de la que jamás creyeron posible en función de lo que está sucediendo en el mercado. Significa que los desarrolladores y líderes de proyectos deben comprender lo que les podría pasar a ellos y a los proyectos en los que están trabajando.

Al mismo tiempo, muchos proyectos de código abierto no tienen el impacto que deberían o caen en desgracia. Según una investigación de Sonatype, sólo el 11 por ciento de los proyectos de código abierto son "mantenidos activamente" por sus creadores o comunidades, y esto representó un aumento del 18 por ciento respecto al año anterior. ¿Deberían los desarrolladores pensar en ceder el control del código fuente y dejar que otra persona asuma el liderazgo de un proyecto? ¿Cómo puede una federación o fundación hacerse cargo cuando una empresa o un individuo no puede generar suficientes ingresos para cubrir sus costos? ¿Y qué sucede con los proyectos más antiguos que todavía se utilizan, pero que no se mantienen activamente?

Hablar de sostenibilidad para el código abierto implica pensar en proyectos que tal vez no tengan una oportunidad de mercado comercial pero que necesitan ser respaldados en el tiempo. Pueden estar integrados en otras herramientas de software o sistemas operativos, y es necesario cuidarlos cuando sean viables y reemplazarlos cuando no lo sean. La última resolución debería ser pensar dónde puede involucrarse y apoyar a los contribuyentes y mantenedores en estos esfuerzos durante 2024.