Cinco factores para usar código fuente abierto en software propietario
Para hacer el mejor uso del vasto y variado conjunto de software de código abierto disponible, los desarrolladores deben ser astutos acerca de lo que realmente puede servir mejor a un proyecto.
El desarrollo de software de código abierto establece un entorno en el que los autores pueden crear y publicar código fuente para el estudio, la adaptación y la redistribución en colaboración.
Cualquier empresa, equipo o individuo puede crear y publicar código bajo una licencia de código abierto. Los componentes de código abierto van mucho más allá de la interfaz de usuario mundana y las funciones utilitarias. Las contribuciones están disponibles en campos tan diversos como la autoedición, la IA, las matemáticas, las imágenes, el almacenamiento de datos y las redes, los juegos, la educación, la programación y la seguridad. Una comunidad como GitHub, por ejemplo, alberga más de 100 millones de repositorios creados por más de 31 millones de colaboradores.
Con esta manantial de riquezas al alcance de la mano, los equipos deben tomar decisiones sobre el uso de código fuente abierto en proyectos de software propietario de manera que no socaven sus objetivos comerciales, la seguridad o las prácticas de desarrollo efectivas.
Ventajas del software de código abierto
Los desarrolladores pueden obtener, modificar e integrar fácilmente innumerables paquetes de código fuente abierto en diversos proyectos de software. El uso de código fuente abierto para habilitar funciones y procesos básicos en un proyecto de software propietario puede reducir el tiempo de los ciclos de desarrollo y liberar a los creadores de código para que se concentren en la funcionalidad principal y de habilitación comercial.
Si bien los elementos de código abierto otorgan beneficios tangibles para los proyectos de desarrollo de software, pueden imponer desafíos y limitaciones a una aplicación propietaria, especialmente si el proyecto está destinado a uso comercial. Las organizaciones deben evaluar la gestión y la integración de los componentes de software de otros creadores, las prioridades de sus proyectos, las responsabilidades, las licencias y la seguridad antes de seleccionar el código fuente abierto para un proyecto.
1. Integración y gestión de software de código abierto
Muchos componentes de código abierto tienen una gran cantidad de alternativas y variaciones. Por ejemplo, los desarrolladores pueden seleccionar entre docenas –y a veces cientos– de opciones de motor de interfaz de usuario de código abierto. Debe evaluar y revisar cada opción para asegurarse de que funcionará con el diseño general de su proyecto. Algunos códigos fuente abiertos requieren integración con otros componentes, y debe probar cada punto de integración para garantizar la calidad del software.
Además, el software de código abierto se actualiza para corregir errores, mejorar el rendimiento y agregar funciones, lo que significa que los componentes del proyecto propietario deben reevaluarse y examinarse cuando se producen cambios en el proyecto de código abierto.
La integración del código fuente abierto en el software propietario puede crear una pesadilla para los gerentes de proyectos. Cuando un proyecto de software distribuido se basa en cientos de componentes de código abierto, el tiempo y el esfuerzo necesarios para realizar un seguimiento de cada componente, sus compatibilidades y sus actualizaciones pueden afectar el ciclo de desarrollo del proyecto.
2. Responsabilidades del código fuente abierto
El proceso de evaluación y verificación del código fuente abierto debe incluir una revisión de la hoja de ruta y la codificación del componente que se está considerando.
Un equipo de software puede querer un código fuente abierto que satisfaga sus necesidades apremiantes para ciertas funcionalidades, pero considerar solo lo que necesitan hoy podría afectarlos más adelante. Infórmese sobre las perspectivas futuras del código, incluidas las posibles modificaciones importantes. Si el componente no se ha actualizado durante un tiempo –algunos llaman a estos proyectos abandonware– o no admitirá fundamentalmente las capacidades que se espera que su proyecto requiera en el futuro, considere usar trabajo interno u otras opciones de código abierto.
El código fuente abierto no ofrece garantías de calidad o rendimiento. Y a diferencia del software comercial, el código generalmente carece de una garantía para ofrecer un recurso en caso de falla o ejecución deficiente. Las empresas asumen toda la responsabilidad por el rendimiento de sus proyectos, incluso si la culpa del bajo rendimiento o un error recae directamente en un elemento de código fuente abierto. Cuando utilice código fuente abierto en proyectos de software propietario, considere cuidadosamente las garantías y limitaciones de responsabilidad delineadas en su licencia.
3. Licencias y propiedad intelectual
Si bien el software de código abierto es libre de obtener, cambiar y trabajar con él, no es de dominio público. El software de código abierto se publica bajo una licencia, como Apache License 2.0; licencia BSD; Licencia Pública General GNU (GPL), Biblioteca GNU o GPL Menor; Licencia MIT; o Licencia Pública de Mozilla 2.0. Cada licencia describe los términos de uso y distribución.
Por lo general, las licencias de software de fuente abierta no restringen significativamente la capacidad de una empresa para adquirirlas y usarlas. Por lo tanto, un producto de software propietario y comercial puede basarse en componentes de código abierto.
Sin embargo, las empresas deben saber si una licencia puede causar problemas y cómo. La GNU GPL requiere que los usuarios publiquen cualquier trabajo derivado bajo la misma licencia GNU GPL. Si una empresa obtiene y modifica el código fuente abierto bajo GNU GPL, debe dejar el código modificado con copyleft, lo que significa liberarlo también al código fuente abierto.
En algunos casos, todo el proyecto de software se considera un trabajo derivado del código fuente abierto que utiliza, y todo el código fuente del proyecto propietario está sujeto a distribución de código abierto según los términos de la licencia. Por esta razón, los responsables de la toma de decisiones empresariales pueden impedir que los desarrolladores utilicen código fuente abierto para un proyecto, incluso si se ajusta a los requisitos y criterios de funcionalidad del grupo.
Casi todas las aplicaciones –el 96 % de las examinadas– contienen algunos componentes de código abierto, según una encuesta de 2018 realizada por el proveedor de pruebas de seguridad de aplicaciones Synopsys. El informe encontró que la aplicación promedio utiliza más de 250 componentes de código abierto en su construcción.
4. Prioridades comerciales
No se limite a evaluar la idoneidad de un componente de código abierto para un proyecto en términos de tiempo y dinero que ahorra. Evalúe si el componente ayuda o no a cumplir sus objetivos comerciales.
Para obtener una ventaja competitiva, las empresas confían en la innovación de funciones de software y el rendimiento eficiente. Los desarrolladores siempre deben buscar oportunidades para innovar , ya sea que eso signifique reducir el tiempo del proyecto al incluir código fuente abierto o que creen componentes personalizados que satisfagan las necesidades exactas de una aplicación.
Por ejemplo, los desarrolladores de un proyecto de herramienta de visualización y renderizado podrían adoptar el software de modelado 3D de fuente abierta Blender para la funcionalidad principal, pero no hay nada que impida que sus principales competidores hagan lo mismo. Por lo tanto, las herramientas resultantes carecerían de diferenciación para ganar clientes potenciales.
5. Seguridad del software de código abierto
Un ecosistema de código abierto profundo y activo es un caldo de cultivo para códigos vulnerables y maliciosos. El mercado de código abierto es el último ejemplo de caveat emptor, que en latín significa «que el comprador tenga cuidado».
La seguridad del software de código abierto se basa tanto en los comentarios de la comunidad –más eficaz cuanto más popular es un proyecto– como en el análisis de vulnerabilidades de rutina. Cuando se utiliza código fuente abierto en software propietario, las empresas deben asumir los riesgos y promulgar una investigación de seguridad más allá de los aportes de la comunidad para garantizar que el software cumpla con sus estándares corporativos. Por ejemplo, los desarrolladores y evaluadores deben examinar el código fuente abierto en busca de spyware y otro malware incrustado, así como también vulnerabilidades que pueden dejar el proyecto de software propietario abierto para ser explotado por partes malintencionadas.
Las organizaciones que confían en el código fuente abierto en los proyectos de software deben usar herramientas de prueba de vulnerabilidades para descubrir la susceptibilidad a problemas como desbordamientos de búfer, falsificación de protocolos de direcciones, ataques distribuidos de denegación de servicio y envenenamiento de caché. Las pruebas de vulnerabilidad se pueden incorporar en una canalización de entrega de software.
Debe evaluar estas cinco áreas clave para cada proyecto y para cada pieza de código fuente abierto. Todos los componentes de código fuente abierto se rigen por términos de licencia específicos, se construyen con diversos grados de rendimiento y están sujetos a innumerables problemas de calidad potenciales.
El factor común en todos los casos de uso de código fuente abierto en proyectos de software propietario es que la responsabilidad recae en el negocio, no en el creador del código. Diseñar políticas sobre cómo usar de manera inteligente el software de código abierto y cómo validar, administrar y optimizar el código.