Premio PFC con Sw Libre

O mércores 12 pola tarde realizouse o evento de resolución do premio. O xurado, estivo conformado polos 3 decanos/directores das facultades de informática galegas: Antonio Mosquera pola ETSE da USC (e anfitrión desta edición), Alberto Valderruten pola FIC da UdC, Enrique Barreiro pola EI da UVigo; Suso Baleato como coordinador de Mancomún, Centro de Referencia e Servizos de Sw Libre a nivel galego; Javier Vázquez e eu mesmo (Andrés Maneiro) por parte de Igalia.

• Aspectos técnicos: a condición de Matrícula de Honra do PFC presentado.

• Actividade pública: integración do PFC cun proxecto existente como gvSIG como extensión non oficial.

Porén, o xurado decidiu conceder o Accésit (cunha dotación de 500€) a Orlando García Feal co proxecto Katmus.

Finalmente, e debido á calidade do proxecto presentado, o xurado decidiu outorgar unha Mención de honra (sen dotación económica) non contemplada ó inicio, a Diego Pérez Montes polo proxecto ASTRA.

[Na foto, Diego Pérez, Orlando García e Miguel Álvarez]

Finalmente, só queremos felicitar a todos os participantes polo gran esforzo realizado nos seus PFC.

Esperamos que o modesto impulso que é o premio contribuíse ós obxectivos que nos marcamos ó comezo:

• Pór en valor o traballo realizado polos estudantes, amosando que é posible realizar PFC con software libre, ben sexa aportando novas funcionalidades a un proxecto existente ou lanzando un propio.

• Aumentar o coñemento do funcionamento das comunidades de software libre na comunidade universitaria a través da guía que fomos elaborando ó longo de todos estes meses.

Gracias a todos por conectarvos connosco.

Unha vez pechado o proceso de inscripción no premio, de todos os interesados e pre-inscritos, finalmente os finalistas son:
• Antón Román – BlueSS Server for Linux
• Carlos Franco – Vídeo estereoscópico
• Diego Pérez – ASTRA: Advanced Sphinx TRAiner
• Miguel Álvarez – Herramientas de análisis de redes en un sistema de información geográfica
  
• Orlando García – Katmus

A fase final do evento realizarase na Universidade de Santiago de Compostela:

• Data: 12 de Novembro, 16:30h
• Lugar: Escola Técnica Superior de Enxeñería da Universidade de Santiago de Compostela. [ver mapa]

<br /> <p>Cada un dos participantes terá 15 minutos para realizar unha presentación do seu proxecto. Posteriormente, o xurado realizará unha avaliación dos mesmos para dar lugar ó gañador.</p> <p>O evento é aberto e estades invitados a asistir tanto á presentación como ós pinchos posteriores, onde ademáis teredes a oportunidade de falar directamente cos participantes e <a xhref=”http://blogs.igalia.com/premio-pfcsoftwarelibre-2008/premio-pfc-sw-libre-unha-faq/#xurado” mce_href=”http://blogs.igalia.com/premio-pfcsoftwarelibre-2008/premio-pfc-sw-libre-unha-faq/#xurado”>xurado</a>.</p> </ul>

Estamos na fase final do Premio ó mellor PFC de Sw Libre, só queda un mes para que se cerre o plazo de inscripción.

Ó longo deste tempo temos publicado unha serie de post co obxetivo de acercar o funcionamento das comunidades de sw libre ó estudantado galego. Acabamos de publicar un post con todo o anterior, onde compilamos unha panorámica global da xestión de un proxecto de software libre.

En liñas xerais, os fitos máis importantes para o premio son:

• Inscripción ata o 31 de outubro de 2008
• Só para PFCs do ano académico 07/08 (setembro 08 incluido)
• O PFC debe ter unha licencia de sw libre (aprovada pola FSF ou a OSI)
• 1000 € ó gañador e posibilidade de un accésit de 500 €

Esperamos a túa participación!

Ó longo do recorrido deste blog temos publicado unha serie de posts sobre os aspectos organizativos, legais e económicos das comunidades e proxectos de software libre.

Recopilamos agora todo o anterior, unha panorámica global da maioría dos puntos a ter en conta para xestionar un proxecto de software libre, coa que pretendemos acercar o funcionamento das comunidades de sw libre á comunidade universitaria galega. Esperamos que vos sexa de utilidade.

Aspectos legais:

• Elexindo licencia para o código
• A xestión do copyright
• Licencias e copyright dos PFC nas universidades galegas
• Caso práctico: o kernel de linux, aspectos legais

Aspectos económicos:

• Financiación e modelos de negocio en Sw Libre
• Caso práctico: kernel de linux, aspectos económicos

Cómo xestionar a colaboración:

• Fomentar a confianza mutua entre os participantes
• A modularidade do proxecto
• Integración das aportacións
• Caso práctico: kernel de linux, cultura organizativa

Decidindo o ciclo de publicación:

• Xestionando o ciclo de publicación
• Caso práctico: kernel de linux, xestión das releases
• Caso práctico: escritorio gnome, xestión das releases

Ferramentas:

• Unha panorámica xeral das ferramentas 
• Repositorios e mantemento do código
• Caso práctico: sesión de traballo con svn e envío de parches

En posts anteriores temos visto a importancia dos procesos de publicación para a sincronización do traballo e unha breve explicación sobre cómo o proxecto GNOME xestiona as releases. A pesar de que –dende as versións 2.6– o kernel posúe un ciclo de publicación baseado en tempos, éste non é tan ríxido como o de GNOME.

Ambos proxectos difiren enormemente: os clientes de gnome son principalmente usuarios, é un proxecto que pretende integrar moitas aplicacións dispersas con problemáticas específicas (localización, accesibilidade, …); porén, os clientes do kernel son -na súa gran maioría- outras aplicacións que requiren unha serie de funcionalidades do hardware, é un proxecto de baixo nivel.

Por outra banda, en canto á cultura organizativa do kernel podemos dicir que é un proxecto intensivo en uso de listas de correo e posúe un modo de organización xerárquico (en conxunción con procesos de peer review), onde a última palabra sobre a publicación a posúe Linus Torvalds.

Os fitos clave da publicación dunha nova versión do kernel:

• Merge window open: o proceso de creación dunha nova release comeza unha vez se publica unha versión estable. Durante un período aproximado de 2 semanas pódense enviar parches relacionados con novas funcionalidades, cambios na API, etc.

• Publícase a “release candidate1“: a partir deste momento comeza un proceso de estabilización das funcionalidades engadidas e -idealmente- non se permiten máis parches que os de corrección de bugs.

• Estabilización do kernel: cada 5/10 días publícase unha nova release candidate do kernel resolvendo novos bugs.

• Publicación da rama estable: aínda que non existe un deadline claro -decídese a través das listas de correo- un baremo habitual é considerar o número de regresións respecto ó anterior. Mais a última palabra tena sempre Linus Torvalds, o desenvolvedor principal.

O proceso repítese de xeito iterativo ó longo das versións, seguindo o esquema mencionado, publicando cada 2/3 meses unha nova versión do kernel. Unha vez publicada o seu mantemento pasa a mans do equipo da rama estable e o ciclo comeza de novo coa seguinte versión.

Según un estudio da Linux Foundation, na versión 2.6.24 do kernel de linux colaboraron uns 1057 desenvolvedores distintos e 187 empresas. As razóns para facer isto son diversas e as empresas teñen as súas propias motivacións económicas. Neste post pretendemos botar luz sobre ese aspecto.

Según os datos recavados pola Linux Foundation:

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

Pódese decir que a principal fonte de financiación do kernel son empresas externas que:

• o usan como base para comercializar produtos derivados (hardware e software)

• realizan melloras específicas que necesitan internamente por outros motivos

Estas empresas posúen co kernel dunha sólida base para a consolidación dos seus respectivos modelos de negocio:

• Venta de hardware (IBM, Intel, HP): a súa aportación débese a que desexan asegurar que os seus sistemas son compatibles cos sistemas linux, o que redundará nunha maior venta de hardware.

• Uso do kernel embedido en sistemas multimedia como móviles, cámaras, televisions, … (Nokia, Sony, ..): colaborando no kernel asegúranse seguir dispoñendo no futuro dunha plataforma sobre a que construir os seus produtos.

• Unha variante do anterior son os sistemas embebidos en produtos non TIC (Volkswagen): esta empresa non vende directamente produtos TIC, porén usa o kernel como base para os seus sistemas integrados nos vehículos.

• Comercialización de software e servizos sobre produtos que integran o kernel (RedHat, Novell): estas empresas empaquetan en conxunción co kernel unha serie de programas que dan lugar a distribucións de linux. Sobre esto contrúen o seu modelo de negocio baseado na comercialización de diversos servizos.

Polo tanto, según os datos que temos visto, pódese dicir que o kernel é un proxecto estable, maduro e sustentable a longo plazo, pois conseguiu agregar ó redor del a unha serie de axentes que teñen os incentivos suficientes para participar activamente na súa produción.

O kernel é un gran proxecto con moitos módulos e código de diversos autores coa posibilidade de ter licencias diferentes. Porén, debido a que nun primeiro momento foi licenciado coa GPLv2, as aportacións posteriores teñen que ser compatibles con esa licencia.

Así, na práctica, pódese dicir que o kernel está licenciado coa GPLv2, o que significa que é posible usalo para facer produtos derivados a partir dese código sempre e cando o resultado sexa licenciado cunha licencia compatible coa gpl.

A GPL e os Loadable Kernel Modules

A pesar da breve introdución que escribimos ó respecto das licencias e a xestión do copyright (tamén no ámbito galego), o mundo legal é complexo e existen algúns puntos grises que non están resoltos. Principalmente porque a GPL nunca tivo que enfrentarse a un xuízo no que se dictase sentencia. (ver comentarios: gracias Fran polas aportacións!).

Un dos aspectos grises é … ¿qué se considera traballo derivado?, e polo tanto, está baixo ás leis do copyright. A idea máis habitual neste sentido é que un programa de software B considérase traballo derivado dun programa A cando B reúsa código fonte de A.

Seguindo a anterior aseveración, os módulos que se cargan no kernel en tempo de execución non son considerados traballos derivados xa que non reúsan o código fonte do kernel (non son compilados como un todo), senón que simplemente fan uso das API públicas para “conectarse” ás súas funcionalidades (kernel e módulo compílanse por separado e o seu único contacto é como binarios en tempo de execución).

Así, sería técnica e legalmente posible realizar un módulo propietario para o kernel.

Mais existe unha razón principal (máis alá das éticas) que desaconsellan facelo: o mantemento do módulo será máis costoso. Ó ser propietario non é posible beneficiarse dos aportes da comunidade; esto implica, por exemplo, que ninguén avisará de cambios nas API do kernel, nin poderán ser correxidos os bugs: será necesario estar ó tanto dos cambios, realizar as probas de mantemento con cada versión publicada do kernel e actualizalo ó longo do tempo.

COPYRIGHT HOLDERS

Logo de analizar o kernel dende o punto de vista da licencia, facémolo agora dende o do copyright.

O copyright de cada unha das aportacións pertence ó propio autor que a realizou. A diferencia doutros proxectos (como o caso da FSF e da Fundación Apache), o kernel non pide unha cesión do copyright. Esta situación implica que un cambio de licencia debe ser negociado con todos e cada un dos implicados.

Por outra banda, a licencia GPL posúe un mecanismo que facilita o relicenciamento: existe unha cláusula coa que se pode indicar que o proxecto pode usar unha determinada versión da GPL ou calquera superior (x ex: GPLv2 or later, ver punto 9). O kernel tampouco usa esta fórmula.

Deste modo, vemos que futuros procesos de relicenciamento do proxecto requerirán o contacto e aprobación de cada un dos autores (que pode ser dificultoso como xa temos visto noutros casos: mozilla e kde), ou simplemente descartar ese código e refacelo dende cero.

Neste momento, estamos capacitados para entender a grosso modo o funcionamento de calquera proxecto de software libre. Debido á súa importancia imos iniciar unha serie de post onde analizaremos -dende todos os puntos de vista tratados neste blog- o kernel de linux.

RECURSOS e TECNOLOXÍAS USADAS

Nun primeiro acercamento ó proxecto teremos que mapear os recursos que posee e o modo de interacción dos colaboradores. En primeiro lugar identificamos as ferramentas máis habituais:

• web, listas de correo, …
• repositorios de git, bugzilla, …

Como característica principal vemos que o repositorio usado no kernel non é svn, senón git. Este sistema de control de versións é distribuido, polo que o fluxo de traballo é un pouco diferente do que vimos en svn. Na propia páxina de git hai extensa documentación sobre cómo usalo. Un documento moi recomendable é Git from the bottom up [PDF].

Outro método para obter información do proxecto é baixarse o código fonte directamente do repositorio. Unha vez localizada a árbore de repositorios, identificamos a rama que corresponde coa última versión do kernel. Descargámolo e executamos o programa sloccount para coñecer o número de liñas de código de cada linguaxe de progamación no proxecto:

cd /tmp

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

cd linux-*

sloccount .

Como resultado obteremos (entre outras cousas) un listado de linguaxes usados e liñas de código de cada un deles. Neste caso, o código escrito en ansic supón un 96% do total. Deste modo temos idea de qué tecnoloxías son maioritarias no proxecto.

Por outra banda, podemos atopar arquivos de interese neste repositorio (x ex: MAINTAINERS, que nos dirá o mantedor de cada módulo).

MODULARIDADE e INTEGRACIÓN

Outro dos puntos importantes que debemos entender é a cultura de colaboración no proxecto: ¿cómo interactúan entre eles? ¿cómo se envían parches? ¿usan wikis ou listas de correo para xestionar o traballo que debe ser feito?

Para tratar de responder a estas preguntas, identificamos 2 recursos principais:

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

Aínda que o modo de facer as cousas, a cultura organizativa, só se pode aprender interactuando dentro da comunidade, sí podemos identificar algúns dos puntos claves do proxecto.

Como dixemos, a modularidade do traballo é un factor clave de cara a distribuir as tarefas o máis posible e obter participación. No kernel, resolven esta cuestión dividindo o proxecto en múltiples módulos nos que participar. Por outra banda, dividir o proxecto en múltiples partes require un proceso de integración posterior.

Este proceso, consiste nun fluxo continuo e iterativo de revisión de parches e ata que éstos finalmente se integran no que será o kernel pasan por varias etapas de revisión. Os aspectos clave de todo o proceso son:

• Revisión de parches en listas de correo de cada subsistema: os parches con novas funcionalidades son enviados á lista de correo correspondente (do módulo ou subsistema) onde se discuten e revisan. Logo de pasar a validación o mantedor pode integralo no seu repositorio. Posteriormente ese conxunto de parches pasan a módulos ou subsistemas superiores repetindo o proceso.

• Árbores de integración: máis alá do proceso anterior de integración ó longo da cadea de subsistemas, existen 2 árbores especialmente dedicados á integración transversal de parches que veñen de diversos sistemas. Éstos son o mm tree (árbore de xestión de memoria) e o linux-next, xestionados por Andrew Morton e Stephen Rothwell respectivamente. A súa función consiste en testear que os parches de varios subsistemas inferiores traballan en conxunto previo ó paso á rama de desenvolvemento principal (mantida por Linux Torvalds).

Este sistema xerárquico de integración e revisión, garante un control de calidade baseado na revisión do código de forma continua e por múltiples programadores. Por outra banda, ferramentas avanzadas de xestión de código (git) e parches (quilt) facilitan o traballo de integración dos programadores.

Con todo esto temos aproximado un primeiro intento de comprensión da cultura dos hackers do kernel, do seu modo organizativo: xerárquico (o traballo delegado en varios subsistemas) á vez que meritocrático (continua revisión de parches a través de listas de correo). Un modo de traballo que lles permite obter un produto de alta calidade cada 8/10 semanas.

Ó longo dos direferentes posts, temos repasado diversos puntos dun proxecto de software libre, dende os aspectos legais ata os organizativos. Mais unha das cuestións clave reside en coñecer os modelos de financiación e rentabilidade do proxecto.

En aras dunha mellor comprensión, podemos distinguir dúas áreas principais de estudo:

• a financiación do producto
  
• o modelo de negocio asociado (ou cómo retornar a inversión)

ESQUEMAS DE FINANCIACIÓN

Co seguinte esquema exemplificamos os modelos de financiación máis habituais, asociando a cada exemplo un caso coñecido de proxecto ou empresa:

En resumen, os esquemas de financiación poden categorizarse a grosso modo según a seguinte lista:

• Pública (modelo LinEx)

Unha determinada institución pública considera adecuado invertir nun proxecto, ben porque ninguén invirte debido ó escaso retorno económico (o caso do CENATIC co DNI-electrónico), por motivos estratéxicos -redución de costes e creación de industria local- (o caso dalgunhas administracións públicas españolas) ou de seguridade nacional (o caso do goberno alemán que financiou desenvolvementos específicos de gnupg).

• Privada sen ánimo de lucro (modelo FSF)

Neste punto encaixa o papel das fundacións privadas como a Free Software Foundation.

• Melloras específicas (modelo Wine-Corel)

Wine é unha implementación da API de windows en entornos UNIX. Nun momento dado, Corel decidiu invertir no proxecto Wine (contratando a desenvolvedores a tempo completo) de cara a mellorar a estabilidade do mesmo. Coas melloras de Wine, Corel gañaba portabilidade entre distintos sistemas, achegándose ós 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):

Neste sentido as inversións en proxectos de sw libre van relacionadas cos modelos de negocio existente (que tratamos posteriormente).

• Outros: marketplace (modelo SourceForge), donacións, bounties (eventos que tratan de incentiva-la creación de código libre)…

MODELOS DE NEGOCIO

Por outra parte, en canto ós modelos de negocio, tamén realizamos un mapa de conceptos exemplificándoos con proxectos e empresas coñecidas:

O esquema está realizado según a clasificación de Hecker (blog persoal), un dos artífices da liberación do código de Netscape e que actualmente traballa para a Fundación Mozilla. Según Hecker, pódense diferenciar os seguintes modelos de negocio (aínda que existen outras clasificacións):

• Support Seller (modelo Ubuntu – Canonical)

Consiste na venta de soporte e servizos asociados ó producto. Nesta categoría podemos encontrar dende servizos de consultoría ata desenvolvemento de necesidades específicas non cubertas polo produto.

• Loss leader (modelo Ximian-Exchange)

O programa libre sirve como base para a comercialización de produtos propietarios. O exemplo máis claro probablemente sexa o da empresa Ximian (agora parte de novell) que se encargou do desenvolvemento do xestor de correo libre Evolution, sobre o que comercializaban o conector para servidores Microsoft Exchange 2000 como produto propietario.

• Widget frosting (modelo Nokia–maemo)

Neste caso, a empresa rentabiliza a inversión coa venta de hardware e o software é unha commodity, algo que non reporta beneficios. Así é o caso da internet tablet de Nokia que corre baixo a plataforma de software libre Maemo.

• Accessorizing (modelo O’Reilly)

Este modelo de negocio consiste na comercialización de produtos relacionados. Moi coñecido é o caso da editorial O’Reilly. unha das máis reputadas no mundo técnico e de software libre. O impacto da marca sobre este nicho de mercado é dedido en gran medida pola continua promoción de eventos e subvención de proxectos de software libre, que logo rentabiliza en forma de publicación de libros técnicos e contacto directo cos hackers.

• Service enabler (modelo google)

Neste modelo, o software libre sirve como base para comercializar un servizo (non relacionado co produto), polo que a empresa ten interese en invertir en proxectos de software libre que necesite á hora de proveer o servizo con calidade (servidores web, linguaxes específicos).

• Brand licensing (modelo MySQL)

Esta estratexia consiste en asociar un produto cunha marca concreta. Unha vez feito, é posible comercializar servizos relacionados coa marca: cursos de formación específicos, certificacións, …

• Software franchising (modelo RedHat, MySQL)

A diferencia do anterior neste modelo franquíciase a marca, podendo usala para certos fins específicos. Programas de partners como os de MySQL entrarían nesta categoría.

• Sell it, Free it (modelo GNAT)

Por último, existe a estratexia de comercializar un produto de software libre para -unha vez teña certo éxito- distribuir as seguintes versións como propietarias durante un tempo, liberándoas con cada nova versión lanzada. Éste é o modelo que sigue a empresa AdaCore vendendo unha versión do compilador de ADA GNAT por unha suscripción que libera posteriormente.

LICENCIAMENTO DUAL

Por último, falamos dun modelo non recollido no artigo de Hecker. Si ben no mundo do software privativo é habitual que o modelo de negocio esté baseado na venta de licencias (que concede a posibilidade de uso dun programa en certos entornos controlados), en xeral non ocorre así no mundo do software libre. Mais existe a posibilidade de obter rentabilidade por pago de licencias.

Para iso, o programa debe ter un licenciamento dual, é dicir, debe ter dúas licencias. É habitual que unha delas sexa unha licencia robusta (polo que permite usar o código e melloralo sempre que os derivados se licencien con outra licencia robusta) e outra sexa específicamente deseñada para poder crear produtos derivados propietarios a cambio dunha cantidade a negociar.

CONCLUSIÓNS

É evidente que os modelos dos que falamos anteriormente non son estancos e as empresas tecen un complexo fluxo comercial no que fan uso de varios simultaneamente. Estudialos de modo desagregado danos a posibilidade de observar as múltiples posibilidades que existen.

Si observamos por exemplo a empresa MYSQL AB vemos que ten varias fontes de ingresos por diferentes motivos: venta de servizos (consulting, support), marca e franquiciado, así como por venta de licencias. Todos eles baseados na explotación do coñecemento ó redor de produtos de software libre.

O ciclo de lanzamento dun proxecto comprende tarefas dependentes unha das outras: mentres o desenvolvedor non remata de facer as modificacións ó programa e engadir/modificar/eliminar as cadeas que se presentarán ó usuario (en forma de diálogos, por exemplo), os tradutores non deberían comezar a facer o seu traballo. Estas interdependencias son habitualmente xestionadas mediante os períodos de conxelación (freezes) ós que se lle asignan datas e a partir dos cales non se poden facer certos cambios.

O ciclo de release do proxecto GNOME está baseado en períodos de publicación de 6 meses, onde se estipulan certos puntos de sincronización de traballo. Algúns dos freezes existentes son:

• Feature Freeze – período a partir do cal non se poden engadir novos módulos ou funcionalidades.
• API/ABI Freeze – as librerías da plataforma deben manter tanto a compatibilidade binaria (ABI) como a API.
• String Freeze – período a partir do cal non se poden engadir novas cadeas de traducción.
• …

Un maior detalle de cada un deles pódese observar dentro da propia páxina de GNOME.

Así, para cada versión do proxecto publícase unha axenda onde se indican os períodos de freeze. Deste modo, os colaboradores poden organizar o seu traballo de acordo a un timeline común. Existe tamén un equipo encargado da xestión da release que vela -entre outras cousas- porque a axenda se cumpla así como da aceptación/denegación dos freeze breaks: a pesar de que existen uns períodos de conxelación para sincronizar o traballo, éstos non son ríxidos e sempre queda a opción de pedir permiso para realizar cambios.

Como exemplo de xestión, podemos ver esta petición de break freeze, onde se plantexa a modificación dunha cadea de traducción (mais o período para modificar as cadeas de traducións xa pasou). A petición é enviada á lista do equipo xestor da release (seguindo as normas do proxecto) para que decida qué facer con ela (valorando si pode ou non retrasar significativamente a release). Seguindo o fío da conversa na lista de correo, podemos ver cómo neste caso a petición é aceptada e a cadea cambiada satisfactoriamente.

Na propia páxina do proxecto podemos observar unha panorámica do lanzamento de Gnome 2.23:

O escritorio GNOME comprende múltiples módulos e colaboradores traballando en paralelo, polo que medidas como as que acabamos de relatar son necesarias para publicar cada 6 meses unha release de calidade. Porén, é habitual que os puntos de sincronización sexan máis informais cando un proxecto é menor en tamaño, ten menor número de colaboradores ou o modo de organización é diferente.