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

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

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:
          • ¿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.
          • 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

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:
          • 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.

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. GNOME_KDE_copyright 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:

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:
Archivo:Financing schemas.png
Esquemas de financiación
En resumen, los esquemas de financiación pueden categorizarse a grosso modo según la siguiente lista: 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). En eeste punto encaja el papel de las fundaciones privadas como la Free Software Foundation. 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.
En este sentido las inversiones en proyectos de sw libre van relacionadas con los modelos de negocio existente (que tratamos posteriormente).

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): 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. 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. 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. 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. 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). 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, ... 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. 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.
Archivo:Linux kernel whoisdoingit.png
Linux kernel: Who is doing it?
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: Estas empresas poseen con el kernel una sólida base para la consolidación de sus respectivos modelos de negocio: 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: .. 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: 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: 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: 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: 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)

Integración de las aportaciones en un todo

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: 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: 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: 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.
Archivo:Release kernel linux.png
Linux kernel: release
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: 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:
Archivo:Freeze schedule.png
GNOME: freeze schedule
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:
Archivo:Gnome schedule.png
GNOME: schedule
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

Cuando hablamos de un proyecto de software libre, no sólo nos referimos a proyectos realizados con tecnologías libres, sino a proyectos de comunidad, donde mucha gente en lugares y motivaciones diversas colabora en la realización exitosa del mismo. Es por ello que se necesita una infraestructura para facilitar la colaboración, para que la gente participe y trabaje en grupo de un modo natural. Desde luego, son necesarias una serie de herramientas que permitan tanto la interacción entre las persoas (listas de correo, foros, jabber, IRC, wiki, web, blog, planets), como la gestión y mantenimiento del código: sistemas de control de versiones, sistemas de gestión de incidencias (bugs, petición de nuevas funcionalidades,...), ... Existen multitud de serivicios que nos proveen de las herramientas más usadas. Sourceforge es uno de los más populares, donde -una vez nos registramos como usuario- tenemos a nuestra disposición las herramientas básicas que se necesitan para llevar a cabo el proyecto. Pero más allá de las herramientas usadas, existen normas sociales, un flujo de trabajo que respetar: cómo usar las herramientas para llevar a cabo el proyecto que tenemos entre manos. De todo esto pretendemos hablar en los siguientes posts. Y para eso trataremos de seguir las 3 claves que destaca Benkler para que un proyecto de comunidad funcione:
  1. La confianza como vertebrador de la participación
  2. La modularidad del proyecto como factor que potencia la colaboración
  3. El problema de la integración y el control de calidad de las aportaciones:

Repositorios y mantenimiento del código

En general, en los proyectos de software libre, colaboran persoas de diferentes lugares que coordinan sus acciones a través de internet (listas de correo, chat, ...). Esta característica demanda una herramienta que posibilite el trabajo en grupo sobre el código de forma eficiente.
Archivo:Repositorio.png
Repositorio de código
Para cubrir esa necesidad emerge una de las herramientas clásicas en el desarrollo de software libre: los sistemas de control de versiones. En un primer momento se puede entender esta herramienta como un sistema para compartir información. Pero los sistemas de control de versiones posibilitan mucho más que eso ... permiten, por ejemplo, la gestión de las revisiones de un documento. Se llama revisión a cada estado del repositorio a lo largo del tempo, es dicir, a los archivos que incluye en un instante n. La diferencia entre la "revisión 3" y la "revisión 4" puede ser que se incluyeron, borraron o modificaron los arquivos del repositorio. Un sistema de control de versións permítenos recuperar calquera das revisións do repositorio. En la siguiente figura se puede observar cómo varía el estado del repositorio (desde la revisión 0 hasta la 3) a medida que vamos realizando cambios, es dicir, al añadir, modificar o borrar algún ficheiro/directorio:
Archivo:Versiones.png
Versiones
Y, a pesar de que el estado final del repositorio es la revisión 3, tenemos acceso a cualquiera de las anteriores, lo que nos posibilita recuperar una revisión antigua si, por ejemplo, alguien ha introducido un cambio que provoca que el código no funcione como debería. Además de esto, los sistemas de control de versións almacenan la historia de cada cambio. Dependiendo del sistema elegido, tendremos acceso a más o menos información, pero en general, siempre se puede observar la fecha de modificación, el autor y los cambios que realizó. En resumen, un sistemas de control de versiones nos ofrece: En el caso de la forja de mancomún, el sistema de control de versiones que se usa es Subversion (también conocido como svn). Una muy buena referencia para introducirse en el uso de este sistema es el libro Version Control with Subversion, con una versión disponible también en español.

Sesión de trabajo con svn y envío de parches

Flujo de trabajo con SVN Con ánimo de ejemplificar su uso, se mostrará a continuación el flujo de traballo de una sesión normal:
  1. Descargar lo que hay en el repositorio (checkout del repositorio).
  2. Trabajar sobre el código realizando las modificaciones oportunas para implementar la nueva característica o corregir un bug.
  3. Comprobar que nadie ha subido nuevos cambios desde que descargamos la última revisión. Puede darse que:
    1. Alguien ha realizado cambios pero no afectan al código que modificamos.
    2. Alguien ha realizado cambios y sí afectan al código que modificamos: en este caso puede existir un conflicto entre sus cambios y los nuestros. De ser así, es necesario adaptar el código a estes cambios antes de subirlo al repositorio.
  4. Subir los cambios al repositorio.
Con ánimo de ejemplificar su uso, en el siguiente post se mostrará cómo trabajar con svn y las herramientas usadas para enviar un parche a un proyecto de software libre.
El proyecto elegido para la demostración será un código que recupera perfiles de usuarios y los artistas maś escuchados de la plataforma last.fm. El programa está desarrollado en el lenguaje perl y usa la API de last.fm para hacerlo. Nuestra tarea será documentar lo que hace cada una de las funciones del código. Lo que necesitamos en un primer momento es tener instalado en nuestro ordenador un cliente svn para conectarnos al servidor y descargar el código. En Ubuntu el paquete a instalar se llama subversion.

Obtención del código fuente y realización de cambios

Una vez lo tenemos vamos a crear un directorio de trabajo temporal para realizar esta sesión. En una consola (el símbolo $ indica que son comandos de shell lo que va a continuación) hacemos lo siguiente: 
$ 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/
En este momento tenemos el código a nuestra disposición y podemos empezar a trabajar con él. Si ahora observamos las diferencias de nuestra copia local de trabajo (conocida como working-copy) con respecto al repositorio (comandos svn diff, svn status) veremos que la salida de ambos comandos es vacía. Lógicamente, debe de ser así, porque aún no hemos realizado ninguna modificación con respecto al código que nos descargamos. Es un buen momento para ver también la historia del proxecto (usando el comando svn log) y jugar con las múltiples opciones que posee. Para seguir con la sesión, abrimos nuestro editor favorito y modificamos el fichero ex11.pl documentando cada una de las funciones. Una vez acabemos, podemos observar los cambios: cómo ha variado el estado de nuestra copia local de trabajo con respecto al repositorio. Comprobamos los ficheros modificados (comando svn status) y luego las modificaciones introducidas en cada uno de ellos (comando svn diff).

Subiendo los cambios realizados

Ahora que sabemos que los cambios que se realizarán son los correctos, debemos asegurarnos de tener la última versión del código del repositorio, pues es posible que alguien más estuviese trabajando en paralelo y el código que tengamos en nuestra nosa copia local de trabajo esté desactualizado con respecto al repositorio. Actualizamos pues nuestra copia de traballo (comando svn update). Una vez resueltos los posibles conflictos existentes, estamos listos para enviar los cambios al repositorio. Puede darse cualquiera de las 2 situacións siguientes:
  1. Tenemos una cuenta propia en el repositorio del proxecto: podemos enviar los cambios directamente.
  2. No tenemos cuenta en el repositorio del proxecto: debemos enviar los cambios a alguien que la tenga.
En el primero de los casos bastaría con: 
$ svn commit
Automáticamente se abriría el editor de texto predeterminado del sistema y en el archivo que nos abre se escribiría una breve descripción de los cambios realizados (”documentación de las funciones” en nuestro caso). Se guarda el archivo y se cierra el editor. Los cambios son enviados al repositorio. Si estamos en la segunda opción (no tenemos conta) debemos enviar un parche a las listas del proxecto para que lo revisen y lo incluyan en el repositorio si lo consideran oportuno.

Cómo enviar un parche

Como ya se ha dicho, es posible que no tengamos acceso al repositorio para subir los cambios. En este caso, la estratexia a seguir consiste en realizar un informe de las diferencias entre nuestra copia local de trabajo y el repositorio. Será eso lo que le enviaremos a las listas del proyecto para que vean los cambios e los apliquen sobre el repositorio si lo creen conveniente. Para hacerlo existen las herramientas diff (que compara archivos línea por línea) y patch (que aplica un parche determinado sobre un archivo). Así, un parche se puede entender como un informe de cambios respecto a uno (o varios) archivo(s). Se puede observar las funcionalidades de cada una de ellas en la página del manual. Para el caso que nos ocupa, el propio cliente de subversion trae integrada la posibilidad de realizar un diff de la copia de trabajo con respecto al repositorio. Lo único que tenemos que hacer para ter un archivo con los cambios respecto al repositorio es: 
$ svn diff > parche.diff
De este modo, en el ficheiro parche.diff tenemos los cambios fichero por fichero. Éste archivo será el que se envíe a las listas del proyecto para que compruben que el parche es correcto, se discuta y se aplique en último caso. Cada proyecto tiene sus normas sociales a la hora de enviar parches, mas en general, buenas prácticas a la hora de realizar y enviar un parche son:
  • Realizarlo sobre la última revisión del proyecto.
  • Enviar el parche a la lista de correo del proyecto, no directamente al programador.
De cara a observar la complejidad del envío y posterior revisión del parche hasta que éste sea aceptado o rechazado, son buenas referencias las siguientes guías:
  • How to participate in the linux community
  • Contribute / Send patches to KDE

Resumen

A lo largo de este post, seguimos el siguiente flujo de trabajo:
  1. svn checkout uri_svn # descargamos el código del proyecto
  2. (trabajamos en la tarea que nos ocupaba: documentación en este caso)
  3. svn update # actualizamos nuestros cambios con otros que han podido hacer otros programadores
    1. (si no existen conflictos pasamos al punto 4)
    2. (revisar y resolver conflictos si existen, luego volver al punto 3)
  4. svn status; svn diff # comprobamos que los cambios registrados sean los correctos
  5. svn commit # subimos los cambios al repositorio
uri_svn = https://svn.forge.morfeo-project.org/svn/freeswmaster/trunk/amaneiro/perl-workshop/ También hemos visto cómo construir y enviar parches en el caso de no tener acceso al repositorio directamente. A partir de este momento, estamos listos para colaborar en cualquier proyecto!