¿Para qué cobrar 800 Euros de más por permitir cambios si en el peor de los casos se puede comprar otro vuelo por 250 Euros? No tiene sentido, el hecho de permitirte cambios no debería ser más caro que comprar un billete nuevo, de lo contrario la gente no comprará esa tarifa y preferirá el riesgo de perder un billete y comprar otro, porque sale más barato.

La receta está hecha para Debian, y probablemente funcionará sin cambios en cualquier otra distro basada en Debian. Te cambia el prompt, y te pone el nombre del directorio en gris claro. Si es un directorio SVN ó Git, te lo cambia a azul claro, y si es Git, además te lo pone en la forma user@host:directorio|rama|modulo $

Los pasos que tienes que seguir son:

• Descarga el fichero de configuración y cópialo a ~/.vcsawarerc
• Añade . ~/.vcsawarerc a tu fichero .bashrc

Los colores del prompt se controlan con las primeras líneas del fichero de configuración:

1:  _novcs='\e[37;40m'
2:  _svn='\e[36;40m'
3:  _git='\e[36;40m'
4:  _normal=$(tput sgr0)

La primera línea es el color para directorios que no estén bajo control de versiones. La última línea devuelve la configuración del color a su valor por defecto. Por ejemplo, mi color por defecto es verde, y el color de _novcs es gris claro. Puedes poner si quieres los colores de SVN y Git diferentes (yo los tengo los dos puestos a azul claro). También puedes cambiar los colores si los que he puesto yo te parecen hortera. El segundo número controla el color del fondo (en este caso, 40 es negro).

22:      prompt='${_git}${base_dir/$HOME/~}${_normal}|${ref}|${_git}${sub_dir}${_normal}'

El aspecto del prompt en un directorio bajo Git se controla en la línea 22 del fichero de configuración. El nombre de la rama está en la variable ref, el directorio padre está en base_dir, y el módulo en sub_dir.

27:      prompt='${_svn}${PWD/$HOME/~}${_normal}'

El aspecto del prompt en un directorio SVN está en la línea 27, y lo único que hace es cambiar el color del nombre del directorio.

Es importante que cuando pongamos el nombre del directorio lo pongamos de la forma ${variable_directorio/$HOME/~}, porque así se sustituye nuestro la ruta a nuestro home por el símbolo ~.

37:  PS1='${debian_chroot:+($debian_chroot)}\u@\h:\[$(__vcs_dir)\]\$ '

El aspecto final del prompt se encuentra en la línea 37. Imita el prompt por defecto en Debian, añadiéndole toda la información que se comenta arriba. Al meter códigos de colores, bash se hace un lío con la longitud del prompt. Por eso se añaden los símbolos \[ y \]. Sin esos símbolos, las líneas muy largas se truncarán antes de llegar al límite de la ventana del terminal. Con esos dos símbolos parece detectar bien ese límite, pero al pasar a la línea siguiente, si borras, a veces se hace un pequeño lío y mezcla las dos líneas. Si logro arreglarlo, pondré la solución aquí.

Por último, todo esto funciona sólo con la shell bash, y necesitas tener instalada la herramienta tput, que está en el paquete ncurses-bin.

Seis palabras para toda una vida, aunque todavía sea corta como la mía, parece una difícil tarea.

Cuando estaba leyendo la entrada, y sobre todo los comentarios, no se me ocurría cómo podría yo resumir mi vida en sólo seis palabras.

Justo después estaba en el escáner, para digitalizar una carta firmada para enviar a la universidad. La carta era para aceptar la ayuda económica para irme este verano de estancia a Oxford (¡me voy a Oxford!). Me he encontrado en la sala a Antonio, y como estoy terminando el doctorado, pues me ha preguntando que cómo iba la tesis, y las cosas que se suelen preguntar en estas situaciones. Hablando, hablando, me ha contado sus experiencias y me ha dado consejos que me han ayudado por un lado a aclarar mis ideas acerca de qué camino tomar después del doctorado, y por otro lado a poder resumir mi vida hasta ahora en seis palabras.

“El vuelo de una mariposa en Pekín provoca un huracán en Nueva York”

Bueno, no exactamente seis, pero es una frase al fin y al cabo.

La motivación es que me he puesto a pensar en la de cosas que he hecho y que me han pasado desde el día en que tomé la decisión de venir a LibreSoft, en cuáles eran mis expectativas entonces, en cuáles son ahora, y en el impacto que puede tener en mi vida cualquier decisión que tome ahora.

Lo mejor de todo es que ¡me encanta!

Nunca pensé que en mi vida pudiera llegar a tener un abanico de posibilidades tan amplio para decidir dónde quiero vivir, en qué quiero trabajar y cómo quiero vivir.

Quizás sea una obviedad, pero vivir debe hacerse como uno quiera, y uno nunca debería seguir un camino que no le hace feliz, por ningún motivo. Sobre todo por la cantidad de oportunidades por sacarle el jugo a la vida que uno está dejando pasar por seguir un camino que no le está haciendo feliz.

Hace unos tres años y medio enviaba un correo electrónico, a una dirección que también encontré en una bitácora de Barrapunto. Un correo electrónico que ha transformado completamente mi vida, y que la va a seguir transformando probablemente por muchos años.

¡A vivir! que son dos días (y seis palabras)

El nuevo portátil es un Dell Latitude D430, pequeñico pero matón. Después de haber estado usando Ubuntu desde que llegué a Libresoft, decidí probar de nuevo Debian (dejé Debian por FreeBSD allá por el 2003). Quería intentar instalar FreeBSD de nuevo, pero tenía dos problemas principales. Es probable que el año que viene dé las mismas prácticas con Bluetooth que este año. Me gusta usar mi portátil para mostrar los ejemplos. Como el entorno que tienen los alumnos en el laboratorio es Ubuntu, si usaba FreeBSD tendría que tener Debian ó Ubuntu de algún modo (máquina virtual, una partición dedicada) para mostrar los ejemplos. Además, hace poco tuve que actualizar la versión de R (el paquete estadístico que se distribuye bajo licencia GNU) en una máquina con FreeBSD. El infierno de dependencias hizo que tuviera que actualizar todos los ports, lo que llevó casi dos días de compilación (y no tenía las X ni OpenOffice.org, ni nada “gordo”). Cierto es que esa máquina hacía meses que no se actualizaba, pero en cualquier caso el sistema de paquetes/ports de FreeBSD está todavía a años luz del sistema de paquetes de Debian.

Así que intenté instalar Debian Unstable, y no se podía. El paquete de grub y el del kernel no eran instalables. Supongo que sería un problema temporal, pero en ese justo momento decidí probar suerte con testing. Como las versiones que tenía de todos los paquetes eran bastante modernas (en algún caso, más moderna que en mi instalación de Ubuntu en el D600), decidí quedarme. Después, leyendo las políticas para decidir qué paquetes pasan de unstable a testing, me dí cuenta que en realidad no pasa demasiado tiempo desde que un paquete pase de unstable a testing, a no ser que esté muy roto.

Bueno, lo que quería comentar en esta entrada es que ahora, antes de actualizar todos los paquetes que tengo en Debian, miro el tiempo que hace en Debian. Esa herramienta se ha desarrollado dentro del proyecto EDOS, que es un proyecto de investigación financiado por el Programa Marco de la Comisión Europea, y que ya ha finalizado. La herramienta en cuestión se llama Anla, y es una suerte de packages.debian.org con esteroides. La única pega es que parece que por ahora tienen sólo el tiempo para la arquitectura i386, y estoy usando amd64 :-S .

Así que si usas Debian y te tiembla el dedo antes de pulsar intro para hacer un upgrade, mira a ver qué tiempo hace y no rompas nunca más tu Debian.

Ahora en serio, el libro es un compendio de capítulos escritos desde diferentes perspectivas, acerca de la gestión del compromiso de las personas con las organizaciones. Rocío ha escrito uno de los capítulos, en particular el que habla sobre las diferencias en la gestión del compromiso según la etapa del ciclo de vida en la que se encuentra la empresa (por ejemplo, no es lo mismo la gestión en una start-up que en una empresa con decenas de años de vida). Otros capítulos han sido escritos por los responsables de Recursos Humanos de empresas de diferentes sectores (banca, energía, etc).

Reconozco que son temas que ignoro completamente y muchas veces me suenan demasiado abstractos. Lo cierto es que muchas veces cuando le comento a Rocío problemas cotidianos y situaciones con las que nos encontramos en la universidad o en Libresoft, me doy cuenta de que en realidad sí que tienen aplicación y son útiles, y en particular nos podrían haber resultado útiles a nosotros.

Aunque el libro está destinado a gestores de recursos humanos, muchos capítulos son recomendables a cualquiera que trabaje en el seno de un grupo (pequeño, grande, mediano, o ninguna de las anteriores ). Muchos de los problemas que surgen en grupos de personas que trabajan juntos están relacionados con las diferencias entre el compromiso de cada persona con la organización. Entender cómo se gestiona ese compromiso puede ayudar a que no se produzcan esos problemas, o a que se resuelvan de una manera más sencilla.

Bueno, hasta aquí el autobombo

Partimos el jueves a mediodía, después de preparar los oportunos bocatas en casa; justo al entrar en Castilla y León nos dio la bienvenida una niebla que no nos abandonó hasta esta mañana. El viaje por carretera fue como un viejo juego de coches del Spectrum, donde sólo veías los 10 metros que tenías delante tuya, y si mirabas por la ventana el paisaje era un manto gris. El manto gris se interrumpió durante una horilla para comer el bocata y tomar un café en el parador de Lerma, un palacio impresionante, donde los camareros van vestidos de Curro Jiménez.

Un par de horas más tarde por fin llegamos a Urrez. El pueblo es pequeñito: tiene dos bares (literal), dos casas rurales (una coincide con uno de los bares) y algunas casillas desperdigadas. Nada más llegar nos dirigimos a la primera casa rural, donde de manera osada se nos ocurrió preguntar si aquella era la Casa Rural de Cabrera. El buen señor de la barra intentó lanzarme rayos gamma con los ojos tras oír la pregunta, pero se ve que a esas horas ya estaba cansado, y se limitó a refunfuñar. Tras cinco segundos donde me dirigió una mirada que seguro que había ensayado tras horas de westerns de John Wayne, su mujer me comentó que ésa era la “otra” casa rural del pueblo, y que fuera a la plaza y preguntara por allí.

La plaza era un cruce de calles a la vuelta de la esquina. Como era ya tarde estaba desierta. Menos mal que una buena pareja se escabulló entre la parroquia que poblaba el bar, y nos dirigió a pie a la “otra” casa rural. Por deseo expreso suyo, no menciono su nombre en esta entrada .

Así que por fin llegamos a la casa. Nada más abrir la puerta, nos recibió un calorcito que animaba a acurrucarte en un rinconcito y no moverte durante los cuatro días de estancia. Sólo los más intrépidos se atrevían a salir a la calle con las temperaturas gélidas. Por fin estábamos en la casa. Al calorcito de los radiadores se le unía también el calor humano de Domingo, el gerente de la casa, que la mantiene en condiciones impecables, y está siempre dispuesto a que la estancia sea lo más agradable posible.

El segundo día fuimos a comer a la cantina del pueblo. La cantina es también el “otro” bar del pueblo. Parece que no están muy acostumbrados a servir comidas. Cuando entramos y dijimos que queríamos comer, el señor nos hizo esperar cinco minutos. Subió arriba, donde su hija jugaba a las cocinitas, le robó la libreta, la bajó, y pasó a explicarnos lo que tenía. Básicamente, cuatro cosas para picar y poco más. Tras el copioso almuerzo fuimos a Burgos, donde paseamos un rato, compramos un par de cosas y de vuelta a casa. Este día la niebla había dado algo más de tregua, y pudimos ver que estábamos justo al lado de los yacimientos de Atapuerca. El viaje nos sirvió para arrojar luz sobre una de las claves científicas de Atapuerca. Al hombre de Atapuerca se le representa siempre desnudo, pero no hay dios que tenga valor de pasearse en bolas por la Sierra de Atapuerca. Con una chaqueta, bufanda y abrigo encima de todo eso, todavía tiritaba del frío. Durante el día, la máxima era de 4ºC, y durante la noche ni idea, pero para muestra, teníamos una botella de cava que en vez de meter en la nevera, dejamos toda la noche en la ventana. Al día siguiente por la tarde, la botella estaba todavía más que fresquita.

Esa misma noche, tras haber arrojado luz sobre uno de los enigmas científicos de nuestra época, todavía nos quedaba por superar otra prueba de intrepidez. Entré al bar del pueblo, a comprar dos bocadillos. La escena fue digna de la mejor película del oeste. El ruido de la puerta dirigió todas la atención hacia mí: el forastero. Entre inquisitivas miradas me dirigí hacia la barra, donde los lugareños formaban en fila cual escuadrón romano, dispuestos a no dejar ni un hueco libre por el que se pudieran usurpar los recursos locales. La técnica del “perdón, por favor, …” no hacía efecto. Me armé de valor, cargué mis codos, y me abrí paso tras las líneas enemigas. Una vez conquistada la barra, me tuve que enfrentar a la “resistance”. La camarera pasaba olímpicamente de atenderme. Tras mucho insistir, y después de una larga y tensa espera bajo la atenta mirada de los lugareños, conseguí mi botín y me batí en retirada.

Al día siguiente fuimos a hacer un “reconocimiento” del terreno. Dimos la vuelta al monte junto al que está Urrez, siguiendo el trazado de un antiguo ferrocarril minero. El trazado estaba vallado a ambos lados del camino, y de las vallas salían extraños mechones de pelo. ¿Algodón en suspensión en el aire que se queda atrapado en las vallas? ¿Lobos que se dejan el lomo pelado cruzando el camino? ¿Señales dejadas por Hansel y Gretel (o los que fueran los protagonistas del cuento de las miguitas) para saber el camino de vuelta? La mayoría de los pelos eran blancos, otros tirando a marrón, y algún que otro negro. La solución llegó más tarde, cuando divisamos un rebaño de ovejas. Las pobres ovejitas se lanzan a comer los brotes de plantas a los lados del camino, y por el mismo precio se hacen la depilación con valla metálica. Ni lobos ni cuentos.

El camino y las indagaciones sobre el misterio peludo nos abrió el apetito. Después de las calurosas acogidas en los bares del pueblo, y dadas las exquisiteces con que nos deleitaban, decidimos dirigirnos a Arlanzón, pueblo cercano a Urrez, a comer como Don Camilo manda. En Arlanzón, tras un breve paseo divisamos un lugar con el prometedor nombre de “Asador de Arlanzón”. Ya en el interior pudimos comprobar que el sitio hacía honor a su nombre. La una del mediodía, y estábamos sentados a la mesa a la espera de un menú castellano con C mayúscula. Estábamos de suerte: tenían cordero asado sólo por encargo, pero una familia les había encargado medio cordero y no sabían que hacer con el otro medio, así que nos lo adjudicamos. Los pobres comensales que llegaron a comer a las dos se quedaron sin cordero, a pesar de solicitarlo insistentemente. Nos las prometíamos felices. Devoramos un caldito y un revuelto de setas, acabamos hasta con las migas de pan, y llegó el cordero. Exquisito. Tierno. Inmejorable (bueno, unas patatitas con el cordero no habrían venido mal). Postre y café, y orgullosos nos disponíamos a pagar la cuenta. La pedimos, y nos la trajeron doblada en un papelito. Unos minutos más tarde entenderíamos lo de “doblada”. Envalentonado ante el descubrimiento de tan acogedor lugar, estiré el brazo, y dije “eh, que invito yo”. Estiré el papel y descubrí que el cordero asado para dos personas lo vendían a unos módicos 56 eurazos, que unido al resto de manjares elevaba la cuenta hasta los 90 euros. La cuenta, doblada, entra mejor. Mi bolsillo no llegaba a 50 euros; busqué desesperadamente el Ctrl+Z, para intentar deshacer lo que había dicho. No me quedó más remedio que solicitar la ayuda económica de mi fiel compañera para poder hacer frente a una estocada que habría hecho hincar la rodilla al mismísimo Alatriste. Doloridos nos batimos en retirada a nuestro castillo en Urrez.

Al día siguiente tocaba volver a Madrid, a revivir lo que por derecho propio debería pasar a formar parte de los Episodios Nacionales: los atascos del puente de diciembre. Con paciencia enfilamos la carretera, repasando nuestras hazañas conquistadas durante tres días en tierras inhóspitas. Con horror comprobamos que nos faltaba por completar una de las misiones: comprar lotería. Así que decidimos parar en Aranda de Duero, pueblo por el que pasábamos justo a la hora de comer. Las oficinas de lotería no vendían lotería, y nos dirigían al bar de la esquina. El bar de la esquina no vendía lotería, y nos dirigía a….bueno, no lo decían, pero tampoco hacía falta. En fin, parece que no les gusta que esquilmemos uno de sus más preciados tesoros (cada burgalés se ha gastado ya 122 euros en lotería de Navidad este año). Para lamer las heridas nos metimos en un restaurante, a comer por última vez un menú castellano. No recuerdo el nombre del restaurante, pero debe ser el sitio al que llevan a comer a todos los toreros, porque no quedaba ni un centímetro cuadrado de pared libre de la oportuna de foto de torero degustando un cordero asado. Hasta Franco aparecía sentado en una de las mesas poniéndose las botas.

El menú en este aparentemente ilustre restaurante era mucho más barato que en Arlanzón, lo que confirmó nuestras sospechas de haber sido timados cual dignos guiris. El menú estuvo regado por la conversación de dos tertulianos en una mesa contigua, que debatían sobre la “cristología”, los herejes y la Iglesia católica. Uno decía creérselo todo a pies juntillas, excepto la parte de la resurrección, que chocaba con su juicio crítico. El otro era un escritor salmantino cuyo nombre no pudimos averiguar, que tampoco paraba de hablar. En realidad sospecho que los dos podrían haber hablado de cualquier tema (por ejemplo, cualquier tema aleatorio sacado de la Wikipedia).

Con la panza llena, intentamos comprar lotería de nuevo, esta vez en el pueblo de Milagros. Con ese nombre, tiene que tocar seguro. Pero de nuevo nos encontramos con los valientes guardianes de los tesoros castellanos. En la gasolinera, un chaval nos dirigió al bar del pueblo, donde él había comprado ayer mismo lotería. Tras conducir doscientos metros hasta el bar, el señor de la barra respondió con un “Ya no queda” que sonó a un “La lotería es pa’ los del pueblo”. En fin, que nos tuvimos que volver sin esa misión cumplida.

En resumen, esta nueva aventura junto a Rocío, compañera de andanzas que me ha robado el corazón, ha estado a la altura de nuestras dos semanas recorriendo el norte de Portugal y sur de Galicia, a lo largo de 250 kilómetros de “caminho portugués”. La Casa Rural de Cabrera es un lugar acogedor, calentito, con todos los lujos e innovaciones de cualquier ciudad (¡hay wireless incluso! aunque lo descubrí demasiado tarde), pero en un lugar apartado. Cerca hay montones de sitios para visitar (yacimientos, museos, monumentos..), rutas para hacer senderismo, o simplemente para estar tumbados sin hacer nada durante días. El año que viene volveremos en misión (no tan) secreta, con el firme objetivo de traer pruebas gráficas de este apartado rincón de la meseta castellana. Esta vez, dado el secretismo con el que los lugareños cuidan sus recursos, no pudo ser, y no hemos traído ni una sola foto (bueno, el hecho de que se nos olvidara la cámara quizá influyó algo también ).

Uno de los mitos que se discutieron es si el código más complejo contiene más defectos (a igual tamaño). Casualmente, hace unos meses escribí un artículo (que, ampliado, es uno de los capítulos de mi tesis) que aborda parcialmente este problema.

Las conclusiones del artículo fueron que diferentes métricas de tamaño y complejidad están altamente correlacionadas, y por lo tanto proporcionan la misma información. Respecto al número de defectos, esto querría decir que cualquiera de las métricas estudiadas sería tan válidad como otra para predecir defectos, y que por tanto, el número de defectos se puede predecir simplemente con tamaño.

Esto tiene dos implicaciones: o bien el código más complejo no contiene más defectos, o bien las métricas que se suelen usar para medir complejidad no están midiendo realmente complejidad.

Yo me inclino más por la segunda opción. Las métricas clásicas sobre complejidad no son buenas.

Esto nos lleva a la cuestión de qué es la complejidad del software, y cómo medirla. Un amigo está trabajando en el tema, intentando medir complejidad usando una métrica curiosa. Él supone que cuánto más variable sea la estructura del código, más esfuerzo será necesario para entenderlo, y por tanto más complejo será. Está trabajando en un artículo, que publicará en breve, en el que mide complejidad como la varianza de la distribución del número de espacios de indentación del código. Por ejemplo, la declaración de una función tiene 0 espacios, pero el código dentro de la función tendrá 2 ó 3. Si hay bucles, condicionales, etc, el indentado variará. Cuánto mayor sea esta variación, mayor será la complejidad. Ésa es su hipoesis. Así que ha medido eso para una muestra de ficheros. Luego compara su métrica con otras medidas de complejidad, y comprueba que existe correlación. Su conclusión es que esa métrica es por tanto buena para medir complejidad. El problema es que para hacer este test ha usado las métricas que yo he comprobado ya que están altamente correlacionadas con tamaño.

Así que a pesar de que es una idea ingeniosa, creo que habrá que seguir mirando una manera sencilla de medir la complejidad del software.

Para buscar una métrica adecuada, tenemos que pensar que un código más complejo es el que demanda más esfuerzo de nosotros a la hora de entenderlo y ser capaces de modificarlo. Teniendo en cuenta esto, mi primera opción es mirar a las dependencias entre ficheros de código fuente. Lo que más odio cuando leo un programa grande, es tener que andar dando saltos de fichero en fichero siguiendo el flujo del programa, o una determinada parte del programa. Además, si cuando cambias algo en una parte rompes cosas en muchos otros sitios, eso significa que el software es más complejo porque requiere más esfuerzos para entenderlo y cambiarlo.

Pero no me gusta demaiado esta métrica, porque en realidad es una medida global de la complejidad. Esa métrica no tendría sentido para un fichero aislado. Y sin embargo entender un solo fichero puede ser tan o mucho más complicado que entender un conjunto de ficheros.

Así que le he seguido dando vueltas al tema. Otra de las sesiones sobre mitos iba sobre clonado de código. Normalmente, se piensa que tener clones de código en un programa es malo. Si tienes que cambiar algo por que hay un fallo en una porción de código, y esa porción está repetida en muchos sitios, tendrás que ir buscándola para arreglar el fallo en muchos sitios diferentes.

Esa es la teoría. En la práctica, los desarrolladores clonan código a modo de patrones. Existen varias razones. Una es que el código sea tan complejo como para entenderlo del todo, y por tanto es mejor copiarlo, pegarlo en otro sitio, y hacer las modificaciones que se necesiten. Otra es que normalmente los ficheros tienen dueños, así que si necesitas una parte de código que no puedes controlar porque no te pertenece, la copias en otro sitio para controlarla, y asegurarte contra cambios que no puedes controlar.

En cualquier caso, parece que en proyectos de software libre hay más clonado del que en teoría sería deseable. Y sin embargo se hace precisamente para poder gestionar la complejidad del proceso de desarrollo. El clonado ayuda a los desarrolladores a dedicar menos esfuerzo a cambiar o entender un programa.

El clonado no es más que información redundante dentro de un programa. No tiene por qué ser exactamente código copiado. Puede haber modificaciones. Por ejemplo, los alumnos cuando copian las prácticas de programación, hacen clones. No son exactamente iguales, pero realizan la misma función. Un ejemplo tonto de clonado sería cambiar un bucle for por uno while con un contador.

Por tanto, podemos asumir que es esa redundancia la que facilita la tarea, y que la ausencia de redundancia sería una medida de la complejidad del programa. Una manera simple de medir redundancia en un programa (en cualquier fichero en realidad) es comprimirlo. Si el tamaño del fichero comprimido es muy pequeño comparado con el fichero original, es que existía mucha redundancia en el fichero original. Este método tiene problemas con el código, porque clones como cambiar un bucle for por uno while no sería detectado. Quizás sería más eficiente si en vez de hacerlo a nivel de código fuente se hiciera a nivel de código objeto (porque el código máquina de los clones se parecerá mucho entre sí).

Por tanto, algún tipo de métrica que relacione el tamaño del fichero (código fuente o código objeto) con el tamaño del fichero comprimido nos está dando una idea de la cantidad de redundancia en el fichero, y por tanto, quizás de la complejidad del programa para ser entendido o modificado por una persona.

¿Tienes experiencia programando? ¿Qué consideras tú que es una buena medida de la complejidad de un programa? ¿Qué opinas de las propuestas que menciono para medir la complejidad?

Sólo conocemos dos modos de construir cosas extremadamente complejas. Una es mediante ingeniería, y la otra mediante evolución.

Esta cita se debe a Daniel Hillis. La nombro en relación a una entrada sobre si es relevante o no que un ERP sea libre (definición de ERP).

El problema de ese tipo de software es que se ha vuelto tan complejo que es completamente inmanejable. De este modo, las empresas que adoptan una determinada solución, quedan atrapadas en ese proveedor, porque el software es tan complejo de gestionar que ni la misma empresa ni algún otro proveedor se podría hacer cargo de esa gestión.

Puede parecer que el hecho de que sea libre o no, no es relevante. En realidad, lo que sí es relevante es cómo se diseña el software. Si se ha hecho en un grupo pequeño y controlado, diseñado desde cero conforme a estrictos requisitos, debido a su complejidad, acaba dando lugar a una mala solución. En otras palabras, puede que si es libre o no carezca de relevancia. Pero si se ha construido por ingeniería o por evolución sí que es relevante. Casualmente, la mayoría del software libre se desarrolla por evolución, y la mayoría del software propietario por ingeniería.

En la entrada original que mencionaba se pone como ejemplo la pila Linux+Apache+MySQL+PHP, que tan usada ha sido tradicionalmente en el mundo del desarrollo web. Estamos ante un ejemplo de solución desarrollada por evolución. Cada parte de la solución ha sido desarrollada por equipos diferentes. Es más, todas las partes de la solución son proyectos de software libre, que en mayor o menor medida se han desarrollado por evolución más que por ingeniería.

En realidad, esta idea no es nueva. En 1997 Eric Raymond exponía las mismas ideas en su artículo “La catedral y el bazar”. El software no libre suele construirse como se hacían antiguamente las catedrales. Un grupo cerrado de diseño, una obra inmensa, se tardaban años en finalizarla. El software libre funciona más como un bazar. Cada pequeño puesto realiza su trabajo, cada uno persigue su interés, pero sin embargo pueden llegar a construir algo complejo por medio de colaboraciones. No sé si Raymond tenía la frase de Hillis en mente cuando escribió su trabajo, pero la idea es básicamente la misma.

Puede que esto sólo sea un ejemplo, y existan contraejemplos de soluciones libres que han fallado, o de soluciones propietarias muy complejas que se desarrollan con éxito.

La evolución de proyectos de software viene siendo estudiada desde hace 30 años. El pionero en estudiar la evolución de un proyecto de software fue Manny Lehman. Su trabajo se puede resumir en las conocidas como leyes de Lehman. Estas leyes son las conclusiones que se extrajeron al estudiar la evolución de OS-360, que es un ejemplo de un sistema complejo diseñado por ingeniería.

Algunas de estas leyes no se cumplen en el caso de proyectos de software libre. Por ejemplo, según Lehman, conforme un proyecto de software evolucion, su crecimiento se hace más lento, porque se vuelve más complejo. Al ser más complejo, requiere más esfuerzo realizar un cambio, así que se harán menos cambios en el mismo intervalo de tiempo.

Sin embargo, algunos proyectos de software libre parecen estar acelerándose en su evolución. El caso mejor estudiado es el del desarrollo del kernel Linux

En la gráfica (haz click en la imagen) se ve el coste que hubiera costado desarrollar Linux desde cero sobre el tiempo. Por ejemplo, en un punto determinado, si se decidiera hacer lo mismo desde cero, tendría el coste indicado por la gráfica. Ese valor es proporcional al tamaño. He puesto esa gráfica porque no he encontrado ninguna otra, pero lo que quiero resaltar es el crecimiento en tamaño. Cada color indica una de las ramas de desarrollo.

Lo que es más relevante de esta gráfica es que cuanto más grande es Linux, más rápido crece. La principal excusa que suele ponerse para explicarlo es que el número de personas que aportan código está creciendo también. Sin embargo, el número de personas que participan en Linux está creciendo sólo linealmente, como muestra el siguiente gráfico (extraído del artículo enlazado):

Es decir, es cierto que el número de personas está incrementándose. Pero el código crece a un ritmo más rápido que el ritmo al que crece el número de personas. Por tanto, la productividad individual de los programadores está incrementándose. En otras palabras, están aprendiendo, y por tanto pueden escribir más código con el mismo esfuerzo.

En mi opinion es debido a que el software libre (o en general, el software desarrollado mediante evolución) se desarrolla mediante un proceso de aprendizaje, de modo que a medida que el proyecto evoluciona, la productividad es más alta, y el crecimiento se sostiene o se acelera. Este fenómeno se observa en otros sistemas también. Por ejemplo, pongamos el caso de la distribución Debian GNU/Linux. En el gráfico siguiente se muestra en el eje vertical el tamaño de Debian en millones de SLOC, y en horizontal el tiempo. Cada barra es una de las versiones estables de Debian (haz click en la imagen):

Si nos fijamos en el crecimiento que hubo entre Woody y Sarge, nos damos cuentas de un hecho notable. Debian incluye la mayoría del software libre que existe para GNU/Linux. Si algo no está en Debian, es que es no muy popular (aunque hay una excepción importante, que es el caso de Java antes de que fuera libre). Por tanto, podemos asumir que el tamaño de Debian es una buena medida del tamaño de todo el software libre más popular que existe ahí fuera. Hasta la liberación de Woody, existían unos 100 millones de SLOC de software libre escrito. Eso supone unos 6 años de historia desde la primera versión estable de Debian. En resumen, en 6 años se escribieron unos 100 millones de líneas de código.

Entre Woody y Sarge transcurrieron tres años de desarrollo. En esos tres años el tamaño se dobló. Es decir, se escribieron otros 100 millones de SLOC, pero en la mitad de tiempo (3 años). Por tanto, la tasa de crecmiento en ese período fue el doble que la tasa en el período anterior. En otras palabras, en 3 años se creó tanto software libre como en toda la historia del software libre hasta Woody.

Lo que quería resaltar con este caso es esa explosión en el desarrollo durante esos tres años.

Por tanto, parece que en los casos mostrados, que son los dos sistemas muy complejos, un diseño por evolución ha dado lugar a sistemas que funcionan correctamente. Pero lo que es más importante, es que esos sistemas contravienen las leyes de evolución. No sólo son más complejos, sino que también crecen más rápido. Quizás si se hubieran diseñado desde cero, si se hubieran creado por ingeniería, su comportamiento sería diferente.

Esto deja muchas cuestiones todavía abiertas. ¿Hasta cuándo se incrementará la velocidad de crecimiento? ¿Existe un límite físico para el tamaño de un proyecto de software? ¿Existe un límite en la capacidad de aprendizaje de los desarrolladores? ¿Supondrá problemas este crecimiento tan rápido? ¿O por el contrario este crecimiento posibilita una rápida adaptación del proyecto al entorno?

Pero la cuestión que más me interesa a mí ahora mismo es cuál es el mecanismo detrás de este fenómeno. En la naturaleza ya se han dado fenómenos similares de crecimiento explosivo. Por ejemplo, durante el período cámbrico se produjo un crecimiento explosivo en el número de especies que existían en la naturaleza. Menciono este ejemplo porque existen investigaciones que muestran que un modelo matemático basado en el concepto de coopetición es capaz de explicar la dinámica de la evolución de las especies, incluídos fenómenos como la explosión cámbrica. Quizás se podrían aplicar los mismos conceptos y modelos para explicar por qué existe este patrón de crecimiento en el caso de software desarrollado por evolución. Es una lástima, porque no creo que llegue a tiempo como para que incluya esta idea desarrollada en mi tesis doctoral.

En cualquier caso, lo que intentaba demostrar es que en el caso de un proyecto muy complejo, sí que es relevante el hecho de que sea libre, porque un proyecto de software libre puede desarrollarse por evolución, lo que posibilita que se realize con éxito y de manera más rápida que en un entorno cerrado.

Los profesores del máster serán los integrantes de Igalia y del grupo de investigación Libresoft. Además, se contará con seminarios impartidos por figuras de reconocido prestigio en el mundo del software libre (que además asesoran en los contenidos del máster):

• Richard Stallman, presidente de la FSF y fundador del proyecto GNU.
• Miguel de Icaza, vicepresidente de Novell, fundador del proyecto GNOME e impulsor del proyecto Mono
• Bdale Garbee, jefe tecnológico del área Open Source & Linux de HP a nivel mundial, y presidente de Software in the Public Interest.
• Alberto Abella, director de desarrollo corporativo de la Fundación CENATIC, y coautor del Libro Blanco del Software Libre en España.
• Marcelo D’Elia Branco, coordinador del proyecto Red Internacional de las Administraciones Públicas por el Software Libre.

El máster tiene 60 créditos ECTS, de los que 12 corresponden al prácticum y 8 a la tesis de máster. Telefónica ofrece dos becas de 3000 Euros para la matrícula para aquellos alumnos cuyo trabajo se centre en el Proyecto Morfeo. Así mismo, Igalia ofrece otras dos becas de 3000 Euros para alumnos cuyo trabajo se centre en el proyecto GNOME.

El programa del máster cuenta con las siguientes asignaturas:

• Introducción al software libre

  Esta asignatura explicará los conceptos más basicos relativos al software libre, licencias y aspectos legales, la historia del software libre, situación actual, cuál es la relación de las empresas con los proyectos de software libre, etc.
  
  En este curso se sentarán los conceptos básicos necesarios para seguir el resto del máster.

• Dinámicas de las comunidades de software libre

  Los proyectos de software libre se suelen desarrollar en una comunidad en Internet. Tras haber explicado los conceptos más básicos en la asignatura Introducción al software libre, este curso explicará cómo se estructura un proyecto típico de software libre, qué sistemas suelen tener, cuáles suelen ser los roles en la comunidad, qué herramientas se emplean para mantener la comunidad, etc.
  
  Además, esta asignatura incluirá métodos de investigación para extraer información de las comunidades, que son útiles para caracterizar y gestionar el proyecto.
  
  Tras haber curso esta asignatura, el alumno habrá aprendido cómo las personas y las empresas se relacionan en la comunidad para sacar adelante el desarrollo del proyecto, y cuáles son los procesos que marcan el día a día en el proyecto.

• Desarrollo de software libre

  Una vez que el alumno aprendido cómo funciona un proyecto de software libre, esta asignatura introduce los aspectos más técnicos que se pueden encontrar en un proyecto típico. Se presentarán las diferentes herramientas de desarrollo, bibliotecas, frameworks, etc, que se suelen usar. Además de acerca del código fuente, se tratarán otros temas como internacionalización, traducción, desarrollo multi-plataforma, accesibilidad, etc.
  
  Tras haber cursado esta asignatura, el alumno será capaz de colaborar en un proyecto de software libre, ya sea escribiendo código o ayudando en la escritura de documentación, traducciones, etc. Además, habrá aprendido cuáles son los mecanismos y procesos que se usan para que se acepten estas colaboraciones. Por ejemplo, cuál es el mejor modo de proponer un cambio y enviar un parche.

• Calidad en el desarrollo de software libre.

  El software libre no vive únicamente de escribir código. Los proyectos normalmente sólo liberan el código fuente, pero no lo compilan o lo paquetizan de modo que esté preparado para ser usado por cualquier persona sin conocimientos técnicos.
  
  De esta tarea se suelen encargar las distribuciones. Ejemplos famosos de distribuciones son Debian GNU/Linux, que obtiene el software de la distribución de los proyectos originales, los compila para diferentes plataformas, crea los paquetes, y lo pone todo junto en la distribución, de modo que sea pueda instalar de manera más o menos sencilla por parte de usuarios sin conocimientos técnicos profundos.
  
  De hecho, gracias a que el software es libre, muchas compañías desarrollan productos comerciales realizando precisamente esto, es decir, convirtiendo el software original en una distribución usable y fácilmente instalable. El ejemplo más típico es Ubuntu.
  
  En este curso se explicará cómo se crean los paquetes, y cómo se transforma un proyecto de software libre en un producto fácilmente usable e instalable. Además, se tratarán otros temas como calidad de software y certificación de calidad.
  
  Tras haber cursado esta asignatura el alumno habrá aprendido cómo se controla la calidad en un proyecto de software libre (por ejemplo, con sistemas de seguimiento de fallos, testing, etc), y cómo se transforman las fuentes originales en un producto fácilmente usable e instalable.

• Integración de sistemas con software libre

  El software libre se emplea ya por multitud de empresas en el mercado de servidores. Por ejemplo, IBM vende sus servidores con GNU/Linux. O el servidor web Apache, que es el servidor web más usado en Internet, por delante de productos como Internet Information Server de Microsoft.
  
  Éstos son sólo dos ejemplos de los muchos servicios que hoy en día se ofrecen usando software libre.
  
  En esta asignatura, se mostrarán diferentes campos dónde se emplea software libre como plataforma principal. Entre otros, se explicarán servidores de correo, servidores web, de mensajería instantánea, de VozIP, etc.
  
  En el curso se explicará cómo instalar y administrar esos sistemas, y cómo migrar sistemas existentes a software libre.

• Estudios técnicos detallados

  Cómo asignatura final, se presentarán varios estudios técnicos detallados de algunos proyectos seleccionados. Entre estos, el kernel de Linux, la distribución Debian GNU/Linux, el escritorio GNOME, Maemo, otros sistemas embebidos, etc.
  
  Tras cursar esta asignatura, el alumno habrá adquirido un conocimiento profundo acerca de los proyectos estudiados. Además, habrá aprendido las metodologías y las herramientas usadas en el análisis de esos proyectos. Estos estudios deberían servir como base para realizar la tesis de Máster, que será precisamente el estudio detallado de algún proyecto seleccionado por el alumno.

Por último, me gustaría señalar que el máster tendrá un alto contenido práctico. Las asignaturas se estructurán usando los mismos sistemas que se encuentran en un proyecto típico (listas de corre, servidor Subversion, bug tracking system, wiki, etc), de modo que los alumnos se familializarán desde el primer día con las tecnologías que se usan en el mundo del software libre. Las prácticas de las asignaturas fomentarán que los alumnos aporten su trabajo como contribuciones a proyectos de software libre, valorando positivamente todas las contribuciones que sean aceptadas.

Al final del máster, el período de Practicum se llevará a cabo en alguna de las empresas colaboradoras, y se pondrán en práctica todos los conocimientos adquiridos.

De este modo los alumnos tendrán la visión de las dos facetas principales del mundo del software libre: desde la comunidad contribuyendo a proyectos, y desde la empresa usando software libre como elemento de negocio, y contribuyendo a la comunidad desde la empresa.

Si te interesa este máster, está abierto a titulados universitarios (ingenieros técnicos, ingenieros, diplomados y licenciados). Recuerda, el plazo termina el 28 de septiembre. Aquí están las instrucciones para matricularse.