No sólo software

Una de las satisfacciones de cursar este máster es que haces cosas reales, aplicables directamente, además de aprender los fundamentos teóricos necesarios. Como ya dije, para la asignatura de introducción al software libre, cada uno de nosotros presentó un trabajo de su interés, obviamente consensuado con los tutores de la asignatura.

Y poco a poco, se están viendo los resultados de esta metodología de aprendizaje, del learning by doing. No sólo el artículo colectivo para la segunda asignatura fue presentado en el FOSDEM, sino que poco a poco los trabajos anteriores comienzan a tomar forma y a ser reseñados por publicaciones relevantes. La última, una entrevista en Código Cero.

Código Cero, la revista de tecnología de información más importante de Galicia, ha publicado una entrevista con Roberto Vieito -uno de los pocos alumnos que todavía, e incido en esto: todavía ;), no tiene blog. Hace unos meses terminó un estudio de investigación sobre el estado del software libre en las compañías de Galicia.

Ha realizado un gran trabajo de integración de datos de diversas fuentes (gallegas, nacionales e internacionales) con el objetivo de obtener un documento de análisis de la situación actual de las compañías gallegas con respecto al software libre (uso y comercialización de productos libres) así como recomendaciones finales para mejorar la situación.

Es realmente reseñable el artículo [PDF], y la entrevista. Espero lo disfrutéis. Además, la foto es tan chula .. xD

La semana pasada hemos presentado el estado de los trabajos para el curso de Introducción al software libre. Cada uno ha hecho la elección del trabajo según sus gustos, tiempos o necesidades del momento. El mío, por ejemplo, nació por tratar de demostrar con números las intuiciones/hipótesis expresadas en palabras.

En estos trabajos, además de evaluar qué se ha hecho, también se evaluará el cómo se ha hecho. Porque aquí no sólo es importante el resultado, sino también el proceso. En éste, hemos usado sistemas de control de versiones (svn) y aplicaciones para generar documentación técnica (docbook).

El sábado nos pasamos la mañana presentándolos (además de alguna que otra sorpresa recibida :D). Fueron bastante diversos y muy interesantes, aunque resumirlos en un sólo post me parece imposible ahora. Por el momento, os dejo los enlaces a cada uno de ellos:

• Guía para la traducción en KDE.

• ¿Debian Long Tail? Un estudio sobre el copyright en Debian.

• Proyectos de software libre: una aproximación basada en la teoría de colas.

• El proyecto OpenJump y sus derivados. ¿Qué ocurre cuando una empresa abandona un proyecto de software libre?
  

• Restricciones y obligaciones en la contratación de software en las administraciones públicas (estudio de la legislación a nivel europeo y español).
  

• Analizando el proceso de unión al proyecto KDE.

• El Software Libre en las compañías gallegas.

• Traducciones en proyectos de software libre.

Si queréis descargaros todos por svn no tenéis más que hacer desde la terminal en linux (y teniendo instalado un cliente svn claro):

Para descargar un proyecto en particular con svn usad la dirección con la que lo enlazo. Por ejemplo, para el estudio sobre OpenJump sería:

Estoy aprovechando las vacaciones para finalizar mi trabajo final de asignatura. En la materia de introducción del máster se han tocado varios temas de soslayo, muchos de los cuales me interesan enormemente, por lo que me ha costado realizar la propuesta. Finalmente tuve que descartar otros 2 que tenía en mente:

Si hasta los títulos tenía.. pero de igual modo que en las películas, uno es esclavo de sus palabras y tiene el derecho a permanecer en silencio… aunque pocas veces yo lo ejerza xD

Me explico. Veréis, durante una de las clases, Gregorio nos presentó un paper sobre el copyright de Debian a lo largo del tiempo. El estudio formaba parte de la nueva rama de investigación que quiere iniciar la gente de Libresoft y que trata de responder a la pregunta: ¿cómo las comunidades de usuarios y las compañías colaboran en el desarrollo de software libre?

Este estudio en concreto, consistía en analizar el copyright de todos los paquetes incluidos en debian con el objetivo de determinar a quien pertenecía. Los resultados son claros: el porcentaje de código con copyright de las empresas era del 14% en la Debian Hamm (1998) y supone un 20% en la Debian Sarge (2005), una cantidad no despreciable pero tampoco demasiado relevante con respecto a la producción individual (en torno al 60%).

Este resultado podría dar a entender que la presencia de las empresas en la comunidad (como desarrolladoras de software) es muy limitada y que se están especializando en otras tareas, por ejemplo: márketing, comercialización de producto, integración, etc.

Fue entonces cuando me erigí en defensor de las empresas como desarrolladoras (Roberto, luego de nuestra experiencia con la empresa CAD… todo ha cambiado! ;D). Como decía, me erigí en defensor de la producción empresarial diciendo algo como:

Me parece que la participación de las empresas está distorsionada por la naturaleza del estudio.

Si -tal y como supongo- la distribución del tamaño de los paquetes en Debian sigue una distribución paretiana, es decir, un modelo Long Tail, existirán muchos paquetes muy pequeños creados por un sólo desarrollador individual, concentrándose la participación de las empresas en los paquetes de mayor tamaño.

Creo que si realizamos el mismo análisis para el 20% de los paquetes de mayor tamaño (por seguir la ley de pareto), el copyright en manos de las empresas aumentará notablemente y superará al copyright de personas individuales. Esto dará una medida de la participación más realista, ya que los paquetes mayores suelen ser más críticos: el kernel, el entorno de escritorio, el sistema de ventanas X11, etc. Se podría argüir así todo lo contrario: la participación de las empresas en el desarrollo de software es crucial.

Y claro, uno no puede tirar una piedra de este calibre ante los libresoft y esconder la mano. Así fue cómo surgió mi trabajo. Por lo que, en estas vacaciones, me toca realizar análisis del copyright de Debian que demuestren -o tiren abajo- mis hipótesis.

Como además estamos en Navidad, la gente de Libresoft me ha cedido amablemente los datos recopilados en su estudio para que pueda jugar con ellos (gracias chicos!). Ahora mismo me siento como un niñito con zapatos nuevos… jugando con su copyright

• la financiación del producto
  
• el modelo de negocio asociado (o cómo retornar la inversión)

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 Nokia-maemo)
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.

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:

En este punto emergen 2 preguntas principales y los debates que las siguen:

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:

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

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.

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á.