Shell


Para la mayoría de personas, cuando un informático hace aparición en sus vidas, los ven como a esas personas que para hacer funcionar cualquier cosa, se sientan delante de la pantalla y se ponen a teclear cosas. Es decir, que todo lo que hacemos, si no es de la Shell (o también conocida como la linea de comandos) no somos verdaderos informáticos. Algo de razón tienen, pero realmente ¿Es tan importante utilizar la Shell?

Exactamente una Shell no deja de ser una aplicación mas del Sistema Operativo, pero tiene ciertas particularidades, entre las mas importantes, es la primera que se ejecuta cuando el usuario inicia sesión. Puede ejecutar otras aplicaciones tanto en segundo plano como compilar el Kernel de Linux, para que podamos realizar otras tareas o en primer plano, como por ejemplo un juego.

Para definir la importancia de que sea el primer programa que se ejecuta al inicio de sesión debemos remontarnos al inicio del sistema. Resumiendo, lo que primero que hacemos es pulsar el botón de encendido de nuestra máquina (O mediante Wake On LAN). La BIOS entonces tomará control del hardware, dependiendo de cómo este configurado buscará un dispositivo que contenga un MBR con el que inciar, puede ser un disco duro, un disco o un pendrive. Este a su vez apuntará a una partición que contenga un cargador de arranque, en Linux es utilizado comúnmente GRUB o LILO. Y lo primero que hará es cargar el Kernel, que desplegará todo el resto de programas gracias al proceso init. Después de realizar los procesos de inicio, llega la pantalla de acceso en el que debemos introducir usuario y contraseña para que haga la comprobación de credenciales, comparándolo con el contenido de /etc/passwd. Si es correcto lanza la aplicación /bin/bash



Al final la Shell es un programa más, y como todo programa, existen multitud de versiones y de variedades. La más famosa es Bash ya que viene incluida en la mayoría de distribuciones Linux, pero también en Mac OS X y ha sido portado a Windows gracias  a Cygwin.

Ken Thompson a la izquierda
La primera Shell que se  publicó fue la Thompson Shell,  desarrollada por Ken Thompson en 1971. Es una Shell muy sencilla, podía hacer redirecciones y pipes, como por ejemplo sacar la salida de un programa hacia un fichero.


Stephen Bourne
En 1977 apareció Bourne Shell, desarrollada por Stephen Bourne. Fue mayormente conocida como sh,consiguió desbancar a la Thompson Shell. Como principal caracteristica es que está orientada a la programación y tenía la capacidad de enviar señales (Ctrl + c). Aún se sigue utilizando como la Shell por defecto del usuario root.


Bill Joy
A pesar de ser escrito en 1978, C Shell, no se popularizó hasta los 80 y como indica su nombre está escrita en C. Bill Joy, además de escribir esta Shell múltiplataforma es el fundador de Sun Microsystem. Como mejora a destacar es el historial de comandos, alias y autocompletado de comandos, que sin duda fue la killer feature de esta Shell.

Tenex C Shell, también conocida por tcsh es una Shell compatible con C Shell. Desarrollada por Ken green en 1975. Mejoraba el autocompletado, incorpora UNICODE para la codificación de caracteres. Es la shell por defecto de tipo BSD, la FreeBSD, DragonflyBSD y DesktopBSD. Es la favorita por muchos programadores.

Korn Shell se presentó en 1983, por AT&T Bell Laboratories. Respeta el estándar de leguaje de Shell (POSIX). Durante 17 años fue propietario, y fue en el año 2000 cuando se liberó bajo una licencia pública de AT&T, pero en el 2005 se ha licenciado bajo Common Public Licens. Es por esto que se crearon alternativas como pdksh, mksh... pdksh es la shell por defecto de OpenBSD. Ha dado pie a otros proyectos, otros proyectos tomaron este código para pequeños proyectos, pues es muy compatible con otros. mksh es usada en Android.

Brian Fox
La Shell más famosa es Bash, que proviene de Bourne-again shell, publicada en 1989 por Brian Fox. Tiene las ideas de todas las anteriores, pero permite programar funciones. Viene con la mayoría de distribuciones GNU/Linux y  Mac OS X 10.

Z Shell o zsh, es la Shell más moderna, escrita en 2007. Es el Proyecto de doctorado de Paul Flastad,  y el nombre viene en homenaje a su profesor Zhong Shao de la universidad de Princenton, pues su nombre de login es zsh. Destaca por la correción automática, es completamente configurable. Muy utilizada por programadores.

Después de dar un repaso por varias Shell, ¿Cómo podemos utilizarlas? Muy fácil, simplemente nos lo instalamos desde los repositorios. Por ejemplo, si queremos instalar zsh desde una distribución basada en Debian:

sudo apt-get update && sudo apt-get install zsh
 Una vez instalado, lanzamos la Shel mediante el comando zsh. Pero si queremos saber que Shell se ejecuta con el sistema, basta con escribir:


ls -l /bin/sh

Kernel Linux



Ya han pasado 20 años desde que este "pequeño" proyecto personal fuera comunicado al mundo un 25 de Agosto de 1991. Tal y como muchos proyectos de Software Libre, todo empezó como una idea personal. Pero acabó siendo quizás el proyecto de mayor relevancia en la historia tanto del Software Libre como de la informática.


El nombre de Linux proviene de su creador Linus Torvalds de Finlandia, que a sus 21 años de edad, quiso realizar un Sistema Operativo similar a Unix. Con la ayuda del código que Tanenbaum desarrolló en Minix, pudo crear una base que ejecutara programas sobre arquitecturas de 80386.

Desde la primera versión 0.01, que inicialmente tuvo como nombre inicial Freax, contaba con 10239 líneas de código, pasando de los 14 millones de líneas de código que tiene actualmente.

Sobre la robustez del código, se han realizado estudio sobre la fiabilidad del código. Coverity, empresa dedicada al testeo de seguridad, realizó un estudio a la versión 2.6 del kernel, como resultado se obtuvo 985 bugs en 5,7 millones de líneas de código. A pesar de la alarmante cifra, si comparamos con cualquier software comercial, la cifra está entre 20 y 30 bugs por cada mil líneas de código, unos 114000 bugs en 5,7 millones de líneas.

A pesar de la gran cantidad de contribuidores, más de un millar de empresas colaboradoras, no quiere decir que no sea un software robusto. Es la experiencia de cada contribuidor, el que hace que el kernel sea tan estable.



La arquitectura es de tipo monolítico, esto hace que la ejecución de todos o su mayoría de servicios del sistema se encuentren en el mismo espacio de direcciones. Es decir, que están dentro del código, esto provoca mejor rendimiento, pero también puede provocar mayor inestabilidad.
Por contrapartida, existen los microkernel, en el que la ejecución de servicios del sistema se hacen en el espacio de usuario como servidores. Es menos complejo, más portable y mantenible. Un ejemplo de microkernel es Minix.

Esta diferencia de arquitectura provocó una gran discusión entre los creadores de ambos sistemas, pues por aquella época, en 1992, Tanenbaum acusaba a Linux de estar obsoleto.

En el kernel de Linux, como en otros Sistemas Operativos existen los módulos, que dan soporte a nuevo hardware, sistema de archivos o incluir nuevas llamadas al sistema. Para trabajar con éstos módulos existen una serie de herramientas llamadas LKM tools que componen las siguientes aplicaciones:


  • lsmod: Listar los módulos cargados.
  • insmod: Cargar un módulo en memoria. Se encuentra en la ruta /lib/modules
  • rmmod: Quitar un módulo de la memoria.
  • modprobe: Usa el fichero de depencias para saber cual hace falta de verdad. Con  modprobe -l podemos sacar una lista de las dependencias.
  • depmod: Crea un fichero de depencias. depmod -a , para regerenar el listado de dependencias. y ser guarda en /lib/modules/$(uname -r)/modules.dep
  • modinfo: Da información detalla sobre un determinado driver. $ modinfo module_name (sacado de lsmod)
Existe también una lista negra de módulos, pues si no queremos cargar cierto módulo por incompatibilidad con el hardware, lo debemos incluir en este directorio: 

/etc/modprobre.d/

o en el siguiente fichero de configuración:

/etc/modprobre.conf

Muy bien, pero... Quiero la última versión del kernel. Existen veces que te compras un ordenador nuevo, y puede que ciertos componentes no funcionen con tu distribución habitual. ¿Cómo solucionar esto? Compilando la última versión del kernel.

Primero necesitamos las herramientas para compilar, para ello debemos descargarnos los siguientes programas:

gcc , binutils, build-essentials, kernel-package, libncurse5-dev

Por ejemplo, desde una distribución basada en Debian sería los siguientes comandos:

sudo apt-get update
sudo apt-get install gcc binutils  build-essential kernel-package  libncurses5-dev 

Una vez que tenemos las herramientas, necesitamos el kernel, nos lo descargamos de la web oficial del kernel, kernel.org

La mejor opción es descargarnos la última versión estable, aunque si queremos lo último siempre podremos utilizar una Release Candidate, marcadas con rc. A la fecha de este post, la última versión es la 3.1.1

Una vez descargado debemos descomprimirlo


sudo tar -xvf linux-3.1.1.tar.bz2 -C /usr/src/


Y ahora vamos donde lo descomprimimos en:


cd /usr/src/linux-3.1.1/

Ahora podemos modificar la configuración del kernel gracias a la herramienta menuconfig

sudo make menuconfig


Esto nos brinda la posibilidad de marcar o desmarcar módulos que nos interesen o que no deseamos que carguen porque sabemos que no lo vamos a necesitar. Puede ser un arma de doble filo, pues si sabemos configurarlo correctamente, tendremos un kernel más ligero y con lo justo para funcionar. Pero si no ponemos todo lo que necesita podremos quedarnos con una distribución que no arranque.

Si no estamos muy seguro de que hacer en este caso, siempre podemos utilizar:

sudo make oldconfig

Con esto creará una configuración como la del kernel que te esta funcionando actualmente, así nos aseguramos de que va funcionar correctamente.

Una vez que guardemos el fichero de configuración, pasamos a compilarlo. Tan sencillo como:

sudo make -j8

Dependiendo de vuestro ordenador tardará mas o menos.



Después de compilar necesitamos instalarlo:

sudo make modules_install install

Esto creará unos ficheros en el directorio /boot/ del tipo:

cd /boot/
ls -la | grep 3.1.1


  • System.map-3.1.1
  • vmlinuz-3.1.1
  • initrd.img-3.1.1
  • config-3.1.1
En caso de no encontrar ningún fichero con un nombre similar a la versión de nuestro kernel, debemos utilizar:

sudo update-initramfs -u -k 3.1.1

Esto pertenece al Initial RAM disk (initrd), son una serie de ficheros usados en el proceso de arranque del kernel. Básicamente montan el sistema de ficheros raíz.
Si el comando anterior no nos ha actualizado o generado un fichero initramfs, debemos crear uno nuevo  con:

sudo update-initramfs -c -k 3.1.1

Por último, este comando nos ha generado una nueva configuración del sistema de arranque grub, si  lo deseamos modificar, podemos hacerlo directamente desde:

sudo vim /boot/grub/grub.cfg

Pero si finalmente queremos aplicar la configuración debemos utilizar:

sudo update-grub

Ya solamente queda reiniciar y a disfrutar!




MySQL


Es muy difícil encontrar hoy en día a alguien que no conozca MySQL o no haber utilizado alguna web que albergara información con este software, TYPO3, Joomla, WordPress, Drupal, Twitter o Wikipedia son parte de una gran lista de ejemplos. Pero muchas veces usamos software sin investigar cómo ha sido su desarrollo o qué es lo que hace tan especial a este sistema de gestión de bases de datos.


Se desarrolló por David Axmark y Michael Widenius por la empresa MySQL AB, una empresa sueca dedicada al Software Libre desde 1995. SQL es el lenguaje desarrollado en 1981 por IBM y que se convirtió en estándar en 1986 gracias a la publicación SQL-86 hecha por ANSI. Michael estaba creando rutinas de bajo nivel para conectar bases de datos, trató de usar mSQL, por entonces era lo más eficiente, pero no lo suficientemente rápido y flexible para sus necesidades. Por lo que creó una API basada en SQL, y cuyo nombre contiene el nombre de la hija de  Michael, MySQL.

Desde que el 23 de Mayo de 1995 apareciera la primera versión interna, fueron expandiendo su software a diferentes arquitecturas y Sistemas Operativos. Tras 13 años de mejoras y con la versión 5 en marcha, el 26 de Febrero de 2008, Sun Microsystems compra MySQL AB por la cifra de 1 billón de dólares. Ahora Sun Microsystems fue comprada por Oracle el 27 de Enero de 2010, y con ello MySQL pertenece a Oracle. Gracias a esta compra, Oracle es hoy por hoy la empresa con el software de bases de datos más importante, pues cuenta con un negocio corporativo desde hace mucho tiempo, y su única competencia era MySQL.

Esta compra, creo una gran controversia, incluso apareció un movimiento llamado "Save MySQL" promovida por Widenius por el temor de que Oracle dejase abandonado el desarrollo de MySQL y se centrara en su linea de negocio privativo como viene siendo habitual. Finalmente se continuará con un sistema de doble licencia, comercial y GPL. De igual manera, como es habitual en esto casos, se realizó un fork llamado MariaDB.

Como modelo de negocio, existe MySQL Enterprise, es un servicio de suscripción y está orientado a un mercado profesional.

Si queremos empezar a utilizar MySQL, es muy fácil. Desde una distribución basada en Debian, podemos usar desde la linea de comandos:

$ sudo apt-get install mysql-server
Con este sencillo comando podremos instalar el servidor de base de datos. Durante la instalación nos pedirá que introduzca una contraseña para el usuario root de la base de datos.


Una vez instalado, desde la linea de comando podremos acceder mediante el siguiente comando:

$ mysql -u root -p
Introducimos la contraseña que introducimos anteriormente, y ya estamos dentro de la consola de MySQL. Desde aqui podremos hacer todo tipo de operaciones. Entre las más básicas se encuentran:

Ver en una lista, las bases de datos que almacena MySQL:
show databases;
 Buscar cuales tienen una letra s en su nombre:
show databases like "%s%";
 Utiliza la base de datos de nombre mysql:
use mysql;
 Muestra las tablas de la base de datos activa:
show tables;

Pero también se pueden realizar acciones sin necesidad de entrar a la consola de MySQL, directamente con el comando mysqladmin :

Crear una base de datos con el nombre olidroide:

mysqladmin -u root -p create olidroide
Eliminar una base de datos con el nombre olidroide:
mysqladmin -u root -p drop olidroide
Mostrar los parámetros de configuración que utiliza la base de datos, las caches y el sistema de codificación entre otra información importante:
mysqladmin -u root -p variables



Puede que la linea de comando no resulte atractiva para ciertos usuarios. Existen herramientas gráficas que ayudan el uso y la gestión de este tipo de bases de datos. Por eso existe MySQL Workbench, integra en una sola herramienta desarrollo, administración y diseño de bases de datos. Personalmente creo que es una herramienta muy completa y bastante estable. El hecho que sea multiplataforma ayuda para no tener problemas de desarrollo en cualquier entorno.

Es muy sencillo de instalar, todos los pasos y mas detalles se pueden encontrar en su web: http://wb.fabforce.eu/

Todos nos beneficiamos con el Software Libre

Muchas veces, parece como si el que mayor beneficio saca del Software Libre es el usuario final. Mucho software se hace para ayudar con una necesidad generalizada. Pero a pesar de esta premisa, el usuario final somos todos, pues que el se libere un programa afecta al usuario final, al desarrollador y al integrador.

Usuarios finales

Como producto final del que vamos a disfrutar, podemos asegurar que utilizando Software Libre evitaremos monopolios. Todos tienen el acceso al código, pero cada empresa un interés único, esto puede crear una competencia real. Como por ejemplo el caso de dos entornos de escritorio famosos, Gnome y KDE, al que podemos sumarle ahora Unity, integrado en las próximas versiones de una de las mas famosas distribuciones Linux, Ubuntu.

Confianza, aunque como en la mayoría de los casos, depende del éxito del programa, siempre podemos decir que tener acceso al código, nos permitirá modificarlo tanto para adaptar nuevas necesidades como exportar datos para portarlo a otro programa. Imaginemos un programa de contabilidad, que dejara de mantenerse por cualquier razón. En este caso podríamos obtener los datos para pasarlo a otro programa de contabilidad. Nos podemos olvidar de cajas negras en las que introducimos datos, se procesan "mágicamente" y nos devuelven resultados, sin saber que ha pasado entre medias.

Todo programa libre como cualquier otro programa, debe ser probado antes de su salida oficial. Pero en el caso del Software Libre podemos predecir que ese programa ha sido testeado en un entorno real, porque el acceso a programas libres es más económico, sin versiones de prueba o por tiempo limitado. Libre de probar y si no te gusta utilizar otro.

Desarrolladores

Oportunidad de competencia, aún teniendo pocos recursos. No es necesario invertir en costosas licencias  para ver que al final no cumple con lo que necesitas para desarrollar. Como se decía antes, se prueba y si no te convence, utilizas otro o lo adaptas.

Tomar ventaja respecto a tus competidores, pero con un previo análisis, pues si partimos de una misma base, no es bueno acabar haciendo lo mismo. En ese caso, es mejor la colaboración con un proyecto.
Los canales de distribución son baratos y globales. Ofrecer un proyecto de Software Libre es ofrecer un repositorio de donde cualquiera pueda obtenerlo, poder ejecutarlo o poder distribuirlos.

Podemos obtener beneficios sobre las modificaciones de dicho software para posteriormente venderlo. Un caso muy práctico es el uso de los desarrolladores web que utilizan Apache para montar un servidor, PHP como herramienta de desarrollo, y posteriormente utilizar una base de Drupal para montar una web. En todo momento está usando software, y no por ello no deja de cobrar por el servicio, que es hacer la página web. Pudiendo además, durante el desarrollo encontrar fallos que reportar o incluso arreglar para ser devueltos a la comunidad.

Integradores

Todo el Software Libre está a su disposición. Si un programa no se ajusta al resto, siempre existe la posibilidad de adaptarlo, el código fuente está disponible. Partes de software pueden ser integrados, no es necesario integrar el software completo. Tal como decía antes, no hay cajas negras, si deseas integrar una serie de software, siempre podrás analizar los parámetros que  entran en el programa y ver su proceso.

Calidad en el Software Libre

¿Cómo podemos medir la calidad en el Software Libre?

Es un gran problema, porque la percepción de calidad es diferente para cada persona, los intereses de uno son completamente diferentes al del otro. Pero si que podemos definir una serie de aspectos que pueden ayudarnos a decidir porqué un software es de mejor calidad que otro.

Eficiencia, porque debe cumplir con todos los requerimientos planteado previamente, utilizando los recursos mínimos necesarios para dicha tarea. Se puede medir concretando previamente las necesidades que va a suplir el software y comprobar posteriormente si las cumple.

Reusabilidad, es la capacidad con la que está desarrollado el software para que pueda ser utilizado en otras funciones o proyectos diferentes.

Usabilidad, las funcionalidades que es capaz de ofrecer para ser ejecutado.

Modularidad, capacidad de división en partes del proyecto para que sus funcionalidades queden aisladas entre si, y se puedan desarrollar de manera autónoma.

Claridad, tanto el código como la funcionalidad final del software, deben ser concretas y definidas, sin que sea complejo volver a analizar su funcionamiento.

Robustez, garantiza la integridad de los datos que use el software, y que en un mal funcionamiento no provoque errores en su conjunto.

Seguridad, compromiso de los datos, y del sistema en general para utilizarlo con fines ilícitos, o hacer un mal funcionamiento.

Además de seguir éstas pautas, se utilizan los estándares. No solamente es llevar un papeleo extenso sobre la manera de realizar un desarrollo. Calidad es cultura, experiencia, buenas prácticas... Los desarrolladores no son elementos fáciles de intercambiar.

La relación entre calidad y proceso son  muy discutibles,  pues no quiere decir que  una buena calidad de producto tenga una buena calidad de proceso y al revés. Pero si que se puede generalizar que si un software está desarrollado por gente con mucha reputación, podemos asegurar que vamos a tener un buen desarrollo, ya que esas personas ya tienen cultura adquirida.

Hay comunidades de software que se han ganado la confianza de los desarrolladores, y tienen guías propias de buenas practicas, como las siguientes:



QSOS - Selección de proyectos de Software Libre


Qualification and Selection Open Source software, traduciendo literalmente, Calificación y Selección de software de Fuentes Abiertas. Gracias a esta metodología, podemos trazar y argumentar de una manera objetiva la selección de entre varios proyectos de Software Libre. Esta metodología es de origen Francés, de la empresa Atos Origin.

QSOS define 4 pasos que debemos tomar:



  1. Definir y organizar qué va a ser evaluado. Puede ser que solamente nos interese una cierta funcionalidad de un software, y puede que exista software que solamente tenga esa funcionalidad que buscamos. Vemos a que familia de software pertenece pues no es lo mismo definir criterios para una software de retoque fotográfico que uno para monitorizar un sistema.
    En este punto también se observa con detalle el tipo de licencia, si podemos tomar posesión del código o es una licencia vírica como lo puede ser GPL.
    Por último, también se define el tipo de comunidad. Si es un desarrollador por su cuenta, un grupo de desarrolladores, organización o entidad legal.
  2. Evaluar el software de la competencia en contra de los criterios definidos anteriormente, incluidos los riesgos de la naturaleza de ese proyecto.
    De esta fase debemos reportar 2 informes, una tarjeta identificativa por cada proyecto evaluado, para realizar búsquedas rápidas, ver aspectos técnicos y servicios.
    Y el otro reporte es un hoja de evaluación que contiene las funcionalidades cubiertas, riesgos que cubre a partir de un usuario y un integrador. Puntuación de 0 a 2, definidos como funcionalidad cubierta, 0 no, 1 media y 2 total.
  3. Calificación según los criterios de la organización en ejes de evaluación, y el filtrado de la selección relacionados con su contexto. Se definen filtros, por ejemplo el software con funcionalidades incompletas, se filtra por tarjeta identificativa.
  4. Selección del software que cumple con todas las necesidades descritas al inicio y anotar los programas que compiten. Para ello hay que crear una malla con todas las puntuaciones del paso anterior y organizarlos.


Ver la metodología se esta manera puede parecer difícil de entender, pero con QSOS quisieron realizar algo diferente, y consiguieron unificar el método con el que se realizan éstas métricas y cuando realicemos un QSOS, podemos compartirlo. 



Existen también herramientas que nos facilitan esta tarea, como la O3S Open Source Selection Software Tool, http://www.qsos.org/o3s/. Pero dentro de la sección de Tools de la web QSOS vemos que hay otras herramientas como la Xuleditor, que como su nombre indica, utilizar el motor gráfico de Firefox.

Ohloh - comunidad de desarrolladores

Ohloh es un directorio público de Software Libre y personas que lo desarrollan y/o usan. Aunque pueda parecer una forja donde alojar proyectos, no lo es.



En Ohloh se centran en un análisis de los proyectos que tiene enlazado. Gracias a los datos que obtiene de los repositorios oficiales de los proyectos puede realizar diferentes informes sobre el uso del lenguaje de programación, el sistema de control de versiones o incluso comparar varios proyectos.

No obstante, puedes realizar otro de consultas gracias a su API abierta, con ejemplos de uso en varios lenguajes de programación.

Al visualizar un proyecto en concreto, podemos observar que Ohloh hace un análisis del mismo, y crea un indice propio al que llama factoids. Podemos ver la actividad de usuarios a nivel geográfico, pero para que esto funcione correctamente, tiene que existir usuarios registrados que marquen  que usan dicho software.


Gracias a estas herramientas, podemos hacer un estudio sobre las motivaciones de los desarrolladores y de los usuarios finales, ya que ambas partes son importantes en el crecimiento de un proyecto.

Estructura social - Modelo de cebolla


No, no os quiero hacer llorar con este post... qué fácil es hacer un chiste malo cuando se incluye una cebolla... Hoy quiero explicar un sistema de estructuración de proyectos de Software Libre. Se llama el modelo en cebolla, denominado así por su similitud a las capas de una cebolla, y este caso, la importancia que tiene según se accede al núcleo.

Esta estructura social es muy común en la mayoría de proyectos de software, en el caso de software libre, existe la oportunidad de llegar hasta el centro, mientras que en software privativo puede que nos quedemos en la capa mas externa siempre. Esto es debido a que en esta estructura, en la capa más externas se encuentran todos los usuarios de un programa. En la siguiente capa mas interna, se encuentran los usuarios activos. Estos empiezan a comprometerse, colaborando en búsqueda de bugs, crear algún parche, traducir... Para que sus modificaciones sean revisadas, deben comunicárselo a la siguiente capa, donde se encuentran lo co-developers, personas que llevan tiempo realizando modificaciones, colaborando, y que tienen un tiempo reservado para realizar este tipo de tareas. Es una capa importante, pues la comunicación y la ayuda entre estas dos capas debe ser la mas intensa, pues la siguiente capa, que es el núcleo, se encuentran los coordinadores del proyecto, y sus desarrolladores.

Podemos ver claramente cual es la dirección que debe tomar cualquier persona que quiera colaborar, y seguir este orden es importante, pues así se mantiene un flujo de pasos que debe seguir para ser parte del núcleo. Esto sirve para explicar la meritocracia, pues según realizas tareas, más posibilidades tienes de ir quitando capas a la cebolla.

Con esta estructura, también se explica la cantidad de personas implicadas en un proyecto de Software Libre, pues cuanto mas externa sea la capa, mayor cantidad de personas hay implicadas. Como suele pasar, el núcleo es muy pequeño, representa a esa minoría, dedicada a que funcione, comparada con la gran cantidad de gente que utiliza ese software.

El modelo en cebolla, brinda a asemejarlo con bastante facilidad a muchas estructuras, a pesar de que ahora mismo nos ocupa la estructura social, podemos también asemejarlo al código, en el que existe una API que se comunica con el exterior del programa, y esta API se comunica con el núcleo, que internamente tiene una serie de funciones divididas en bibliotecas. El núcleo a su vez se comunicará con el hardware. Es un modelo que estructura muy bien cada parte de un programa.

Es importante saber la existencia, y la aplicación de esta estructura social en un proyecto, pues si no estuvieran definidos, puede ser difícil de mantener una gran cantidad de código, listas de correo, parches, etc... 

Open Data - Datos abiertos en las administraciones públicas


¿Cuantas veces necesitamos acceder a datos administrativos de tu ayuntamiento?, o datos a nivel demográfico, estaciones meteorológicas o incluso las cámaras de tráfico para ver si hay atasco en un determinado punto kilométrico. Datos que son recogidos, administrados por el organismo competente, para realizar estudios y/o censarlo. Si esos datos, nos conciernen a todos los ciudadanos ¿Porqué no tener acceso a ellos?

Open Data es un movimiento que determinados datos, estén libres a todo el mundo, sin restricciones de copyright, patentes u otro mecanismo de control. Esto no implica únicamente en desarrollar una web, en el que aparezcan un serie de datos. Implica que se deben desarrollar mecanismos de comunicación, accesible, legible, comprensible, estructurado y reutilizable. Esto puede ser mediante una API con el que cualquier aplicación pueda conversar con esos datos. De esta manera no se limita el uso a la aplicación web, si no al de cualquier tipo de aplicación, de escritorio o móvil.

Para cumplir esta serie de requisito, podríamos decir que hacen falta tres conceptos que debe cumplir todo ayuntamiento con datos accesibles:

Transparencia: La administración pública debería permitir el acceso sobre actos que se están realizando y sobre sus planos de actuación. Permitiendo a los ciudadanos poder realizar un control de la acción gubernamental, y poder crear valor a partir de estos datos cedidos.

Colaboración: Estos cambios se realizan para implicar más al ciudadano, empresas, asociaciones y otros agentes, permitiendo realizar un trabajo conjunto.

Participación: Favorece el derecho de la ciudadanía a participar activamente en las actuaciones sobre asuntos públicos de los organismos oficiales del estado.

Aunque  el movimiento parece que está estrechamente relacionado con el Software Libre, no quiere decir que a pesar de tener datos abiertos, se utilicen herramientas privativas, para el manejo de los mismos. Un posible ejemplo es la utilización de Google Maps para representar la situación geográfica donde se encuentran las estaciones meteorológicas. A pesar de tener datos abiertos, y Google Maps, que tiene una API abierta, no quiere decir que los datos estén almacenados en sistemas cerrados. En este caso recomendaría el uso de OpenStreetMaps.

Obviamente, hay ciertos tipos de datos que las Administraciones no pueden hacer públicos, como son los datos de carácter personal, los sujetos a propiedad intelectual o aquellos que estén relacionados con la seguridad.

Podemos contar con la experiencia de otras administraciones extranjeras que ya han empezado a dar acceso abierto a sus datos. Como el de Estados Unidos http://www.data.gov/ , el gobierno británico http://data.gov.uk/ , y a nivel nacional, el País Vasco http://opendata.euskadi.net.

Desde Cenatic se ha creado un video en el que Manuel Velardo describe las características de este movimiento.

Creo que si todos los ayuntamientos aceptaran Open Data, como forma de comunicarse con la ciudadanía, mejorarían problemas sociales, económicos o incluso ideológicos. Open Data es la comunicación entre gobierno y ciudadano de la forma más directa y diversa posible.

Más información en el documento realizado por la Junta de Castilla y León:
http://www.orsi.jcyl.es/web/jcyl/ORSI/es/Plantilla100Detalle/1262860952313/1262860952313/1284139023547/Redaccion

Creative Commons


Cuando hablamos de Software Libre, nos referimos a todo aquel software que siguen las 4 libertades básicas descritas por la Free Software Foundation. Pero estamos hablando de software, ¿Podemos aplicar estas libertades a otra cosa que no sea software?

Sí, y para ello se fundó la Creative Commons, mediante nuevas licencias, permite reducir las barreras legales respecto a la creación de contenido creativo, como pueden ser contenido textual, fotográfico, pictórico  musical o audiovisual.


Fue fundada en 2001 por  Lawrence Lessig, Hal Abelson, y Eric Eldred.Pero hasta Diciembre de 2002 no se hicieron públicas el primer conjunto de licencias. Pero ya existían licencias libres, ¿para qué mas?. Aunque pueda parecer que es una proliferación de licencias, en Creative Commons buscan solucionar ciertos problemas que con el software no se daban.
Crearon una serie de capas visuales, de tal manera que fueran fácilmente identificadas y aplicadas.

CC BY
Reconocimiento: Debe reconocer los créditos de la obra de la manera especificada por el autor o el licenciador (pero no de una manera que sugiera que tiene su apoyo o apoyan el uso que hace de su obra).

CC BY-SA
Reconocimiento: Debe reconocer los créditos de la obra de la manera especificada por el autor o el licenciador (pero no de una manera que sugiera que tiene su apoyo o apoyan el uso que hace de su obra).
Compartir bajo la misma licencia: Si altera o transforma esta obra, o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta.


CC BY-ND
Reconocimiento: Debe reconocer los créditos de la obra de la manera especificada por el autor o el licenciador (pero no de una manera que sugiera que tiene su apoyo o apoyan el uso que hace de su obra).
Sin obras derivadas: No se puede alterar, transformar o generar una obra derivada a partir de esta obra.


CC BY-NC
Reconocimiento: Debe reconocer los créditos de la obra de la manera especificada por el autor o el licenciador (pero no de una manera que sugiera que tiene su apoyo o apoyan el uso que hace de su obra).
No comercial: No puede utilizar esta obra para fines comerciales.

CC BY-NC-SA

Reconocimiento: Debe reconocer los créditos de la obra de la manera especificada por el autor o el licenciador (pero no de una manera que sugiera que tiene su apoyo o apoyan el uso que hace de su obra).
No comercial: No puede utilizar esta obra para fines comerciales.
Compartir bajo la misma licencia: Si altera o transforma esta obra, o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta.

CC BY-NC-ND


Reconocimiento: Debe reconocer los créditos de la obra de la manera especificada por el autor o el licenciador (pero no de una manera que sugiera que tiene su apoyo o apoyan el uso que hace de su obra).
No comercial: No puede utilizar esta obra para fines comerciales.
Sin obras derivadas: No se puede alterar, transformar o generar una obra derivada a partir de esta obra.


CC 0
Esta licencia permite al autor dejar su obra al dominio público, de esta manera no tendrá ningún derecho sobre la obra, incluso de atribución.

Para aplicar una licencia de Creative Commons, podemos utilizar la herramienta oficial.

Debido a estas diferenciadas licencias, se creó Free Cultural Works, que trata de definir un trabajo cumpliendo las 4 libertades básicas del movimiento del Software Libre. Pero desde Creative Commons se ha asegurado cumplir con esta definición a través de la licencia de Reconocimiento y Reconocimiento-CompartirIgual. El dominio público también cumple con los requisitos de la Free Cultural Works, y para identificar claramente una obra con ésta definición se creó un logo.

Puede que haya licencias que se adecuen a tus necesidades, pero pueden ser un arma de doble filo, puede que no quieras que con tu obra no se beneficie nadie económicamente. Pero puede jugar en tu contra, si alguna vez deseas utilizarlo para una actividad comercial y cobres por ello, o en el peor de los casos, debes competir contra tu misma fuente. Estarías infringiendote a ti mismo. Por supuesto, que esto no se aplica si no hay nadie que acuse de violación de derechos, y nadie se tira piedras a su propio tejado.

Después de analizar las posibilidades que nos ofrece Creative Commons, creo que es interesante utilizar este tipo de licencias, pues incluyen siempre el reconocimiento del autor, protegiendo así del problema que muchos autores se les pasa por la cabeza, el temido plagio.
Ya existen sitios donde puedes comprar, contenido bajo licencias Creative Commons, como Jamendo para la música, Flickr para fotos, o Blip.tv para videos, y actualmente youtube.

Roles en un proyecto de Software Libre

Si planeas empezar con un proyecto de Software Libre desde cero, puede que este apartado sea irrelevante. Parece que los roles empiezan a ser importantes cuando hay una cierta cantidad involucrada. Pero definir y saber qué y quién va ha realizar determinadas tareas, puede ser crucial en ciertos momentos para que el proyecto siga adelante. Es fácil que un proyecto de Software Libre tenga muchos colaboradores, por su propia naturaleza.

En 1975, Fred Brooks definió la Ley de Brooks, decía que cuando un proyecto de software crece, lo hace de manera exponencial, y cuando además está retrasando su salida el Manager tiende añadir a mas gente nueva al proyecto para terminar antes. Esto es un grave error pues esa gente nueva no conoce el modelo y tiene que ponerse al día, y al final acaban picando código alocadamente.
En Software Libre cuando mas grande es el proyecto, más propenso a tener roles. Como una gran orquesta, en la que cada uno debe dar su parte en su debido tiempo. Consiguiendo así una armonía.

Paso a describir una serie de roles básicos en cualquier proyecto:

Desarrolladores

Los creadores de código. Deben informar de sus cambios, no sirve de nada ser un lobo solitario y desarrollar por tu cuenta. Eligen que entorno de desarrollo se va a utilizar, aunque hay casos en los que no hay definido un IDE. Sus objetivos están dirigidos por lo que dicta la comunidad, pero sin llegar a la pasividad. No todos los desarrolladores tienen derecho a commit en el repositorio del proyecto, pues hay casos que deben ser revisados. Una vez realizado ese commit, hay que actualizar la lista de funcionalidades o errores corregidos.

Maintainers


Existen muchas subcategorias:

  • Patch Manager: Puede que el desarrollador no da a basto con los Bugs, y el Patch Manager debe canalizar esto. Debe acotar los bugs, ver cual es importante o no, si existe el patch que alguien lo revise o ellos mismos.
  • Manager de traduccion: documentación, código, internacionalización u localización. Portar código de un lenguaje de programación hacia a otro. Los mensajes de la interfaz. Los manuales. 
    • Internacionalizacion trata de adaptar el software para otras culturas y/o idiomas, favorece la protabilidad. Da soporte para distintas monedas, soporte para unicode.
    • Localizacion son los mensajes de la interfaz de usuario.
  • Documentation manager: la guia del usuario, es una tarea tediosa. Se pueden vender como guías.
  • Issue Manager: Parecido al patch manager, pero también atiende a las peticiones. Encaja la oferta con la demanda.
  • FAQ Manager: Cuando un proyecto es grande es necesario. La tarea es sencilla, leer los foros y wikis en busca de preguntas. Tratar de buscar las mas frecuentes. Se formula bien la pregunta y se responde, y reorganizarlo para que no exista preguntas duplicadas y organizarlo por categorías.
  • Release Manager: Se encarga de las nuevas release, en Ubuntu son cada 6 meses. Suele ser un cargo que cambia mucho de persona, porque es una tarea agotadora. Tiene en la cabeza el RoadMap, tiene que cumplirlo, y si se desvía, trata de que haya consenso. Coordina todo para que haya homogeneidad.

Documentation writer

Lo que más importa es que escriba bien y no mucha cantidad. Lo mas conciso posible, con posibilidad de crear una guia del desarrollador. Un buen ejemplo GNOME Project system-admin-guide. También debe escribir/revisar la documentación de Man.

Distribution Developer

Se encarga de la homogeneidad del proyecto de paqueteria. Revisa las licencias. 

Traductores

Hasta que el desarrollador no termina, no empiezan a traducir. Esto es debido porque puede haber cambios finales, en el que se muestre o se deje de mostrar un mensaje por pantalla. Por lo que tienen un esfuerzo extra antes de la siguiente release, pues siempre se están cambiando código contiuamente.

Tester

Personas encargadas de probar el programa, su correcto funcionamiento, o incluso forzar para que de errores. El skill de estos tester no es meramente técnico, cade vez es más social y útil por que da una visión más amplia del usuario final.

Community Manager

Construir, alimentar y expandir la comunidad, son las prioridades de esta persona. Que exista buen ambiente, proporciona atajos para encontrar a la persona que quieres, pues si alguien se quiere incorporar a realizar una tarea muy específica, es preferible que tenga contacto con las personas que han desarrollado o modificado esa parte de código. Al final puede acabar como un relaciones publicas. Cualquier proyecto colaborativo es necesario este rol, no solamente en proyectos de software. Ayudan a encontrar fuentes de ingresos. No se encarga directamente en todo, delega todo. Tiene un rango multidisciplinar. Son gente hiperactiva. Escuchan. Ayuda la colaboracion entre varios roles. Periodicamente hacen brainstorming, conferencias, para aportar nuevas ideas. Recomendaciones y guias de buena conducta.

Project Leader

Persona mas relevante o influencia en el proyecto, o por ser el fundador o porque te lo hayas ganado (Meritocracia). Por ser el fundador es fácil, por estar desde el principio y puso las reglas, el ejemplo mas claro es Linus Torvalds. Por meritocracia, es más difícil, se pueden equivocar sin tantos problemas como el fundador, pues el fundador lo debe conocer mejor que nadie. A veces se encuentran dictadores benevolentes, cuando se detecta que hay opiniones enfrentadas, se pide la actuación del dictador benevolente y se aplica su decisión.Capturan la esencia de la motivación del proyecto.

Todos estos roles no tienen porque ser obligatorios. Aunque muchos de ellos son indispensables, como los desarrolladores y un community manager que promocione el proyecto. Incluso se pueden crear nuevos roles, como los encargados del diseño de la aplicación, como su iconografía y darle un resultado vistoso. Antes este rol no tenía mucho sentido, pero poco a poco, la interfaz del usuario ha ido tomando un papel importante en el desarrollo de software. Por otro lado, llegar a conseguir uno de estos roles en ciertos proyectos, puede ser muy fácil en algunos casos o todo lo contrario. En el proyecto Apache tiene un proceso fuerte para incorporar a nuevas personas.

La finalidad de estos roles, es saber lo que tiene que hacer cada persona, en cada momento. También ayuda a involucrar a más gente el proyecto, que no tienen skill de programador, pero quieren colaborar igualmente. Nunca hay que rechazar una colaboración ;)


La Catedral y el Bazar


Cuando hablamos de este ensayo, estamos también hablando de Eric S. Raymond. En 1997 se le consideró una figura líder del movimiento Open Source. Fue cofundador de la OSI (Open Source Initiative). Contribuyó a la liberación del navegador web Netscape. Como programador coordino el cliente de correo Fetchmail, colaboró en Emacs, y Ncurses.

Y gracias a la colaboaración de este software, lo que le llevo a escribir un ensayo sobre dos modelos opuestos de desarrollo, la catedral es el modelo que utilizaban la mayoría de fabricantes de software, y el bazaar, más parecido al Software Libre.

Durante el ensayo, analiza 19 lecciones sobre su experiencia en estos dos modelos de desarrollo.

  1. Todo buen proyecto de software comienza con la necesidad personal del programador.
    Comienzan como su proyecto mascota, que cuidan y miman, pues es su obra. Al contrario que ocurre con el software privativo, en el que el programador realiza una tarea impuesta guste o no. Esta motivación explica grandes proyectos como el núcleo Linux.

  2. Los buenos programadores saben qué escribir. Los mejores, que reescribir (y reutilizar).Absolutamente importante en el Software Libre, Linus Torvalds no empezó desde cero, cogió partes de Minix. Aunque finalmente reescribió el código, fue fundamental para comenzar con el proyecto.

  3. "Contemple desecharlo; de todos modos tendrá que hacerlo." (Fred Brooks, The Mythical Man-Month, Capítulo 11). No se entiende el problema hasta que lo implementas por primera vez, por eso es recomendable, empezar de nuevo alguna vez.

  4. Si tienes la actitud adecuada, encontrarás problemas interesantes.
    Eric se encontró con un cliente de correo popclient interesante escrito por Carl Harris, pero lo tenía abandonado. Eric debía tomar la decisión de cogerlo y empezar a coordinarlo por su cuenta.

  5. Cuando se pierde el interés en un programa, el último deber es heredarlo a un sucesor competente.
    Antes de abandonar un proyecto de Software Libre, hay que encontrar un sucesor, que lo trate como si fuera de la mascota que tratábamos en el primer punto. Como bien dice el eslogan "No los abandones, ellos no lo harían", siempre hay alguien dispuesto a asumir ese cargo.

  6. Tratar a los usuarios como colaboradores es la forma más apropiada de mejorar el código, y la más efectiva de depurarlo.
    Y qué mejor ejemplo que el núcleo Linux. Cualquier persona tiene acceso al código y/o cambiarlo, encuentra fallos, y los puede arreglar, y en caso de no saber arreglar, lo puede comunicar al resto.
  7. Libere rápido y a menudo, y escuche a sus clientes.
    Totalmente necesario, y es fomentado gracias al sistema de canales de software. Se pueden mantener tres lineas de proceso, una estable, en la que se mantiene para implementar con gran cantidad de fallos testeados. Las nightly versiones previas a una estable para que los testeadores empiecen a probar posibles errores y corregirlos para la versión estable. Y un canal diario, en el que cambio que sea realice, cambio que está disponible al mundo. De esta manera estimulamos tanto a desarrolladores, usuarios entusiastas, y usuario s finales.
  8. 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.
    O definir la Ley Linus "con muchas miradas, todos los errores saltarán a la vista". En este punto se diferencia la catedral, con meses de revisión exhaustivos para alcanzar el máximo número de errores. Por eso se tarda tanto en aparecer nuevas versiones.
    Por otro lado, el bazar, asume que los errores son evidentes cuando se muestra a desarrolladores entusiastas. Por consecuencia se libera más a menudo por incluir los cambios de estos.
  9. Las estructuras de datos inteligentes y el código burdo funcionan mucho mejor que en el caso inverso.
    Un problema universal es la dificultad de entender el código que otra persona a escrito. Realizar diagramas o definir las estructuras de datos utilizadas, permiten comprender mejor el funcionamiento del programa.

  10. Si usted trata a sus analistas (beta-testers) como si fueran su recurso más valioso, ellos le responderán convirtiéndose en su recurso más valioso.Tal y como cuenta Eric, en su experiencia con Fetchmail, creo una lista beta para todos los que le preguntaron por la implementación. Anunciaba nuevas releases para estimular a que la gente lo probara. Escuchaba las opiniones de estos usuarios primerizos. Como consecuencia, dar importancia a estos recurso hará que tu software sea más práctico al final.
  11. Lo más grande, después de tener buenas ideas, es reconocer las buenas ideas de sus usuarios. Esto último es a veces lo mejor. Obtener las opiniones de los usuarios es lo mas enriquecedor que debes tener en cuenta.
  12. Frecuentemente, las soluciones más innovadoras y espectaculares provienen de comprender que la concepción del problema era errónea.Esto me recuerda mucho al punto 3, en algún momento, gracias a haber atendido a las sugerencias de los usuarios, podemos encontrarnos que el camino o las soluciones que se proponen son erróneas. Parar, dar marcha atrás para coger otro camino, es duro, pero merece la pena.

  13. "La perfección (en diseño) se alcanza no cuando ya no hay nada que agregar, sino cuando ya no hay algo que quitar."Cuando el código va mejorando y se va simplificando, es cuando se hace lo correcto. Respecto a la interfaz de usuario, creo que pasa lo mismo. Para mi un claro ejemplo es Gnome, pasó de un entorno de escritorio para hackers, ya que cada componente tenia gran cantidad de configuración, a pasar a ser un escritorio multidisciplinar, se fue aligerando la interfaz de usuario, quitando opciones innecesarias.

  14.  Toda herramienta es útil empleándose de la forma prevista, pero una *gran* herramienta es la que se presta a ser utilizada de la manera menos esperada.Aquí juega un papel importante la innovación, dar al usuario esa manera de usar un programa que incluso mejora las expectativas.

  15. Cuándo se escribe software para una puerta de enlace de cualquier tipo, hay que tomar la precaución de alterar el flujo de datos lo menos posible, y ¡*nunca* eliminar información a menos que los receptores obliguen a hacerlo!Puede parecer un comentario único para el proyecto en el que trabajaba Eric, pero creo que tiene importancia en la manera que si tienes un programa, que debe leer una entrada estandarizada, y después sacarla por pantalla o tratarla para una salida, debe mantener el mismo estándar.
  16. Cuando su lenguaje está lejos de un Turing completo, entonces el azúcar sintáctico puede ser su amigo.
  17. Un sistema de seguridad es tan seguro como secreto. Cuídese de los secretos a medias.

    Estas dos lecciones son propias del proyecto Fetchmail, habla sobre el sistema de seguridad  de la aplicación, cómo guardar y encriptar las contraseñas.
  18. Para resolver un problema interesante, comience por encontrar un problema que le resulte interesante.Es la única forma de no abandonar un proyecto, como le ocurrió a Carl Harris. Hay muchos motivos para motivar a un desarrollador, en el Software Libre, mayormente no es económico, es mas bien una satisfacción de su ego y su reputación entre desarrolladores.
  19. Si el coordinador de desarrollo tiene un medio al menos tan bueno como lo es Internet, y sabe dirigir sin coerción, muchas cabezas serán, inevitablemente, mejor que una.
    Cuando Eric escribió esto, aún estaban empezando a dar sus frutos el Software Libre como movimiento. Creo que hoy en día está claro el éxito de un producto libre.
Tras estas 19 lecciones, tengo que recordar que es un ensayo, carece de rigor. Trata de generalizar todos los proyectos de Software Libre, aplicándole un modelo de bazar. Esto puede ser confuso, pues proyectos cómo el núcleo Linux pueden aparentar más un modelo de catedral, con un dictador benevolente a la cabeza que es Linus Torvalds. Quizá el  bazar no es la definición mas correcta para definir un proyecto de Software Libre. Puede que el modelo de catedral y bazar de Eric se viera influenciado por los acontecimientos que se vivían por aquel entonces.

En cualquier caso, el mejor modelo que define el Software Libre es aquél que garantice las cuatro libertades.

PYMES ¿Cómo le afecta que el software sea libre o privativo?

Existe un momento en toda empresa, en el que se debe informatizar. Ya sea para gestionar la contabilidad, las facturas, hacer caja, escribir documentos o incluso publicitarse mediante un blog... Para manejar estos datos es importante decidir que software se va a utilizar para dicha tarea. Existe multitud de programas para ayudarnos en cada propósito. Entre ellas hay gran variedad de Software Libre. Pero, ¿en qué medida nos beneficia utilizar este tipo de software?

Interoperabilidad

Cuando elegimos Software Libre, aceptamos que tenemos libertad para utilizar el código fuente. Gracias a esta característica, sabemos cómo el programa procesa los datos, cómo se comunica con el hardware  y la manera de introducir nuevos cambios para adaptarlo a cada necesidad en particular. Aunque no sea intrínseco, en la mayoría de los casos, el Software Libre cumple con estándares. Un claro ejemplo es del navegador web Firefox, incluye características del estándar de HTML, CSS o JavaScript. Pero también trae  efectos de renderizado propios de Firefox y que no se incluye en ningún otro navegador. Esto ocurre con Internet Explorer, pero la diferencia es que, en Firefox al tener acceso al código, pueden incluirse como estándar de HTML5.

Control de los datos

No hay puertas traseras. Puede haberlas, pero sería dejarlas a conciencia o por error. Con el acceso al código, podemos trazar por donde entrar los datos, y donde deben acabar. Puede que para empresas pequeñas que manejen poca cantidad  de información, ésto no importe, pero ahora que muchos datos están en la nube, hay que tener en cuenta empresas como Google, deben cumplir con leyes Americanas, que podrían obligar a tener puertas traseras con la NSA para cumplir la seguridad nacional. En el peor de los casos, hay proveedores en la nube que permiten la realización de backups en dispositivos locales.

Independencia del proveedor

En muchos casos, el software se hace a medida para solventar ciertas necesidades únicas en cada empresa. El acceso al código es fundamental para que podamos cambiar a otro proveedor de software y éste lo pueda entender. Aunque hay casos como Liferay, que a pesar de ser Software Libre, son el único proveedor en España.

Ahorro de licencias

El Software Libre es comúnmente "vendido" por suprimir por completo el coste de las licencias. Hay programas en lo que esto no es una realidad, porque no existe una alternativa a la altura. Sí... los que usen AutoCAD para arquitectura, deberán seguir utilizando su licencia, porque Blender es más especifico para la animación. Pero en otros ámbitos, existen alternativas totalmente viables, como LibreOffice como suite ofimática. Pero el ahorro de licencias no quiere decir me guardo ese coste desde el principio. Si veníamos de utilizar software privativo, hay que adaptarlo a la alternativa con Software Libre, hay casos mas fáciles y otros más complejos. Si nunca se ha usado el nuevo software, hay que enseñar a los usuarios a utilizarlo. Puede que un principio haya que reinvertir el mismo gasto en adaptarse a este cambio, pero en cualquier caso, es un gasto que irá en decremento.

Decisiones de adquisición

Puede ser nulo, eres libre de probar un nuevo software, comprobar si se adapta o poder adaptarlo a tus necesidades. Con software privativo no podemos hacer esto, pues aunque existan versiones de prueba, en algunos casos son con características capadas o por una duración determinada que no permite exprimir lo suficiente para tomar una decisión.

Gestión de instalación, más seguro de virus.

Es parte de la cultura del Software Libre, todo el mundo quiere la última versión. Y el sistema de paquetes ayuda a este hecho. Hay proyectos que actualizan cada 6 meses, como Ubuntu. En otros casos, puedes asociarte al canal de desarrollo de Firefox, y utilizar las últimas versiones compiladas dia a dia. Esto puede ser un engorro para más de algún administrador de sistemas que necesite comprobar la retrocompatibilidad, pero esta característica hace que el software siempre esté corrigiendo errores o incluyendo nuevas características. Actualmente hay ordenadores de oficina que tienen un Sistema Operativo de hace 10 años, me refiero a Windows XP. Aunque hayan sacado actualizaciones, hay que recordar que es un software que se creó hace ya bastante tiempo y eso puede acarrear muchos problemas de seguridad.

Creo que estos son unos puntos a tener en cuenta necesariamente, cuando vayamos a implementar software en una empresa. No debemos olvidarlos, pues muchas decisiones que se toman al principio, son cruciales para el futuro de esa información.

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.