Recently in Software libre Category

"Talk is cheap, show me the code" -- Linus Torvalds

No hablo mucho de mi trabajo en este blog, es una política personal, pero voy a mencionar que hace unos meses tuve la oportunidad de implementar un servicio de misión crítica, en que todas las componentes están soportadas por productos opensource, desde el sistema operativo (RedHat), el middleware (JBoss) hasta la base de datos (Postgres).

Creo que hicimos un buen trabajo con ayuda de nuestros proveedores tecnológicos, y establecimos de pasada las bases de la infraestructura básica de servicios (SOA) para nuestra compañía, la que guiará nuestros futuros desarrollos en los próximos años.

Tal como dice Franco Catrin, la elección de componentes de base, como el sistema operativo es una decisión táctica, pero cuando empezamos a subir en la escala de complejidad de las soluciones informáticas, la decisión de usar o no opensource se convierte en una decisión estratégica.

Estas decisiones no deben tomarse con el criterio de ahorrarse las licencias, de hecho, las licencias de mantención de Redhat Linux Enterprise suelen costar lo mismo y a veces más que una versión de Windows. El costo de licencias no es la decisión relevante en estos casos, el que toma decisiones tecnológicas basado en el costo de licencias es un ratón.

"El Open Source no es algo a lo cual temer. El Open source es algo que debe ser explicado. El Open source gana no porque sea abierto, ni porque sea gratis. El Open source gana sólo cuando es mejor" - Larry Ellison

Me llega un bonito documento sobre "80 casos para el estudio de la ética", elaborado por el Centro de Etica Aplicada de Duoc UC [1] centro preocupado de la "formación de capital humano". ¡Capital Humano! 

"A mediados de los 70, en Silicon Valley, un grupo de hackers y aficionados a la naciente informática utilizaba un software pasado de mano en mano, es decir, lo ocupaban sin fijarse en quién era su dueño. En un comienzo no había problema, pero cuando comenzaron a aparecer empresas u organizaciones que lucraban con la producción de softwares empezaron a surgir dificultades. Esto fue un impedimento para que ellos se pudieran realizar profesionalmente y esde ese entonces comenzaron a divisar que la solución estaba en organizarse como una comunidad para buscar el bien común. Bill Gates, mediante una carta a consumidores y compradores de sistemas operativos, quiso hacer notar a la comunidad de hackers y aficionados que ellos estaban devaluando el sueldo de todos los involucrados en el desarrollo de proyectos que eran afectados por el uso indebido de las copias. Además existía un robo, si bien era de algo intangible como el software, es un robo al fin y al cabo." 

La verdad es que se nota que el trabajo es obra de un estudiante de informática de este centro de estudios, como varios de los otros casos que alcancé a leer. 

Así que no es que esto sea un texto que se le esté enseñando a los informáticos en esa carrera en el DUOC. Al menos ¡eso espero!.

Pero para ser honestos, hay muchos fanáticos del software libre que transmiten este mito, y ¡los peores son los profesores universitarios, que lo hacen!

El estudiante despistado, o el aficionado a la tecnología, es mal informado con la idea de que todo esto del software libre, nació como una respuesta en contra de ese cruel déspota que era Bill Gates, quien  a fines de los 70 recién estaba creando su empresa, y sólo trataba de vender su interprete de Basic (o sistemas operativos), desde  Albuquerque, Nuevo México, ni siquiera en ¡Sillicon Valley! Por cierto, la carta era enviada a los aficionados a los primeros microcomputadores, quienes estaban repartiendo copias de Altair Basic, sin pagarle a Gates (¡yo también habría reclamado lo mismo!). 

Es cierto, la carta no es muy afortunada, por la forma que está redactada, da a entender que la mayoría de los aficionados robaban software, pero, ¡no es por esa carta que se generó la creación del movimiento del software libre!

El Manifiesto GNU, el documento fundacional del software libre, fue escrito casi diez años después que la carta de Bill Gates, y publicado por primera vez en la edición de marzo de la DDJ.

Todo nació porque Richard Stallman se encontraba un tanto tostado con esto de no tener acceso al código fuente, y tener que pagar licencias por el software (en realidad no las pagaba él, las pagaba el MIT, pero anda a explicarle eso a un hippie).

Todo partió cuando Brian Reid vendió su sistema de procesamiento de texto Scribe, y accedió a colocar "bombas de tiempo" en este, de modo que el programa se desactivara después de 90 días si no se había pagado la licencia de uso. A Stallman esto le pareció un "atentado contra la humanidad", y empezó su obsesión, su delirio y el resto es historia (sí, hay locos que han logrado que se realicen grandes cosas en la historia).

Se dicen muchas inexactitudes sobre el software libre, y creo que ya es tiempo de ir educando, y explicando las cosas como son, y para eso es bueno partir por la historia tal como fue, no como nos gustaría que hubiera sido.

Por último, lo que de verdad me intriga es ¿si será posible hablar de ética faltando a la verdad? ¿O sin verificar si lo que se dice es cierto, o ajustado a la realidad histórica? o ¿si puede un profesor de ética aceptar este trabajo sin verificar si lo citado por el autor es cierto? ¿Donde están las referencias,  o las fuentes que acrediten tantos disparates? 

Eso me parece que no es ético, no sé, ¿habrá que preguntarle quizás a Wittgenstein? 

[1] Traté de encontrar el caso 24 en el sitio del programa de ética, donde están publicados algunos de los ejemplos, lamentablemente no está, tampoco el recopilatorio con 80 casos, pero la copia que pongo acá  me fue entregada por alguien vinculado a ese centro. 

"No tengo nada contra Microsoft. De hecho creo que Windows tiene características muy buenas, sin embargo si seguimos usando software privativo seguiremos siempre siendo sólo usuarios nada más. Chile alguna vez fue líder en educación y cultura. Con el software libre es eso lo que fomentamos: el desarrollo. Y es lo que la gente debería tener, el derecho a elegir".

Hoy se realiza FLISOL en varios puntos de Chile. Me gusta esta actividad, y me parece que encarna el espíritu social que debe importar en el desarrollo de la computación.

Yo uso software libre, y software open source desde hace años, recientemente implantamos un servicio de misión crítica en mi trabajo usando sólo productos opensource.

No tengo empacho en usar software abierto, y tampoco en usar software propietario (o privativo, como debería decirse para ser gramaticalmente correcto).

Lo que me molesta en estos eventos es cuando se nos trata de vender una idea incorrecta, la idea de que usar el software libre es algo ético, mientras que usar el software cerrado (propietario o privativo) no. Algo que por supuesto es falso, y es parte de una cierta ideología, capciosa, que no tiene que ver con la naturaleza del software. No es la tecnología la llamada a ser ética, es la gente la que debe serlo, pero no quedas manchado por usar software privado. Creo que e

sa es una visión odiosa, y que deberíamos desterrarla de las discusiones.

El software abierto tiene muchos méritos, pero la ética, no es uno de esos. Y para explicar mi punto adjunto un extracto reciclado y mejorado que escribí febrero de 2006:

Libertad

¿Sómos libres los hombres?

Esta pregunta es importante, porque define los límites de la ética. Aristóteles se lo pregunta, y dice que somos libres hasta por ahí no más. Algunos más severos, como Spinoza plantean que cómo somos parte de la esencia de Dios la libertad está en asumir su voluntad, o sea que en el fondo no podemos ser libres en el sentido vulgar del término.

Yo creo que somos libres, por que podemos elegir. Sin embargo una cosa es lo que quiero, y otra cosa lo que puedo. Una cosa es lo que elijo, y otra cosa es lo que me pasa.

En palabras de mi hermano Ricardo:

...la libertad en el terreno cotidiano no puede ser 

absoluta. Cada vez que decido hacer algo, "tomar helado", dejo de elegir o de hacer otras cosas, por ejemplo "dejar de tomar té". Alguien listo podría decirme "pero puedes tomar té con helado". Cierto pero esa ya es una tercera opción que excluye el simple he

cho de tomar sólo helado. Cada acto libre, excluye en su realización otros actos libres.

No somos libres, así con libertad absoluta, porque no somos seres absolutos. Y el sostener la libertad absoluta es una opción que bien puede caer en el plano ideal, pero no vivencial.

Según esta filosofía, uno puede construir software para controlar misiles balísticos intercontinentales de destrucción masiva siempre que el programa sea estudiable, es decir, su código fuente debe ser accesible (incluso para el enemigo ;).

Uno diría que los militares no harían eso nunca, pero la libertad 0 no lo impide. Es más, hay software GPL para la industria militar, RedHawk Linux es el ejemplo más impactante, que es usado en el desarrollo de aviones de combate, e incluso la NSA ha desarrollado una versión de linux adaptada a las necesidades de seguridad de los Estados Unidos.

A mi no me gusta que Linux se use para eso. De hecho es ridículo discutir sobre si el software GPL debe restringir el uso de DRM, cuando es éticamente más cuestionable que el software libre sea usado para desarrollar bombarderos que matarán a miles de niños.

A mi no me gusta que Linux se use para eso. De hecho es ridículo discutir sobre si el software GPL debe restringir el uso de DRM, cuando es éticamente más cuestionable que el software libre sea usado para desarrollar bombarderos que matarán a miles de niños.

Parece ser que en el GPL el otro aspecto de la libertad, la responsabilidad no se cuestiona, es decir, no define un marco ético, que es un marco de cómo uso la libertad. 

Aunque Stallman trata de vender la idea de que todo esto es algo ético, y bueno para la sociedad, la verdad es que usa argumentos dualistas trasnochados, llevando a sus interlocutores a confundir ética con moral, con "cierta moral", con un discurso que plantea falsos dilemas, es un maniqueo, que sostiene que el que desarrolla software prropietario es un tipo malo, que sólo trata de perjudicar deliberadamente a la sociedad, un mensaje que prende muy fuerte en la juventud, pero que no tiene mucha sustancia en realidad, y que de ética tiene muy poco, como decía Nietzche, "sólo es un sonido, no la verdad". 

El GPL busca libertad absoluta para el software, pero no le impone ningún tipo de responsabilidad ética, salvo quizás, la de que debes compartir tu código fuente con tu prójimo.

Así que lo correcto es decir que el software libre es una ideología, y no una ética. Si hubiera ética en el free software, se definirían las responsabilidades que conllevan seguir esta filosofía. 

Que sea una ideología no tiene nada de malo. Lo malo es que quieran venderla como la única forma ética de desarrollar software, o que nos quieran hacer creer que es la única visión ética, y correcta, para guiar la profesión de desarrollar software.

Me parece que la primera vez que escuché esta canción fue en la versión de Joe Cocker, la misma que pueden ver en este video en Youtube.

La canción es de los Beatles, de Lennon y McCartney, por supuesto, y originalmente la canta Ringo Starr. Sin embargo, para muchos, incluido yo, la versión de Cocker es superior, incluido yo, pero es cuestión de gustos.

La versión de Cocker es una innovación, con varios cambios con respecto a la versión original,  un compas de 6/8, en otra escala, con una introducción instrumental más larga, y varios acordes distintos. A pesar de estos cambios, sigue siendo una versión distinta del trabajo original de los Beatles, no se le considera una creación nueva. A esto, en el caso de la música popular, se le llama cover. Un cover es algo permitido en la música popular, y no debe ser confundido con el plagio (de hecho, algunos han tratado de defender sus plagios a posteriori, argumentado que en realidad trataban de versionar, o hacer un cover).

A mi se me ocurre que este concepto de cover, es una buena forma de explicar lo que pasa con el OpenSource o Software Libre (*), a una persona que no entiende de estos temas, sobre todo si trabaja para la SCD ;)

"OpenOffice es un cover de Microsoft Office", hablando en forma metafórica.

Claro que en el caso de la música, para hacer un cover de una canción debes pedir autorización del dueño de los derechos de autor del tema. Ese es el problema con las metáforas, como diría el Dr. House, que nunca son totalmente adecuadas.

Porque en el caso del software puedes duplicar el comportamiento, sin afectar la propiedad intelectual del autor original, basta con que repliques la funcionalidad externa (siempre que ésta no se encuentre patentada), y demostrar que el código que sustenta esta nueva funcionalidad no es el mismo que el original.

Ya hemos comentado antes acerca de la (im)posibilidad de plagiar en software. He insistido en que siempre ha sido considerado algo legítimo el poder duplicar la funcionalidad del software, por eso que las patentes de software son tan criticadas en nuestra industria, porque, entre otras cosas, nos limitan las posibilidades de innovar.

Me gusta el nombre de esa canción: "con una pequeña ayuda de mis amigos", porque tiene mucho que ver con el tema del desarrollo del software del tipo opensource, o software libre.

Cuando hablamos de proyectos de software libre, sólo aquellos que logran formar una comunidad que lo soporte son los que logran sobrevivir, y tener éxito.

Esa es, en mi opinión, la gran innovación disruptiva del FLOSS. Pero esa es una innovación de otro tipo, el software libre modifica la forma de hacer tecnología, pero no la tecnología en sí misma. Concedo que esto discutible, pero no quiero entrar en esta discusión ideológica o ética sobre el software libre, algo que ya encuentro aburrido a esta altura.

Me interesa explorar hoy en día que pasa con la innovación tecnológica que genera el FLOSS.

Mi punto es este, el software libre es como la versión de Cocker, una innovación, grandiosa para algunos, puede a incluso superar a la versión original, pero la creación original, la innovación disruptiva, no viene del FLOSS, porque el FLOSS es, hasta ahora al menos, un desarrollo reactivo, ante la creación que viene desde otros lados, principalmente el software propietario (o privativo, para ser gramaticalmente correcto).

Creo que los grandes desarrollos disruptivos del FLOSS se han dado en el ámbito de los lenguajes de programación (Perl, Python, PHP), pero todo el resto, ha sido, en general, tomar ideas que fueron desarrolladas en el ámbito propietario, con código cerrado. De hecho, esos desarrollos son reacciones, al hecho de que esos desarrollos disruptivos tengan su código cerrado. Esa es la causa por la que nacen estos proyectos opensource, y su motivación principal, copiar la funcionalidad de un proyecto realmente innovador.

Esta es mi pata de palo que tenía para tirar al fuego hoy ;) 

Por cierto, este es un primer argumento, algo superficial, si quieren, porque hay mucho más que desarrollar, fuentes que citar, estadísticas que mostrar. Al menos tengo otra razón para argumentar por qué el FLOSS no genera mucha innovación disruptiva (según algunos, no innova nada, pero esa no es mi posición), pero esto pienso desarrollarlo más adelante..

Tal como dije ayer, me gustaría aprovechar los blogs para discutir este tema, creo que las discusiones, al final deben iluminarnos a todos. Nunca podremos ponernos de acuerdo totalmente, pero al menos algo aprenderemos en el proceso, todo con la ayuda de nuestros amigos ;).

(*) pido disculpas anticipadas a los puristas, en este escrito voy a usar los términos opensource y software libre y FLOSS casi en forma intercambiable, estoy totalmente consciente de la diferencia, he escrito código abierto y normalmente he optado por licenciarlo via GPL (software libre), pero no entremos en una discusión de distinciones a lo Richard Stallman, trataré de no abusar de este intercambio de términos.

Déjenme que les cuente una cosa, un secreto en realidad, no confíen en "los expertos" que habla de las TICs. 
Tengo la teoría de que ese término nació en las telcos, porque le temen tanto a desaparecer y volverse irrelevantes, que agregaron una C a TI, con el fin de mantenerse en el inconsciente colectivo.

Las comunicaciones,la C en TIC, es una más de las tecnologías de la información (TI), decir TIC es redundante, ridículo, y la verdad es que desprestigia a quien usa el término.

Pero no es por esto que voy a criticar al nuevo encargado de la estrategia digital del gobierno, si quiere insistir en usar un término neurológico para hablar de nuestra industria, es problema de él, habrá que usar un  filtro pasa bajo.

La verdad es que no hemos tenido nunca en este cargo un funcionario que realmente valga la pena. Algo se ha mejorado, el primero no sabía distinguir entre bit y byte, al menos los dos últimos alguna vez han desarrollado software (al menos eso dicen sus curricula), y conocen algo de la industria, porque vienen desde esta (lo que no sé si será mucho que decir, porque en realidad el nivel de la TI en Chile hace rato que deja mucho que desear).

Ernesto Evans partió mal, echándose en contra la comunidad del software libre con sus declaraciones:

¿Cree que el Estado debería incorporar más el software de código abierto?

"Es un tema de costo beneficio. La discusión no es si hay que incorporar software pagado u open source. Si tengo una aplicación que me cuesta cero, pero su implantación y desarrollo es más caro que un software pagado, entonces hay que optar por el segundo. Creo que se tiene que ver caso a caso. El software libre es un gran anhelo, pero hay que ver cuánta gente está capacitada para desarrollarlo, en qué áreas y cuál es su expertiz. Repito: No puede ser un tema ideológico."

 ¿Y qué opina que el Parlamento haya rechazado la glosa tecnológica acerca del software libre en las compras estatales?

"¡Menos mal que no la aprobaron! Imponer código abierto hoy es una locura. Si definimos como país que vamos avanzar en código abierto es otra cosa, para lo cual tenemos que generar una cultura para ello. Pero imponer el código abierto sería como un Transantiago tecnológico. Hay que ser responsable en estas cosas.'

Estoy batallando con el filtro spam de mi blog, y me he dado cuenta que me ha dejado oculto varios comentarios interesantes.

Uno de los que he rescatado fue enviado por Micronauta, y como él escribe uno de mis blogs favoritos, creo que se merece una respuesta destacada (además que aprovecho de pedirle las disculpas por no haber publicado su comentario).

Veamos, el comentario está en mi articulo sobre el fallo en Debian, encontrado por Luciano Bello ;) Tengo que confesar que no he quedado satisfecho con la nota tan breve y seudo humorística que hice y creo que en algún momento escribiré sobre las lecciones que nos entrega ese caso, pero vamos al comentario de Ignacio.

La primera parte del comentario dice:

Tu frase "también demuestra que tampoco es cierta la mal llamada Ley de Linus", tendría que ser soportada con estadísticas. Yo sostengo la hipótesis de que Torvalds tiene razón. No porque haya alguien por ahí que pilló un bug, se demuestra que dicha ley no es cierta.

Bueno, primero hay que aclarar que la Ley de Linus fue formulada por Eric Raymond, en su clásico ensayo La Catedral y el Bazar, y dice así:

"given enough eyeballs, all bugs are shallow" (con muchas miradas, todos los errores saltarán a la vista).

Incluso hay una versión más formal de esta ley:

"Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone." (Dada una base suficiente de desarrolladores asistentes y beta-testers, casi cualquier problema puede ser caracterizado rápidamente, y su solución ser obvia al menos para alguien).

Basta un contra ejemplo para derrumbar este enunciado de Raymond, y muchas críticas a este enunciado parten de este hecho.

Un contra ejemplo es el fallo de Debian, porque no era obvio en el código las consecuencias de eliminar una línea, a pesar de que el caso fue sometido y comentado por la comunidad antes de realizar el cambio que llevó al desastre.

Insisto que el tema merece un análisis más profundo, que daría para un ensayo sobre ingeniería de software, pero creo que queda claro, que tal como está planteada, la Ley de Linus no puede ser considerada una ley, y a lo más una declaración de intenciones.

Pero es más, el mismo Raymond reconoce el error de su formulación original, en la respuesta a un mensaje a la lista e-mac-devel, respondiendo un mensaje de Stephen J. Turnbull, que dice:

It is not true that to "many eyes, all bugs are shallow". What is true is that (1) with many eyes, shallow bugs get caught very quickly, and (2) that the more eyes there are, the more likely it is that some member of the group has sufficiently penetrating vision to catch the deeper-swimming bugs.

No es cierto que "para muchos ojos los fallos son obvios". Lo que es cierto es que (1) con muchos ojos, los fallos obvios son atrapados muy rápidamente, y (2) que mientras más ojos hay, lo más probable es que algún miembro del grupo tenga la visión suficientemente penetrante para atrapar los fallos más profundos.

A lo que Eric Raymond responde:

As I observed recently on the Open-Source list, one of the advantages of being me is that I'm not required to believe the popular oversimplifications of my thinking. Congratulations: you have captured my actual view of the many-eyeballs effect rather exactly!

Como he observado en la lista Open-Source recientemente, una de las ventajas de ser yo es que no estoy obligado a creer las sobresimplificaciones populares de mi pensamiento. ¡Felicitaciones: has capturado mi real visión del efecto de los muchos ojos de una manera exacta!

Lamentablemente, es la formulación original la que ha quedado, y nadie toma en cuenta que es una ley errónea, que lleva a consecuencias desastrosas, como han escrito varios autores más autorizados que yo.

Ahora, el segundo párrafo del comentario de Ignacio:

Debe ser más probable que se pillen bugs en software de código abierto que en software de código cerrado, simple economía de la atención, por lo tanto como resultado debe ser estadísticamente más seguro usar soluciones basadas en código abierto. Sentido común.

Esto merece mayor atención, y dudo que alguien tenga las cifras para demostrarlo en un sentido u otro, pero vamos a intentar una respuesta, usando el sentido común, al que apela mi comentarista.

Sabemos que la observación de un bug, por parte del usuario, o de un beta-tester, no es suficiente para determinar la causa del bug. De hecho, muchas veces la causa de un bug es la cosa menos obvia, y puede tener origen en una componente muy profunda del sistema, o ser el resultado de un efecto lateral que no es una consecuencia directa del código.

Por lo tanto, el tener una base grande de usuarios nos permite encontrar bugs más rápidos, porque esta base de usuarios aporta con datos, y la información es la mejor herramienta que tenemos para encontrar un fallo. Pero esta ventaja aplica tanto para código abierto y cerrado, y de hecho sabemos que Microsoft recolecta bastas cantidades de información de errores generados por millones de usarios en miles de configuraciones distintas.

Por otro lado, está el tema de los muchos ojos, pues bien, esos ojos no sólo deben estar observando el código, sino que estar motivados, capacitados y preparados para observar ese código.

Tener un ambiente de desarrollo adecuado para compilar, y depurar el código de OpenSSL es un trabajo de preparación no menor ( de hecho el bug de Debian nació de la necesidades de uno de estos ambientes de desarrollo).

La consecuencia de lo que estoy diciendo, es que no hay suficientes ojos observando el código, y de los ojos que están observandolo no todos estan preparados, de hecho, toman decisiones que son catastróficas que toman años corregir (el caso de Debian no es el único).

La ley de los grandes números, uno de los fundamentos del análisis estadístico, requiere de, bueno, grandes números, y la Ley de Linus es una ley de este tipo.

Estos grandes números se dan en algunos proyectos, donde además hay grandes inversionistas pagando a los ojos para que pongan atención al código, pero eso no pasa en la mayoría, y es precisamente lo que pasa en OpenSSL, donde sus propios desarrolladores reconocen que no hay tiempos ni recursos para hacer una adecuada mantención a este código.

Por otro lado, el software cerrado tiene la cantidad ojos que necesita, ojos preparados, motivados (esperamos) y pagados para observar ese código.

La diferencia fundamental está en que, en el caso del código abierto, una vez identificado un fallo, un externo puede entrar y realizar la corrección.

La ventaja del código abierto está en que el tiempo de respuesta es muchas veces superior al del código cerrado, porque, "una vez identificado un error, muchos ojos tornan su atención al código", y esa sí sería una hermosa ley, más precisa y realista, y que aplica a código abierto y cerrado. El corolario es obvio, la cantidad de ojos que tornan sus ojos al código abierto es mayor, y por ende suben las probabilidades de encontrar la solución en menor tiempo.

(Fotografía original desde Flickr tomada por maqroll, bajo licencia CC)