Premio PFC con Sw Libre

No proceso de integración das aportacións é habitual atopar unha serie de medidas informais para garantir a calidade das aportacións e a súa fácil integración. Mais alén destas medidas, a maioría dos proxectos de software libre prevén etapas de testeo e calidade específicas e coordinan os seus esforzos a través dunha axenda común: os ciclos de release.

Funcionalidades VS tempo

Un ciclo de release consiste no tempo e accións que ocorren entre que se publica unha versión do software ata a seguinte. A grandes rasgos, podemos identificar 2 grandes modos de xestionar o ciclo de publicación dun proxecto:

1. Publicación basada en funcionalidades.
2. Publicación basada en tempo.

Decidir cal dos modelos se adecúa ás necesidades do proxecto, pode impactar directamente na calidade do mesmo. Para elexir o modelo adecuado, é preciso ter en conta certos condicionantes:

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

Nunha release basada en tempos este proceso é trivial xa que só entran as que están dispoñibles cando se publica a release. Polo contrario, nunha release basada en funcionalidades o proceso implica negociación entre os múltiples colaboradores do proxecto. Este proceso de negociación pode ser lento e dar lugar a continuas discusións que retrasen unha e outra vez a publicación.

O perfil do coordinador da release nun e noutro caso son moi diferentes. Mentres no primeiro caso, o seu papel limítase a xestionar os tempos e contactar cos colaboradores de cada módulo para facer o seguemento do proceso; no segundo ten un perfil máis político, xa que nun momento determinado pode chegar a forzar a publicación da nova versión.

• Control de calidade

A pesar das medidas informais das que falabamos en post anteriores, unha fase de testeo é necesaria para estabilizar o programa.

Nunha release basada en tempos ésta defínese na propia planificación e si todo vai ben debe cumplirse. Nunha basada en funcionalidades, as releases poden ocorrer súbita e forzadamente (logo dun proceso de negociación que se alonga no tempo e os xestores deciden levar adiante a publicación) polo que a fase de control de calidade pode ser insuficiente.

• ¿O proxecto depende de outros?

Si é así, é importante contar coas releases das dependencias. Por exemplo, si o proxecto usa o kernel de linux como base para facer outra cousa, quizás o máis interesante sexa amoldar o ciclo de release do proxecto ó do kernel, xa que dese modo poderase dispoñer en cada versión das últimas melloras que provee o kernel.

• ¿Qué outras axendas dependen do teu proxecto?

O caso do escritorio GNOME é digno de estudio. Logo da release da versión 2.0, decidiron facer as releases cada 6 meses. Este aspecto organizativo, xunto con outras diferencias co seu competidor directo KDE, facilitaron que moitas distribucións de linux o elexisen como escritorio por defecto. Debido a que coñecen cando se publicará a seguinte versión, outros proxectos poden planificar as súas accións (release da distribución, accións de márketing, organización de eventos etc) con antelación.

A este respecto, Mark Shuttleworth, fundador de Ubuntu, publicou recentemente un post sobre a sincronización da pila completa de aplicacións libres no que falaba sobre a estratexia 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 dispoñen?

A pesar de que as releases basada en tempos teñen grandes vantaxes, necesitan á súa vez unha inxección de recursos importantes, que, si non se dispoñen, poden facer desaconsellable o uso desta ciclo de publicación. Por exemplo, si o proxecto ten unha carencia de programadores que fará imposible sacar regularmente novas versións.

CONCLUSIÓNS

Ó longo deste post, temos visto cómo a sincronización do proxecto ten importancia tanto a nivel interno -garantir a motivación dos colaboradores e unha efectiva coordinación dos esforzos- como a nivel externo -facilitar sinerxias entre proxectos.

Así, elexir o modelo adecuado en cada etapa do proxecto non só afectará ás relacións con outros proxectos e á calidade, senón tamén á motivación dos colaboradores, o codiciado grial de calquera comunidade de software libre.

Logo do último post onde introduciamos os conceptos básicos dun sistema de control de versións, neste imos simular unha sesión de traballo habitual contra un proxecto de software libre.

Para iso escollemos o noso obxectivo. Neste caso imos usar un código que recupera perfís de usuarios e os artistas máis escoitados da plataforma last fm. O programa está feito na linguaxe perl e usa a API de last fm para facelo. A nosa tarefa será documentar o que fai cada unha das funcións do código.

O que necesitamos nun primeiro momento é ter instalado no noso ordenador un cliente svn para conectarnos ó servidor e descargar o código. En Ubuntu o paquete a instalar chámase subversion.

OBTENCIÓN DO CÓDIGO FONTE E REALIZACIÓN DE CAMBIOS

Unha vez o temos imos crear un directorio de traballo temporal para realizar esta sesión. Nunha consola (o símbolo $ indica que son comandos de shell o que vai a continuación) facemos o seguinte:

$ 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/

Neste momento temos o código á nosa disposición e podemos empezar a traballar con él.

Si agora observamos as diferencias da nosa copia local de traballo (coñecida como working copy) con respecto ó repositorio (comandos svn diff, svn status) veremos que a saída de ambos comandos é vacía. Lóxicamente, debe ser así, porque aínda non fixemos ningunha modificación con respecto ó código que nos descargamos. É un bo momento para ver tamén a historia do proxecto (usando o comando svn log) e xogar coas múltiples opcións que posúe.

Para seguir coa sesión, abrimos o noso editor favorito e modificamos o ficheiro ex11.pl documentando cada unha das funcións.

Unha vez rematemos, podemos observar os cambios: cómo variou o estado da nosa copia local de traballo con respecto ó repositorio. Comprobamos os ficheiros modificados (comando svn status) e logo as modificacións introducidas en cada un deles (comando svn diff).

SUBINDO OS CAMBIOS REALIZADOS

Agora que sabemos que os cambios que se realizarán son os correctos, debemos asegurarnos de ter a última versión do código do repositorio, pois é posible que alguén máis estivese traballando en paralelo e o código que teñamos na nosa copia local de traballo esté desactualizado con respecto ó repositorio. Actualizamos pois a nosa copia de traballo (comando svn update).

Unha vez resoltos os posibles conflitos existentes, estamos listos para enviar os cambios ó repositorio. Pode darse calquera das 2 situacións seguintes:

1. Temos unha conta propia no repositorio do proxecto: podemos enviar os cambios directamente.
2. Non temos conta no repositorio do proxecto: debemos enviar os cambios a alguén que teña conta.

No primeiro caso bastaría con facer:

$ svn commit

Automáticamente abriríase o editor de texto predeterminado do sistema e no arquivo que nos abre escribimos unha breve descripción dos cambios realizados (“documentación das funcións” no noso caso). Gardamos o arquivo e cerramos o editor. Os cambios son enviados ó repositorio.

Si estamos na segunda opción (non temos conta) debemos enviar un parche ás listas do proxecto para que o revise e o inclúa no repositorio si o considera oportuno.

CÓMO ENVIAR UN PARCHE

Como xa dixemos, é posible que non teñamos acceso ó repositorio para subir os cambios. Neste caso, a estratexia a seguir consiste en realizar un informe das diferencias entre a nosa copia local de traballo e o repositorio. Será iso o que lle enviaremos ás listas do proxecto para que vexan os cambios e os apliquen sobre o repositorio si o creen conveniente.

Para facer isto existen as ferramentass diff (que compara arquivos liña por liña) e patch (que aplica un parche determinado sobre un arquivo). Así, un parche pode entenderse como un informe de cambios respecto a un (ou varios) arquivo(s). Podedes observar as funcionalidades de cada unha delas na propia páxina do manual. Para o caso que nos ocupa, o propio cliente de subversion trae integrada a posibilidade de facer un diff da copia de traballo con respecto ó repositorio.

O único que temos que facer para ter un arquivo cos cambios respecto ó repositorio é:

$ svn diff > parche.diff

Deste modo, no ficheiro parche.diff temos os cambios ficheiro por ficheiro. Éste arquivo será o que se envía ás listas do proxecto para que comproben que o parche é correcto, se discuta e se aplique en último caso.

Cada proxecto ten as súas normas sociais á hora de enviar parches, mais en xeral, boas prácticas á hora de realizar e enviar un parche son:

• Realizar o parche sobre a última revisión do proxecto.
• Enviar o parche á lista de correo do proxecto, non directamente ó programador.

De cara observar a complexidade do envío e posterior revisión do parche ata que éste sexa aceptado ou rexeitado, son boas referencias as seguintes guías:

• How to participate in the linux community
• Contribute / Send patches to KDE

RESUMO

Ó longo deste post, seguimos o seguinte fluxo de traballo:

1. svn checkout uri_svn # descargamos o código do proxecto
2. (traballamos na tarefa que nos ocupaba: documentación neste caso)
3. svn update # actualizamos os nosos cambios con outros que puideron facer os programadores
1. (si non existen conflictos pasamos ó punto 4)
2. (revisar e resolver os conflictos si existen, logo volver ó punto 3)
4. svn status; svn diff # comprobamos que os cambios rexistrados sexan os correctos
5. svn commit # subimos os cambios ó repositorio

uri_svn = https://svn.forge.morfeo-project.org/svn/freeswmaster/trunk/amaneiro/perl-workshop/

Tamén vimos cómo construir e enviar parches no caso de non ter acceso ó repositorio directamente. A partir deste momento, estamos listos para colaborar en calquera proxecto!

En xeral, nos proxectos de software libre, colaboran persoas de diferentes lugares que coordinan as súas accións a través de internet (listas de correo, chat, …). Esta característica demanda unha ferramenta que posibilite o traballo en grupo sobre o código de forma eficiente.

Para cubrir esa necesidade emerxe unha das ferramentas clásicas no desenvolvemento de software libre: os sistemas de control de versións.

Nun primeiro momento podemos entender esta ferramenta como un sistema para compartir información.

Pero os sistemas de control de versións posibilítannos moito máis que iso .. permítennos, por exemplo, a xestión das revisións do documento. Chámase revisión a cada estado do repositorio ó longo do tempo, é dicir, ós arquivos que inclué nun instante n. A diferencia entre a revisión3 e a revisión4 pode ser que se incluíron, borraron ou modificaron os arquivos do repositorio.

Un sistema de control de versións permítenos recuperar calquera das revisións do repositorio.

Nas seguinte figura podemos observar cómo varía o estado do repositorio (dende a revisión 0 ata a 3) a medida que imos facendo cambios, é dicir, ó engadir, modificar ou borrar algún ficheiro/directorio:

E, a pesar de que o estado final do repositorio é a revisión 3, temos acceso a calquera das anteriores, o que nos posibilita recuperar unha revisión antigua si, por exemplo, alguén introduciu un cambio que fai que o código xa non funcione como debería.

Ademáis disto, os sistemas de control de versións almacenan a historia de cada cambio. Dependendo do sistema elexido, teremos acceso a máis ou menos información, pero en xeral, sempre se pode observar a data da modificación, o autor e os cambios que realizou.

En resumo, un sistemas de control de versións ofrécenos:

• Un lugar onde comparti-lo código do proxecto
• A posibilidade de xestionar as revisións
• Un histórico das modificacións de cada revisión

No caso da forxa de mancomún, o sistema de control de versións que se usa é Subversion (tamén coñecido como svn). Unha moi boa referencia para introducirse no uso deste sistema é o libro Version Control with Subversion, cunha versión dispoñible tamén en español.

FLUXO DE TRABALLO CON SVN

Co ánimo de exemplificar o seu uso, mostramos a continuación o fluxo de traballo dunha sesión normal:

1. Descargar o que hay no repositorio (checkout do repositorio).
2. Traballar sobre o código facendo as modificacións oportunas para implementar a nova característica ou correxir un bug.
3. Comprobar que ninguén subiu cambios dende que descargamos a última revisión. Pode darse que:
1. Alguén fixo cambios pero non afectan ó código que modificamos.
2. Alguén fixo cambios e sí afectan ó código que modificamos: neste caso pode existir un conflicto entre os seus cambios e os nosos. De ser así, é necesario adaptar o código a estes cambios.
4. Subir os cambios ó repositorio.

Co ánimo de exemplificar o seu uso, no seguinte post mostraremos cómo traballar con svn e as ferramentas usadas para enviar un parche a un proxecto de software libre.

Si a modularidade do proxecto é un factores clave para aumentar a participación, o proceso de integración das aportacións é primordial para que non morrer de éxito, é dicir, que a xente continúe participando á vez que se obtén un producto de calidade. Así, as preguntas que debemos responder son as 2 seguintes:

• ¿cómo combinamos cada unha das aportacións nun todo, nun producto final?
• ¿cómo aseguramos a calidade das aportacións?

O modo en que habitualmente as resolven algúns proxectos de software libre supón unha conxunción de uso de ferramentas e cumplimento de certas normas sociais que agora pasamos a relatar.

Ferramentas

A continuacion enumeramos algunhas ferramentas que facilitan o traballo distribuido entre múltiples colaboradores (programadores, traductores, …) xeográficamente dispersos. Aínda que non publicaremos tutoriais de cada unha delas, sí faremos en próximos post unha breve introdución ás máis relevantes.

De cara a entender a súa función, podemos agrupalas nas seguintes categorías:

• Sistemas de control de versións: úsanse para o mantemento, integración e distribución do código fonte dos programas. Exemplos: svn, cvs, git, bazaar.

• Xestión da compilación e configuración. Na compilación e release do producto final é habitual ter que facer unha serie de tarefas repetitivas. Para realizar este tipo de tarefas existen algunhas ferramentas que nos axudan a automatizalas. Exemplos: autotools (autoconf, automake, libtool), ant.

• Sistemas de xestión de incidencias: usadas para a publicación e xestión de bugs encontrados no programa. Nalgúns casos úsanse para listar funcionalidades interesantes para o proxecto. Exemplos: bugzilla, trac.

• Sistemas de monitorización do desenvolvemento (nightly build tools): este tipo de ferramentas son usadas para compilar automáticamente o código e xerar informes (erros de compilación, detección de regresións, …). Exemplos: tinderbox, maven.

As dúas primeiras categorías encaixan á perfección dentro do proceso de integración das aportacións nun producto final: as facilidades que nos dan ferramentas tipo svn ou autotools son inmensas e reducen o coste da integración.

Pola contra, nas últimas 2 categorías encaixan ferramentas especialmente deseñadas para realizar o control de calidade das aportacións.

Procesos e boas prácticas

A continuación agruparemos unha serie de prácticas que se realizan habitualmente nas comunidades e proxectos de software libre que podemos encaixar dentro dos procesos de integración e control de calidade. Evidentemente, existen moitas máis e cada proxecto ten as súas propias. Sirvan éstas simplemente como mostra.

Prácticas relacionados co control da calidade e revisión de código entre pares (peer review):

• Lista de correo de cambios (commits): é común que exista unha lista de correo á que se envían de modo automático os cambios no repositorio do proxecto. Deste xeito, todo o mundo suscrito a esa lista pode observar os cambios que foron feitos, detectando erros e aportando melloras.

• Revisión de parches: ter unha persoa que revise o código que o resto do grupo lle envía. Sólo esta persoa pode enviar os cambios ó repositorio de código do proxecto.

• Grupos de calidade: en certos proxectos existen grupos específicos dedicados á calidade. No proxecto GNOME, por exemplo existe a Bugsquad que se dedica a explorar o xestor de incidencias e bugs, tratando de cerrar aqueles que xa estén resoltos ou repetidos. Con esta práctica están axudando ós desenvolvedores dos proxectos que poden centrarse nos erros realmente importantes. Incluso se chegan a realizar eventos coa única finalidade de realizar esta tarefa.

Prácticas relacionadas coa integración das aportacións nun todo:

• Política de cambios: unha serie de normas que definen cómo se deben facer os cambios no repositorio de código. É normal, por exemplo, atopar a regla de nunca subir cambios que provoquen que o proxecto non compile. Este tipo de normas sociais facilitan que programadores que desexen subir os seus cambios, non se vexan obligados a resolver erros cometidos por cambios introducidos anteriormente.

• Coding style. É habitual que cada proxecto teña o seu estilo de programación, que facilite a lectura e revisión do código. Moitas veces os parches son denegados porque o código enviado non sigue as reglas de estilo do proxecto. Ex: Gnome Coding Style, Mozilla Coding Style Guide.

Por outra banda, existen convencións para o uso de cada ferramenta que se deben explorar a medida que se usan.

Ademáis destas medidas informais integradas no traballo diario, no propio fluxo de publicación do proxecto poden existir fases específicas dedicadas a testear o funcionamento do programa ou á integración. Así, marcarse un plan e ter unha axenda clara que sirva como sincronización dos esforzos, é unha das accións principais que poden favorecer a evolución do proxecto.

Para finalizar, máis que tomar nota de cada unha das prácticas e ferramentas descritas, para liderar un proxecto de software libre, é necesario comprender que a integración das aportacións e os mecanismos de control de calidade son necesarios para que o proxecto non morra de éxito.

Si nun post anterior falabamos da confianza e a motivación como motores da participación, neste rescatamos as 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 cos resultados do estudio de Niels Jorgensen (Incremental and decentralized integration in FreeBSD) onde se di que o …

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

… o que representa unha situación habitual nos proxectos de software libre, xa que a alta modularidade do traballo, permite facer as tarefas asíncronamente á vez que un pode variar o seu nivel de compromiso según a dispoñibilidade.

É por isto, que o teu proxecto debe ser altamente modular.

Porque sen dúbida, ésta é unha das condicións principais que se debe ter en conta á hora de conseguir a masa crítica de participantes, que fagan o proxecto sostible a longo plazo.

Mais neste caso, a modularidade do traballo non se consigue con ningunha ferramenta específica nin só a través da propia arquitectura do software, senón que é relativo á organización do traballo e á capacidade de delegación de tarefas e xestión de grupos humanos. E se ben non existen fórmulas máxicas, sí podemos observar unha serie de patróns habituais ou boas prácticas que facilitarán a participación no proxecto:

• Show me the sources! É boa idea publicar un código base a partir do que continuar o traballo. Non te preocupes de que sexa a mellor solución, senón de que sexa un primeiro intento. Deste modo é máis sinxelo que alguén idee melloras sobre a túa solución e decida participar.

• Release early, release often. Non intentes acabar o proxecto e logo abrilo ó público. ¿Quen desexa participar nun proxecto finalizado? Si queres fomenta-la colaboración dende o principio debes face-lo traballo públicamente.

• ToDo. Manter unha lista de tarefas por facer (to do) é altamente recomendable. Existen múltiples maneiras: a través da web do proxecto, nun arquivo chamado TODO no teu repositorio público de código fonte, ter dispoñible un xestor de incidencias (bugs e features) no que calquera poida encontrar tarefas que realizar, …

• Arquitectura orientada a módulos ou plugins: é unha práctica extendida desenvolver un sistema que soporte plugins e que cada característica (feature) sexa desenvolta como tal (o mesmo se podería dicir dos módulos), desaclopando así o desenvolvemento dunha nova característica co mantemento do core da ferramenta.

• Dar soporte a outros linguaxes (realizar bindings): é posible que o teu proxecto dispoña de bindings que permitan programar noutra linguaxe distinta á que ti decidiches usar no comezo. Esto significa que, por exemplo, si o teu proxecto está programado en C, poderías dar soporte para que calquera persoa que traballe en python poida colaborar.

Debido a que o tempo dos posibles participantes no proxecto é limitado e as súas motivacións diversas, o único que un líder de proxecto pode facer é xerar confianza nas posibilidades do proxecto, dividir o traballo en pequenas tarefas, ampliar o rango posible de participantes.. e confiar en que a xente desexe participar.

Acabamos de crear un grupo para o premio en Facebook.

O grupo é público polo que é posible unirse e invitar a calquera persoa a unirse. Podedes enviar tamén no foro que habilitamos as vosas dúbidas/críticas/suxerencias … ou facelo en modo privado ó meu correo: .

En calquera caso esperamos as vosas aportacións. E recordade, tedes ata o 31 de Outubro para inscrivirvos!

A principal tarefa dun líder de proxecto, consiste en conseguir que o traballo se faga. Diversas motivacións animan ós seres humanos e tendo en conta que os usuarios deciden participar por sí mesmos nun proxecto ou noutro, non existe ningún outro vínculo que una á comunidade máis aló da confianza mutua.

É por iso que tanto os aspectos técnicos como os relativos ás relacións sociais e nettiqueta son necesarios para levar a cabo un proxecto de comunidade exitosamente.

Nun dos textos máis emblemáticos da enxeñería do software libre, “A catedral e o bazar“, Eric S. Raymond expón unha serie de puntos derivados da súa experiencia ó liderar o desenvolvemento do proxecto FetchMail. É interesante observar algúns deles …

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 conta de que a principal idea detrás dos mesmos reside na creación de confianza.

Evidentemente, ésta só se gaña con traballo continuo, mais existen unha serie de boas prácticas a considerar. Como recomendación de cabeceira, o libro Producing Open Source Software, toca moitos dos temas que se deben ter en conta:

• Infraestructura social e política do proxecto ¿quen pode decidir qué?
• Boas prácticas na comunicación
• Xestión de voluntarios

Outro punto importante da vertente social, consiste na organización de eventos onde os participantes se reúnen para discutir o futuro do proxecto, disfrutar de talleres e charlas sobre a tecnoloxía e actividades lúdicas, difundir o propio proxecto… pero básicamente realizan o maior acto social ligado á confianza: reunirse cara a cara e falar.

O CASO NITOT

Un caso de estudio relevante para ilustrar a confianza como vertebrador da comunidade é o “Caso Nitot“.

Para poñernos en contexto, Nitot é o fundador e actual presidente de Mozilla Europe. No BDigital Congress de maio de este ano fixo as seguintes declaracións:

“Hai unha versión en catalán de Firefox construída por voluntarios aos que lles importa o seu idioma, ao igual que a hai en éuscaro. Pero aínda non hai unha versión en galego.

Moitas veces pregúntanmo e a miña resposta é que se ninguén se presenta, non haberá unha versión en galego. Estamos dispostos a que a xente traballe connosco”.

Porén, sí existía unha versión do firefox en galego públicamente dispoñible dende Mancomún pero non integrada nos repositorios do proxecto Mozilla pola excesiva burocracia das súas peticións (ver bugzilla: 1 e 2), o que fixera que os 2 principais colaboradores desistisen nos seus esforzos.

Esto iniciou unha serie de comentarios na rede galega de blogs e listas de correo, así como a resposta do coordinador de Mancomún –Suso Baleato– o que estaba perxudicando a imaxe da Fundación Mozilla.

Logo de 48h todo se solucionou coa peticion de desculpas de Nitot, que recoñecía así o descoñecemento da situación real e o seu erro nas declaracións:

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

Na actualidade, o firefox en galego está oficialmente soportado nos repositorios de mozilla.

A lección a extrapolar neste caso é que nas comunidades de software libre, o único elemento vertebrador é a confianza. Minar a confianza significa golpear as bases da comunidade. Por iso, a única saída a un conflito como o que mostramos era pedir desculpas. Porque no traballo en grupo os erros son asumibles, a mala fé non.

Cando falamos dun proxecto de software libre, non só nos estamos referindo a proxectos realizados con tecnoloxías libres, senón a proxectos de comunidade, onde moita xente en lugares e motivacións diversas colabora na realización exitosa do mesmo.

É por isto que se precisa unha infraestructura para facilitar a colaboración, para que a xente participe e traballe en grupo de un modo natural.

Dende logo, son necesarias unha serie de ferramentas que permitan tanto a interacción entre as persoas: listas de correo, foros, jabber, IRC, wiki, web, blog, planets … como a xestión e mantemento do código: sistemas de control de versións, sistemas de xestión de incidencias (bugs, peticións de novas funcionalidades, …), …

Existen multitude de servizos que nos proveen das ferramentas máis usadas. Sourceforge é un dos máis populares. No caso galego dispoñemos da forxa de mancomún, onde -unha vez nos rexistramos como usuario– temos á nosa disposición as ferramentas básicas que necesitamos para levar a cabo o noso proxecto. En concreto, a forxa de mancomún ofrécenos as seguintes:

• listas de correo e foros
• wiki e web
• sistema de xestión de incidencias
• sistema de control de versións (SVN neste caso)

Pero máis alá das ferramentas usadas, existen asimesmo normas sociais, un fluxo de traballo que respetar: cómo usar as ferramentas para levar a cabo o proxecto que temos entre mans.

De todo esto pretendemos falar nos seguintes posts. E para iso trataremos de seguir as 3 claves que destaca Benkler para que un proxecto de comunidade funcione:

1. A confianza como vertebrador da participación
2. A modularidade do proxecto como factor que potencia da colaboración
3. O problema da integración e control de calidade das aportacións:

• Ferramentas: sistemas de control de versións (cvs, svn, git), sistemas de control de incidencias (bugzilla, trac), ferramentas de axuda á compilación (make, autotools, ant, maven), …
• Boas prácticas na integración do código

Como xa sabedes, nos requisitos para a participación no premio explicítase que para inscribir un PFC no concurso, é necesario:

1. Inscribirse no formulario que temos habilitado
2. Dar de alta o proxecto na forxa de mancomún.

Para facilitar a tarefa de dar de alta un proxecto na categoría , publicamos no blog os seguintes mini-howto visuais realizados pola xente de mancomún.

Os pasos a realizar para dar de alta o proxecto na forxa de mancomún son os seguintes:

1. Darvos de alta como usuario [PNG] [PDF]
2. Rexistrar o voso PFC na forxa [PNG] [PDF]
3. Rexistrar o PFC na categoría Premio ó mellor PFC con SwL (ano 2008) [PNG] [PDF]

Existen varios manuais e guías visuais na forxa de mancomún para introducirse no uso da forxa. Esperamos que vos sexa de axuda todo ese material.

Nos últimos posts, temos visto cómo a principal diferencia do software libre radica nas 4 liberdades: qué se pode facer e qué non. Mais é sobre esta diferencia que emerxen as diferentes vantaxes deste … modo de facer as cousas.

O SwL como PLATAFORMA de INNOVACIÓN e PRODUCTIVIDADE

Nos últimos 8 anos, o software libre pasou de ser un aspecto marxinal da industria do software a convertirse en punta de lanza da mesma. Según estudios da Unión Europea, ademáis do impacto indirecto en termos de crecemento económico, productividade e innovación, tamén se espera que …

“no 2010, o 4% do PIB da Unión Europea dependa de servizos relacionados co software libre, supoñendo o 32% do mercado TIC de servizos”

En palabras de Alberto Abella, director do CENATIC que resume o informe nas seguintes palabras:

“Hoy por hoy, los principales fabricantes de software propietario están localizados en Estados Unidos […] el software libre es una oportunidad para el sector tecnológico europeo, que, por otra parte mantiene el liderazgo en número de desarrolladores […].

Así, tanto por motivos de capacidad de adaptación como por situación de mercado, el software libre es una oportunidad para España y para Europa.”

Todo isto parece indicar un futuro prometedor para o software libre como negocio.

O SwL como PLATAFORMA de APRENDIZAXE

Pero máis alá do negocio xerado e que facilita o software libre, éste tamén se pode entender como unha plataforma de aprendizaxe como nunca tivemos. Un lugar onde a transferencia de coñecementos e tecnoloxía faise de modo natural.

Según as enquisas levadas a cabo por Rishab Gosh, da Universidade de Maastricht, a principal razón pola que os desenvolvedores participan nas comunidades de software libre consiste na posibilidade de:

“aprender e mellorar as súas habilidades (nos campos da programación, entendemento e xestión do copyright así como na xestión e traballo en equipo)”

As respostas pódense ver máis en detalle na gráfica seguinte:

Polo de agora, este gran ecosistema de aprendizaxe compartido e de transferencia tecnolóxica quedaba ó marxe da educación formal.

Mais xa dixemos que o presente e futuro é prometedor para o negocio do software libre, polo que emerxe ós poucos a necesidade de persoal capacitado que sexa capaz de traballar con software libre e entenda este modo de face-las cousas.

Tanto é así que nos últimos anos lévanse realizando en España ata 3 iniciativas distintas especializadas no estudio do software libre (máster da URJC, máster da UOC, máster da UEX). Aparecendo tamén grupos de investigación centrados no estudio e evolución do software libre (Grupo Open Source do MIT, Grupo Libresoft da URJC).

CONCLUSIÓNS

Existen claras razóns comerciais e de aprendizaxe compartido para fomenta-lo uso do software libre, mais é preciso remarcar que defendendo o software libre como ferramenta …

“[…] estamos a defender unha sociedade baseada no coñecemento como actividade económica principal. Unha sociedade que desenvolva a súa calidade de vida, o seu benestar, ó redor da explotación dese coñecemento, da innovación e colaboración sobre el.

O software libre é unha ferramenta que, de forma natural, se integra nese obxectivo, porque responde a esa fórmula de colaboración e de traballo.

Non é unha cuestión de defende-lo software libre, senón de defender unha sociedade baseada no coñecemento”.

Éses son os nosos obxectivos, as nosas cartas. Apúntaste?