Curso sobre las comunidades

Hace unas semanas que hemos iniciado el curso de “Dinámica de las comunidades de software libredel máster. En este curso, llevado por los libresofts, hemos tenido la oportunidad de acercarnos a algunas de las herramientas, papers y proyectos de investigación punteros sobre las comunidades de software libre. Son tan punteros .. que algunos son secreto de estado … o están a penas en fase beta! (que, de cualquier modo… es la fase habitual de un proyecto de software).
A través del estudio de 3 proyectos de cliente de correo (Balsa, Evolution, Sylpheed) hemos tratado varios temas como la estructura social subyacente a un proyecto, el proceso de integración en uno, roles presentes, …

En siguientes post, trataré de hacer una breve introducción al uso de algunas herramientas. Pero para ir abriendo boca, podéis seguir los materiales del curso desde mi slideshare o investigar a partir de los enlaces del del.icio.us etiquetados como freeswmaster.

Y para los paparazzi … algunas fotos también estoy sacando 😛 (aunque ya menos.. verdad compañeros?). Para comprender lo bien que nos lo pasamos, sólo hay que ver la sonrisa de Isra cuando se pone en plan apocalíptico… ¿qué pasaría si … ? y entonces le viene esa sonrisa de Dr. Maligno a la boca… en fin, profesores… 😀

Los mumis del software libre

En los últimos posts, he tratado de introducir los conceptos de potlacht y mumi, para, a partir de ellos, construir una analogía con la actualidad. Aceptando ahora esas condiciones de partida, podemos centrarnos de lleno en explicar el papel de los mumi y preguntarnos quiénes son los del siglo XXI.

Como hemos explicado, en entornos económicos que siguen la lógica de la abundancia, como en el software libre, aparecen ciertas estructuras y agentes especiales: los potlacht y los mumi por seguir la terminología de Harris.

Asociando esos patrones antropológicos con la época actual, parece sencillo defender que, por ejemplo, Richard Stallman o Google (enlazo a un listado de servicios y productos) son nuestros actuales Mumis, puesto que consiguen agregar voluntades en torno a un proyecto ideológico o facilitar el uso masivo de las herramientas asociadas a internet (gmail es sin duda la killer app de los correos on-line, blogspot fue la plataforma de referencia en los blogs, con google docs han reinventado la manera de trabajar, …).

Por otro lado, el patrón potlacht, puede perfectamente asociarse con los bounties (eventos que tratan de incentivar la creación de código libre), de los que ya hablamos. Pero de hecho, podemos ir más allá y decir que el potlacht, podría asimilarse a la manera misma en que se construyen algunos proyectos de software libre: agregación de múltiples voluntades convergentes de un modo intenso y durante un intervalo de tiempo limitado, pero cuyo esfuerzo repercute (o se redistribuye) a toda la comunidad (con la creación del producto/servicio).

Es ésta idea la que he rescatado brevemente (y de la que prometí escribir chicos :D) durante el curso que estamos tomando ahora en el máster (dinámica de las comunidades de software libre).

Me parece muy interesante esta analogía porque si la clave de un proyecto libre es crear la comunidad, conocer los patrones del entorno en que nos movemos es imprescindible.

¿Hacia un modelo distribuido de repositorios de software?

En el anterior post he tratado de mostrar lo ocurrido con la wikipedia y tendencias futuras de ese modelo. Ahora, toca imaginar si en el mundo del software puede ocurrir algo similar. De igual modo que la tendencia hacia la especialización de la wikipedia parece ser de dos tipos (contenidos locales, contenidos temáticos), la pregunta es … ¿podrían aparecer esas dos tipologías de repositorios? ¿Le sucederá a SourceForge lo mismo que a la Wikipedia?
Bien. Realmente esto ya está ocurriendo, aunque de manera aún distinta. Además de los grandes repositorios (sourceforge, freshmeat, berlios, …) empiezan a emerger otros cientos de repositorios. En España, por ejemplo ya tenemos varios: la pionera forja de la comunidad de Extremadura (forjamari), la de Andalucía, la de Galicia que se ha subido al carro hace poco(asociada al proyecto mancomún), etc. Pero no me confundáis, más allá de tratar el tema de la autonomización de las forjas en España, me interesa explorar el futuro de los repositorios de software.

Extrapolando en las mismas condiciones que para el caso Wikipedia, tendríamos:

  • Repositorios con contenidos locales (forjas autonómicas, regionales, … ). En este sentido sólo puedo imaginar la utilidad futura de estas forjas como repositorios por idiomas. Es decir, que por ejemplo, la forja gallega se especialice y se convierta en el lugar de referencia para encontrar los programas en gallego (además de en los respectivos sitios de los programas, claro).
  • Repositorios temáticos o identitarios. Es decir, especializados por los actores a los que va dirigido, por sectores profesionales, etc. Por ejemplo, sería muy útil un repositorio con todo el software adecuado a las necesidades de los ayuntamientos, o de las ongd; o por temática profesional (software de edición gráfica y video, soft de ingeniería civil, …).

Creo que esto puede ocurrir porque existen los incentivos (pero que pueda suceder no significa que necesariamente suceda; ni que suceda de la manera que he descrito).

Los incentivos existen porque poco a poco (a medida que el software libre va ganando terreno) se va haciendo necesaria la función de discriminar el producto/aplicación según las necesidades de cada actor específico.

Es claro que existen otras maneras de que se materialicen los incentivos… y también trataremos de hablar en breve de ellas. Pero volviendo ahora a la idea que propongo, sin duda, ésta mejoraría la experiencia del usuario: si muchos ayuntamientos se descargan un soft específico de contabilidad, éste será más adecuado para ellos que la descarga de otro soft cualquiera de SourceForge, ya que en el gran repositorio que es SourceForge no ha pasado el “filtro de la identidad” (o lo que es lo mismo: un programa de contabilidad para una gran empresa ubicada en diversos países del mundo no tiene porque ser el idóneo para un ayuntamiento de 30.000 habitantes).

Por supuesto, también tendría varios inconvenientes (fragmentación de contidos principalmente). Más ponderando costes/beneficios creo que son mayores las ventajas, por lo que es probable que la tendencia hacia la especialización también se imponga en los repositorios de software.

En un principio, descartaría los repositorios por tecnologías, es decir, repositorios para PHP, para aplicaciones Java, etc. No tienen ningún sentido de cara al usuario (que busca resolver un problema); y tampoco parece tener sentido si tenemos en cuenta la alta tasa de renovación tecnológica.

Queda la pregunta en el aire… ¿caminamos hacia la especialización de los repositorios de software?

Hacia las wikipedias distribuidas

En los últimos tiempos hemos estado viendo una tendencia bastante fuerte hacia un modelo distribuido de Wikipedias. Dejando de lado el debate sobre modernismo VS posmodernismo que eso conlleva, podemos hechar una mirada sobre estos sucesos y preguntarnos si los repositorios de software no pueden seguir un modelo similar.

Las primeras en dar este paso fueron las wikipedias identitarias: la de la serie Lost (lostpedia), la wikipedia freak (frikipedia), etc. Tiempo después, Alfredo Romeo y Sergio Gómez lanzaron el proyecto Cordobapedia (lueo también la Madripedia). Empieza así a tomar forma el concepto de de Locapedia. Más información: artículo presentado en la FreeSoftwareConference [PDF] – serie de artículos en Generación Red:

Posteriormente, se retoma el fenómeno de las wikipedias identitarias y se inicia un fuerte debate sobre el modelo wikipedia (principalmente desde el entorno ciberpunk español de esa época: David de Ugarte, Enrique Gómez, …). Y nace el término contextopedia.

Sienfo así, todo el movimento de especialización de la Wikipedia parece que se profundizará en los próximos años. Si tratamos de sistematizar lo ocurrido, parece que hubiese dos patrones claros:

Una vez comprendido el proceso, podemos preguntarnos si estos mismos movimientos no podrían ser extrapolados al mundo del software… y surgen algunas preguntas: ¿podrían aparecer esas dos (u otras) tipologías de forjas ou repositorios? ¿Le sucederá a SourceForge lo mismo que a la Wikipedia? Imaginemos que sí… entonces… ¿para qué actores hay espacio y qué incentivos existen para que suceda?

Modelos de negocio en Software Libre

Luego de algunas sesiones sobre los aspectos legales relacionados con el software y los distintos tipos de licencias, hemos tratado también en la asignatura de introducción los aspectos económicos que un proyecto debe tener en cuenta.

En aras de una mejor comprensión, se pueden diferenciar dos áreas principales:

Luego de leer algunos materiales y discutir algunos casos, se hizo un ejercicio que consistió en asociar cada uno de los modelos con algunas empresas muy conocidas. En la parte de financiación obtuvimos el siguiente mapa de conceptos (hechos con la aplicación VYM: ViewYourMind):
En resumen, los esquemas de financiación pueden categorizarse según ésta sea:

  1. Pública (modelo LinEx)
  2. Privada sin ánimo de lucro (modelo FSF)
  3. Mejoras específicas (modelo Wine-Corel)
  4. Venta de servicios relacionados (modelo O’Reilly)
  5. Inversión interna (que da lugar a diversos modelos de negocio)
  6. Otros: marketplace (modelo SourceForge), donaciones, bounties (eventos que tratan de incentivar la creación de código libre)…

Por otra parte, en cuanto a los modelos de negocio, también realizamos nuestro mapa de conceptos con empresas conocidas:

Este esquema lo realizamos según la clasificación de Hecker (página personal), uno de los artífices de la liberación del código de Netscape y que actualmente trabaja para la Fundación Mozilla. Según Hecker se pueden diferenciar los siguientes modelos de negocio (que difieren un poco por los identificados en los materiales del curso):

  1. Venta de soporte y servicios asociados (modelo Ubuntu)
  2. Loss leader (venta de productos propietarios asociados al libre, modelo Ximian-Exchange)
  3. Venta de hardware (modelo Nokiamaemo)
  4. Venta de servicios (modelo google)
  5. Venta de marca (venta de derechos de uso, formación; modelo MySQL)
  6. Franquiciado de la marca (certificaciones, partners; modelo RedHat, MySQL)
  7. Sell it, Free it (modelo GNAT)
  8. Venta de productos relacionados (modelo O’Reilly)

A pesar del enfoque académico de este post, es evidente que los modelos no son estancos, que las empresas pueden usar varios de forma simultánea. El típico caso sería el de MYSQL que vende servicios (consulting, support), marca y franquiciado.

Con este post espero haber introducido los aspectos económicos de un proyecto libre. Evidentemente, no todo son facilidades… y sin embargo, el ecosistema de negocio generado por la filosofía open source es muy rico y variado.

Tipos de licencias de software (libre)

Para que un software se considere software libre debe cumplir las 4 condiciones de la Free Software Foundation (o, similarmente las 10 directrices de la Open Source Initiative). De cualquier otro modo, no lo será.

Pero en lo que respecta al licenciamento del mismo podemos destacar algunas diferencias con importantes consecuencias prácticas y filosóficas. Se pueden destacar 2 categorías principales de licencias libres:

  • Licencias Permisivas: permiten la creación de trabajos derivados cambiando las condiciones de la licencia (por ejemplo, coger el código y crear a partir de él un producto cerrado). Ejemplo: BSD.
En este punto emergen 2 preguntas principales y los debates que las siguen:
  • ¿Qué licencia es más libre? ¿La que garantiza la libertad a los usuarios en las sucesivas modificaciones (copyleft)? ¿O la que garantiza la libertad a los desarrolladores (que podrían así integrar y distribuir código con licencias libres y propietarias)?
  • ¿Cual es la mejor elección de cara a garantizar la existencia del procomún? ¿Podría con las licencias permisivas darse el problema de los free-riders (o la tragedia de los comunes) en el software?
Lo único que sabemos en la actualidad es que con la GPL (principal exponente de las robustas) se licencia el 65% de los proyectos de Freshmeat, y con la licencia BSD (como licencia permisiva principal) en torno al 6% (sumando bsd original y modificada). Y que a partir de código BSD se ha seguido desarrollando muchos proyectos libres desde hace 20 años.

Por ello, no es descabellado pensar que a pesar de existir la posibilidad de realizar proyectos cerrados a partir de licencias permisivas (y, como en un juego de suma cero, ello podría redundar en menoscabo del software libre), los incentivos para hacerlos abiertos son tales que -de momento- no tenemos el problema de los free riders en el mundo del software.

Para próximos posts (o como contribuciones vuestras a éste ;D) queda pendiente un análisis de los paquetes Debian con una y otra licencia, o incluso la cantidad de código licenciado con una y otra.

Transversalmente a estes 2 términos, se pueden analizar las licencias según sean o no compatibles entre sí. Nosotros, las analizaremos según sean o no compatibles con la GPL:

una licencia se considera GPL-compatible cuando no añade ninguna restricción adicional a las impuestas por ésta.

Como consecuencia práctica se tiene que el código con una licencia no compatible con la GPL, no puede integrarse con código GPL.

Tanto las licencias robustas como las permisivas pueden ser gpl-compatible (o no). Probablemente, uno de los casos más famosos es el de la licencia BSD. La BSD original, tenía como restricción adicional a la GPL que:

3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the University of California, Berkeley and its contributors.

Aunque pueda parecer demasiado estricta la GPL-compatibilidad, no olvidemos que pretende ser una licencia, un mecanismo legal al que aferrarse. Por lo tanto, aceptar la anterior restricción suponía abrir legalmente la puerta a otras restricciones similares.

Siendo así, el código BSD no era GPL-compatible y no podía integrarse con ningún código de este tipo. Por ello se creó la licencia BSD modificada que elimina esta restricción, haciéndose de ese modo GPL-compatible (dando soporte legal a la integración con código GPL).

Con este post, espero haber aclarado el mapa de conceptos de licencias libres y su terminología.

Y como ejercicio final para comprobar lo que has aprendido, puedes intentar descubrir qué tipo de licencia tiene la distribución Jesúx 😉 .. y postearlo en los comentarios si lo deseas 😀

De aspectos legales

Luego de las primeras sesiones sobre historia y contexto del mundo libre, la pasada semana nos tocó una de aspectos legales. Esta vez nos acompañaron Gregorio Robles y Juanjo Amor (blog).

Aunque ya tenía nociones de los problemas clave que engendra un sistema de patentes que no funciona (resumen en español [PDF]) en la era digital y la economía de la información, me han servido las sesiones de trabajo para trasladar los conocimientos al caso específico del software. Y recobrar de alguna manera el espíritu free frente al únicamente open-source.

Como ejercicios prácticos hemos realizado un debate sobre la idoneidad de la GPL v3, analizamos la Cristian Software Public License (licencia de la distribución Jesux: “a new Linux distribution for Christian hackers” 😉 ) y el simulacro de 2 juicios.

La sesión del sábado fue la más divertida. Fue entonces cuando realizamos los juicios. En el primero (yo estaba como jurado) se trataba de defender o fiscalizar la validez de la frase:

La GPL es la única licencia de software libre de verdad porque garantiza no sólo la libertad actual sino también la futura.

Roberto y Pablo lo tenían difícil como defensores… y un apabullante 0-6 se impuso en contra de la frase (y sí, estábamos en clase de un máster en software libre aunque no os lo creáis :P). La lucha semántica fué determinante: la GPL no es la “única”. Nacho y Javier se impusieron con relativa facilidad. En posteriores iteraciones, modificamos la postulación de la frase y las posturas variaban, y seguíamos discutiendo los conceptos aprendidos durante las anteriores sesiones.

Ya en el segundo juicio, Andrés E. y yo mismo tuvimos que defender la validez de la frase:

“Hay que adaptar las licencias a las normativas nacionales para asegurar su validez legal.

Partimos de un 2-2-2 (a favor-indecisos-en contra).. y acabamos en un 3-1-2 que nos dió la victoria! .. aunque con las reservas oportunas. Adrián y Pedro fueron unos rivales difíciles de batir 😀

Al final, nos lo pasamos muy bien y aprendimos lo fundamental sobre los aspectos legislativos y sus implicaciones prácticas. Qué hay que tener en cuenta a la hora de evaluar las distintas licencias.

Así, con estas 2 sesiones presenciales que llevamos (y el trabajo on-line) tenemos cubierta una primera fase de contexto del movimiento. Las siguientes serán de aspectos técnicos y económicos.

Primera semana

Mañana empieza la segunda semana del máster en software libre y aún no he dicho nada de la primera 🙁 Aún aterrizando en Coruña y sin conexión en casa.. se hace difícil actualizar y resumir cuando uno apenas tiene tiempo para digerir debates y lecturas.

En un principio, Ismael Alfaro (de Caixanova) y Chema (de Igalia y coordinador del máster) hicieron las presentaciones de rigor. Sólo entonces pudimos escuchar a los ponentes del primer día.

Lo que puedo decir de momento es que la charla de Jesús Barahona (del grupo de investigación Libresoft) ha sido muy buena, no pude ni siquiera pestañear. Aquí la tenéis… pero lo realmente interesante es oir a Jesús contando:

Por otro lado Israel Herráiz (también de LibreSoft) nos ha contado (y así lo pudimos practicar) que las asignaturas se plantean como mini-proyectos y estaremos usando en todas ellas las herramientas básicas de la comunidad como sistemas de cvs, bugzilla, listas de correo, … aprender haciendo.

Durante las clases se habla en español (excepto cuando vengan los ponentes). El resto de interactuación (listas de correo, material, trabajos, …) trataremos de hacerla en inglés, puesto que es una buena forma de sacarle en polvo a la lengua franca en el mundillo del software libre.

Y como se trata de aprender también en comunidad y dejar libres los materiales.. a título personal me he propuesto 2 cosas:

Los etiquetaré con el tag “freeswmaster” para que sean de fácil acceso. Lo demás (artículos, debates, ponencias, …) trataré de resumirlo en el blog. Será éste un lugar donde condensar lo aprendido.

Comienza el máster

Hoy comienza el Máster en Software Libre. En unas pocas horas estaremos con Israel Herráiz y Jesús González Barahona (del grupo de investigación de la URJC LibreSoft); también con Chema Casanova y otra gente de Igalia. Esto promete, aunque mi emoción nunca la pude ocultar. Tampoco mis razones.

Y en esas estamos mientras Andrés E. (otro masterando) está cogiendo un tren hacia Coruña y calentando motores… su último post es realmente clarificador. Creo que aprenderé mucho este año.. y no sólo en clase. Mucho me temo que se alarguen demasiado los cafés. Habrá que pedirlos sólos. Largos.

Me presento. Yo también soy Andrés. Andrés M. Y en este blog trataré de ir dando cabida a los previsibles debates sobre el software, su construcción, filosofía, también recetas técnicas. Pero no sólo de software vive el hombre. Y el software libre es apenas la avanzadilla de un cambio estructural mayor.

De todo ello hablaremos. Al menos, se intentará.

Ciberguerras e software libre

Hai uns días saltaba á prensa o caso dos ataques informáticos que recibiron os sistemas de Estonia. Na súa maioría a sistemas públicos, aínda que tamén a algunha entidade privada. De tal magnitude que a OTAN enviou a un enviado especial á rexión. Non tanto para axudar, como para aprender do caso estonio.

O ataque en sí foi un DDOS (ataque de denegación de servicio distribuido) que consiste en bloquea-los sistemas informáticos a base de facerlles múltiples peticións (Denial Of Service). Múltiples peticións que veñen de múltiples computadoras (Distributed DOS). Puro swarming.

Para a realización de ataques DDOS, en primeira instancia débese conseguir unha rede de computadores dende a que facelo (netbot). Os principais candidatos a ser membros destas redes son os usuarios con sistemas de seguridade descoidados: ben por falta de parches para os erros de seguridade, ben por desidia. Os atacantes, toman o control deses computadores e úsanos como plataforma para lanzar os seus programas. Os métodos son os mesmos que os usados para o envío masivo de spam.

Unha vez atendida a tipoloxía do ataque (ver tamén os datos), é sinxelo comprender que -a pesar das medidas que se poidan tomar nos servidores destino do ataque- a potencia do mesmo radica no número de computadores cautivos da netbot (ata un millón parecen ser os usados neste caso). Por isto, a robustez contra ataques informáticos DDOS radica máis en aumenta-la seguridade do usuario medio que de grandes gastos nos servidores atacados.

Como indicaron Bruce Schneier e compañía hai anos: o monocultivo informático é unha peza clave da fortaleza dos atacantes. Porque a tecnoloxía non é boa nin mala, pero tampouco neutra.

Aparece así unha das vantaxes esenciais do software libre: a seguridade asociada ó mesmo. Seguridade que o goberno estadounidense xa ten en conta dentro da súa “Estratexia Nacional para asegura-lo ciberespacio“. E logo do caso Estonio, é seguro que a OTAN e a Unión Europea teñen en mente algo parecido. Mais o principal seguirá sendo asegura-los sistemas usados polo usuario medio para este tipo de ataques.

É probable ademáis que, en breve, nos vexamos enfrontados de novo a recortes dos nosos ciberdereitos. Haberá que estar alerta, porque …

cuando dos elefantes se pelean, quien sufre es la hierba