Este libro fue originalmente publicado a lo largo del verano de 2008, como una serie de post en el blog del Premio al mejor Proyecto Fin de Carrera con Software Libre.

1. 1. 1. Aspectos legales
         1. Licencia
            1. ¿Qué es el Software Libre?
            2. Licencias robustas VS Licencias permisivas
            3. Compatibilidad de licencias
            4. Licenciamiento dual
            5. Relicenciamiento
            6. Selección de la licencia adecuada
            7. Las licencias recomendadas por Bruce Perens
            8. Artículos y Bibliografía
         2. Copyright
            1. Copyright como derecho de explotación
            2. Implicaciones legales: la Fundación Apache y la Free Software Foundation
            3. Lecciones aprendidas: Mozilla y KDE
            4. Implicaciones económicas: el caso MySQL
            5. Implicaciones sociales: el caso GNOME KDE
         3. Casos prácticos
            1. Proyectos Fin de Carrera en las universidades gallegas
            2. Kernel de linux, aspectos legales
      2. Aspectos económicos
         1. Financiación y modelos de negocio
            1. Esquemas de financiación
            2. Modelos de negocio
            3. Licenciamiento dual
            4. Conclusiones
         2. Casos prácticos
            1. Kernel de linux, aspectos económicos
      3. Aspectos sociales
         1. Arquitectura para la participación
            1. La confianza mutua
            2. La modularidad del proyecto
            3. Integración de las aportaciones
               1. Herramientas
               2. Procesos y buenas prácticas
         2. El ciclo de publicación
            1. Funcionalidades VS Tiempo
            2. Control de calidad
            3. Conclusiones
         3. Casos prácticos
            1. Kernel de linux, cultura organizativa
            2. Kernel de Linux, el ciclo de publicación
            3. GNOME, el ciclo de publicación
            4. Firefox y el caso Nitot
      4. Herramientas
         1. Una panorámica general de las herramientas
         2. Repositorios y mantenimiento del código
         3. Caso práctico: sesión de trabajo con svn y envío de parches

Aspectos legales

La única diferencia legal entre un código considerado software libre y otro propietario es su licencia.

Licencia

La licencia es el mecanismo legal mediante el cual el autor declara qué derechos sobre el programa cede al usuario. Se podría decir que es un contrato entre el autor del programa y el usuario final, donde se declara cómo y para qué puede usarlo.
Sin embargo, la autoría del software no cambia, ésta siempre es del programador y está garantizada por las leyes de copyright. Por defecto, las leyes de propiedad intelectual no garantizan ningún derecho al usuario. Es imprescindible que un programa declare que está bajo una determinada licencia de software libre para que sea considerado como tal.

¿Qué es el software libre?

Para que un programa sea considerado software libre debe cumplir las 4 condiciones siguientes:

1. • L0: libertad para ejecutar el programa, con cualquier propósito.
   • L1: libertad para estudiar su funcionamento y adaptarlo a las necesidades. Es necesario el acceso al código fuente.
   • L2: libertad para redistribuir copias del programa.
   • L3: libertad para mejorarlo y publicar las mejoras u otras modificaciones. Es necesario el acceso al código fuente.

Licenciamiento de software

Tanto la Free Software Foundation como la Open Source Initiative mantienen un listado actualizado de licencias. Aunque todas las que cumplan las 4 libertades son consideradas licencias libres, existen algunos matices importantes a la hora de decantarse por una u otra.

Licencias Robustas VS Permisivas

Se pueden destacar por lo menos 2 categorías principales de licencias libres:

1. 1. 1. 1. 1. • Licencias Robustas: exigen que los trabajos derivados se redistribuyan con la misma licencia, sin añadir ninguna restricción adicional. Son conocidas como licencias copyleft. Ejemplos de licencias robustas: GPL: GNU General Public License, LGPL: Lesser GPL, MPL: Mozilla Public License.
         1. • Licencias Permisivas: permiten la creación de trabajos derivados cambiando las condiciones originales de la licencia. Esto, por ejemplo, permite crear a partir de un código software liber un producto que no lo sea. Ejemplos de licencias permisivas: BSD: Berkeley Software Distribution, X11/MIT License, Apache.

Elegir entre un tipo u otro de licencia determinará si los programas derivados pueden o no añadir restricciones a nuestra licencia original. Esto determina, por ejemplo, si se puede crear software propietario a partir del programa libre.

Compatibilidad de las licencias

Las licencias se pueden analizar según sean o no compatibles entre sí, es dicir, el código licenciado con una determinada licencia A se puede mezclar con el código licenciado con otra distinta B.
Un ejercicio ilustrativo en este sentido puede ser estudiar qué licencias son 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 de las que antes hablábamos, pueden ser (o no ser) gpl-compatibles. 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.

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

Licenciamiento dual

Se dice que un programa tiene licencia dual o doble licenciamiento cuando tiene dos o más licencias.
Esta práctica puede ser útil cuando se libera un producto con una licencia copyleft y otra permisiva. Esta práctica ha sido desarrollada en casos notorios como el de la base de datos MySQL para permitir que -aunque el producto sea libre con copyleft- también pueda ser embebido en otros productos propietarios.

Relicenciamiento

El relicenciamiento consiste en cambiar la licencia del programa. Esto únicamente puede ser hecho si todos los agentes que detentan el copyright están de acuerdo.

1. 1. 1. 1. • Problemas de relicenciamiento de Mozilla y KDE

Selección de la licencia adecuada

La elección de licencia es el único distintivo legal entre un programa de software libre y otro que no lo sea. Antes de elegir licencia, es necesario responder a las siguientes preguntas:

1. 1. 1. 1. • ¿Podrán añadirse restricciones a la licencia original? O como popularmente se formula, ¿es necesario que a partir de tu programa se pueda crear software propietario?
            • ¿Se integrará el código con otro? En ese caso, ¿qué licencia es compatible con las necesidades?

A continuación se muestra una tabla con las restricciones y libertades que tienen las principales licencias de software:

Las licencias recomendadas por Bruce Perens

Según Bruce Perens, se podrían utilizar únicamente 3 o 4 licencias, que además son compatibles entre sí, lo que facilita la integración de código. Si tienes dudas sobre cual elegir, probablemente la mejor elección sea una de estas tres.

1. 1. 1. 1. • Apache: es una licencia permisiva, permitiría ser combinada tanto con software libre como con propietario en un trabajo derivado.
            • GPL: es una licencia robusta. Es la más popular de las licencias de software libre. Únicamente permite ser combinada con software libre.
            • AGPL o Affero GPL: igual que la GPL, pero teniendo el cuenta el caso de “Software as a Service”. La licencia GPL no obliga a compartir el código hasta que éste sea distribuido con alguien. ¿Pero qué ocurre cuando se usan servicios externos que corren en otros servidores? La Affero obliga a estes servicios a dar la posibilidad de descargar el código desde la web.
            • LGPL o Lesser GPL: es una licencia robusta. Sin embargo, a diferencia de la GPL, permite su uso con programas propietarios. Está especialmente diseñada para librerías que se cargan en tiempo de ejecución del programa (no se compila con todo el software) y que sean usadas por software propietario.

Artículos y bibliografía

1. 1. 1. 1. • Licencias de software libre, Free Software Foundation
            • Licencias de software libre, Open Source Initiative
            • Copyright and Open Source Software Licensing, de Sau Sheong Chang
            • How many Open Source licenses do you need?, Bruce Perens
            • Estudio sobre la licencia GPL v3 y otras licencias open source, Sánchez Crespo abogados y consultores

Gestión del copyright

Copyright como derecho de explotación

El copyright y la licencia de un programa son cosas distintas. La licencia es el mecanismo legal mediante el que el autor declara qué derechos sobre el programa proporciona al usuario. Sin embargo, el copyright es el mecanismo legal mediante el cual se indica a quien pertenecen los derechos de explotación del código.
Las principales implicaciones de tener o no el copyright son:

1. 1. 1. 1. • Decidir sobre los cambios/asignación de la licencia.
            • Mantener los derechos de explotación del software. Es decir, las posibles ganancias por la venta de licencias del programa repercutirán sobre los agentes que mantengan el copyright.

A efectos legales, se puede decir que mantener el copyright del código significa ser el propietario del mismo. Existen proyectos y comunidades de software libre, que a la hora de participar, exigen a sus colaboradores que se les ceda el copyright. Éste es el caso, por ejemplo, del proyecto Apache, de la Free Software Foundation y de MySQL.

Implicaciones legales: la Fundación Apache y la FSF

Desde el punto de vista legal, que el copyright sea de un único agente simplifica el proceso de relicenciamentos futuros, facilitando asimismo afrontar procesos legales, ya que grandes instituciones pueden tener más recursos económicos.
Éste es el caso de la Apache Foundation y la Free Software Foundation, que exigen a sus colaboradores que les ceda el copyright antes de aceptar sus aportaciones. Según el Contributor License Agreement de la Apache Software Foundation:

The purpose of this agreement is to clearly define the terms under which intellectual property has been contributed to the ASF and thereby allow us to defend the project should there be a legal dispute regarding the software at some future time.

así como la Free Software Foundation:

In order to make sure that all of our copyrights can meet the recordkeeping and other requirements of registration, and in order to be able to enforce the GPL most effectively, FSF requires that each author of code incorporated in FSF projects provide a copyright assignment

Lecciones aprendidas: Mozilla y KDE

A diferencia de las anteriores entidades, Mozilla y KDE no pedían cederles el copyright para contribuir. Cuando ambos proyectos tuvieron que enfrentarse a procesos de relicenciamientosufrieron las consecuencias de que el copyright estuviese distribuido entre todos los colaboradores.
La complejidad de este proceso radica en que para hacer el cambio de licencia es necesario que todos y cada uno de los detentores del copyright estén de acuerdo, y no siempre es fácil encontrar a alguien que ha colaborado con el proyecto años atrás y ahora no está de ningún modo involucrado. En esos casos la única solución es escribir esa parte del programa desde cero.

1. 1. 1. 1. • Proceso de relicenciamiento de Mozilla
            • Proceso de relicenciamiento de KDE

Implicaciones económicas: el caso MySQL

Desde el punto de vista económico, se puede decir que la cesión del copyright sustenta una de las formas en que una compañía puede ganar dinero con software libre: el licenciamento dual.
El ejemplo más conocido -aunque no el primero- de este modelo fue quizás la empresa MySQL AB. MySQL AB era una empresa finlandesa que desarrollaba la base de datos MySQL. Esta base de datos tiene la licencia GPL, es decir, se puede usar y modificar libremente, pero no se pueden realizar productos cerrados a partir del código GPL. Pero MySQL AB entendía que existían ciertos agentes que deseaban realizar productos propietarios a partir de su base de datos. Es por ello, que además de licenciarla con la GPL, también lo hacían con la MySQL Comercial License.
Tal y como lo explicaban desde MySQL:

MySQL is the owner and copyright holder of the entire MySQL product, whereas Linux does not have one single entity as a copyright holder. This makes the MySQL Dual Licensing model possible.

The MySQL users benefit from this in the form of further product development financed by MySQL (with currently over 80 developers on MySQL’s payroll). While MySQL has developed most of the MySQL database itself, and continues to do so, MySQL also wants to simplify the processes for contributors to MySQL.

El licenciamento dual de MySQL no sería posible (o sería muy complejo de implementar) si los participantes de la comunidad no cediesen su copyright a la empresa.

Implicaciones sociales: el caso GNOME y KDE

Que el copyright pertenezca a autores individuales, a una Fundación (organización sin ánimo de lucro) o a una empresa puede variar también el índice de participación de los distintos agentes.
Esto se puede comprobar estudiando el copyright de los proyectos GNOME y [http:www.kde.org KDE] (los dos principales escritorios en software libre), podemos observar distintos patrones de participación en las 2 comunidades.
En la siguiente figura se muestra el porcentaje de líneas de código asociadas a cada tipo de participante: desarrollador particular, universidad, empresa, fundación o grupo de desarrollo.

La diferencia más reseñable entre ambos proyectos es que:

el porcentaje de código debido a las empresas es 3 veces mayor en GNOME que en KDE

Esto puede ser debido a que las librerías principales de KDE (Qt) tenían el copyright de la empresa Trolltech (comprada por Nokia), mientras que las de GNOME (GTK) tienen el copyright de la Fundación GNOME y de los desarrolladores individuales. Esta característica puede ser la razón principal de la reticencia de participación de otras empresas en el proyecto KDE.

Casos prácticos

Licencias y copyright de los PFC en las universidades gallegas

Para realizar este artículo se ha contactado con los responsables de las respectivas titulaciones así como revisado los respectivos reglamentos. Tanto en la FIC como en la ETIS, el copyright pertenece de forma compartida a los autores (tutor y alumno del PFC) y existe una licencia de uso en favor de la universidad. Es distinto el caso de la Escuela de Informática de Orense, donde no existe una clara delimitación al respecto.

Ingeniería Técnica en Informática de Sistemas, Universidad de Santiago de Compostela

En la legislación de los PFC de la ETIS (PDF) se contempla lo siguiente:

Artigo 38. Dereitos do Proxecto
A propiedade intelectual do PFC, así como no seu caso os dereitos de comercialización dos productos desenvolvidos ou deseñados, corresponden conxuntamente o alumno que o realizou e o Director do mesmo. No caso de realizarse o PFC no marco dun contrato ou convenio con algunha entidade, os dereitos do PFC serán os recollidos en dito contrato ou convenio baixo o disposto na lexislación vixente.
Artigo 39. Uso dos Proxectos
O traballo e os desenvolvementos do Proxectos poderán ser utilizados na Universidade de Santiago de Compostela, sempre con mención específica ós seus autores.

Facultad de Informática, Universidad de La Coruña

Como se puede ver en el artículo 6 de la legislación de los PFC –PDF del reglamento– en la FIC, la situación es similar a la de la ETIS:

A propiedade intelectual do traballo realizado nun proxecto corresponde ó autor deste, xunto co director, de forma compartida. En calquera caso o traballo e os desenvolvementos do proxecto poderán ser utilizados para a docencia na universidade, sempre con mención específica ós seus autores.

Escuela Superior de Enxeñería Informática de Orense, Universidad de Vigo

En la normativa de los PFC (PDF) no aparece ningún apartado relacionado con la propiedad intelectual del mismo. Sin embargo, si nos remitimos tanto al reglamento general de los estudiantes (sección 3: derecho a la propiedad intelectual):

4.- Os estudiantes conservarán o dereito á propiedade intelectual dos traballos orixinais por eles realizados. A publicación ou reproducción total ou parcial, ou a súa utilización para calquera outro fin, deberá contar coa autorización por escrito do seu autor/a.

Finalmente, a raíz de la consulta realizada por el director de la EI al departamento jurídico de la UVigo (PDF), se puede decir que el copyright de los PFC en esta escuela pertenece a los autores (aunque no se especifica si sólo al alumno o conjuntamente al alumno y tutor). Por otro lado, no existe ningún sistema de licenciamento en favor de la universidad.

Kernel de Linux, aspectos legales

La licencia

El kernel es un gran proyecto con muchos módulos y código de diversos autores con la posibilidad de tener licencias diferentes. Sin embargo, debido a que en un primer momento fue licenciado con la GPLv2, las aportaciones posteriores tienen que ser compatibles con esa licencia.

En la práctica, se puede decir que el kernel está licenciado con la GPLv2, lo que significa que es posible usarlo para realizar productos derivados a partir de ese código siempre y cuando el resultado sea licenciado co una licencia compatible con la GPLv2.

La GPL y los “Loadable Kernel Modules” (módulos binarios)

Uno de los aspectos grises al respecto de licencias y copyright es ¿qué se considera trabajo derivado?, y por lo tanto, qué está sujeto a las leyes del copyright.
La idea más extendida es que un programa de software B se considera trabajo derivado de otro programa A cuando B usa código fuente de A. Siguiendo la anterior aseveración, los módulos que se cargan en el kernel en tiempo de ejecución no son considerados trabajos derivados ya que no usan el código fuente del kernel (no son compilados como un todo), si no que simplemente hacen uso de las API públicas para “conectarse” a las funcionalidades: kernel y módulo se compilan por separado y su único contacto es como binarios en tiempo de ejecución.
En este caso, sería técnica y legalmente posible realizar un [módulo propietario para el kernel].
Existen razones que desaconsejen hacerlo, éticas y de mantenimiento: al ser propietario, no es posible beneficiarse de los aportes de la comunidad; esto implica, por ejemplo, que nadie avisará de cambios en las API del kernel, ni podrán ser corregidos los bugs. Pero lo cierto es que ya se está haciendo, como es el caso de los conocidos Blobs del Kernel.

Copyright

En el kernel, el copyright de cada una de las aportaciones pertenece al propio autor que la ha realizado.

A diferencia de otros proyectos como el caso de la FSF y la Fundación Apache, el kernel no pide una cesión del copyright. Esta situación implica que un cambio de licencia debe ser negociado con todos y cada uno de los implicados.
Por otro lado, la licencia GPL posee un mecanismo que facilita el relicenciamento: existe una cláusula con la que se puede indicar que el proyecto puede usar una determinada versión de la GPL o cualquiera superior (por ejemplo: GPLv2 or later, ver punto 9 de la licencia). El kernel tampoco usa esta fórmula.

Futuros relicenciamientos del kernel

Debido a que el copyright está distribuido entre cada uno de los participantes, futuros procesos de relicenciamento del proyecto implicarán el contacto y aprobación de cada uno de ellos. Esto puede ser dificultoso como han demostrado los casos de Mozilla y KDE. En caso de no poder contactar con los autores o que éstos se opongan, la única solución sería descartar ese código y rehacerlo desde cero.

Aspectos económicos

Financiación y modelos de negocio

A lo largo de diferentes posts, hemos repasado diversos puntos de un proyecto de software libre, dende los aspectos legales hasta los organizativos. Mas una de las cuestiones clave reside en conocer los modelos de financiación y rentabilidad del proyecto.
En aras de una mejor comprensión, podemos distinguir dos áreas principales de estudio:

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

Esquemas de financiación

Con el siguiente esquema ejemplificamos los modelos de financiación más habituales, asociando a cada ejemplo un caso conocido de proyecto o empresa:

En resumen, los esquemas de financiación pueden categorizarse a grosso modo según la siguiente lista:

• Pública (modelo LinEx)

Una determinada institución pública considera adecuado invertir en un proyecto, bien porque nadie invierte debido al escaso retorno económico (el caso del CENATIC con el DNI-electrónico), por motivos estratégicos -reducción de costes y creación de industria local- (el caso de algunas administraciones públicas españolas) o de seguridad nacional (el caso del goberno alemán que financió desarollos específicos de gnupg).

• Privada sin ánimo de lucro (modelo FSF)

En eeste punto encaja el papel de las fundaciones privadas como la Free Software Foundation.

• Mejoras específicas (modelo Wine-Corel)

Wine es una implementación de la API de windows en entornos UNIX. En un momento dado, Corel decidió invertir en el proxecto Wine (contratando a desarrolladores a tiempo completo) de cara a mejorar la estabilidad del mismo. Con las mejoras de Wine, Corel ganaba portabilidad entre distintos sistemas, acercándose a los sistemas UNIX:

The future is going to be a variety of platforms. It only makes sense to centralise around one operating system. The operating system is the common denominator. We’re keen on everything — including Transmeta and mobile Linux — that expands the Linux universe.

• Privada con ánimo de lucro (Canonical, O’Reilly):

En este sentido las inversiones en proyectos de sw libre van relacionadas con los modelos de negocio existente (que tratamos posteriormente).

• Otros: marketplace (modelo SourceForge), donaciones, bounties (eventos que tratan de incentivar la creación de código libre), …

Modelos de negocio

Por otra parte, en cuanto a los modelos de negocio, también realizamos un mapa de conceptos ejemplificándolos con proyectos y empresas conocidas:
El esquema está realizado según la clasificación de Hecker (blog persoal), 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 (aún que existen otras clasificaciones):

• Support Seller (modelo Ubuntu – Canonical)

Consiste en la venta de soporte y servizos asociados al producto. En esta categoría podemos encontrar desde servicios de consultoría hasta desarrollo de necesidades específicas no cubiertas por el producto.

• Loss leader (modelo Ximian-Exchange)

El programa libre sirve como base para la comercialización de productos propietarios. El ejemplo más claro probablemente sea el de la empresa Ximian (ahora parte de novell) que se encargó del desarrollo del gestor de correo libre Evolution, sobre el que comercializaban el conector para servidores Microsoft Exchange 2000 como producto propietario.

• Widget frosting (modelo Nokia-maemo)

En este caso, la empresa rentabiliza la inversión con la venta de hardware y el software es una commodity, algo que no reporta beneficios. Así e el caso de la internet tablet de Nokia que corre bajo la plataforma de software libre Maemo.

• Accessorizing (modelo O’Reilly)

Este modelo de negocio consiste en la comercialización de productos relacionados. Muy conocido es el caso de la editorial O’Reilly, una de las más reputadas en el mundo técnico y de software libre. El impacto de la marca sobre este nicho de mercado es debido en gran medida por la continua promoción de eventos y subvención de proyectos de software libre, que luego rentabiliza en forma de publicación de libros técnicos y contacto directo con loss hackers.

• Service enabler (modelo google)

En este modelo, el software libre sirve como base para comercializar un servicio (no relacionado con el produto), por lo que la empresa tiene interés en invertir en proyectos de software libre que necesite a la hora de proveer un servicio con calidad (servidores web, lenguajes específicos).

• Brand licensing (modelo MySQL)

Esta estrategia consiste en asociar un producto con una marca concreta. Una vez hecho, es posible comercializar servicios relacionados con la marca: cursos de formación específicos, certificaciones, …

• Software franchising (modelo RedHat, MySQL)

A diferencia del anterior en este modelo se franquicia la marca, pudiendo usarla para ciertos fines específicos. Programas de partners como los de MySQL entrarían en esta categoría.

• Sell it, Free it (modelo GNAT)

Por último, existe la estrategia de comercializar un producto de software libre para -una vez tenga cierto éxito- distribuir las siguientes versiones como propietarias durante un tiempo, liberándolas con cada nueva versión lanzada. Éste es el modelo que sigue la empresa AdaCore vendiendo una versión del compilador de ADA GNAT por una suscripción que libera posteriormente.

Licenciamiento dual

Por último, hablamos de un modelo no recogido en el artículo seminal de Hecker. Si bien en el mundo del software privativo es habitual que el modelo de negocio esté basado en la venta de licencias (que concede la posibilidad de uso de un programa en ciertos entornos controlados), en general no ocurre así en el mundo del software libre. Mas existe la posibilidad de obtener rentabilidad por pago de licencias.
Para ello, el programa debe tener un licenciamento dual, es dicir, debe tener dos licencias. Es habitual que una de ellas sea una licencia robusta (por lo que permite usar el código y mejorarlo siempre que los derivados se licencien con otra licencia robusta) y otra sea específicamente diseñada para poder crear produtos derivados propietarios a cambio de una cantidad a negociar.

Conclusiones

Es evidente que los modelos de los que hablamos anteriormente no son estancos y las empresas tejen un complejo flujo comercial en el que hacen uso de varios simultaneamente. Estudiarlos de modo desagregado nos da la oportunidad de observar las múltiples posibilidades que existen.
Si observamos por ejemplo la empresa MYSQL AB vemos que tiene varias fuentes de ingresos por diferentes motivos: venta de servicios (consulting, support), marca y franquiciado, así como por venta de licencias. Todos ellos basados en la explotación del conocimiento alrededor de productos de software libre.

Casos prácticos

Kernel de linux, aspectos económicos

Según un estudio de la Linux Foundation, en la versión 2.6.24 del kernel de linux colaboraron unos 1057 desarrolladores distintos y 187 empresas. Las razones para hacerlo son diversas y las empresas tienen sus propias motivaciones económicas. En este post pretendemos hedchar luz sobre ese aspecto.

Según los datos recavados por la Linux Foundation:

over 70% of all kernel development is demonstrably done by developers who are being paid for their work.

Se puede decir que la principal fuente de financiación del kernel son empresas externas que:

• lo usan como base para comercializar productos derivados (hardware y software)
• realizan mejoras específicas que necesitan internamente por otros motivos

Estas empresas poseen con el kernel una sólida base para la consolidación de sus respectivos modelos de negocio:

• Venta de hardware (IBM, Intel, HP): su aportación se debe a que desean asegurar que sus sistemas son compatibles cos sistemas linux, o que redundará en una mayor venta de hardware.

• Uso del kernel embedido en sistemas multimedia como móviles, cámaras, televisions, … (Nokia, Sony, …): colaborando en el kernel se aseguran seguir disponiendo en el futuro de una plataforma sobre la que construir sus produtos.

• Una variante del anterior son los sistemas embebidos en produtos no TIC (Volkswagen): esta empresa no vende directamente productos TIC, sin embargo usa el kernel como base para sus sistemas integrados en los vehículos.

• Comercialización de software y servicios sobre productos que integran el kernel (RedHat, Novell): estas empresas empaquetan en conjunto con el kernel una serie de programas que dan lugar a distribuciones de linux. Sobre esto construyen su modelo de negocio basado en la comercialización de diversos servicios.

Por lo tanto, según los datos que tenemos visto, se puede decir que el kernel es un proyecto estable, maduro y sostenible a largo plazo, pues ha conseguido agregar alrededor de él a una serie de agentes que tienen los incentivos suficientes para participar activamente en su producción.

Aspectos sociales

Arquitectura para la participación

La confianza mutua

La principal tarea de un líder de proyecto, consiste en conseguir que el traballo se realice. Diversas motivaciones animan a los seres humanos y teniendo en cuenta que los usuarios deciden participar por sí mismos en un proyecto u otro, no existe ningún otro vínculo que una a la comunidad más allá de la confianza mutua.
Es por ello que tanto los aspectos técnicos como los relativos a las relaciones sociales y nettiqueta son necesarios para llevar a cabo un proyecto de comunidad exitosamente.
En uno de los textos más emblemáticos de la ingeniería del software libre, “La catedral y el bazar“, Eric S. Raymond expone una serie de puntos derivados de su experiencia al liderar el desarrollo del proyecto FetchMail. Es interesante observar algunos de ellos:

• Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
• Release early. Release often. And listen to your customers.
• If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.
• The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
• Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
• Provided the development coordinator has a medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

.. para darnos cuenta de que la principal idea detrás de los mesmos reside en la creación de confianza.
Evidentemente, ésta sólo se gana con trabajo continuado, mas existen una serie de buenas prácticas a considerar. Como recomendación de cabecera, el libro Producing Open Source Software, toca muchos de los temas que se deben de tener en cuenta:

• Infraestructura social y política del proxecto ¿quien puede decidir qué?
• Buenas prácticas en la comunicación
• gestión de voluntarios

Otro punto importante de la vertiente social, consiste en la organización de eventos donde los participantes se reúnen para discutir el futuro del proyecto, disfrutar de talleres y charlas sobre la tecnoloxía y actividades lúdicas, difundir el propio proxecto, … pero básicamente realizan el maior acto social ligado a la confianza: reunirse cara a cara y hablar.

La modularidad del proyecto

Si en un post anterior hablábamos de la confianza y la motivación como motores de la participación, en éste rescatamos las palabras de Benkler…

when a project of any size is broken up into little pieces, each of which can be performed by an individual in a short amount of time, the motivation to get any given individual to contribute need only be very small.

seguido con los resultados del estudio de Niels Jorgensen (Incremental and decentralized integration in FreeBSD) donde se dice que…

65% [of developers] said that their last task had been worked on largely by themselves only, with teams consisting of two or three developers each representing 14%.

lo que representa una situación habitual en los proyectos de software libre, ya que la alta modularidad del trabajo, permite realizar las tareas asíncronamente a la vez que uno puede variar su nivel de compromiso según la dispoñibilidad.
Es por ello, que el proyecto debe ser altamente modular.
Porque sin duda, ésta es una de las condiciones principales que se debe tener en cuenta a la hora de conseguir la masa crítica de participantes, que hagan el proyecto sostenible a largo plazo.
Mas en este caso, la modularidad del trabajo no se consigue con ninguna herramienta específica ni únicamente a través de la propia arquitectura del software, sino que es relativo a la organización del traballo y la capacidad de delegación de tareas y gestión de grupos humanos. Y si bien no existen fórmulas mágicas, sí podemos observar una serie de patrones habituales o buenas prácticas que facilitarán la participación en el proyecto:

• Show me the sources! Es una buena idea publicar un código base a partir del que continuar el trabajo. No te preocupes de que sea la mejor solución, sino de que sea un primer intento. De este modo es más sencillo que alguien idee mejoras sobre tu solución y decida participar.

• Release early, release often. No intentes acabar el proyecto y luego abrirlo al público. ¿Quien desea participar en un proyecto finalizado? Si quieres fomentar la colaboración desde el principio debes realizar el trabajo públicamente.

• ToDo. Mantener una lista de tareas por facer es altamente recomendable. Existen múltiples maneras: a través de la web del proyecto, en un archivo chamado TODO en tu repositorio público de código fuente, tener disponible un gestor de incidencias (bugs y features) en el que cualquiera pueda encontrar tareas que realizar, …

• Arquitectura orientada a módulos o plugins: es una práctica extendida desarrollar un sistema que soporte plugins y que cada característica (feature) sea desarrollada como tal (lo mismo se podría decir de los módulos), desaclopando así el desarrollo de una nueva característica del mantenimiento del core de la herramienta.

• Dar soporte a otros lenguajes (realizar bindings): es posible que tu proyecto disponga de bindings que permitan programar en otro lenguaje distinto al que has decidido usar al principio. Esto significa que, por ejemplo, si tu proyecto está programado en C, podrás dar soporte para que cualquier persoa que trabaje en python pueda colaborar.

Debido a que el tiempo de los posibles participantes en el proxecto es limitado y sus motivacións diversas, lo único que un líder de proyecto puede hacer es generar confianza en las posibilidades del proyecto, dividir el trabajo en pequeñas tareas, ampliar el rango posible de participantes… y confiar en que la gente desee participar.

Integración de las aportaciones

Peer production is limited not by the total cost or complexity of a project, but by its modularity, granularity and the cost of integration.
— Benkler. Coase’s Penguin or Linux and The nature of the firm.

Si la modularidad del proxecto es uno de los factores clave para aumentar la participación, el proceso de integración de las aportacións es primordial para no morir de éxito, es dicir, que la gente continúe participando a la vez que se obtiene un producto de calidad. Así, las preguntas que debemos responder son las 2 siguientes:

• ¿cómo combinamos cada una de las aportaciones en un todo, en un producto final?
• ¿cómo aseguramos la calidad de las aportacións?

El modo en que habitualmente las resolven algunos proyectos de software libre supone una conjunción de uso de herramientas y cumplimiento de ciertas normas sociales que ahora pasamos a relatar.

Herramientas

A continuacion enumeramos algunas de las herramientas ferramentas que facilitan el trabajo distribuido entre múltiples colaboradores (programadores, traductores, …) geográficamente dispersos. Aunque no se publicarán tutoriales de cada una de ellas, sí se hará en próximos posts una breve introducción a las más relevantes.
De cara a entender su función, podemos agruparlas en las siguientes categorías:

• Sistemas de control de versiones: se usan para el mantenimiento, integración y distribución del código fuente de los programas. Ejemplos: svn, cvs, git, bazaar.
• Gestión de la compilación y configuración. En la compilación y release del producto final es habitual tener que realizar una serie de tareas repetitivas. Para realizarlas existen algunas herramientas que nos ayudan a automatizarlas. Ejemplos: autotools (autoconf, automake, libtool), ant.
• Sistemas de gestión de incidencias: usadas para la publicación y gestión de bugs encontrados en el programa. En algunos casos se usan para listar funcionalidades interesantes para el proyecto. Ejemplos: bugzilla, trac.
• Sistemas de monitorización del desarrollo (nightly build tools): este tipo de herramientas son usadas para compilar automáticamente el código y generar informes (errores de compilación, detección de regresións, …). Ejemplos: tinderbox, maven.

Las dos primeiras categorías encajan a la perfección dentro del proceso de integración de las aportaciones en un producto final: las facilidades que nos dan herramientas tipo svn o autotools son inmensas y reducen el coste da integración.
Por otro lado, en las últimas 2 categorías encajan herramientas especialmente diseñadas para realizar el control de la calidad de las aportaciones.

Procesos y buenas prácticas

A continuación agruparemos una serie de prácticas que se realizan habitualmente en las comunidades y proyectos de software libre que podemos encajar dentro de los procesos de integración y control de calidad. Evidentemente, existen muchas más y cada proyecto tiene las suyas propias. Sirvan éstas simplemente como muestra.

Control de calidad y revisión de código entre pares (peer review)

• Lista de correo de cambios (commits): es común que exista una lista de correo a la que se envían de modo automático los cambios en el repositorio del proxecto. De este modo, todo el mundo suscrito a esa lista puede observar los cambios que fueron realizados, detectando errores y aportando mejoras.

• Revisión de parches: tener una persoa que revise el código que el resto del grupo le envía. Sólo esta persoa puede enviar los cambios al repositorio de código del proyecto.

• Grupos de calidad: en ciertos proyectos existen grupos específicos dedicados a la calidade. En el proyecto GNOME, por ejemplo, existe la Bugsquad que se dedica a explorar el gestor de incidencias y bugs, tratando de cerrar aquellos que estén resueltos o repetidos. Con esta práctica están ayudando a los desarrolladores de los proyectos que pueden centrarse en los errores realmente importantes. Incluso se llegan a realizar eventos con la única finalidad de realizar esta tarea.

Integración de las aportaciones en un todo

• Política de cambios: una serie de normas que definen cómo se deben de realizar los cambios en el repositorio de código. Es habitual, por ejemplo, asumir la regla de no incluir cambios que provoquen que el proxecto no compile. Este tipo de normas sociales facilitan que programadores que deseen subir sus cambios, no se vean obligados a resolver errores cometidos por cambios introducidos anteriormente.

• Coding style. Es habitual que cada proyecto tenga su estilo de programación, que facilite la lectura y revisión de código. Muchas veces los parches son denegados porque el código enviado no sigue las reglas de estilo del proxecto. Ej: Gnome Coding Style, Mozilla Coding Style Guide.

Por otra banda, existen convenciones para el uso de cada herramienta que se deben explorar a medida que se usan.
Además de estas medidas informales integradas en el trabajo diario, en el propio flujo de publicación del proxecto pueden existir fases específicas dedicadas a testear el funcionamento del programa o la integración. Así, marcarse un plan y tener una agenda clara que sirva como sincronización de los esfuerzos, es una de las acciones principales que pueden favorecer la evolución del proyecto.
Para finalizar, más que tomar nota de cada una de las prácticas y herramientas descritas, para liderar un proyecto de software libre, es necesario comprender que la integración de las aportacións y los mecanismos de control de calidad son necesarios para que o proyecto no muera de éxito.

El ciclo de publicación

Durante el proceso de integración de las aportaciones es habitual encontrar una serie de medidas informales para garantizar la calidad de las mismas y su sencilla integración. Más allá de estas medidas, la mayoría de los proyectos de software libre preveen etapas de test y calidad específicas y coordinan sus esfuerzos a través de una agenda común: los ciclos de release.

Funcionalidades VS Tiempo

El ciclo de publicación de un proyecto consiste en el tiempo y acciones que ocurren entre que se publica una versión del software hasta la siguiente. A grandes rasgos, se pueden identificar 2 grandes modos de gestionar el ciclo de publicación de un proyecto:

1. Basado en funcionalidades.
2. Basado en hitos temporales.

Decidir cual de los modelos se adecúa a las necesidades del proyecto, puede impactar directamente en la calidad del mismo. Para elegir el modelo adecuado, es necesario tener en cuenta ciertos condicionantes.

Control de calidad

A pesar de las medidas informales de las que hablábamos en post anteriores, una fase de testeo es necesaria para estabilizar el programa.
En una release basada en tiempos ésta se define en la propia planificación y si todo sale bien debe cumplirse. En una basada en funcionalidades, las releases pueden ocurrir súbita y forzadamente (luego de un proceso de negociación que se alarga en el tiempo y los gestores deciden llevar adelante la publicación) por lo que la fase de control de calidad puede ser insuficiente.

¿Cómo se decide qué funcionalidades son aceptadas?

En una release basada en tiempos este proceso es trivial ya que sólo entran las que están disponibles cuando se publica la release. Por el contrario, en un basada en funcionalidades el proceso implica negociación entre los múltiples colaboradores del proyecto. Este proceso de negociación puede ser lento y dar lugar a continuas discusiones que retrasen una y otra vez la publicación.
El perfil de coordinador de la release en uno y otro caso es muy diferentes. Mientras en el primer caso, su papel se limita a gestionar los tiempos y contactar con los colaboradores de cada módulo para realizar el seguimiento del proceso; en el segundo tiene un perfil más político, ya que en un momento determinado puede llegar a forzar la publicación de una nueva versión.

¿El proyecto depende de otros? ¿Qué otras agendas dependen de tu proyecto?

Si es así, es importante contar con las releases de las dependencias. Por ejemplo, si el proxecto usa el kernel de linux como base para realizar otra cousa, quizás lo más interesante sea amoldar el ciclo de release del proyecto al del kernel, ya que de este modo se podrá disponer en cada versión de las últimas mejoras que provee el kernel.
El caso del escritorio GNOME esé digno de estudio. Luego de la release de la versión 2.0, decidieron realizarlas cada 6 meses. Este aspecto organizativo, junto con otras diferencias con su competidor directo, KDE, facilitaron que muchas distribuciones de linux lo eligiesen como escritorio por defecto. Debido a que conocían cuando se publicaría la siguiente versión, otros proyectos pueden planificar sus acciones (release de la distribución, acciones de márketing, organización de eventos, etc) con antelación.
A este respecto, Mark Shuttleworth, fundador de Ubuntu, ha publicado un post sobre la sincronización de la pila completa de aplicaciones libres en el que hablaba sobre la estrategia de release de Ubuntu:

[…] at Ubuntu we have converged around the idea of releasing about one month *after* our biggest predictable upstream, which happens to be GNOME. And similarly, the fact that the kernel has their own relatively predictable cycle is very useful. We don’t release Ubuntu on the same day as a kernel release that we will ship, of course, but we are able to plan and communicate meaningfully with the folks at kernel.org as to which version makes sense for us to collaborate around.

¿De qué recursos se disponen?

A pesar de que las releases basada en tiempos tienen grandes ventajas, necesitan a su vez de una inyección de recursos importantes, que, si no se dispoñen, pueden hacer desaconsejable el uso de este modo de publicación. Por ejemplo, si el proyecto tiene una carencia de programadores que hará imposible sacar regularmente nuevas versiones.

Conclusiones

A lo largo de este post, hemos visto cómo la sincronización del proyecto tiene importancia tanto a nivel interno -garantizar la motivación de los colaboradores y una efectiva coordinación de los esfuerzos- como a nivel externo -facilitar sinergias entre proyectos.
Elegir el modelo adecuado en cada etapa de vida del proyecto no sólo afectará a las relaciones con otros proyectos e la calidad, sino también a la motivación de los colaboradores, el codiciado grial de cualquier comunidad de software libre.

Casos prácticos

Kernel de Linux, cultura organizativa

En este momento, estamos capacitados para entender a grosso modo el funcionamento de cualquier proyecto de software libre. Debido a su importancia vamos a iniciar una serie de post donde analizaremos -desde todos los puntos de vista tratados en este blog- el kernel de linux.

Recursos y tecnologías usadas

En un primer acercamiento al proyecto tendremos que mapear los recursos que posee y el modo de interacción de los colaboradores. En primer lugar identificamos las herramientas más habituales:

• web, listas de correo, …
• repositorios de código, bugzilla, …

Como característica principal vemos que el repositorio usado en el kernel no es svn, sino git. Este sistema de control de versiones es distribuido, por lo que el flujo de trabajo es un poco diferente de lo que vimos en svn. En la propia página de git hay extensa documentación sobre cómo usarlo. Un documento muy recomendable es Git from the bottom up [PDF].
Otro método para obtener información del proxecto es bajarse el código fuente directamente del repositorio. Una vez localizado el árbol de repositorios, identificamos la rama que corresponde con la última versión del kernel. Lo descargamos y ejecutamos el programa sloccount para conocer el número de líneas de código de cada lenguaje de progamación en el proxecto:

cd /tmp
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cd linux-*
sloccount .

Como resultado obtendremos (entre otras cosas) un listado de lenguajes usados y líneas de código de cada uno de ellos. En este caso, el código escrito en ansic supone un 96% del total. De este modo tenemos idea de qué tecnoloxías son mayoritarias en el proyecto.
Por otro lado, podemos encontrar archivos de interés en este repositorio (por ej: MAINTAINERS, que nos dirá el mantedor de cada módulo).

Modularidad e Integración

Otro de los puntos importantes que debemos entender es la cultura de colaboración en el proxecto: ¿cómo interactúan entre ellos? ¿cómo se envían parches? ¿usan wikis o listas de correo para gestionar el trabajo que debe ser hecho?
Para tratar de responder a estas preguntas, identificamos 2 recursos principales:

• FAQ newbies
• How to participate in the Linux Community, da Linux Foundation.

Aún que el modo de realizar las cosas, la cultura organizativa, sólo se puede aprender interactuando dentro de la comunidad, sí podemos identificar algunos de los puntos claves del proyecto.
Como se ha dicho, la modularidad del traballo es un factor clave de cara a distribuir las tareas lo máximo posible y obtener participación. En el kernel, resuelven esta cuestión dividiendo el proyecto en múltiples módulos sobre los que participar. Por otra banda, dividir el proxecto en múltiples partes requiere un proceso de integración posterior.
Este proceso, consiste en un flujo continuo e iterativo de revisión de parches. Hasta que éstos finalmente se integran en lo que será el kernel pasan por varias etapas de revisión. Los aspectos clave de todo el proceso son:

• Revisión de parches en listas de correo de cada subsistema: los parches con nuevas funcionalidades son enviados a la lista de correo correspondiente (del módulo o subsistema) donde se discuten y revisan. Luego de pasar la validación el mantenedor puede integrarlo en su repositorio. Posteriormente ese conjunto de parches pasan a módulos o subsistemas superiores repitiendo el proceso.

• Árboles de integración: más allá del proceso anterior de integración a lo largo de la cadena de subsistemas, existen 2 árboles especialmente dedicados a la integración transversal de parches que vienen de diversos sistemas. Éstos son los -mm-tree (árbol de gestión de memoria) y el -linux-next, gestionados por Andrew Morton y Stephen Rothwell respectivamente. Su función consiste en testear que los parches de varios subsistemas inferiores trabajan bien en conjunto, previamente al paso a la rama de desarrollo principal (mantenida por Linux Torvalds).

Este sistema jerárquico de integración y revisión, garantiza un control de calidad basado en la revisión del código de forma continuada y por múltiples programadores. Por otra banda, herramientas avanzadas de gestión de código (git) y parches (quilt) facilitan el trabajo de integración por parte de los programadores.
Con todo esto tenemos aproximado un primer intento de comprensión de la cultura de los hackers del kernel, de su modo organizativo: jerárquico (el trabajo está delegado en varios subsistemas) a la vez que meritocrático (continua revisión de parches a través de listas de correo). Un modo de trabajo que les permite obtener un producto de alta calidad cada 8/10 semanas.

Kernel de Linux, el ciclo de publicación

En posts anteriores hemos visto la importancia de los procesos de publicación para la sincronización del trabajo y una breve explicación sobre cómo el proyecto GNOME gestiona las releases. A pesar de que -desde las versiones 2.6- el kernel posee un ciclo de publicación basado en tiempos, éste no es tan rígido como el de GNOME.

Ambos proyectos difieren enormemente: los clientes de GNOME son principalmente usuarios, es un proyecto que pretende integrar muchas aplicaciones dispersas con problemáticas específicas (localización, accesibilidad, …); sin embargo, los clientes del kernel son -en su gran mayoría- otras aplicaciones que requieren de una serie de funcionalidades del hardware, es un proyecto de bajo nivel.
Por otra banda, en cuanto a la cultura organizativa del kernel se puede dicir que es un proxecto intensivo en uso de listas de correo y posee un modo de organización jeráquicco (en conjunción con procesos de peer-review), donde la última palabra sobre la publicación la posee Linus Torvalds.
Los hitos clave de la publicación de una nueva versión del kernel:

• Merge window open: el proceso de creación de una nueva release comienza una vez se publica una versión estable. Durante un período aproximado de 2 semanas se pueden enviar parches relacionados con nuevas funcionalidades, cambios en la API, etc.

• Se publicar la “Release Candidate 1“ (RC1): a partir de este momento comienza un proceso de estabilización de las funcionalidades añadidas e, idealmente, no se permiten más parches que los de corrección de bugs.

• Estabilización del kernel: cada 5/10 días se publica una nueva RC do kernel resolviendo nuevos bugs.

• Publicación de la rama estable: aunque no existe un deadline claro -se decide a través de listas de correo- un baremo habitual es considerar el número de regresiones respecto al anterior. Mas la última palabra la tiene siempre Linus Torvalds, el desarrollador principal.

El proceso se repite de modo iterativo a lo largo de las versiones, siguiendo el esquema mencionado, publicando cada 2/3 meses una nueva versión del kernel. Una vez publicada, su mantemento pasa a manos del equipo de la rama estable y el ciclo comienza de nuevo con la siguiente versión.

GNOME, el ciclo de publicación

El ciclo de lanzamiento de un proyecto comprende tareas dependientes unas de las otras: mientras el desarrollador no acaba de realizar las modificaciones al programa y añadir/modificar/eliminar las cadenas que se presentarán al usuario (en forma de diálogos, por ejemplo), los traductores no deberían empezar su trabajo. Estas interdependencias son habitualmente gestionadas mediante los períodos de congelación (freezes) a los que se le asignan fechas, a partir de los cuales no se pueden realizar ciertos cambios.
El ciclo de release del proxecto GNOME está basado en períodos de publicación de 6 meses, donde se estipulan ciertos puntos de sincronización del trabajo. Algunos de los freezes existentes son:

• Feature Freeze – período a partir del cual no se pueden añadir nuevos módulos o funcionalidades.
• API/ABI Freeze – las librerías de la plataforma deben mantener tanto la compatibilidad binaria (ABI) como la API.
• String Freeze – período a partir del cual no se pueden añadir nuevas cadenas de traducción.
• …

Un mayor detalle de cada uno de ellos se puede observar dentro de la propia página de GNOME.
Así, para cada versión del proyecto se publica una agenda donde se indican los períodos de freeze. De este modo, los colaboradores pueden organizar su trabajo de acuerdo a un timeline común. Existe también un equipo encargado de la gestión de la release que vela -entre otras cosas- porque la agenda se cumpla así como de la aceptación/denegación de los freeze breaks: a pesar de que existen períodos de congelación para sincronizar el trabajo, éstos no son ríxidos y siempre queda la opción de pedir permiso para realizar cambios.
Como ejemplo de gestión, podemos ver esta petición de break freeze, donde se plantea la modificación de unha cadena de traducción (mas el período para modificarlas ha expirado). La petición es enviada a la lista del equipo xestor de la release (siguiendo las normas del proyecto) para que decida qué hacer con ella (valorando si puede o no retrasar significativamente la release). Siguiendo el hilo de la conversión en la lista de correo, se puede observar cómo en este caso la petición es aceptada y la cadena cambiada satisfactoriamente.
En la propia página del proyecto se puede observar una panorámica del lanzamiento de Gnome 2.23:

El escritorio GNOME comprende múltiples módulos y colaboradores trabajando en paralelo, por lo que medidas como las que acabamos de relatar son necesarias para publicar cada 6 meses una release de calidad. Sin embargo, es habitual que los puntos de sincronización sean más informales cuando un proyecto es menor en tamaño, tiene menor número de colaboradores u otro modo de organización.

Firefox y el caso Nitot

Un caso de estudio relevante para ilustrar la confianza como vertebrador de la comunidad es el “Caso Nitot“.
Para ponernos en contexto, Nitot es el fundador y actual presidente de Mozilla Europe. En el congreso BDigital Congress de mayo de este año hizo las siguientes declaraciones:

“Hay una versión en catalán de Firefox construída por voluntarios a los que les importa su idioma, al igual que la hay en euskera. Pero aún no hay una versión en gallego. Muchas veces me lo preguntan y mi respuesta es que se nadie se presenta, no habrá una versión en gallego. Estamos dispuestos a que la gente trabaje con nosotros”.

Sin embargo, sí existía una versión del firefox en gallego públicamente disponible desde Mancomún, pero no integrada en los repositorios del proyecto Mozilla por la excesiva burocracia de sus peticiones (ver bugzilla: 1 y 2), lo que había provocado que los 2 principales colaboradores desistiesen de sus esfuerzos.
Esto inició una serie de comentarios en la red gallega de blogs y listas de correo, así como la respuesta del coordinador de Mancomún -Suso Baleato- lo que estaba perjudicando la imagen de la Fundación Mozilla.
Luego de 48h todo se solucionó con la peticion de disculpas de Nitot, que reconocía así el desconocimiento de la situación real y su error en las declaraciones:

I honestly did not want to sound controversial to the Galician community, but it sounds like I was. Well, I should have known better! The good news is also that there is already a Galego language pack for Firefox 2 hosted on AMO, along with a dictionary. I guess that the next step is to discuss with the Galician localization team how to work together for CVS integration, but I’ll leave the Mozilla L10n team deal with this: I think I’ve said enough stupid things for the week 😉

En la actualidad, el firefox en gallego está oficialmente soportado en los repositorios de Mozilla.
La lección a extrapolar en este caso es que en las comunidades de software libre, el único elemento vertebrador es la confianza. Minar la confianza significa golpear las bases de la comunidad. Por ello, la única salida a un conflicto como el que mostramos era pedir disculpas. Porque en el trabajo en grupo los errores son asumibles, la mala fé no.

Herramientas

Una panorámica general de las herramientas

$ mkdir /tmp/lastfm_test
$ cd /tmp/lastfm_test
$ svn checkout uri_svn .
uri_svn = https://svn.forge.morfeo-project.org/svn/freeswmaster/trunk/amaneiro/perl-workshop/

$ svn commit

$ svn diff > parche.diff