Por qué los desarrolladores utilizan el código abierto en sus proyectos y cómo gestionar los riesgos

Comparte este artículo

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
codigo-abierto-riesgos

Si eres un desarrollador, incorporar código fuente abierto en tu proyecto es como pedir un kit de comida en lugar de cocinar desde cero. Te ahorra tiempo y esfuerzo. Pero también reduce tu nivel de control sobre el producto final y podría generar problemas no previstos.

Eso no quiere decir que no debas usar código abierto (o, para el caso, kits de comida). Hay muchas buenas razones para que los desarrolladores aprovechen el código abierto en sus proyectos.

Pero es importante estar consciente de los posibles inconvenientes y riesgos, y tener un plan para abordarlos.

¿Por qué agregar código abierto a tu base de código?

La mayoría de las organizaciones con equipos de desarrollo internos mantienen sus propias bases de código. Sus desarrolladores escriben la mayor parte del código para ellas.

Sin embargo, pueden optar por agregar código fuente abierto de terceros a sus bases de código, por varias razones.

La más obvia es que a menudo es más rápido y más fácil incorporar una función o crear una integración utilizando código de terceros que escribirlo uno mismo.

¿Por qué pasar una semana construyendo un nuevo servicio desde cero cuando puede obtener el código que necesita de un repositorio abierto en GitHub? ¿Por qué reinventar la rueda si alguien ya la inventó para ti y quiere que la uses gratis?

La incorporación de código abierto también puede ser útil en situaciones en las que un equipo de desarrollo interno no tiene la experiencia necesaria para implementar una determinada función o servicio.

Tal vez necesites agregar una nueva función a una aplicación heredada escrita en un lenguaje que nadie conoce bien, por ejemplo, por lo que decides extraer el código que necesitas de un proyecto de código abierto en lugar de aprender tú mismo el lenguaje.

Los desarrolladores también pueden optar por trabajar con código fuente abierto por razones que podrían describirse como políticas. Tomar prestado código de proyectos de código abierto de terceros puede ayudar a construir puentes con esos proyectos.

Contribuir de nuevo con el código construye puentes aún más fuertes. Si una empresa quiere establecerse como participante en el ecosistema que rodea a un determinado proyecto de código abierto, en otras palabras, trabajar con su código puede ser una forma de hacerlo.

Los inconvenientes de usar código fuente abierto

Si bien las razones para agregar código fuente abierto a la base de código interno de una empresa son sólidas, existen posibles inconvenientes a tener en cuenta.

Una es que, para citar al ingeniero Steve Belovarich, “cuando adoptas herramientas de código abierto, a menudo no sabes lo que estás obteniendo”.

En otras palabras, cuando usas código fuente abierto, puedes comprender aproximadamente lo que hace y cómo encaja en tu base de código. Pero a menos que los desarrolladores pasen días estudiando detenidamente cada línea del código, lo cual es poco probable, porque eso frustraría el propósito de tomar prestado el código para ahorrar tiempo y esfuerzo, el equipo no comprenderá con precisión cómo funciona este código fuente abierto.

Eso es un riesgo, porque significa que la empresa se vuelve dependiente de algo que sus desarrolladores no comprenden completamente.

La reutilización del código fuente abierto también puede provocar problemas de licencia. Hay docenas de diferentes licencias de código abierto, todas las cuales tienen sus propias reglas sobre cómo se puede incorporar el código abierto en otras bases de código. Algunas licencias permiten a los desarrolladores hacer lo que quieran con el código fuente abierto.

Otros requieren la atribución de los autores originales del código. Algunos imponen restricciones en situaciones en las que el código se usa públicamente, pero no si las empresas solo lo usan internamente.

Debido a esta complejidad, es fácil encontrarse con problemas de licencia al reutilizar el código fuente abierto de una manera que viola cualquier licencia que lo gobierne. Y aunque puede ser fácil suponer que las licencias no se harán cumplir realmente, no siempre es así.

Las empresas se enfrentan a un riesgo real si toman prestado código de fuente abierta sin entender los términos de la licencia y sin realizar un seguimiento de dónde existe el código dentro de sus propias bases de código.

Asimismo, los problemas de seguridad pueden ser una preocupación cuando se usa código fuente abierto. El código abierto no es menos intrínsecamente seguro o inseguro que el código propietario.

Pero cuando los desarrolladores usan el código abierto sin comprender completamente cómo funciona el código y sin saber qué vulnerabilidades pueden estar al acecho, corren el riesgo de introducir problemas de seguridad en sus bases de código.

Cuándo y cuándo no usar código fuente abierto

Decidir si utilizar o no el código fuente abierto, entonces, se reduce a evaluar si los beneficios superan los riesgos, así como la capacidad de su organización para controlar esos riesgos.

Si agregar código abierto a su base de código le ahorrará una cantidad significativa de tiempo, esfuerzo y dinero al reducir significativamente la cantidad de codificación original que debe realizar el equipo de desarrollo, probablemente valga la pena. Puede que sea menos si solo les ahorra a los desarrolladores el trabajo de un día.

Del mismo modo, si confía en la fuente del código y está seguro de que es seguro, tiene más sentido apoyarse en él. En general, es mejor usar código fuente abierto de un proyecto importante que extraer código de un repositorio de GitHub aleatorio.

Lo más importante de todo es el nivel de visibilidad y control que los desarrolladores tienen sobre el código fuente que utilizan. Independientemente de cuánto confíen en los autores originales del código o de lo bien que esté escrito, es imposible tener plena confianza en que no presentará problemas de seguridad, licencias u otros problemas sin realizar su propia investigación de antecedentes.

Ahí es donde entran soluciones como Software Composition Analysis (SCA) de Checkmarx. Las herramientas SCA permiten a las empresas encontrar el código fuente abierto que existe dentro de sus bases de datos (lo cual es importante porque los desarrolladores no siempre hacen un buen trabajo al realizar un seguimiento de dónde agregan código abierto) para que puedan evaluar el código en cuanto a licencias, seguridad, y otros riesgos.

De esta manera, SCA brinda a los equipos de desarrollo y a las empresas a las que apoyan la capacidad de aprovechar los beneficios que ofrece el código fuente abierto al tiempo que mitiga los riesgos asociados con él.

Chris Tozzi ha trabajado como periodista y administrador de sistemas Linux. Tiene intereses particulares en el código abierto, la infraestructura ágil y las redes. Es editor senior de contenido y analista de DevOps en Fixate IO. Su último libro, For Fun and Profit: A History of the Free and Open Source Software Revolution, fue publicado en 2017.

Ebook: 5 razones por las que la Seguridad del Software es más crítica que nunca