código abierto
Las aplicaciones de código abierto se han establecido en los sistemas TI de las grandes y medianas empresas. De dominar segmentos como servidores web, bases de datos y analíticas, las soluciones de código abierto ahora también se utilizan para la contenedorización, el aprendizaje automático, DevOps y, por supuesto, el desarrollo de software. Muchas empresas se están pasando al código abierto para tareas que no son del sector TI, como el CRM, la producción de contenido visual y la publicación de blogs. De acuerdo con Gartner, más del 95 % de las empresas TI utilizan soluciones de código abierto, pero incluso entre las empresas que no se incluyen dentro de este sector la cifra supera el 40 % y no deja de aumentar. Por si fuera poco, esta cifra no incluye los muchos casos en los que se utilizan bibliotecas de código abierto dentro de aplicaciones.
Elegir entre código abierto y cerrado no es nada fácil: no es solo un dilema entre pago o gratuito, con o sin soporte. A la hora de decidir sobre cualquier solución TI, las empresas deben tener en cuenta una serie de aspectos importantes.
El coste y cronograma de implementación
Aunque las soluciones de código abierto no suelen tener coste, implementarlas no sale gratis. Dependiendo de la complejidad de la solución, puede que debas gestionar las horas de dedicación del equipo TI, traer consultores expertos o incluso contratar desarrolladores que adapten constantemente la aplicación a las necesidades de tu empresa.
También existe el modelo de licencia híbrida, que te permite usar una edición comunitaria de la aplicación de forma gratuita, pero la versión extendida con funciones “empresariales” requiere una licencia de pago.
Además, muchos productos de código abierto no cuentan con documentación completa y/o actualizada o cursos de formación para usuarios finales. En grandes implementaciones, es posible que haya que cubrir este vacío internamente, lo que cuesta tiempo y dinero.
La ventaja del código abierto en la fase de implementación es, por supuesto, que permite realizar pruebas completas. Aunque planees implementar una solución de código abierto como alojamiento dedicado o, con la ayuda de un proveedor especializado, realizar una prueba piloto (prueba de concepto) por tu cuenta es mucho más eficaz que ver demostraciones en vídeo de soluciones privativas. Inmediatamente verás lo funcional y aplicable que es la solución para tu empresa en particular.
Al comparar soluciones de código abierto y cerrado antes de la implementación, es importante comprender qué tiempo queda disponible para las pruebas y si tienes la opción de cambiar el producto en sus primeras etapas. Si los plazos no son constantes y la respuesta a la segunda pregunta es afirmativa, tiene sentido realizar pruebas exhaustivas de un producto de código abierto.
El coste del soporte
El soporte y la configuración del día a día de muchas aplicaciones de código abierto a escala industrial, así como su adaptación a altas cargas de trabajo, requieren un conocimiento muy específico y profundo por parte del equipo TI.
Si esta opción no está disponible, este conocimiento deberá adquirirse, ya sea mediante la contratación o subcontratación de expertos. Entre los tipos más comunes de subcontratación se encuentra la ayuda de expertos específicos de la aplicación (formato Red Hat) o el alojamiento dedicado optimizado para una solución TI específica (Kube Clusters, WP Engine o un formato similar).
Por supuesto, el soporte de pago también es un estándar de las soluciones privativas; el de código abierto no es el único que lo necesita. El coste no es muy diferente: como muestra la práctica, el soporte técnico anual para una aplicación corporativa típica de código abierto es solo entre un 10 y un 15 % más económico que el de las soluciones privativas.
La corrección de errores, las nuevas funciones y la posibilidad de escala
Aunque las soluciones maduras de código abierto se actualizan regularmente para ampliar sus funciones y corregir errores, a menudo puede suceder que los desarrolladores no prioricen un error crítico para una empresa en particular. Esto es aún más común en el caso de las solicitudes de funciones. Aquí, debes sentarte y esperar pacientemente, o gastar el valioso tiempo de tus desarrolladores (internos o contratados) para que escriban el código necesario. Lo bueno es que esto es posible (al menos teóricamente); lo malo, que puede convertirse en un gasto importante e impredecible.
Ten en cuenta que el alojamiento dedicado elimina la preocupación de tener que andar instalando parches y actualizando aplicaciones, pero no puede evitar estos ajustes individuales. Una empresa con esta necesidad que accede al mercado de desarrollo debe elegir el formato de la extensión que crea: una bifurcación del producto de software principal o una adición a la rama de desarrollo principal en asociación con los desarrolladores originales de la aplicación. Es aquí donde entran en juego las ventajas estratégicas del código abierto: la flexibilidad de uso y la velocidad de la innovación.
La integración y el soporte multiplataforma
Para las soluciones multicomponente a gran escala que intercambian datos de forma activa, la integración y la compatibilidad con diferentes plataformas pueden desempeñar un papel importante en la elección del producto de software. La prioridad aquí es el soporte de formatos de la industria para el almacenamiento e intercambio de datos, además de interfaces de programación de aplicaciones (API) bien documentadas. A veces, una solución de un solo proveedor con código de software propietario puede cumplir estos requisitos mejor que un enjambre de soluciones de fuente abierta, incluso las de alta calidad. Pero siempre resulta útil estimar el coste que supone modificar una solución de código abierto si gana en otros criterios y ha pasado la fase de prueba de concepto.
Riesgos, seguridad y cumplimiento
A menudo, el código abierto se promociona como la opción más segura. Después de todo, que alguien pueda ver el código fuente y corregir errores, debe ser más seguro que la oferta de una caja negra de software propietario, ¿cierto?
Como siempre, la realidad es más complicada. En primer lugar, muchas aplicaciones de código abierto tienen millones de líneas de código que nadie puede auditar en su totalidad. La gran cantidad de actualizaciones de este código solo complica aún más la tarea. Dicho esto, pequeño no significa seguro. Por ejemplo, la vulnerabilidad Shellshock basada en Bash pasó desapercibida durante 20 años.
En segundo lugar, el problema de las dependencias es grave, ya que las aplicaciones y el código tienen su propia cadena de suministro. Una aplicación de código abierto puede usar una biblioteca de código abierto de terceros, que a su vez esté vinculada a otra biblioteca de terceros, y es poco probable que los encargados de verificar la aplicación comprueben también todas esas bibliotecas. Los riesgos de esta cadena se han demostrado muchas veces, por ejemplo: la vulnerabilidad en la biblioteca de registro gratuita Log4j que afectó a miles de grandes soluciones de código abierto, impactando a gigantes como Amazon, Cloudflare y Elastic; el ataque que reemplazó las bibliotecas npm con homónimos maliciosos funcionó en Apple y Microsoft; y la decisión de un desarrollador independiente de no admitir la biblioteca left-pad en el repositorio de npm que bloqueó más de mil aplicaciones y sitios populares (incluido Facebook) durante varias horas.
Dependencias de software. Fuente.
Otro problema con las dependencias son las licencias. Las licencias de código abierto son bastante específicas y no tener que pagar no significa que no haya un titular de los derechos de autor. La aplicación en sí y sus bibliotecas pueden venir con varias licencias, y la violación de las más estrictas (copyleft) está plagada de litigios. Al igual que el proceso bien establecido de auditoría de seguridad TI y mitigación de vulnerabilidades, los principales usuarios y desarrolladores de software de código abierto deben tener un proceso similar para verificar periódicamente el cumplimiento de la licencia, a poder ser semiautomatizado.
Todo lo anterior no significa que el código abierto sea la peor opción desde la perspectiva de la seguridad de la información. Solo debes comprender todos los riesgos: el equipo de implementación debe evaluar la cultura de desarrollo y la frecuencia de las actualizaciones de seguridad en las aplicaciones de la competencia y controlar las dependencias y licencias (por ejemplo, mediante el uso de SBOM, siglas en inglés de software bill of materials). Además, si tu empresa trabaja en el campo de desarrollo de software, es una buena idea escanear todos los paquetes de código abierto en busca de vulnerabilidades y funcionalidades maliciosas.
