O Kernel de Linux: xestión das releases
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.
O Kernel de Linux: aspectos económicos
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 de Linux: aspectos legais
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.
O Kernel de Linux: recursos e cultura organizativa
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:
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:
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.
