Novedades en la categoría Open Source
El viernes 25, Sam Ramji en el contexto de la OSCON, nos sorprendió con otra nota sobre el apoyo oficial que está dando Microsoft al proyecto Apache, se trata de financiamiento en este caso, porque Microsoft se ha convertido en sponsor platinum la Apache Software Foundation (ASF).
Algunas aclaraciones sobre que significa este apoyo financiero, para aquellos que se sientan despitados con las notas periodisticas:
- Todos los sponsors platinum aportan la misma cantidad de dinero, al menos 100.000 dolares al año, y se sabe que hay al menos 3 patrocinadores en esta categoría: Google, Microsoft y Yahoo.
- Efectivamente, la licencia Apache, permite incorporar el código fuente dentro de un producto comercial cerrado sin necesidad de publicar los códigos fuente, un modelo que es visto con buenos ojos por los sectores más "conservadores" dentro de Microsoft.
history.forward()
El título de la nota de Ramji es muy claro: history.forward().
Pero esta es noticia que no nos sorprende, al menos no debería sorprender a los lectores de este blog.
Hace rato que venimos informando de cómo se está integrando el opensource dentro de Microsoft. No ha sido un proceso fácil, por cierto, pero es algo inevitable. Yo creo que hay mucha actitud pragmática, y la necesidad de adaptarse para sobrevivir en un nuevo escenario.
Como un ejemplo, Ramji nos cuenta que el equipo de Microsoft SQL Server desarrolló un driver nativo para PHP, y en los laboratorios opensource han parchado AdoDB para que use este nuevo driver, probándolo con más de 100 aplicaciones PHP comunitarias.
Hace unos meses atrás el equipo del servidor apache visitó Microsoft con el fin de obtener información técnica interna de primera fuente. Tuvieron acceso amplio y colaboraron en forma abierta con el equipo de Windows 2008 y de IIS.
¿Está Microsoft comprometiéndose seriamente con el opensource? No es menor que hayan colaborado en un proyecto que usa la LGPL, algo que hace un tiempo atrás habría parecido impensable. Por supuesto uno puede ver esto de manera cínica, o decir que Microsoft ha sido obligado a seguir este camino. La verdad es que en parte es eso, pero también hay una necesidad de negocios sumamente pragmática.
Hay que seguir observando el curso de estas acciones. Por supuesto que en muchas partes, sobre todo en nuestro medio local, las viejas y cancinas discusiones bizantinas continuarán, pero es claro que hay un segmento importante de Microsoft que está en otra actitud más abierta y colaborativa, probablemente porque es inevitable, y están reconociendo que el opensource será una de las fuerzas dominantes de nuestra industria en el futuro.
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)
Ahora que capté su atención estimado lector, le cuento que no se trata del Luciano Bello de la foto, quien, a pesar de sus intentos de poner cara de inteligente, no creo que se dedique a la informática.
No, el Luciano Bello en cuestión es un hacker argentino, quien se tomó el tiempo de leer el código de la implementación Open SSL de Debian, y encontrar un fallo bastante serio (Debian la base de la distribución Ubuntu) y otros.
El bug estaba desde 2006, y demuestra, una vez más, que el software libre no es más seguro "per se".
También demuestra que tampoco es cierta la mal llamada Ley de Linus, acuñada por Eric Raymond, quien postula que al haber muchos ojos mirando el código todos los bugs son evidentes.
La verdad, es que aún habiendo suficientes ojos, igual se pasan los bugs por entre las patas de los desarrolladores.
Lo mejor de todo este incidente es la tira de XKCD de hoy:
Richard Stallman ha decidido adoptar un laptop XO y migrar a este equipo como su plataforma de trabajo permanente, porque al parecer el XO es el único laptop que corre una BIOS basada en software ibre.
Pero Stallman escribe sobre las controversias que se ha dado dentro de la OLPC, luego que Negroponte dijera que OLPC ha fracasado por usar software opensource, es más, ha criticado una supuesta posición fundamentalista de los promotores del opensource dentro del OLPC.
Esta actitud de Negroponte provocó fisuras y grandes pérdidas para el OLPC. Las críticas de Negroponte no sólo apuntan a este supuesto fundamentalismo, sino que a la falta de un arquitecto que guiara el desarrollo de la interfaz Sugar en forma más orgánica.
Finalmente, Negroponte ha tratado de imponer el soporte para windows XP dentro de los laptops de la OLPC.
Cosas que recordar cuando lean noticias sobre el OLPC
La gente que se ha ido ha reaccionado a las críticas de Negroponte, y con respecto a esta falta de un arquitecto Ivan Krstic le responde en un interesante post titulado, Esto también pasará, cosas que recordar cuando lean noticias sobre el OLPC.
Krstic nos informa/recuerda que:
La tarjeta SD no fue instalada para dar soporte a Windows, sino como un efecto lateral del trabajo de Mark Foster, arquitecto de hardware, quien al crear un nuevo chip permitió incorporar la cámara y un slot SD:
_"The SD card slot didn't get added to the XO for Microsoft, as he is fond of saying, but because we were getting terrible read/write performance with our solid-state storage. Hardware architect Mark Foster designed a dedicated chip to speed things up; that chip, as an unanticipated bonus, made it easy to attach a camera and an SD slot.
e. Hardware architect Mark Foster designed a dedicated chip to speed things up; that chip, as an unanticipated bonus, made it easy to attach a camera and an SD slot."_
Negroponte dice que Sugar se ha desarollado en forma amorfa por falta de un arquitecto, Krstic nos cuenta que la OLPC le hizo una oferta escrita para que él se hiciera cargo de la labor de arquitecto jefe de software, pero Negroponte rescindió la oferta unilateralmente, sin dar razones. Así que si no hay arquitecto también es culpa del presidente de la OLPC.
"Nicholas' recent claim of Sugar growing amorphously because it "didn't have a software architect who did it in a crisp way" is similarly muddy: convincing him of the need for an architect is a battle Walter and I fought for months without success. The organization decided to move anyway, and extended me a written offer to take over as Chief Software Architect. Nicholas rescinded the offer unilaterally several weeks later, for reasons he refused to explain to anyone. So yes, there was no architect, but that's because Nicholas didn't want one. If he believes that's the cause of Sugar's problems, he has no one but himself to blame."
Es un proyecto educativo
Stallman ha expresado muy bien el hecho de que el OLPC corre el riesgo de volverse irrelevante:
[OLPC] It is also superfluous. The OLPC has already inspired other cheap computers; if the goal is only to make cheap computers available, the OLPC project has succeeded whether or not more XOs are built. So why build more XOs? Delivering freedom would be a good reason.
Eso preocupa a Negroponte, y piensa, equivocadamente, que se trata de colocar laptops en la mayor cantidad de niños, cumpliendo eso, la meta del OLPC se cumple.
Esa también es la misión del proyecto chileno, UCPN, que los niños tengan acceso a un computador personal.
Yo no creo que esa sea la idea, ya hay computadores baratos que permitirían lograr esta meta, y al estado chileno no le costaría tanto en estos tiempos.
Creo que el mayor valor está, como siempre, en el software.
Walter Bender y muchos que lo apoyan piensan lo mismo, y por eso que ha establecido una lista de discusión para definir el futuro de Sugar, dado que al estar disponible bajo licencia libre (GPL), tiene sentido construir una comunidad enfocada en el desarrollo de Sugar como plataforma de softwaer educativo.
Its an eductation project, es el nombre de la lista creada por Bender, y recientemente ha publicado los objetivos de este grupo de trabajo:
* La teoría y practica del aprendizaje necesita evolucionar en la medida que evoluciona la tecnología.
* Hay la necesidad de tender un puente entre la comunidad de desarrolladores y la comunidad de educadores.
* El desarrollo del software Sugar puede servir como un sustento estructural tangible.
* Entender la importancia educacional de Sugar es el foco actual de la lista de discusión.
Como siempre me ha interesado más el software, que el hardware, estoy interesado más en la propuesta de Bender, que en las ideas de Negroponte, e incluso de UCPN.
No se trata de regalar máquinas, las máquinas son irrelevantes, lo que queda es la educación, en definitiva, lo que importa es el software, y no cualquier software.
[Imagenes tomadas de wiki.laptop.org y del blog de Ivan Krstic radian.org]
Le preguntan a Linus Torvalds:
¿Cómo es la comunidad Linux? ¿Sigue siendo fuerte el proyecto open source?
Nunca ha sido cohesivo, en muchas formas es inadecuado llamarlo una comunidad. Algunos están involucrados debido a la ideología, muchos se involucran porque hay algún area que están usando o en la que están interesados y no necesariamente se preocupan de los demás. Pero sucede que hay suficientes intereses compartidos. Todos quieren las mismas cosas: estabilidad, desempeño.
Las compañías involucradas... tienen diferentes áreass de interes, como dispositivos empotrados: para ellos lo importante es que Linux se mantenga pequeño. Hay otros trabajando en máquinas con miles de CPUs. ¡Es sorprendete que eso funcione después de todo!
Entrevista a Linus Torvalds en el Sidney Morning Herald de Australia.
No es para menos, porque su acuerdo con Microsoft le ha significado sobre los 300 millones de dolares de ingresos para el 2007, tal como lo muestran sus estados financieros.
De acuerdo al SEC-10K Filling, el documento donde se declara el estado de la empresa, al termino del año, Novell incrementó en un 69% las ventas de plataformas Linux, y esto se lo atribuyen al acuerdo con Microsoft.
En la página 29 del informe dice:
"Bajo el Business Collaboration Agreement, estamos comercializando una oferta combinada con Microsoft. La oferta combinada consiste de SUSE Linux Enterprise Server y una subscrición a soporte SLES junto con
Microsoft Windows Server,Microsoft Virtual Server y Microsoft Viridian, y se ofrece a cliente que deseen desplegar Linux y Windows en un ambiente virtualizado. Microsoft hizo un pago inmediato a nosotros de $240 milliones por los "certificados" de subscripciones SLES, los cuales Microsoft puede usar, vender o distribuir durante el curso de este acuerdo, permitiendo al dueño del certificado obtener una subscripción anual o multi anual para el soporte SLES por parte nuesta (lo que le da derecho a upgrades, actualizaciones y soporte técnico). Microsoft accedíó a gastar $60 millones durante la duración del acuerdo en marketing sobre escenarios de virtualización de Linux y Windows y también 34 millones en términos de acuerdos para que las fuerzas de venta de Microsoft se dediquen primariamente al marketing de la oferta combinada. Microsoft acordó que por tres años posteriores al inicio del acuerdo no realizará ningún trato con otro distribuidor de Linux ni a promover la adopción de ninguna virtualizacion "Linux No Novell"/Windows Server bajo algún programa substancialmente similar al programa de distribución de certificados de subscripción SLES."
En suma, la firma del trato con Microsoft le significó 240 millones de dolares en plata fresca, más 94 millones en marketing.
Pero eso no es todo, porque está el acuerdo de Patentes, en que Microsoft se compromete a no realizar acciones legales contra los clientes de Novell. Según este acuerdo de patentes (pagina 29), Microsoft hizo un pago neto a Novell de $108 millones de dolares, y Novel se compromete a realizar un pago mínimo de 40 millones de dolares durante 5 años (que es lo que dura el contrato), tomado de un porcentaje de la ventas del "Open Platform Solutions and Open Enterprise Server".
Por algo los ejecutivos de Novell han John Dragoon, y Jeff Jaffe están tan contentos y cantan al mundo las alabanzas de este acuerdo, ¿quién no? (ya sabemos quienes, pero gente amargada siempre hay).
Les quiero presentar un par de innovaciones del investigador Johnny Chung Lee, postulante a doctorado en la Universidad de Carnegie Mellon.
La primera innovación la descubrí a través de un post en
Botón Turbo.. Lamentablemente en ese blog no entendieron muy bien que es lo que sucede, así que permitanme explicarlo, antes de presentarles el video.
En este caso Chung Lee escribe un programa en C# y utiliza el control de la Wii como dispositivo de entrada conectado a su Laptop, corriendo Windows. En ningún momento ha escrito código que se ejecute en la consola de Nintendo, todo ocurre en el laptop, y lo que se usa es el WiiMote. La característica principal de esta innovación es que utiliza el control de la Wii al revés, mueve el sensor infrarrojo en vez del WiiMote.
Noten el efecto que se produce al introducir el marco, una técnica usada en computación gráfica. Claro que sólo sirve para un usuario, el que esté portando el sensor infrarrojo a la altura de sus ojos. Como explica Chung Lee, esta innovación le da nuevas posibilidades a la Wii.
La segunda innovación de Chung Lee, y que a mí me parece más interesante es cómo usa este concepto de usar el WiiMote para seguir el rastro de un lapiz infrarrojo. Con esto monta una pizarra interactiva, y luego construye su propia versión del Surface, claro que a una centésima parte del costo (una WiiMote cuesta unos 50 dolares, y un Surface unos 5000).
¡¡Con esto se pueden montar pizarras interactivas en cualquier colegio, a una fracción del costo!!
Lo mejor es que todo el código fuente de estos proyectos está publicado, les sugiero explorar la página de proyectos de Chung Lee y sorprenderse con este innovador.
Estos proyectos han sido desarrollados en Windows usando como base la Managed Library for Nintendo's Wiimote escrita por Brian Peek y publicada en el blog de Microsoft Coding4Fun.
