Software
Código
Open source

7 inconvenientes de la cultura del código abierto

La pasión por el código abierto alimenta la creatividad, el aprendizaje y la comunidad de desarrolladores, pero no es Shangri-La. He aquí siete escollos que hay que tener en cuenta antes de unirse a un proyecto de código abierto.

software codigo

No cabe duda de los méritos de la filosofía del código abierto para escribir código y producir software. Muchos de los paquetes de software que constituyen el núcleo de la informática moderna, desde el sistema operativo Linux hasta MySQL, se crearon utilizando un modelo de código abierto compartido y desarrollo colaborativo. Cuatro décadas de gran código, alimentado por la filosofía de la apertura, han resuelto cualquier duda sobre si la idea del código abierto funciona.

Pero a pesar de toda su grandeza, el código abierto no está exento de defectos. Ahora que el código abierto ha entrado en la corriente dominante, consideremos algunas de sus desventajas, no tanto la filosofía como la realidad cotidiana. He aquí siete razones por las que los desarrolladores podrían pensárselo dos veces antes de contribuir a un proyecto de código abierto.

 

El código abierto no funciona con la nube

 

Muchas de las actuales licencias de código abierto se crearon antes de la nube, cuando los usuarios accedían al software descargándolo y ejecutándolo en sus ordenadores de escritorio. Desde entonces, las empresas de la nube han encontrado la manera de aprovecharse de la ética del código abierto manteniendo la propiedad de los cambios en su código. Un directivo de código abierto de una importante empresa de nube me dijo, con bastante timidez, que ellos distribuyen el software, por lo que no necesitan compartir el código fuente.

Hay docenas de ejemplos de proveedores de la nube que crean versiones especiales de proyectos de código abierto para revenderlos en la nube. Una de las desavenencias más visibles se produjo entre Amazon Web Services y los creadores de Elasticsearch. Al no llegar a un acuerdo, ambas partes se separaron y ahora existen dos versiones efectivas del código base de Elasticsearch.

Algunos defensores del código abierto se oponen a la cooptación de la nube elaborando licencias más estrictas o enmiendas como la Cláusula Commons. Puede que veamos mejoras en el futuro, pero no ayudarán con los sistemas heredados que se distribuyen bajo las licencias de código abierto originales.

 

El código abierto tiene un problema de diversidad

 

En los círculos del código abierto se habla mucho de comunidad, pero eso no significa que la cultura del código abierto sea una especie de Shangri-La. Los desarrolladores de código abierto pueden ser un grupo nervioso: bruscos, distraídos, testarudos e incluso francamente mezquinos. También es bien sabido que el código abierto tiene un problema de diversidad, y ciertas figuras prominentes han sido acusadas de racismo y sexismo. La desigualdad estructural puede ser menos visible cuando las personas contribuyen a los proyectos de código abierto con relativo anonimato, comunicándose sólo a través de correos electrónicos o tablones de anuncios. Pero a veces ese anonimato genera sentimientos de desconexión, lo que puede hacer que el proceso de colaboración sea menos agradable y menos inclusivo de lo que parece.

 

Construir y mantener una comunidad lleva tiempo

 

Muchas empresas lanzan versiones de código abierto de sus productos como "edición para la comunidad". Es una gran herramienta de marketing y también una buena forma de recoger ideas y, a veces, código para mejorar el producto. Sin embargo, crear una verdadera comunidad en torno a ese proyecto requiere tiempo y recursos. Si un usuario y posible colaborador publica una pregunta en el tablón de anuncios de una comunidad en línea, espera una respuesta. Sí, muchas contribuciones se hacen libremente, en el espíritu del código abierto, pero alimentar la comunidad sigue llevando tiempo. Cuando funciona bien, el resultado puede ser un grupo floreciente que está construyendo un gran código, pero a menudo hay mucho trabajo en el camino. Una consecuencia de este equilibrio es que los grandes proyectos empresariales tienden a dominar el campo. Pueden permitirse financiar el modelo de comunidad mediante funciones remuneradas que las empresas más pequeñas no pueden gestionar.

 

La tutoría de código abierto es sorprendentemente escasa

 

En la misma línea, muchos desarrolladores están dispuestos a compartir su código con cualquiera, pero eso no significa que quieran ayudar a otros a aprender. Dar a alguien acceso a un repositorio Git lleva unos minutos, pero apoyar su crecimiento como desarrollador y colaborador es un compromiso importante. Algunos proyectos incluso incluyen una cláusula en sus acuerdos de colaboración por la que los colaboradores no deben esperar ser incorporados o apoyados, o incluso que se respondan sus preguntas. En esencia, contribuir a un proyecto de código abierto puede ser como tirarse de cabeza a la piscina: aquí tienes un billón de líneas de código y un problema que resolver. Encontrarás muy pocos comentarios que expliquen lo que está pasando. Gracias y suerte.

 

Hasta los incondicionales necesitan un sueldo

 

La mayoría de los desarrolladores de código abierto son idealistas que no están motivados por la fama y la fortuna, pero necesitan comer y dormir bajo un techo. El mundo real tiene muchas limitaciones físicas que no son compatibles con el espíritu de libre intercambio del código abierto. La escasez puede ser un concepto ajeno al mundo digital, pero es un problema muy real para las formas de vida biológica.

El código abierto funciona bien para pequeñas pilas y proyectos pasionales, en los que nadie espera cobrar, pero puede resultar incómodo para bases de código más grandes en las que trabajan codificadores a tiempo completo. Si demasiados usuarios optan por la versión gratuita, todo el proyecto puede venirse abajo.

 

Nada es realmente gratis

 

Si pasas mucho tiempo en el mundo del código abierto, es probable que te encuentres con el acrónimo TANSTAAFL, que significa "There Ain't Such Thing As a Free Lunch" (Nada es gratis).

Después de que los usuarios descarguen software de código abierto y lo utilicen, empezarán a descubrir sus limitaciones. A veces, el código sólo necesita pequeños retoques. A veces, ni siquiera tiene las características adecuadas. Nadie quiere quejarse del vaso que sólo está medio lleno, sobre todo cuando el precio es cero. Pero llenar el resto del vaso puede ser una carga considerable para el desarrollador con un plazo de entrega. Incluso cuando el código libre te permite llegar al 99% de tu objetivo, ese último 1% puede ser un verdadero esfuerzo.

 

Algunos proyectos no deberían ser de código abierto

 

Un desarrollador de una base de datos me dijo que nunca se había planteado la posibilidad de que su proyecto fuera de código abierto. Sus clientes eran grandes empresas con enormes conjuntos de datos. Tenían el presupuesto y estaban dispuestos a pagarle por hacer el trabajo. Si un cliente quería leer el código fuente, él estaba más que dispuesto a dárselo. Pero no quería tomarse la molestia de separar una versión formal y abierta del proyecto.

Las versiones de código abierto son buenas para el código utilizado por una amplia variedad de desarrolladores que pueden ayudar a desarrollar el código juntos. En algunos casos, sin embargo, el intercambio de dinero es una forma más sencilla y, en última instancia, más sostenible de organizar el trabajo de creación de software.



TE PUEDE INTERESAR...

CASOS DE ÉXITO

Accede a nuestra publicación de canal

DealerWorld Digital

Documentos ComputerWorld

Documento Pure Storage y Kyndryl INFRAESTRUCTURAS