Software Libre

Dentro de poco hará un año que empecé con el Máster en Software Libre en la Universidad Rey Juan Carlos. Cuando empecé apenas llevaba tiempo usando Software Libre. No sabía exactamente que implicaba el uso legal de este tipo de software, cómo influye en la sociedad o si existían modelos de negocio detrás de este movimiento.

Para empezar a entender todos los entresijos, hay que remontarse a este personaje, Richard M. Stallman que por culpa de una impresora, a la que no podía hackear para hacerla funcionar con sus ordenadores, porque su fabricante no le envió el código fuente, empezó a idear el manifiesto GNU. A principios de los 80, por el MIT y otras instituciones, no temían si el código del programa que estaba desarrollando lo cogiera otra persona, por aquel entonces se ayudaba entre programadores compartiendo código. Entonces empezaron a obligar a los empleados de estas instituciones a firmar un acuerdo de no divulgación. Este par de hechos, hicieron ver a Stallman que había que conservar esa comunidad de Hackers, en la que el código, como conocimiento básico era transmitido sin ningún problema.

En 1983 Stallman anunció el Proyecto GNU, pero no fue hasta 1985 cuando se publicó el manifiesto, del que se pueden extraer las 4 libertades fundamentales.

• Libertad 0, ejecutar el programa para cualquier propósito.
• Libertad 1, estudiar/modificar el programa para aprender o usarlo como quieras. Se requiere del código fuente de forma legible para realizar esta acción.
• Libertad 2, redistribuir copias para ayudar al prójimo.
• Libertad 3, distribuir las versiones modificadas.

En este mismo se año también se creo la Free Software Foundation. Fundación encargada de eliminar las restricciones de copia, redistribución, modificación o manejo dél código.

Tal y como se dicta, son libertades y no obligaciones. Esto quiere decir que si realizas modificaciones de un software que sea libre, no tienes la obligación de distribuir esos cambios realizados en ese software.

Esto es lo que ocurre cuando un programa no tiene licencia. La licencia dicta lo que se puede, y se debe hacer con ese código. Para ello el autor debe poner claramente, bajo qué licencia publica su código. Pues si no pone nada, no se sabe si es libre o no.

Para solucionar este problema se creo la GPL. Básicamente lo que obliga esta licencia es a preservar que un programa sea siempre libre, de tal manera que las versiones modificadas, cuando sean publicadas deberán ser también GPL.

Ahora que estaban sentadas las bases del Software Libre, en abril de 1991 empezó a crearse Linux, el núcleo de un sistema operativo desarrollado por Linus Torvalds con 21 años, bajo licencia GPLv2.

Mientras Linux crecía de manera exponencial, se crearon multitud de empresas que utilizaban y apoyaban este movimiento. Pero poco a poco se vio que los ideales de la Free Software Foundation, eran demasiado restrictivos para el mundo empresarial/comercial. En 1998 se creó la Open Source Initiative, a raíz de la liberación del navegador web Netscape. Por aquél entonces Eric S. Raymond publicó La catedral y el bazar, analiza dos modelos de crear software libre, son las guías para el desarrollo de un proyecto libre. Junto con Bruce Perens, crearon esta iniciativa.

Entre todas las empresas que aparecieron, hay que dar una mención especial a Red Hat, ya que demostró que el uso de Software Libre puede hacer funcionar a una empresa económicamente. En agosto de 1998 salió a bolsa obtuvieron una gran posición.

Para mí, estos son los grandes, primeros hitos de la historia del Software Libre. Creo que con esto se demuestra la filosofía con la Free Software Foundation, la aplicación con el núcleo Linux, la GPL y la OSI, y los beneficios que puede tener una empresa como RedHat.

Como recomendación para ampliar más información, recomiendo este documental REVOLUTION OS y la publicación de Richard M. Stallman Free as in freedom.

KDE

Kool Desktop Environment, así es una de las grandes alternativas al de entorno de escritorio para Linux. La famosa K proviene de CDE de Sun Microsystem, el que hasta entonces era lo que se usaba.

KDE es Software Libre, es obligatorio que toda aplicación incluida en KDE sea libre. Este concepto lo tienen muy claro, porque KDE se basa en el toolkit gráfico Qt, básicamente porque el creador , Matthias Ettrich, estaba trabajando con esta tecnología. Cuando empezó a crearse este proyecto, Qt era propiedad de TrollTech, y por entonces el código no era libre. Después fue comprado por Nokia y lo volvió a licenciar bajo LGPL. En el tiempo que no era Software Libre, es cuando apareció el proyecto Gnome, buscando esa libertad que no tenían con KDE.

No solamente KDE es un entorno de escritorio, son aplicaciones y además con capacidades multiplataforma, pudiendose usar tanto en Windows, Mac OS X o Linux. Por supuesto que esto aumenta la complejidad de la aplicación, pues cuando se desarrolla pensando en multiplataforma, hay que tener en cuenta los elementos característicos de cada Sistema Operativo. En Windows, el sistema de ficheros tiene como raiz en la mayoría de los casos C:/ pero esto no es viable en Linux, en el que la raiz es /. Por eso hay que utilizar las herramientas de la API creadas para todos los Sistemas Operativos compatibles, y realizar llamadas a esas funciones, que ya se encargará de reconoce en que sistema se encuentra y qué parámetros deberá utilizar. 

También hay que recordar que como plataforma compatible están Maemo y Meego, Sistemas Operativos para dispositivos móviles, impulsadas por Nokia, sobretodo Maemo, del que existen en venta unos pocos terminales.

Matthias Ettrich

KDE empezó en Octubre de 1996, por  Matthias Ettrich. Un año después, en Agosto de 1997, se realizó el primer meeting para organizar todo lo creado hasta entonces, KDE ONE. Poco después se consolidó KDE e.V. asociación sin animo de lucro que sirve para coordinar las subvenciones y donaciones recibidas. Posee la única empleada de todo KDE.

En Abril de 1998 se crea la KDE Free Qt Foundation, cuya principal misión es si alguna vez Nokia decide cerrar Qt, esta fundación de mantener un fork de la última versión libre bajo licencia BSD.

En Julio de 1998 aparece KDE 1.0 y en Septiembre del mismo año, se libera Qt bajo GPLv2.

en Octubre de 2000 aparece KDE 2, después de otros dos años, en Octubre de 2002 aparece KDE 3. Por lógica parece que en el 2004 debería aparecer KDE 4, pero no fue hasta el 2008 cuando apareció KDE 4. Cada versión ademas corresponde a una nueva versión de Qt, y en el último cambio fue muy drástico, pues Qt cambió mucho internamente, y tuvieron que trabajar mucho para cumplir con estos cambios. A pesar de su esfuerzos, KDE 4 se la recuerda por sus numerosos fallos, que posteriormente fueron corrigiendo en siguientes versiones.

La numeración de las versiones tienen el modelo KDE x.y.z donde:

• x pertenece a un gran cambio.
• y un cambio menor.
• z versiones parcheadas.

La licencia que tiene hoy dia KDE son  LGPLv2, BSD, MIT, X11 y su documentación está en FDL. Qt   mantuvo durante mucho tiempo la filosofía de su licencia propietaria QPL, que permitía usar sus librerías, siempre y cuando no comercialices tu software, si deseas comercializarlo debías pagar la licencia y te daban soporte.

La comunidad realiza varias actividades, entre ellas las KDE Developer Meetings, cada año se realiza una, desde 1997. Con el tiempo paso a llamarse aKademy. También se hacen meetings de subgrupos como por ejemplo el de KDEEDU. Se destaca el aKademy de 2009 por realizarla conjuntamente con Gnome.

Como en otros proyectos similares, existe la meritocracia, pero dejan de lado la figura del dictador benevolente. Existen listas de correos, foro y chat en irc.freenode en el canal #KDE, para una buena comunicación con gente interesada en el proyecto.

Para obtener el derecho a commit, no es tan estricto como en otros proyectos. Aqui hace falta una persona que te avale dentro del proyecto, y también hayas contribuido previamente con parches.

No solamente necesitan programadores, pues también necesitan traductores, artistas gráficos, testers, escritores para documentar o promotores para dar marketing.

Existen empresas que gracias a KDE realizan su labor, como por ejemplo Kolab Konsortium que desarrollan un servidor de tipo LDAP, para compartir contactos , correo...

Toda esta información fue extraida gracias a la charla de Aleix Pol González que pertenece a KDE España, que dio en el Máster en Software Libre 2010/2011. Podéis ver los videos de la charla en los siguientes enlaces:

http://blip.tv/mswl/casos-de-estudio-ii-kde-parte-i-4812873

http://blip.tv/mswl/casos-de-estudio-ii-kde-parte-ii-4812920

The Corpora - Qbo

The corpora es una empresa robótica de España, creada en el 2006 por Francisco Javier Paz entusiasta de los robots y experto en seguridad informática, vino a una sesión del Máster en Software Libre a presentarnos su proyecto, Qbo.

Francisco Javier Paz - Qbo

Qbo quiere romper con el modelo que se está siguiendo hasta ahora sobre la comercialización de robots. Actualmente, las empresas que se dedican a la fabricación o el desarrollo de robots asumen todo el gasto generado para crear el robot. 

El material con el que se fabrica es muy caro, el molde para crear una pieza en producción tiene un coste aproximado de 30000€, en el caso de Qbo, tiene 35 piezas. Cierto es que para el desarrollo se utilizan prototipado rápido con una calidad muy inferior a la final. Por otro lado tenemos el coste en I+D, los ingenieros encargados de que todo eso no sea solamente un montón de hierros con circuitos, creando la lógica y cómo se va desenvolver con el entorno. Estos costes incrementan el valor del producto, para que sea rentable y causa que mucha gente no compre un robot, solamente por el precio final en el mercado, como es el caso de Sony con el robot-perro Aibo con un coste final alrededor de 3500€.

Con Qbo se plantea un nuevo modelo de mercado, solamente venden la caja, esto puede ir dirigido a fabricantes que quieran incluir sus modificaciones y su lógica para después venderlo, o para usuarios finales, que deseen crear un robot a su medida.

El hardware está basado en Arduino, tiene una gran comunidad trabajando detrás. Permite adaptar todo lo que queramos. Se basa en un chip con un lenguaje de programación (Basado en C) y a partir de este chip, se van añadiendo componentes, como por ejemplo una webcam, GPS...

 

Por software lleva Linux como núcleo. ROS como sistema de control, framework. Festival para el habla sintética. Julius como reconocedor de voz, aunque le falta un modelo acústico y se ha creado VoxForge para colaborar con tu propia voz en el proyecto. OpenCV es una libreria para el reconocimiento espacial, reconoce objetos y su profundidad, de esta manera hace slam alrededor de donde se encuentra y crea un mapa interno.

Aparte de utilizar componentes libres y software libre, donde reside toda la "magia" del proyecto es en su sistema para gestionar la base del conocimiento. Esta base es la que se encarga de la lógica del robot, donde va a consultar ante cualquier elección que deba tomar. Su modelo en especial es que está en la nube, por lo que todo lo que aprenda un robot, o le enseñen, estará a disposición del resto de robots, pudiendo tener el mismo conocimiento al mismo tiempo.

Este modelo es totalmente innovador y muy útil. Pongámonos en el papel de ASIMO este robot tiene un desarrollo lógico que está creado por CMLabs. Ellos programan la lógica, pero ¿Que pasa si hay un caso de uso que no habían pensado?, se quedarían todos los robots sin ese conocimiento hasta que no recibieran una actualización por parte de ellos. Y lo peor de todo es que hay otras empresas como esta, que crean su lógica y no la usan nada mas que para un dispositivo en concreto.

La idea es clara, un modelo cerrado en el mundo de la robótica, no da y no ha dado sus frutos. Este cambio fomentará al uso de estas tecnología, a mejorarla entre todos (Crowdsourcing), y a un precio asequible. Por que no es lo mismo desarrollarlo sin tener el hardware que con él.

Los videos de la presentación los podéis encontrar en:

http://blip.tv/mswl/casos-de-estudio-ii-the-corpora-parte-i-4851272

http://blip.tv/mswl/casos-de-estudio-ii-the-corpora-parte-ii-4851391

Gnome, historia y comunidad

Para entender el porqué de la existencia de este gran proyecto de Software Libre, que ha creado un modelo a seguir y del que aprender debemos remontarnos al principio de sus orígenes.

1995, apareció Windows 95. Fue el gran éxito de Microsoft, consiguieron llevar a casi todos los ordenadores del mundo su escritorio.

1996, empieza Matthias Ettrich a crear KDE por la necesidad de crear un entorno de escritorio para Unix

1997, se anuncia Gnome.

A pesar de que existía una herramienta de escritorio, KDE tenía problemas de licencia. Todo depende de Qt, una librería gráfica usada en este entorno de escritorio, por aquel entonces no era Software Libre, pertenecía a Troll Tech, y posteriormente pasó a Nokia y ahora... ¿Microsoft? Con Gnome, querían mejorar y crear una alternativa de interfáz gráfica de escritorio carente en UNIX. Hasta entonces se utilizaba X-Window de tal manera que cada aplicación quedaba muy aislada, manteniendo una interfaz poco homogénea.

También se buscaba integrar aplicaciones tal y como hace Windows, que viene integrado un reproductor de video y audio, gestor de correo, buscaminas... :P

              

 

Federico Mena

Miguel de Icaza

¿Y quienes empezaron con todo este lio? Uno de los responsables fue Miguel de Icaza, por aquel entonces tuvo cierto contacto con Microsoft donde le fascinó tecnologías como ActiveX. Quería transladar esta tecnología al mundo UNIX, asi que se juntó con su compañero de estudios Federico Mena.

Para comenzar este gran proyecto, se intentó no partir desde cero, ya que jugaban con gran desventaja, KDE y Windows llevaban mas tiempo cuando esto todavía no había empezado. La reutilización es uno de los paradigmas del Software Libre, así que decidieron contactar con Troll Tech para que cambiaran la licencia de Qt. No recibieron respuesta...

Necesitaban un toolkit gráfico, Federico trabajaba en el proyecto The Gimp, este software tiene su propio toolkit, asi que manos a la obra, separaron este componente del resto de la aplicación y nació GTK Gimp ToolKit.

A partir de entonces empezó a expandirse, en Agosto de 1997 se anuncia oficialmente a la comunidad. fueron sacando versiones en las que destaco la 0.20 por ser la primera en poder distribuirse. La versión 0.99 apareció casi un año después de anunciar en Noviembre de 1998, y poco después en Marzo de 1999 apareció la versión 1.00, fue un desastre porque por aquél entonces, tenían una guerra de versiones, en la que Gnome era la que menor versión tiene y creían que podría parecer un software inferior. Por esto emprezaron a utilizar el nombre de los meses como identificador de versión, October Gnome... pero al pasar un año, vieron que esta estrategia no era muy factible.

En Marzo de 2000 se celebra la primera Guadec en Paris. Un punto de encuentro  de usuarios y desarrolladores de Gnome.

Agosto de 2000  se crea la fundación Gnome apoyada por grandes empresas como IBM, Red Hat, Sun Microsystem (Oracle) y otras fundaciones como la Free Software Foundation.

Ya en Abril del 2001 se celebra la segunda Guadec en Copenague, y sale la versión 1.4 que traía novedades como Nautilus como gestor de ficheros, Evolution como cliente de correo, Abiword y Gnumeric como herramientas ofimáticas.

A pesar de todos los esfuerzos para crear un entorno para el usuario, aún era un entorno de escritorio demasiado hacker, demasiadas configuraciones, que para un usuario normal puede asustarle. Se realizaron estudios de usabilidad, accesibilidad para personas con discapacidad puedan usarlo, por ejemplo, utilizar un teclado en braile. Este estudio lo llevo acabo Sun Microsystem, y fue importante este hecho, pues que una empresa de gran tamaño, tiene mayor recurso, y no todo el mundo se puede permitir el hardware que hace falta para probarlo en condiciones reales. Todo esto se fue consolidando para salir en la nueva versión Gnome 2, junto con la Guadec de Sevilla. Con esta nueva versión se garantizo la retrocompatibilidad de la API / ABI con la versiones anteriores de Gnome. Aladidos como VFS, para  acceso a carpetas virtuales, Gobject es un sistema de orientación de objetos. GDKPixBuf para la carga y manipulación de imágenes. Fueron incluyendo más aplicaciones en cada versión hasta que llegó Gnome 3.

Al principio querían hacer coincidir la salida de la versión 2.30 como la versión 3, por el juego de números al correr la coma, y quitar el 2, nos da la versión 3. Pero aún no estaba preparado, no querían que ocurriera lo mismo que pasó con el lanzamiento de KDE 4.

Realizaron grandes cambios visuales, ahora utiliza Clutter como toolkit gráfico, con el que se puede realizar efectos 3D. Esto puede que en ordenadores más antiguos sea un problema, pues necesita de una aceleradora gráfica, aunque los problemas provienen sobretodo en los drivers para Linux de las tarjetas gráficas, no están lo suficientemente optimizados para que funcione fluido. A pesar de Clutter que nos sirve para los efectos visuales, no quiere decir que se abandona GTK, aparece la versión 3, con el que se rompe con la retrocompatibilidad. No quiere decir que no funciones aplicaciones en GTK2 sino que no podrán ejecutar componentes de diferentes versiones simultáneamente. El sistema de temas pasa a ser programado bajo CSS, una gran ayuda y facilidad para muchos desarrolladores web, acostumbrados a usar este estándar.Y empiezan a aparece características multitouch, que por ahora no se usan pero da una visión sobre donde podrá implementarse Gnome 3, como por ejemplo tablets o smartphones.

GNOME IS PEOPLE!

Después de hablar de la historia, no quiero cerrar el post sin hablar de las personas responsables de este proyecto, de la comunidad de Gnome. La comunidad está dividida en equipos, de los cuales existen de  desarrollo, traductores, documentadores, accesibilidad o Marketing. También existe la brigada de bugs que coordinan el bugzilla ahorrando trabajo extra a los desarrolladores. Existe una web centralizada con los recursos de comunicación, pero también puedes comunicarte a través de listas de correo, canales de char IRC. También existe una lista de aplicaciones incluidas en el entorno.

Existe la meritocracia por lo que a pesar de que exista cierta facilidad para dar tu opinión en listas de correo y demás, tiene mayor valor alguien que esté dentro del proyecto, y que haya colaborado previamente. Esto puede causar la ira de muchos Trolls dispuestos a flamear hilos de conversación, por eso se ha creado un código de conducta para evitar discusiones innecesarias.

Cualquier persona puede llegar a ser un committer del repositorio, para que alguien obtenga este permiso tiene que realizar una petición de cuenta, que por regla general es impulsado por el maintainer del modulo. Una vez obtenidos los permisos de commit no quiere decir que puedes subir cualquier código, debe ser revisado.

El maintainer es el encargado de un módulo, escribe las release notes, revisa parches para aprobarlos o rechazarlos, siempre explicando porqué y animando a que siga colaborando guiando qué cosas no fueron las correctas. Al final no dejan de ser dictadores benevolentes, ya que sus cambios no es obligatoriamente revisado.

Si quieres apoyar al movimiento puedes encontrar mas información en Gnome Hispano. Toda esta información ha sido recopilada gracias a las clases de Carlos García Campos realizadas durante el Master de Software Libre 2010/2011. Podéis encontrar los videos en los siguientes enlaces:

http://blip.tv/mswl/casos-de-estudio-ii-gnome-parte-i-4792190

http://blip.tv/mswl/casos-de-estudio-ii-gnome-parte-ii-4792249

Netiquetas

Cuando mantenemos un proyecto de Software Libre o nos queremos dirigir a una comunidad ya establecida, no debemos lanzarnos a escribir en sus listas de correo, foros o cualquier canal de  comunicación público, si no antes cuidar nuestro lenguaje, a quién nos dirigimos y si realmente nuestra consulta es necesaria. Cada caso tiene unas ciertas reglas que deberíamos preguntarnos antes de escribir y después de escribir.

Para dirigirse a en un BTS (Bug Tracking System), intentar describir como reproducir ese bug, leer las instrucciones del mismo BTS sobre como se debe reportar un error en este sistema, si tenemos diferentes errores abir diferentes hilos. No utilizar un BTS como un foro de discusión, y sobretodo, y quizás lo mas importante, buscar o tratar de encontrar si tu error no existía previamente.

El código fuente también debe cuidar el aspecto, hay que utilizar las estructuras comunes de guías de estilo para cada lenguaje. Cada persona tiene su forma de escribir su propio código, pero para que todo el mundo nos sea más fácil comunicarnos con nuestro propio código, debemos escribir siguiendo unos patrones de estilo. No se escribe igual un código en Java y otro en Python, debido a su sintáxis, su escritura también difieren.
Cuando hacemos commit en el repositorio oficial debemos cuidar que el mensaje sea lo suficiente claro y conciso, no debe ocupar mucho, para que al verlo se pueda identificar qué cambios se han realizado, sin tener que ir linea por linea comparando código.

Si dentro del proyecto, estamos en un nivel jerárquico que nos posiciona como committers, y todos los parches deben ser aprobados por nosotros, como un dictador benevolente, debemos cuidar la manera de dirigirnos ante la persona que nos envía un parche. No todo el mundo tiene el mismo nivel sobre el proyecto, si por alguna razón, su parche es rechazado, cuidaremos nuestro lenguaje, pues la persona al otro lado, puede sentirse muy ofendido, y existen casos en los que con mucha razón. Un clásico ejemplo es el de Linus Torvalds https://lists.linux-foundation.org/pipermail/desktop_architects/2005-December/001588.html pues no cuida sus formas.

Estas y muchas más reglas fueron descritas por primera vez en el RFC 1855 . Más adelante, este tipo de personas o actos fueron tomando nombres, creando una jerga hacker, en las que podemos encontrar palabras como:

Flame: Término para describir una discusión sin sentido dentro de un foro o lista de correo.
Troll: Persona que dedica esfuerzos a crear Flame.
Lamer: Persona que a pesar de no tener un alto conocimiento técnico, presumen de tenerlo para tratar de tener fama.

Forjas, ¿Dónde alojar tu proyecto de software?

Cuando empiezas con un proyecto de software, no pensamos donde vamos a almacenar ese código que vamos escribiendo. Pero cuando llega el momento en el que decides liberar todo ese trabajo con el que te has peleado, para poder ayudar a otras personas con tu esfuerzo, necesitas un lugar para que el gran público pueda verlo, descargarlo, modificarlo y ejecutarlo. Para eso nacieron las forjas.

A continuación detallo unas forjas de las que he tenido experiencia:

Google Code

Uno de los grandes para empezar. Google cuenta con esta forja que permite subir proyectos. A pesar de tener mucha fama a nivel internacional, cuenta con una serie de limitaciones:

• Sistema de control de versiones: Subversion o Mercurial. No es que me parezcan pocas pero creo que mucha gente hecha en falta Git.
• Licencias permitidas:  Apache, Artistic, BSD, GPLv2, GPLv3, LGPL, MIT, MPL y EPL aunque puedes utilizar cualquiera que esté aprobada por la OSI. Creo que es suficiente, aunque no deja de ser una pequeña limitación.
• El número de proyectos que puedes alojar por persona, es de 25.
• Desde ciertos paises no puedes acceder a esta herramienta,  Cuba, Iran, Libia, Corea del Norte, Sudan y Siria. 
• Google Code no es libre, por lo que no podremos montar nuestra propia forja al estilo Google.

Como ventaja, es la API que incluye, con la que podrás integrar fácilmente otros productos de Google como Analytics. Permite crear una Wiki por proyecto.

Github

Uno de los repositorios con control de versiones Git más famosos. Al igual que la forja de Google, los proyectos que subamos, deben tener una licencia de Software Libre. Pero en este caso permite crear repositorios cerrados pagando una cuota. Se detacan su fácil y agradable interfaz para navegar por partes del código públicado. No es Software Libre, pero nos facilitan su propio repositorio con gran cantidad de  software liberado de sus recursos, como la creación de wikis, la API o la forma de colorear la sintaxis de código.

Morfeo Project

Forja de ámbito nacional, la conocí gracias al contacto con Cenatic, donde mantengo alojado mi proyecto visor ODF para Android. La mantienen varias entidades como Telefónica, GSyC/LibreSoft,  Universidad Rey Juan Carlos (URJC), Universidad Politécnica de Madrid (UPM), Cenatic entre otros, y forman parte del centro de competencia Qualipso. Quizás no cuente con el estilo visual que competidores de la talla de Google, pero es un buen punto de partida para dar a conocer un proyecto dentro del ámbito nacional.

Por supuesto, existe una gran cantidad de forjas que no he mencionado, y de las que existe una buena tabla comparativa en Wikipedia: http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities

Caso de éxito: Ayuntamiento de Zaragoza

Acabo de empezar la nueva asignatura sobre implantación en el Máster en Software Libre. Para ir abriendo boca, sobre lo que tratará la asginatura, nos estuvieron explicando como se está migrando el ayuntamiento de Zaragoza hacia Software Libre.

Todo empezó en el 2005 por una acuerdo entre partidos políticos, decidiera realizar este paso. En un primer momento, como suele pasar en estos casos, es hablar del ahorro en el coste de las licencias. Es un punto con el que no hay que discutir con nadie, pues todo el mundo está de acuerdo en tener lo mismo de manera gratuita. Pero es importante saber que en una fase inicial de una migración, no se debe recortar por completo el desembolso que se realizaba en la compra de licencias. En la primera fase hay que utilizar ese coste para modernizar equipos, dar formación y subvencionar a las personas encargadas de dar soporte.

No olvidemos que es una migración, esto quiere decir inevitablemente un cambio. Este cambio en algunos aspectos puede ser drásticos, pero en otros no. En la migración del ayuntamiento de Zaragoza decidieron crear varias fases de migración. Lo primero es saber de qué es lo que se dispone. Tanto el software que se utiliza actualmente como el hardware, son esenciales para ver en qué debemos invertir al principio.

Tras analizar lo que tenemos a disposición y en uso, fue hacer una migración "ligera". Es decir, buscar Software Libre con versión tanto para Windows como para Linux. Hay una gran cantidad y que es usada a diario. De esta manera, los usuarios pueden empezar a introducirse con pequeños cambios, como puede ser sustituir Internet Explorer por Firefox, Outlook por Thunderbird, Windows Media Player por VLC...

Aunque no todas las aplicaciones son fáciles de migrar. Es el caso de la solución ofimática. El claro cambio es pasar de Microsoft Office a OpenOffice. Esta parte es dificil, pues el formato con el que se guarda los documentos de Office, es totalmente cerrado. Como resultado, muchos documentos no se ven como "se deberían ver" en OpenOffice, ya que por ingeniería inversa, se ha conseguido parsear formatos nativos de Office. Por otra parte, no tenemos que olvidar las macros, escritas en Visual Basic en los sistemas Microsoft Office y OOBasic para los de OpenOffice, de los que se tuvieron que reescribir gran parte de las macros para su correcto funcionamiento.

Aqui entra en juego, algo por el que toda sucursal del gobierno debe ir planteándose migrar, pues por decreto, toda documentación que sea emitida hacia el ciudadano de manera electrónica, deberá estar en un formato abierto.

Durante este proceso de adaptación, se deben formar a los técnicos que darán soporte una vez realizada la implantación.

Una vez preparado todo el software compatible tanto en sistemas privativos como libres, se necesita dar un paso muy grande, cambiar el Sistema Operativo. Para ello crearon una propia distribución AZLINUX. Que tiene como base OpenSUSE. Es  importante esta base, pues dentro del kernel compilado ofrecido por Novell, contiene un elemento fundamental para la integración con la red del ayuntamiento, Novell Directory Service NDS.

¿Porque es necesario este componente? Es debido a que la migración, no solamente en este caso, en la mayoría de los casos, se parte de sistemas cerrados en los que muchos usuarios ya están acostumbrados a su uso. Ya sea por resistencia al cambio, o por sencillamente, no cambiar por su correcto uso, hay cierto software que no se puede migrar tan fácilmente. Por eso contamos con herramientas como WINE, capaza de emular las librerias y capas lógicas de Windows, para que podamos ejecutar aplicaciones de Windows en sistemas Linux.

Ha sido muy grata contar con una experiencia real de una migración tan masiva como la que está sucendiendo en el Ayuntamiento de Zaragora. Durante este transcurso, en su blog como en su Twitter @azlinuxzgz nos tienen al dia de recursos y documentación muy práctica y a tener en cuenta para futuras migraciones.