" />
ZOOM
GALERÍA
0 COMENTARIOS

Las empresas que usan fuentes abiertas para sus desarrollos "olvidan" después que se comprometieron a publicar las mejoras

La importancia de la fuente abierta en IoT

Que los programas de tipo Open Source, fuente abierta, son importantes en cualquier área de informática está fuera de toda duda. E incluso más en los temas de Internet of Things, el internet de las cosas. Hay muchos dispositivos de todo tipo que trabajan en alguna modalidad de programa de tipo fuente abierta. Lo cual no sólo incluye Linux, sino otros múltiples tipos de programación creada y distribuido bajo la fórmula de fuente abierta. El código creado bajo esta licencia de distribución no sólo asegura que el programa se basa en otro código, sino que las modificaciones y mejoras realizadas, incluso con propósito comercial, contribuyen a mejorar y refinar el código original. Y todo ello, disponible sin coste alguno, o restricciones de otro tipo, a cualquiera que desee consultarlo o emplearlo.

Sin embargo, a pesar de las obligaciones aceptadas cuando se inicia un proyecto en base a código fuente abierta, este compromiso no siempre se lleva hasta el final. Lo cual hace que, si bien muchos proyectos no hubieran tenido capacidad de arrancar o crecer sin la licencia de fuente abierta, cuando, por los motivos que sea, el proyecto no continúa en el tiempo, el producto (y sus servicios asociados) acaban en una vía muerta. O, al menos, en muchos casos, incluso si el producto llegó a alcanzar un cierto éxito, aunque fuera momentáneo. Lo cual lleva a dispositivos que tienen/tuvieron un buen nivel de funcionalidad a acabar en un inesperado pozo oscuro, sin posibilidades de continuar su inicial funcionalidad. Incluso cuando la filosofía de fuente abierta estaba en el corazón del dispositivo.

Sin duda es un problema para los (entregados) usuarios que confiaron en las cualidades del producto, y en su base de fuente abierta, como garantía de continuidad. Y más todavía, cuando el funcionamiento del producto lleva servicios asociados. ¿Hay alguna manera de cambiar esto? Desde luego, habría que modificar la mentalidad de las empresas, sobre todo las que se basan en la fuente abierta, que deben tener un plan B en caso de no lograr el esperado, y deseado, éxito comercial. Una de las claves y principios de la fuente abierta es que uno, individual o empresa, se aprovecha de un conocimiento previo puesto a disposición pública y se compromete, a su vez, a desarrollar y devolver las mejoras realizadas a la comunidad. Con el mismo coste que en la “adquisición”, es decir, de manera gratuita.

El problema

La mayor dificultad radica en que muchas empresas crean productos basados en hardware y/o software de fuente abierta, pero “olvidan” que, según el tipo de licencia del original, se comprometen a publicar las mejoras realizadas. O, simplemente crean modificaciones “particulares” que mantienen en privado como activo importante de la empresa. En otros casos, se crean servicios o APIs propias, incluso apoyadas sobre otras plataformas abiertas, sin apenas documentación pública. O se crea un hardware particular, cuyas particularidades se mantienen más o menos en secreto.

Con todo ello se crea una estructura que supone por una parte una protección de los creadores frente a otros rivales y competidores, pero que, a la vez, impide que terceras partes sean capaces de colaborar, y posiblemente mejorar, el producto/servicio original. Muchas empresas todavía basan en ello su ventaja competitiva. E incluso, al final de la existencia, consideran que esa información “tiene valor” y que puede obtener algún tipo de ingresos con su venta. Por lo que permanecen sin ver la luz pública.

En ocasiones, el producto desaparece porque la empresa matriz se ve obligada a cerrar sus puertas por falta de viabilidad económica. Pero tampoco son raros los casos de empresas que son compradas o absorbidas por otras más grandes. En esta situación hay veces en que la compra es, digamos de buena fe, para hacerse rápidamente con un desarrollo completo y ya probado. Que luego logra incluso más impulso comercial bajo el paraguas de la compañía compradora que es más importante, como demuestra el caso de Nest, tras su compra por parte de Google. Si bien tampoco son raros los casos en la compra se realiza con intención de quitarse a un competidor del mercado. En ocasiones el producto comprado pasar a formar parte de la oferta de su nuevo dueño. En otras, simplemente se aprovecha parte del saber hacer del producto, ya sea a través algunos de los componentes del equipo de diseño original, para mejorar los productos propios del nuevo dueño, o simplemente tomando ideas del producto y adaptándolas a los productos propios. Si bien tampoco resulta infrecuente en el terreno de las adquisiciones, que la potente empresa compradora decida, vía talonario, quitar de en medio a un competidor. Con los cual el producto acaba siendo abandonado y deja de tener continuidad en cuanto a servicios o mejoras.

Esto deja a los productos en una vía muerta, sin continuidad, es decir, convertidos en un ladrillo poco menos que inútil. Porque, no hay que olvidarlo, en el mundo de los dispositivos IoT hay una parte importante de funcionalidad que se centra en el servicio asociado. Un ejemplo son los denominados termostatos inteligentes, que basan su principio de operación en conocer si el usuario está o no en casa y ajustar la temperatura adecuadamente, o en controlar a distancia, vía smartphone, la modalidad de operación. Un servicio que se pierde por completo, restando gran parte de su funcionalidad al termostato en caso de que la empresa original no tenga continuidad.

La comunidad Open Source

Sin embargo, si estos productos, o las APIs, junto con una adecuada documentación, se hacen públicos, no será raro que gente con conocimiento y dedicación sean capaces de crear una pequeña comunidad que ayude a mantener con vida, y funcionamiento, a este tipo de productos, más allá de la existencia de las empresas que lo iniciaron. Y esa es, precisamente una forma de devolver a la comunidad parte del conocimiento de origen. No es raro que Linux, o alguna de sus distribuciones, sea empleada como base o inicio del proyecto. Así que parece de justa correspondencia volver a hacer pública la documentación del proyecto, una vez que deja de tener vigencia comercial.

La comunidad de fuente abierta es altamente colaborativa, con las ventajas que ofrece el que expertos programadores dediquen parte de su tiempo a la tarea de ampliar y mejorar el código que otros iniciaron. Y la facilidad de que la contribución provenga de múltiples expertos, distribuidos por todo el mundo, empujando un proyecto común con diferentes conocimientos y habilidades. En este campo hay tanto programadores profesionales, que, en su tiempo libre se lanzan a esta tarea, como entusiastas aficionados, con más o menos pericia, que se suman a un proyecto.

Uno de las mayores barreras para lograr que los proyectos avancen es, sin duda, contar con una buena documentación. Y no sólo que el código fuente esté bien comentado, sino, también que haya una cierta literatura de apoyo, indicando cada una de las rutinas, su función, los parámetros que recibe y/o devuelve, así como una introducción en cada bloque que ayude a comprender qué hay en cada archivo de código y cómo se relacionan entre ellos. Sin olvidar un poco de texto de presentación que describa el proyecto y sus partes. La parte digamos “literaria” de los proyectos tecnológicos suele estar bastante descuidada, lo que no ayuda a entenderlo inicialmente, o a desarrollarlo. Y es que, precisamente, los programadores no son por otra parte grandes “literatos”, ni dedican mucho esfuerzo a la parte de documentación directa. En general, consideran que un código “limpio” y bien estructurado, junto con algunos comentarios, es más que suficiente.

Y esto ocurre en un tiempo en que incluso grandes empresas, conocidas en su momento por la feroz protección de sus programas y procedimientos, se han ido abriendo progresivamente a la hora de publicar, o al menos mostrar, su código fuente. Aunque sea parcialmente y tras firmar algún tipo de contrato restrictivo en cuanto a su difusión. Una medida más de tipo legal que realmente orientada a mantener en secreto el código o el diseño. E incluso ciertas empresas, como Tesla, hayan optado casi desde el comienzo, por ofrecer de forma pública y gratuita, el fruto de sus propios desarrollos. Con ello esperan sumar esfuerzos en una línea común, de manera que no haya competición, con varios estándares desarrollando en caminos divergentes, sino en una rama común compartida. Un moderno espíritu de compartir conocimientos, en lugar de una competición basada en ocultar los avances.

Al igual que hay licencias que fijan, no sólo en términos legales, sino también funcionales, las condiciones de compartir y publicar código, deberíamos comenzar a pensar en fijar las obligaciones de los creadores, para lograr que sus programas y servicios no queden en el olvido. En este campo, repositorios abiertos y libres, como GitTub, CodePlex o SourceForge y otros, facilitan que el código no quede en el olvido del ordenador de su creador, sino que resulte accesible a cualquier que posteriormente desee apoyarse en él para ampliarlo, o como base de un nuevo proyecto, encontrando así parte del camino ya construido y probado. Ya sólo queda que las empresas, o los desarrolladores individuales, sean conscientes de que, a través de la comunidad de fuente abierta, sus creaciones tienen ocasión de perdurar y servir de ayuda a otros. Tanto a nuevos creadores, como a simples aficionados a la programación, sin olvidar a los viejos clientes y usuarios.

No comments yet.

Deja un comentario