Código Abierto: es exponer el código o la receta con el que se hizo el programa. Existen númerosos proyectos que funcionan bajo esta modalidad, siendo los más famosos el Linux y el Apache.
Seguridad: Vamos a referirnos a la seguridad que necesitamos en nuestras computadoras para proteger el acceso no querido.
Para seguir tendríamos que decir que para proteger a nuestra computadora tenemos que explicar que aún la computadora más egoísta y tímida tiene que dar algo de sí misma para integrarse a una red. Y seguidamente también, tendríamos que decir que una red expresa una necesidad de interactuar.
Como dice un viejo conocido: “La computadora más segura es la computadora que está en una caja fuerte cerrada, en un cuarto de concreto cerrado, desconectada de toda red y apagada. Y aún así no pondría las manos en el fuego por ella.”
Pensar en crear herramientas de seguridad en un esquema de código abierto podría llevarnos a pensar que estamos jugando una mano de poker con las cartas hacia arriba. Pero estaríamos equivocados.
Si bien un buen virus podría conocer a la perfección el mejor lugar para instalarse y hacerse invisible, el código que está atacando es bien conocido por la comunidad. Y la extensa comunidad que lo usa y lo soporta aprende rápidamente a identificar el problema y a corregirlo. Y puede adaptarse rápidamente. Puede aprender de los errores que observa en los demás, y en proyectos maduros como los que mencionaba arriba, esta erosión del tiempo ha dejado productos muy pulidos.
El problema se presenta desde muchas partes: puede ser alguien que quiere producir un daño, pero también puede ser alguien que teoriza sobre conectividad, de alguien que está desarrollando un software asociado, o de un estudiando haciendo una tesis. Los proyectos de código abierto especialmente, reciben mucho más aporte en estas cuestiones que los proyectos que no lo son, sobre todo porque reproducir y entender un problema de seguridad interactuando con una caja cerrada es mucho más arduo.
El problema está planteado entonces, ahora bien, corregirlo puede ser algo muy sencillo de hacer, pero la relación con nuestros socios hará que la implementación sea más o menos posible.
Habíamos hablado de red, pero para entender el mundo del software tendríamos que profundizar la idea que subyace en lo que representa una madeja de relaciones.
Cuando una pieza de software se vuelve productiva, otras personas la usan. Y algunas personas también pueden desarrollar piezas de software que en alguna medida aportan nueva funcionalidad apoyadas en esta primera roca, que adquirió un lugar en este mundo.
Esto va formando un entramado que tiende lazos entre las distintas ideas que florecen, se transforman en hitos sobre los que se pueden parar otras apliaciones y seguir adelante. En el caso de ofrecer una caja cerrada con botones que emergen de ella, como es la metodología de ofrecer una API (por Application Programming Interface), cambiar el comportamiento de una función hará que todo lo que funcionaba deje de funcionar. O peor, que todo lo que funcionaba ahora lo haga inesperadamente distinto.
La interfaz de programación es un contrato que ofrece la compañía productora de software y no debe ser cambiada. Especifica las funciones a usar, la entrada y la salida de datos y se documenta el proceso que deben hacer. Qué es lo que se hace con los contratos entonces? Porque de hecho, la funcionalidad no se puede pensar toda de golpe, ni perfectamente, ni se puede comprender de entrada cuáles serán las necesidades de las personas que usen ese contrato. Como versionar las librerías dinámicas no parece ser una práctica posible dentro del esequema de Microsoft Windows, lo que se hace es agregar funciones. Es la forma más segura de alterar una interfaz. Lo que estaba queda, y se le agrega una función más, llamada muy parecido y que hace además otra cosa que se le pide.
Por esto, las APIs tienen la tendencia de crecer, y transformarse en bibliotecas inaccesibles con miles de fósiles que están expuestos pero que no se usan y con muchas funciones repetidas que no deberían estar allí.
Cambiar cosas en este esquema tiene siempre repercusiones inesperadas. En un esquema comunitario, los cambios son mucho más conversables. Muchos ojos pueden estudiar el cambio de rumbo y de hecho, muchas de las soluciones propuestas vendrán de los mismos usuarios de estas librerarías que están allí para que todos las vean.
De hecho, tengo la fuerte impresión de que todo sistema complejo debería ser de código abierto. Algo tan aburrido como el sistema operativo tendría que ser llevado de esta manera, por ejemplo. No hablo del escritorio que puede tener miles de cosas divertidas, hablo del proceso de conectarse con los dispositivos, de montar el sistema de archivos y todas esas cosas que un usuario normal no tendría que conocer.
De esta manera, tendríamos un sistema operativo que está centrado en las necesidades de la gente, y no en ventajitas o features, que están hechos para que la gente vaya y compre. Se imaginan un mundo en el que Microsoft siguió la idea de Apple y que ponga un Unix debajo del capó? Yo sí!