Hackers de bien

Estos días Antonio ‘Error 500’ Ortiz se ha marcado un par de entradas en el blog que me han llamado poderosamente la atención… por un lado El valor de Change.org y de la cultura de la adscripción y, por otro, Derechos civiles, intelectuales y “geeks” (no os perdáis el origen, Geeks are the New Guardians of Our Civil Liberties), que están íntimamente relacionadas entre sí (y si alguien no seguía Error 500, también puede aprovechar para repasar Aaron Swartz, in memoriam, bastante en la línea).

El tema lleva, casi automáticamente, a pensar en un puñado de proyectos que han visto la luz en los últimos tiempos, como España en llamas, Fixmedia.org o tuderechoasaber.es, por citar los tres que más han sonado en mi entorno (por cierto, todoos ellos salidos de esa fantástica fábrica de proyectos que es GOTEO, de la que hemos hablado recientemente en Mosaic, por aquello de tirar aún más de serendipia). Además, los dos últimos manifiestan características prodemocracia que me llevan al siguiente punto…

En unos días marcados por iniciativas legislativas populares y los problemas de nuestros partidos políticos mayoritarios con entender la democracia y lo que esta significa, los problemas de legitimidad con que carga Change.org últimamente me retrotraen a una iniciativa de la que me hice eco por aquí hace cosa de dos años y medio y que podría haber significado el paso adelante que Change no ha querido, sabido o podido dar hasta el momento: Usa tu DNI electrónico: recogida de firmas con e-ilp.org (que también recogieron en su momento Antonio en Recogida de firmas en internet con DNI electrónico e Ismael Peña en Firma online contra el Canon (este último en SociedadRed, otro recurso imprescindible sobre estas materias, que echa humo estos días)). A día de hoy www.e-ilp.org (un proyecto del grupo de investigación CCSG de la UAB con el soporte del Plan Avanza del Ministerio de Industria), languidece un poco (un mal endémico y casi inevitable entre los proyectos que nacen en las universidades cuando se seca el pozo del dinero público :-S), hasta el punto que os hará saltar una advertencia de seguridad porque el certificado de seguridad, mucho me temo, debe haber caducado. Aún así, el proyecto, afortunadamente, sobrevive como Recsig en SouceForge (una de las grandes virtudes del código abierto es que facilita que el código sobreviva al proyecto que le hizo nacer).

Y de ahí saltamos a otra iniciativa genial, hackforgood.net/barcelona, que se celebrará en el Campus Nord de la UPC los próximos 1, 2 y 3 de marzo. Ojalá se pudiese recuperar, mejorar y ampliar Recsig en ese marco. Pero, aunque no se consiga, es otro escenario en que dar unos cuantos pasos más adelante para demostrar que la comunidad hacker es una de las mejores vías con que contamos para salir de una situación que se me antoja cada vez más insostenible si no cambiamos de rumbo urgentemente.

WordPress 2.7, el trailer

Pues la verdad es que ya tengo ganas de ver la peli… (Versión grande.)

(Una pequeña reflexión sobre software libre y/o de código abierto… ¿Por qué casi todos los proyectos de este estilo flojean tanto por la ‘pata’ de las interfaces, la usabilidad y la experiencia de usuario? ¿Por qué me sorprende tanto (y tan poco a la vez) que la versión de WordPress que más me apetece probar se centre precisamente en esos puntos? ¿Necesita el código abierto unas lecciones sobre el tema? ¿O quizá las necesiten, directamente, las escuelas de ingeniería en informática?)

Free cooking

Vaya por delante: si me dan a elegir entre código libre y código abierto, me suena mucho más atractivo lo de abierto que lo de libre. Pero confieso que, incluso después de haber estudiado un poco el tema, sigo sin tener muy clara cuál es la diferencia y cada vez que consulto listados de licencias de la Free Software Foundation y de la OSI me hago un lío más grande. Cortito que es uno, oiga.

Vaya por delante, también, que, por filosofía, tanto ‘open’ como ‘free’ me suenan mejor que ‘closed’ o ‘proprietary’, pero que tengo por casa copias legales de Windows XP, de Vista, de Microsoft Office y un buen montón de software de Adobe. De la misma manera que tengo corriendo algún Linux y copias de OpenOffice.org, The Gimp o Inkscape. A igualdad del resto de factores, me quedaré con la solución abierta/libre sobre la cerrada/propietaria. Y a falta de una cuenta corriente infinita, lo gratis suena más atractivo que lo comercial, también (aunque no, no confundo ‘free as in free speech’ con ‘free as in free beer’).

Viene la cosa porque releo las anotaciones de Isma (Richard Stallman: Free Software and Beyond) y Julià Minguillon (Be free, my friend) sobre la charla de Richard Stallman en el FKFT (que me perdí, cosas que pasan, a pesar de currar un par de días de voluntario en la conferencia) y me vienen a la cabeza diversas cosas.

La más importante, sobre todo, por una anotación que recoge Isma de lo dicho por Stallman: que la analogía con las recetas de cocina es la mejor para comprender las cuatro libertades del software libre. Ciertamente, ¿no deberían garantizarse universalmente las cuatro libertades de las recetas de cocina?

  • La libertad de elaborar una receta, para cualquiera (libertad 0).
  • La libertad de estudiar una receta y adaptarla a tus necesidades (libertad 1). El acceso al ‘código’ de la receta es una precondición para esta libertad.
  • La libertad de redistribuir copias de la receta para ayudar al prójimo (libertad 2).
  • La libertad de mejorar la receta y publicar tus mejoras, para que toda la comunidad se beneficie (libertad 3). De nuevo, el acceso al ‘código’ es una precondición.

Hablamos de comida y no creo que nadie me discuta que la cocina es tan esencial como el software para la humanidad (habría, incluso, quien llegaría a decir que la cocina es más importante…). Tampoco discutirá nadie que es vital (nunca mejor dicho) la existencia de un corpus de recetas libres y abiertas, amplio y bien documentado.

Y sin embargo, todos (o al menos todos los que vivimos en el primer mundo y disponemos de una renta digna) hemos ido alguna vez a algún establecimiento de comidas que vulnera impunemente las cuatro libertades y, de regalo, no revelaría los secretos de sus recetas ni a punta de pistola. Corre por ahí una cierta compañía de refrescos con burbujas que, de hecho, considera su principal patrimonio el ‘código fuente’ de una de sus bebidas. Y puede que sean malvados, pero a casi nadie se le ocurriría decir que lo son por no divulgar sus recetas…

Además, la existencia de este tipo de empresas y establecimientos no atenta contra ese vital recetario libre y universal. Si hasta hay una OpenCola… Y, curiosamente, que exista un modelo de negocio basado en las recetas de código propietario y cerrado tampoco impide que el negocio alrededor de las recetas abiertas y/o libres sea boyante, incluso en tiempos de crisis. Enciéndase la tele un día de diario hacia el mediodía y podrán presenciar el trabajo de diversos ‘gurús de la receta libre’ que publican con total alegría [parte de] su propiedad intelectual y se ganan muy bien la vida con ello. Me han comentado, además, que hasta en las librerías se pueden comprar cientos de libros que publican el ‘código’ de infinidad de recetas. Muchos restaurantes viven de la explotación del ‘recetario libre’ porque disponer de la receta y convertirla en un plato no son la misma cosa: aún teniendo la receta usada por el restaurante en casa existen múltiples razones para pagar por que te la ‘ejecuten’: ahorro de tiempo y esfuerzo, que la ejecución del cocinero del restaurante es mejor que la nuestra… Existen estimaciones, de hecho, que dicen que el negocio alrededor del recetario abierto/libre es mucho mayor que el que se ha formado alrededor del modelo cerrado/propietario: parece ser que las industrias de las materias primas y los utensilios sacan mucho más del que cocina recetas abiertas y libres en casa que de los restaurantes cerrados. Hasta existen modelos mixtos: instituciones que obtienen beneficios de su ‘recetario cerrado’ y que también lo hacen de la ‘liberación’ de recetas… Finalmente, sin que nadie se rasgue las vestiduras, son multitud los que toman una receta abierta, la modifican para mejorarla… ¡y no publican el resultado!

Impresionante, ¿no?

Existen diversos factores que contribuyen al buen funcionamiento de la cosa:

  • Ni el recetario libre/abierto ni el cerrado/propietario están en peligro. Nada indica que vaya a dejar de hacer restaurantes ‘propietarios’ a medio plazo. Mientras tanto, el ‘recetario libre’ goza de indudable salud (comparativamente mejor en tiempos de crisis). Y tampoco tenemos monopolios. La oferta de establecimientos de cualquier tipo de comida es, casi intrínsecamente, no-monopolizable. Incluso si hablamos de comida rápida —que en ubicuidad sería comparable a sistemas operativos y suites de ofimática— el abanico de opciones cerradas/propietarias/abiertas/libres es mareante… Desafortunadamente, que esto sea así en el caso del software es, desde luego, más que discutible: aún sin hablar de programar, prefiero no saber qué porcentaje de la ‘comunidad informatizada’ podría sobrevivir sin el binomio cerrado y propietario de Windows más Microsoft Office. Parece que el ecosistema está ganando en diversidad con la cuota de mercado creciente de otras soluciones, tanto cerradas/propietarias (léase Apple) como abiertas/libres, aún siendo (¿todavía?) brutalmente minoritarias.
  • Hay múltiples garantías de calidad. A pesar del ocasional brote de legionela, podemos confiar en las recetas, tanto si tenemos acceso a ellas como si no. Cuando vamos a comer a un restaurante, independientemente del tipo de recetario que use este, existen mecanismos para asegurar la calidad y fiabilidad, tanto formales y “oficiales” (inspecciones de sanidad), como motores de recomendación ‘sociales’ o “tradicionales” (los tradicionales serían, por ejemplo, las críticas de los medios de comunicación, y van con doble comilla porque qué puede ser más tradicional que las recomendaciones sociales, en este caso) y ‘reglas de sentido común’ más o menos universalizadas (si el establecimiento está sucio, no entramos; si un restaurante está lleno y el de al lado vacío, querrá decir algo). De nuevo, cosas que pasan mucho menos en el mundo del software: ¿quién garantiza la calidad del software? La espantosa (aunque comprensible) y casi universal falta de cultura y educación informática impide a la inmensa mayoría elegir con un mínimo criterio entre dos o más alternativas. Es para echarse a llorar que muy probablemente haya más gente capacitada para elegir entre el Porsche y el Ferrari que nunca se podrán permitir que entre Microsoft Office y OpenOffice.org. Lo que nos lleva a recordar que…
  • Todo el mundo tiene una cierta idea de cocinar. Si hasta yo sé calentar pasta, oiga :-P. Todos sabemos interpretar el código de una receta, ejecutarlo e, incluso, adaptarlo a nuestras necesidades si falta un ingrediente o somos siete a cenar, y no cuatro. Hasta me atrevo a aventurar que son mayoría los que saben implementar sus mejoras a una receta, aún con las notables variaciones en aptitudes y formación para hacerlo (redistribuyan o no posteriormente esas mejoras). De nuevo, algo que no pasa con el código. Ni siquiera con la informática en general, como comentábamos antes.

Y todo esto me lleva a pensar que además de fomentar el desarrollo y uso de software de código libre y/o abierto, existen otras medidas tan o más importantes, a las que sería conveniente dedicar más esfuerzos que a la satanización del modelo cerrado:

  • Luchar contra los monopolios. Aún limitándonos al software cerrado/propietario, no es sano que una solución tenga una cuota de mercado del 90%. Y soy de los que opina que debería hacerse todo lo posible, además, para que en cualquier campo de aplicación lo suficientemente amplio exista una opción libre/abierta. Si para ello deben usarse fondos públicos, adelante.
  • Asegurar la calidad. Tantas cosas dependen del software… Una hoja de cálculo decide cuánto pagaré de hipoteca. Un par de líneas erróneas en el código de un alcoholímetro pueden resultar en una multa injusta o dar con los huesos de alguien en la cárcel (o dejar que siga circulando quien no debería). Un cambio de unidades mal hecho estrelló una sonda espacial contra Marte. Un signo cambiado en un programa de cálculo de estructuras puede matar. Un generador de números aleatorios mal ejecutado supone un problema para la seguridad de los que navegamos por la red, por no hablar del sistema financiero mundial. Ni el software abierto ni el cerrado están libres de pecado y tampoco hace falta ser alarmistas (de momento las cosas no nos van tan mal), pero hay que asegurar la calidad del software. Y eso implica procesos certificables en el desarrollo de software y, muy probablemente, en el caso del software cerrado, al menos la disponibilidad, limitada pero universal, del código fuente de prácticamente cualquier aplicación. El uso de estándares bien documentados es también uno de los hitos del camino de la calidad del software.
  • Fomentar la cultura informática. ¿Hace falta que todo el mundo sepa programar de manera competente? Probablemente ni tan solo sea una meta alcanzable (cuando ningún sistema educativo garantiza, ni siquiera, que todos seamos capaces de jugar al fútbol de manera competente :P). Pero quizá sí deberíamos saber todos qué es un algoritmo y ser conscientes de la complejidad de desarrollar software. Y me parece de cajón que unas ciertas competencias informáticas/ofimáticas son imprescindibles para casi todos. Añadamos, además, que no podemos hablar de cultura informática si nos limitamos a una única solución. Sea del tipo que sea: claman muchas voces contra un sistema educativo dependiente de las soluciones cerradas de Microsoft, pero haríamos un flaco favor a aquellos a quienes enseñamos si nos limitáramos a las soluciones de Apple o erradicáramos el software propietario del currículo, si este es competitivo y la solución imperante en el mundo laboral. Por poner un ejemplo no canónico: ¿qué escuela de diseño se atrevería a trabajar solo con Inkscape y obviar la existencia de Illustrator? Y como con todo, educar en diversidad es muy difícil e implica sacrificios: el tiempo es finito y si no enseñamos una suite ofimática, sino dos, restamos del tiempo que podríamos/deberíamos dedicar a otros apartados del currículo…

Pues eso. Otro día más ;-).

¿Symbian en abierto?

De hecho, no es tan sorprendente. El principal damnificado con la aparición de Android es Symbian (y, por extensión, Nokia): si un fabricante de móviles quiere un sistema operativo para sus smartphones, puede (i) querer el de Apple, pero ‘va a ser que no’, (ii) querer el de Microsoft, que tiene sus cosas, y pagar por ello (iii) querer el de Nokia y pagar por ello o… (iv) optar por Android y ahorrarse la licencia pero contar con el desarrollo de Google. No es difícil imaginar que eso iba a acabar con las ya de por sí licencias de Symbian que no son de Nokia. O sea que en una huida adelante, cuentan en ZDNet, Nokia ha comprado la parte de Symbian que no le pertenecía y ha anunciado que liberará el código y dejará de cobrar por las licencias… Una gran noticia para los usuarios de smartphones :-).

Difícil, esto de hacer un navegador

Ahora que el tema del desarrollo de los cuatro “grandes” navegadores (esto es, el grandote, el mediano y los dos chiquitines, si hablamos de cuota de mercado) está tan de moda (los dos renacuajos han pasado la prueba del ácido, el mediano apunta a su tercera versión pronto y prepara la cuarta, el grande está llegando a la 8 cuando la 7 aún no tiene mucha tracción…), resulta muy interesante la entrevista con Asa Dotzler en Wired, que trata, entre otros temas, de la brutal complejidad de mantener un gran proyecto de software como Mozilla, desarrollado a medias por profesionales a sueldo de la Mozilla Foundation y la gran comunidad de programadores que orbita a su alrededor. Me quedo con dos detalles:

  • Al igual que Linux y muchos otros grandes proyectos de software libre, Firefox no es una democracia en la que las cosas se decidan de acuerdo con la opinión de las mayorías. En el caso concreto de Firefox, la estructura es meritocrática y, además, cada uno de los diferentes módulos tiene un “propietario” con nombre y apellidos que es quien toma las decisiones finales.
  • La que para mí es la característica definitoria de Firefox, su arquitectura de extensiones, en sus inicios no era más que una solución para evitar la deserción de muchos desarrolladores, que se habían frustrado al ver que las características que habían creado no se incluían (o más aún, eran eliminadas) del código del navegador para evitar la “featuritis”.