fbpx
Antonio Marín SegoviaCC BY-NC-ND

3 lecciones aún no aprendidas sobre FOSS

Recientemente, al software libre y de código abierto se le ha referido como FOSS por sus siglas en inglés (Free and Open Source Software), siendo éste el software informático que puede clasificarse tanto como libre como de código abierto, lo cual evita la filosófica discusión que busca diferenciarlos, misma que en los hechos no genera ningún valor.

Así, FOSS es un término inclusivo que abarca a los dos y en el que se comprende que, a pesar de describir modelos de desarrollo similares, tienen culturas y filosofías diferentes. En tal contexto surge la inquietante pregunta: ¿qué se ha aprendido o no, de manera inclusiva y por separado, en el gobierno?

No es sinónimo de gratuito

La primera lección que no ha quedado del todo clara para las diversas instituciones del Estado y sus áreas de Sistemas es que software libre no tiene que ver con “gratis”. El término “libre” se refiere a la capacidad de los usuarios y las organizaciones para copiar y reutilizar el software; libertad que implica grandes esfuerzos e inversión para poder utilizarlo, estudiarlo, mejorarlo o redistribuirlo, todo lo cual se pasa por alto pensando incorrectamente que libre significa gratuito.

Por otro lado, el de código abierto ha sido menos entendido. Un esquema en que se busque obtener beneficio ha de enfocarse en las fortalezas percibidas del modelo de desarrollo peer-to-peer (de igual a igual), por lo que las dependencias gubernamentales ya deberían contar con una fábrica de software común en la que, sumando los esfuerzos de todos los desarrolladores institucionales (en esquemas de igual a igual), lograran contribuir al mantenimiento, la mejora continua y la innovación del software de código abierto, que pueda utilizarse de manera interinstitucional, cotidiana y bien orquestada.

De nada sirve que exista la filosofía de trabajo del software de código abierto si los entes de gobierno operan como silos, cada uno en su “versión” (en el mejor de los casos, si no es que adoptando las de otros países), sin hacer sinergia del capital intelectual y tecnológico que hay en cada una de las dependencias.

Puede aplicarse en los sistemas críticos

¿Cuál es la segunda lección que no se ha captado? Que FOSS es totalmente aplicable y capaz de implementarse en los sistemas críticos de las instituciones, debido a que es posible desarrollarlo a través de diversos métodos, incluyendo los utilizados para aplicaciones de seguridad nacional e institucional de misión crítica, siempre y cuando el código fuente resultante esté disponible de forma libre. Un FOSS bien proyectado y rigurosamente diseñado puede aprovechar la experiencia colaborativa de los desarrolladores institucionales –y por qué no, de todo el mundo– para lograr un producto pulido, correcto y seguro.

Sistemas de este tipo se utilizan actualmente para muchas aplicaciones de misión crítica, como los sistemas financieros, los de control de los expedientes médicos de los ciudadanos en países desarrollados, en la instrumentación de la biotecnología médica (específicamente para las intervenciones quirúrgicas de dispositivos médicos robotizados), en la aeronáutica y la aviónica terrestres, los satélites y las sondas extraterrestres, y las infraestructuras críticas nacionales como los sistemas regionales de agua y energía, así como la defensa de países avanzados.

De hecho, gran parte del software seguro utilizado por el Gobierno Federal de los Estados Unidos –por minoristas como Amazon, con presencia en casi todo el mundo– es FOSS. ¿Por qué no ha de funcionar en las instituciones mexicanas? Claramente es porque no se ha entendido que puede implementarse completamente en los sistemas críticos de todas ellas, pero eso sí, hay que invertirle.

Los cambios son más flexibles y rápidos

Lección número tres: los sistemas FOSS tienen mayor flexibilidad que los de código cerrado, lo que permite una fácil implantación de modificaciones que llegan desde el poder legislativo, en el que los legisladores hacen, deshacen y cambian las leyes, en muchos de los casos como respuesta a la presión pública por ciertos acontecimientos de tipo social o, en otros, por la presión de los medios de comunicación, partidos políticos, organizaciones de la sociedad civil, exigencias del Banco Mundial u otros orígenes. Estos cambios deben ser rápidamente aplicados y, por lo general, no se consulta con anticipación a los funcionarios responsables de los sistemas en que hay que materializarlos (con apremio) para generar realmente un beneficio a los ciudadanos, de tal manera que no queden cual letra muerta.

Es claro, entonces, que los sistemas de información de todas las instituciones en el país deben ser modificados constantemente, lo cual requiere, en la mayoría de los casos, tener un alto control y entendimiento del código fuente. No se aprende que, en sistemas propietarios, el acceso al código es altamente limitado y a menudo el desarrollador que produjo el software tiene su modelo de beneficio-venta justo en lograr, en primera instancia, el control de éste; si se requiere alguna modificación, el precio y el desarrollo estará sujeto a lo que el proveedor determine, sin que los ajustes requeridos por la ley (que apremian) se puedan realizar con agilidad, quedando su aplicación completamente supeditada y dependiente de su suministro.

En contraste, debido a que el código fuente para los FOSS está disponible libremente, los desarrolladores de software pueden competir por el diseño, desarrollo e implementación del cambio de la forma más conveniente, y posteriormente compartir o hacer sinergia para materializarlo de manera expedita. Incluso si el problema es que no existen desarrolladores al interior de las instituciones, del mismo modo los proveedores podrían concursar entre ellos por contratos para crear y mantener este tipo de sistemas.

Sólo falta el interés de las dependencias gubernamentales por fomentarlo y, si no hay quien lo haga, por desarrollar a los proveedores y generar un ambiente “multiproveedor”. Y todo es factible gracias a que el código fuente está ahí, disponible para los FOSS, lo cual minimizaría hasta los precios de los contratos, ya que no se requiere trabajar con el proveedor inicial al haber libertad como clientes, lo que tristemente no se ha comprendido y aprovechado.

Comentarios de Facebook