Los abundantes resultados finales producidos por el proyecto Debian derivan simultáneamente del trabajo de sus desarrolladores experimentados en la infraestructura, trabajo individual o grupal de desarrolladores en paquetes Debian y comentarios y sugerencias de usuarios.
1.3.1. Los desarrolladores Debian
Los desarrolladores Debian tienen varias responsabilidades y, como miembros oficiales del proyecto, tienen una gran influencia en la dirección del mismo. Un desarrollador Debian generalmente es responsable de al menos un paquete, pero según su disponibilidad y voluntad son libres de involucrarse en varios grupos asumiendo, así, más responsabilidades dentro del proyecto.
La manutención de paquetes es una actividad relativamente organizada, muy documentada o inclusive reglamentada. Debe, de hecho, adherirse a todos los estándares establecidos por la
Normativa Debian («Debian Policy»). Afortunadamente, existen muchas herramientas que facilitan el trabajo de los desarrolladores. Ellos pueden, entonces, concentrarse en las particularidades de su paquete y en tareas más complejas como la corrección de errores.
La Normativa («Policy») es un elemento esencial del proyecto Debian, establece las normas que garantizan tanto la calidad de los paquetes como también la interoperabilidad perfecta de la distribución. Gracias a este documento, Debian se mantiene consistente a pesar de su gigantesco tamaño. La Normativa no está escrita en piedra sino que evoluciona continuamente gracias a propuestas formuladas en la lista de correo
debian-policy@lists.debian.org. Las modificaciones acordadas por todas las partes interesadas son aceptadas y aplicadas al texto por un grupo reducido de desarrolladores que no tienen responsabilidad editorial (sólo incluyen las modificaciones aceptadas por los desarrolladores Debian que son miembros de la lista antes mencionada). Puede leer las correcciones propuestas siendo discutidas en el sistema de seguimiento de errores:
Las directrices cubren muy bien los aspectos técnicos del embalaje. Sin embargo, los problemas organizativos también surgen por el tamaño del proyecto; estos se tratan en la Constitución de Debian, que establece una estructura y un procedimiento para la toma de decisiones. En otras palabras, un sistema formal para la gestión de proyectos.
Esta constitución define un cierto número de roles y posiciones y las responsabilidades y autoridades para cada uno. Cabe destacar especialmente que los desarrolladores de Debian siempre tienen la autoridad para tomar decisiones finales a través de una resolución general que requiere una mayoría calificada de tres cuartas partes (75 %) de los votos emitidos para realizar cambios sustanciales (como los que afectan a los documentos principales). Mientras tanto, cada año los desarrolladores eligen un "líder" que los representa en las reuniones y que asegura la coordinación interna entre los diferentes equipos. Esta elección es siempre un momento de amargo debate. El rol de este líder del proyecto Debian (
DPL>) no se define explícitamente en ningún documento: Los candidatos a este puesto suelen proponer su propia definición de este puesto. En la práctica, las funciones del líder incluyen representar a los medios, coordinar equipos "internos" y brindar orientación general sobre el proyecto para que los desarrolladores se refieran a ellas: las opiniones del DPL son expresadas tácitamente por la mayoría de los miembros del Proyecto reconocidos.
Específicamente, el líder realmente tiene autoridad: sus votos deciden votaciones empatadas, pueden tomar decisiones sobre aquello que no esté a cargo de alguien más y pueden delegar parte de sus responsabilidades.
Desde su creación, el proyecto ha sido dirigido sucesivamente por Ian Murdock, Bruce Perens, Ian Jackson, Wichert Akkerman, Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson, Anthony Towns, Sam Hocevar, Steve McIntyre, Stefano Zacchiroli, Lucas Nussbaum, Neill McGovern, Mehdi Dogguy, Chris Lamb, Sam Hartman y Jonathan Carter.
La constitución también define un «comité técnico». El rol esencial de este comité es tomar decisiones en asuntos técnicos cuando los desarrolladores involucrados no llegaron a un acuerdo entre ellos. De lo contrario, el comité tiene un rol de consejero para cualquier desarrollador que no tome una decisión en una cuestión de la que son responsables. Es importante notar que el comité sólo se involucra cuando alguna de las partes así lo solicita.
Por último, la constitución define la posición de «secretario del proyecto» quien está a cargo de organizar las votaciones relacionadas a las varias elecciones y resoluciones generales.
El procedimiento de "resolución general" (
GR) está totalmente detallado en los estatutos, desde el periodo inicial de debate hasta el recuento final de votos. El aspecto más interesante de ese proceso es que, cuando llega el momento de la votación propiamente dicha, los promotores tienen que ordenar las distintas opciones de votación entre sí y el ganador se elige con un
método Condorcet (más concretamente, el método Schulze). Para más detalles ver:
Aunque esta constitución establece una apariencia de democracia, la realidad diaria es bastante diferente: Debian sigue naturalmente las reglas del software libre de la do-ocracia: el que hace las cosas decide cómo hacerlas. Se puede perder mucho tiempo debatiendo los méritos respectivos de varias formas de enfocar un problema; la solución elegida será la primera que sea a la vez funcional y satisfactoria... que saldrá del tiempo que le dedique una persona competente.
Esta es la única forma en que ganará sus insignias: haga algo útil y muestre que ha trabajado bien. Muchos equipos «administrativos» en Debian funcionan por cooptación, prefiriendo voluntarios que ya han realizado contribuciones palpables y demostrado ser competentes. La naturaleza pública del trabajo de estos equipos hace posible que nuevos colaboradores la observen y empiecen a ayudar sin ningún privilegio especial. Esta es la razón por la que Debian es normalmente descripto como una «meritocracia».
Este método de operaciones es efectivo y garantiza la calidad de los contribuyentes en los equipos «clave» de Debian. Este método dista de ser perfecto y ocasionalmente algunos no lo aceptan. La selección de desarrolladores aceptados en los grupos puede parecer arbitraria o incluso injusta. Lo que es más, no todos tienen la misma definición de los servicios esperados de estos equipos. Para algunos es inaceptable tener que esperar ocho días para la inclusión de un nuevo paquete en Debian, mientras que otros esperarán pacientemente por tres semanas sin problemas. Por ello, regularmente hay quejas sobre la «calidad de servicio» de algunos equipos por aquellos que están descontentos.
1.3.2. El papel activo de los usuarios
Uno se podría preguntar si es relevante mencionar a los usuarios entre aquellos que trabajan dentro del proyecto Debian, pero la respuesta es un sí definitivo: tienen un papel crítico en el proyecto. Lejos de ser «pasivos», algunos usuarios utilizan versiones de desarrollo de Debian y reportan fallos regularmente para indicar problemas. Otros van más allá aún y envían ideas para mejoras reportando errores con gravedad «wishlist» o inclusive envían correcciones al código fuente, llamados «parches» (revise el recuadro
Sección 1.3.2.3, “Enviar arreglos”).
1.3.2.1. Informar de errores
La herramienta fundamental para enviar errores en Debian es el sistema de seguimiento de errores de Debian («BTS» por sus siglas en inglés), usada por grandes porciones del proyecto. La parte pública (la interfaz web) permite a los usuarios ver todos los errores reportados con la opción de mostrar una lista ordenada de los errores de acuerdo a diversos criterios de selección tales como: paquete afectado, gravedad, estado, dirección del que lo ha reportado, dirección del desarrollador a cargo del error, etiquetas, etc. También es posible navegar por el listado histórico completo de todos los debates sobre cada uno de los errores.
Bajo la superficie, el BTS de Debian se basa en el email: toda la información que almacena proviene de mensajes enviados por las personas involucradas. Cualquier correo enviado a
12345@bugs.debian.org será asignado a la historia del error número 12345. Personas autorizadas pueden «cerrar» un error escribiendo un mensaje que describa las razones de la decisión para cerrarlo a
12345-done@bugs.debian.org (un reporte es cerrado cuando el problema indicado es resuelto o ya no es relevante). Un nuevo error se puede reportar enviando un correo a
submit@bugs.debian.org siguiendo un formato específico que identifica el paquete en cuestión. La dirección
control@bugs.debian.org permite editar toda la «metainformación» relacionada al reporte.
El BTS de Debian tiene otras características y funciones como el uso de etiquetas para clasificar errores. Para más información revise
Los usuarios también pueden usar la línea de órdenes para enviar informes de bugs en un paquete de Debian con la herramienta reportbug. Ayuda a asegurarse que el bugr en cuestión no se ha informado previamente, evitando así duplicados en el sistema. Recuerda al usuario las definiciones de los niveles de gravedad para que el informe sea lo más preciso posible (el desarrollador siempre puede ajustar estos parámetros luego si hiciera falta). Ayuda a escribir un informe de error completo sin necesidad de que el usuario conozca la sintaxis correcta, escribiéndola primero y luego dejando que el usuario la edite. Luego se envía este informe a través de un servidor de correo (uno remoto gestionado por Debian de forma predeterminada, pero reportbug también puede utilizar un servidor local).
Esta herramienta siempre apunta primero a las versiones de desarrollo, donde se solucionarán los errores. En efecto, no se introducen cambios en una versión estable de Debian salvo por unas pocas excepciones, como actualizaciones de seguridad u otras actualizaciones importantes (si, por ejemplo, un paquete no funciona en absoluto). La corrección de un error menor en un paquete de Debian deberá, entonces, esperar a la próxima versión estable.
1.3.2.2. Traducción y documentación
Además, a muchos usuarios satisfechos con el servicio ofrecido por Debian les gustaría hacer su propia contribución al proyecto. Como no todos tienen la experiencia necesaria en programación pueden elegir ayudar con la traducción y revisión de la documentación. Existen listas de correo específicas a cada idioma para coordinar este trabajo.
Los usuarios más avanzados podrían ser capaces de proporcionar un arreglo a un programa enviando un parche.
Un parche es un archivo que describe los cambios realizados a uno o más archivos de referencia. En particular, contendrá una lista de las líneas eliminadas o agregadas al código así como también (además) líneas tomadas del texto de referencia que ponen en contexto las modificaciones (permiten identificar la ubicación de los cambios en caso que los números de línea hayan cambiado).
La herramienta utilizada para aplicar las modificaciones en uno de estos archivos es patch. La herramienta que los crea es diff y se utiliza de la siguiente forma:
$ diff -u archivo.antiguo archivo.nuevo >archivo.patch
El archivo archivo.patch contiene las instrucciones para cambiar el contendo de archivo.antiguo al contenido de archivo.nuevo. Podemos enviarlo a alguien que luego puede utilizarlo para crear archivo.nuevo de los otros dos de la siguiente forma:
$ patch -p0 archivo.viejo <archivo.patch
El archivo archivo.viejo es ahora idéntico a archivo.nuevo.
En la práctica, la mayoría del software se mantiene actualmente en repositorios Git, por lo que es más probable que los colaboradores utilicen git para recuperar el código fuente y proponer cambios. git diff generará un archivo en el mismo formato que lo que haría diff -u y git apply puede hacer lo mismo que patch.
Si bien la salida de git diff es un archivo que puede compartirse con otros desarrolladores, normalmente hay mejores formas de enviar cambios. Si los desarrolladores prefieren recibir parches por correo electrónico, normalmente quieren parches generados con git format-patch para que puedan ser integrados directamente en el repositorio con git am. Esto preserva la información de metadatos de los «commits» y permite compartir varios «commits» de golpe.
Este proceso de trabajo por correo electrónico es todavía popular, pero tiende a ser reemplazado por el uso de merge requests (o pull requests) cuando el software se aloja en una plataforma como GitHub o GitLab —y Debian usa GitLab en su servidor salsa.debian.org—. En estos sistemas, una vez creada una cuenta, bifurcas (fork) el repositorio, creando efectivamente una copia del repositorio en tu cuenta, y después puedes clonar ese repositorio y subir (push) tus propios cambios a este. Desde ahí, la interfaz web te sugerirá que envíes un merge request, notificando a los desarrolladores de tus cambios, facilitándoles la revisión y aceptación de tus cambios con un simple clic.
1.3.2.4. Otras formas de colaborar
No sólo los usuarios se ayudan entre ellos (y a otros) con problemas técnicos que los afectan directamente sino que también discuten las mejores formas para contribuir con el proyecto Debian y ayudar moverlo adelante — discusiones que frecuentemente resultan en sugerencias para mejoras.
Como Debian no gasta fondos en capañas de promoción sus usuarios cumplen un papel esencial en su difusión, asegurando su fama con el boca a boca.
Este método funciona bastante bien ya que se encuentran fanáticos de Debian en todos los niveles de la comunidad de software libre: desde festivales de instalación (talleres en los que usuarios experimentados ayudan a novatos a instalar el sistema) organizado por grupos de usuarios Linux (
LUG por sus siglas en inglés), hasta puestos de la asociación en grandes convenciones técnicas que tienen que ver con Linux, etc.
Los voluntarios elaboran carteles, folletos, pegatinas y otros materiales promocionales útiles para el proyecto que ponen a disposición de todo el mundo, y que Debian ofrece libremente en su sitio web y en su wiki:
1.3.3. Equipos, "Blends" y subproyectos
Debian está organizado, desde sus comienzos, sobre el concepto de paquetes fuente, cada uno con su mantenedor o grupo de mantenedores. Con el tiempo, han aparecido numerosos equipos de trabajo asegurando la administración de la infraestructura, la organización de tareas no específicas a un paquete en particular (control de calidad, normativa de Debian, instalador, etc.), con los últimos equipos creciendo alrededor de subproyectos.
1.3.3.1. Subproyectos Debian y Blends existentes
¡Para cada uno, su Debian! Un subproyecto es un grupo de voluntarios interesados en adaptar Debian a una necesidad específica. Además de seleccionar un subgrupo de programas destinados a un dominio particular (educación, medicina, creación multimedia, etc.) los subproyectos están involucrados en mejorar paquetes existentes, crear nuevos paquetes de software, adaptar el instalador, crear documentación específica y más. Si bien un "blend" puede no ser exactamente lo mismo, funciona de manera bastante similar y también intenta brindar una solución para grupos de personas que tienen la intención de usar Debian para un dominio en particular. Se podría decir que "Debian Pure Blends" es el sucesor de los subproyectos.
A continuación se muestra una pequeña selección de los Debian Pure Blends actuales:
Debian Junior., por Ben Armstrong, ofrece un sistema Debian atractivo y fácil de usar para los niños;
Debian Edu, de Petter Reinholdtsen, se centró en la creación de una distribución especializada para el mundo académico y educativo;
Debian-Med, por Andreas Tille, dedicada a la campo de la medicina;
Debian Multimedia, que se ocupa del trabajo del audio y multimedia;
Debian GIS, que se ocupa de las aplicaciones y los usuarios de Sistemas de Información Geográfica;
Debian Astro, tanto para profesionales como para astrónomos aficionados;
Debian Science, finalmente, que trabaja para proporcionar a investigadores y científicos una mejor experiencia usando Debian;
Freedombox, creado para desarrollar, diseñar y promover servidores personales que ejecuten software libre para comunicaciones privadas y personales;
Debian Games, que ofrece juegos en Debian desde arcade y aventura hasta simulación y estrategia;
DebiChem, centrado en la Química, proporciona paquetes y programas de química.
El número de proyectos seguramente continuará creciendo con el tiempo y la mejor percepción de las ventajas de los Debian Pure Blends. Completamente apoyados en la infraestructura Debian existente pueden enfocar su trabajo con un valor añadido real sin preocuparse por mantenerse sincronizados con Debian ya que se desarrollan dentro del proyecto.
1.3.3.2. Grupos administrativos
La mayoría de los equipos administrativos son relativamente cerrados y solo reclutan miembros por cooptación. La mejor forma de convertirse en miembro de uno es asistir inteligentemente a miembros actuales demostrándoles que uno entiende sus objetivos y métodos de operación.
Los ftpmasters están a cargo del archivo oficial de paquetes Debian. Mantienen el programa que recibe los paquetes enviados por desarrolladores y los almacena automáticamente en el servidor de referencia luego de algunas revisiones (ftp-master.debian.org).
Antes de incluirlo en el conjunto de paquetes existentes, deben también verificar la licencia de todo paquete nuevo para asegurar que Debian puede distribuirlos. Cuando un desarrollador desea eliminar un paquete, se dirige a este equipo a través del sistema de seguimiento de errores y el «pseudopaquete» ftp.debian.org.
El equipo
Debian System Administrators (
DSA, «administradores de sistemas de Debian»,
debian-admin@lists.debian.org) es, como uno esperaría, responsable de la administración de los muchos servidores utilizados por el proyecto. Aseguran el funcionamiento óptimo de todos los servicios base (DNS, sitio web, correo, consola, etc.), instalar software pedido por desarrolladores Debian y tomar todas las precauciones necesarias en cuanto a seguridad.
Los «listmasters» administran el servidor de email que gerencian las listas de correo. Crean nuevas listas, manejan rechazos (anuncios de fallo de entrega) y mantienen filtros de spam (correo masivo no solicitado).
Cada servicio específico tiene su propio equipo de administración, generalmente compuesto por voluntarios que lo han instalado (y también con frecuencia han programado ellos mismos las herramientas correspondientes). Este es el caso del sistema de seguimiento de fallos (BTS), el gestor de paquetes,
salsa.debian.org (servidor GitLab, ver la barra lateral
HERRAMIENTA GitLab, alojamiento de repositorios Git y mucho más), los servicios disponibles en
qa.debian.org,
lintian.debian.org,
buildd.debian.org,
cdimage.debian.org, etc.
1.3.3.3. Equipos de desarrollo, equipos transversales
A diferencia de los equipos de administradores los equipos de desarrollo son más abiertos, incluso a los colaboradores externos. Incluso si Debian no tuviera vocación de crear software, el proyecto necesita algunos programas concretos para alcanzar sus objetivos. Desarrollado por supuesto bajo una licencia de software libre, estas herramientas hacen uso de métodos probados en otras partes del mundo del software libre.
Debian desarrolló poco software propio, pero algunos programas asumieron roles centrales y su fama se propagó más allá de los alcances del proyecto. Son buenos ejemplos dpkg, el programa de administración de paquetes de Debian (su nombre es, de hecho, una abreviación de paquete Debian - «Debian PacKaGe» y generalmente se lo nombra «dee-package» en inglés) y apt, una herramienta para instalar automáticamente cualquier paquete Debian y sus dependencias garantizando la consistencia del sistema luego de la actualización (su nombre es acrónimo de herramienta avanzada para paquetes - «Advance Package Tool»). Sus equipos son, sin embargo, mucho más pequeños ya que se necesitan habilidades de programación algo avanzadas para entender el funcionamiento de este tipo de programas.
El equipo más importante probablemente sea el del programa de instalación de Debian,
debian-installer, que ha llevado a cabo una obra de increíbles proporciones desde su concepción en 2001. Fueron necesarios numerosos colaboradores ya que es difícil escribir un único programa capaz de instalar Debian en una docena de arquitecturas diferentes. Cada una con su propio mecanismo de arranque y su propio gestor de arranque. Todo este trabajo es coordinado en la lista de correo
debian-boot@lists.debian.org bajo la dirección de Cyril Brulebois.
El (pequeñísimo) equipo del programa debian-cd tiene un objetivo mucho más modesto. Muchos contribuyentes «pequeños» son responsables de su arquitectura ya que el desarrollador principal no puede conocer todas sus sutilezas ni la manera exacta para iniciar el programa de instalación desde el CD-ROM.
Muchos equipos tienen que colaborar con otros en la actividad de empaquetado:
debian-qa@lists.debian.org intenta, por ejemplo, garantizar la calidad en todos los niveles del proyecto Debian. La lista
debian-policy@lists.debian.org desarrolla la normativa Debian de acuerdo con las propuestas de todos lados. Los equipos encargados de cada arquitectura (
debian-architecture@lists.debian.org) compila todos los paquetes, adaptándolos a su arquitectura particular si es necesario.
