Programa electoral de Branden Robinson como candidato a DPL para el 2004

Introducción

He sido un Desarrollador de Debian aproximadamente desde enero de 1998. Mi trabajo más prominente en Debian ha sido mantener los paquetes de XFree86, lo cual he hecho durante casi seis años, desde marzo de 1998. Desde agosto del 2001 hasta febrero del año actual, presté mi servicio como Tesorero de Software in the Public Interest, Inc., organización padre de Debian y encargada del manejo de la propiedad del proyecto Debian en los Estados Unidos. En el 2002, me uní al equipo de editores del Manual de Políticas de Debian. Soy un elemento inevitable en la lista de correo debian-legal, y participo junto con otros desarrolladores en la discusión y análisis de los términos y la aplicación de las diferentes licencias de software, así como si son válidas ante las Directrices de Software Libre de Debian (DFSG). También participo también en otras listas de correo de Debian. Tengo 29 años, estoy empleado como desarrollador de software libre, estoy casado y no tengo hijos.

A lo largo del año pasado, el trabajo del cual más me enorgullezco ha sido la transición del esfuerzo de empaquetamiento de XFree86 en Debian, cambiando de un modelo básicamente individual a uno basado en el trabajo en equipo. En el proceso, he mejorado vastamente la visibilidad diaria del trabajo invertido en los paquetes de XFree86 de Debian, y el ritmo de integración de cambios, pequeños y grandes, ha aumentado tremendamente. La disponibilidad pública de un depósito Subversion permite a quien quiera tomar y construir los paquetes en proceso, enviar parches limpios, y revisar los cambios que hemos hecho, ayudando a localizar posibles errores. La transición fue un esfuerzo bastante sensible, dado que fue llevada a cabo de manera simultánea con el mantenimiento del paquete, pero la inversión ya ha sido recompensada en términos de mayor apertura y revisión entre iguales, y creo que en el futuro será recompensada cada vez más gracias a que permitirá delegar y compartir responsabilidades. Enfatizo este trabajo porque muchas de estas ventajas respecto a la administración de desarrollo de software pueden traducirse a ventajas en la administración del proyecto, como les mostraré a continuación.

Antes que nada, explicaré mis motivaciones para presentarme, después de lo cual describiré las acciones que llevaré a cabo en caso de resultar elegido.

¿Por qué me estoy presentando?

Necesitamos mejorar nuestros procesos.

La mayor parte de los peores conflictos internos de Debian (o «flamazos», «flamewars» N. del T.) en los últimos años han tenido que ver con tres temas:

Con demasiada frecuencia veo que las discusiones respecto a estos temas terminan en gritos acerca de dos alternativas: "X persona nos impide progresar" contra "las cosas funcionan correctamente, y tus quejas no sirven de nada".

Estos tipos de argumentación, en mi opinión, y por todo el tiempo y páginas de texto enviado por correo que se les dedica, no atacan el problema. Tengo la creencia de que tenemos estas disputas porque es muy difícil llegar a la información relevante, y los foros pra resolver problemas no técnicos no han sido suficientemente desarrollados.

O en términos más simples, es demasiado difícil para para quien "no tiene idea" el tener una idea, y dada la ausencia de remedios documentados para la gente insatisfecha, los ataques se han vuelto personales. Eso, a su vez, pone a la gente a la defensiva (a veces por sí mismos, a veces en pro de otras personas), y las recriminaciones crecen de manera incontrolable.

En mi opinión, y en balance, hacemos un trabajo adecuado en estos puntos. Si estos fueran realmente terrible, el Proyecto Debian no continuaría. Mucha gente cree que el ciclo de nuevas versiones es demasiado lento; puede ser cierto, pero es necesario recordar a algunos de los proyectos de Software Libre (e incluso distribuciones) que ya no existen porque nunca alcanzaron siquiera la versión 1.0, o porque no pudieron sostener su propio desarrollo. Nuestro proceso de nuevos mantenedores funciona también demasiado lentamente (y a veces demasiado misteriosamente) a decir de muchas personas, pero estamos haciéndolo mucho mejor que cuando llanamente no admitíamos nuevos desarrolladores en el proyecto. Debe también ser obvio que, desde la administración de los sistemas hasta las listas de correo, los demonios de construcción y el sistema de seguimiento de fallos, las cosas esencialmente funcionan, y esencialmente funcionan bien. No creo que sea inteligente envolver a los problemas observables con dramatismo; desafortunadamente, sospecho que sin quererlo podemos estar fomentando este tipo de dramatismo porque es la única alternativa que mucha gente ve a que su queja sea ignorada por completo.

Bueno es bueno, pero podemos ser mejores. Adecuado es adecuado, pero debemos buscar la excelencia. Espero hacernos mejores haciendo lo que hacemos.

Necesitamos hacer nuestros procesos más abiertos y visibles.

Las mejoras tienen menos valor, así como menor probabilidad de ser reconocidas o siquiera vistas, si ocurren de manera invisible. Del mismo modo, es difícil saber qué corregir si no está claro qué no está bien. Hemos visto ignoradas las sugerencias de mejora provenientes de diversas personas porque los datos de su queja subyacente no eran correctos. Si bien simpatizo sin duda con el deseo de que las quejas que la gente dirija hacia nuestro proyecto y trabajo sean fieles a la realidad, no siempre un error en los hechos presentados convierte el problema en uno inexistente. He visto gente gastar cantidades tremendas de esfuerzo corrigiendo y refutando dichos errores, a veces en un tono muy irritable.

La comunicación interactiva puede ser muy ineficiente. En muchas áreas, la documentación respecto a cómo funciona nuestro proyecto no existe, no es adecuada, es inaccesible o es simplemente difícil de encontar. Sospecho que podemos ayudar a aislar a los encargados de nuestra infraestructura en quienes más confiamos de crítica sin razon si mejoramos la presentación de información fáctica de cómo llevamos a cabo nuestro trabajo y si tenemos un método más estructurado para elevar estas quejas hacia la gente adecuada. Sería bueno poder discriminar las quejas válidas de las causadas por falta de información de una manera abierta y visible, para que la gente no sólo pueda ver cómo funciona, sino que efectivamente funciona.

Necesitamos un líder que defienda nuestra causa.

En mi trabajo, he tenido el privilegio de hablar con gente en la industria (y no sólo en los Estados Unidos) acerca de qué necesitan de una distribución de GNU/Linux. Muy rara vez me he encontrado con casos donde no haya una oportunidad de adoptar Debian (las excepciones son aquellos que buscan compatibilidad con Red Hat o Suse, o con el formato de paquetes RPM, por sí solo, no por las necesidades reales de cómputo que tengan.) He visto que el interés en Debian ha crecido tremendamente en los últimos cuatro o cinco años. Muchos subproyectos y divisiones («forks») han nacido de Debian, lo cual mantiene verídica nuestra afirmación de que Debian es "el Sistema Operativo Universal".

Debian está avanzando, al parecer en todo campo. Quiero acelerar este proceso y evangelizar respecto a Debian donde sea que pueda. Definitivamente no veo el fenómeno de los subproyectos o divisiones como una amenaza, sino que más bien como una señal de nuestro éxito. Opino que podemos hacer de Debian un estándar de facto en la industria. La compañía para la cual trabajo ha logrado certificar su adherencia a la LSB para una imagen de Debian "Sarge" en enero. He sido entusiasta respecto a Debian desde el día que me convertí en mantenedor, y sigo entusiasmado hoy en día. Más aún, sé que puedo comunicar este entusiasmo a una audiencia.

Debemos tomar a nuestra Constitución más en serio.

Me decepcionó darme cuenta en noviembre que el líder actual del proyecto no cree que el proceso de delegación delineado en nuestra Constitución sea la manera en que Debian realmente funciona. Se negó a delegar oficialmente a los administradores del archivo, de sistemas y similares por "pragmatismo". Ya sea que esto es correcto o no, dejaré que nuestros desarrolladores y usuarios lo decidan por sí mismos, pero sé que este punto de vista es contrario a nuestra Constitución como yo la entiendo. Nuestro sitio indica que la Constitución de Debian es "el documento de mayor importancia para la organización" y creo, por tanto, que debemos brindarle mayor respeto. La Constitución de Debian reconoce a seis grupos o individuos con poder de decisión: Los Desarrolladores (actuando como grupo a través de una Resolución General), el Líder del Proyecto, el Comité Técnico, el Desarrollador individual que trabaja en determinada tarea, el Secretario del Proyecto y los delegados del Líder del Proyecto.

Necesitamos dar mayor respeto al proceso de delegados, o en todo caso enmendarlo. No creo que cada "tarea particular" en nuestro proyecto sea igual que mantener un paquete. Las tareas del administrador del archivo, mantenedor del llavero GPG del proyecto y administrador de sistemas del proyecto son importantes. distinguimos estos roles de los de mantenedor de paquetes de muchas maneras. Son particularmente importantes y merecen atención especial. No creo que puedan ser incluidos en la misma categoría que la del mantenedor de paquetes individual. Tienen poderes especiales, y deben ser tratados de manera especial. El concepto del delegado en la Constitución fue creado pensando en estos roles. El hecho de que ningún DPL anterior haya dado este paso obvio me decepciona.

La Constitución de Debian describe el proceso para elegir al Líder del Proyecto. Esto fue hecho esperando que esta tarea fuera importante. Debemos llevar a cabo una selección significativa entre los candidatos, pues el proceso nos ayudará a entender quién somos y hacia dónde vamos. No me postularía si nadie pudiera ver problemas que el Líder del Proyecto Debian tuviera el poder de resolver.

Me pidieron que me presentara.

El año pasado obtuve muy buenos resultados en una carrera muy cerrada entre los tres candidatos, y me estoy presentando nuevamente para asegurarme que las necesidades de nuestros desarrolladores y usuarios sean cubiertas. El proceso de campaña no es mi tarea favorita, ni espero que encarar los problemas que veo sea pan comido. Después de solicitar la opinión de nuestros desarrolladores en la lista debian-project, sin embargo, muchos me escribieron solicitando que me presentara, con puntos de vista muy consistentes respecto a qué es lo que requiere atención en nuestro Proyecto y qué puedo yo hacer al respecto. Estas son responsabilidades que estoy dispuesto a aceptar, puesto que me importa demasiado el proyecto como para no brindarle toda la energía que pueda.

¿Qué haré?

Una vez enumerados nuestros retos y nuestras oportunidades, las soluciones aparecen fácilmente.

Estableceré mecanismos para hacer nuestros procesos más visibles.

He configurado una instalación de un sistema de seguimiento de solicitudes (del paquete Debian request-tracker3) en una máquina de mi propiedad para que sirva como un sitio de resolución de disputas («ombudsman»). El sistema de seguimiento de fallos (BTS) de Debian no es adecuado, en mi opinión, para el manejo de problemas no relativos al software, y las listas de correo, como lo hemos visto una y otra vez, son muchas veces una alternativa pobre. Tengo experiencia con el uso de un sistema de seguimiento de solicitudes en mi trabajo, y no es difícil de aprender. Si este experimento tiene éxito, trabajaré con los Administradores de Sistemas de Debian para mover esta instalación a una máquina del proyecto Debian. Además (y con mayor énfasis en caso de que este experimento falle), buscaré otras alternativas para hacer la operación de nuestro proyecto clara en los puntos en que actualmente es opaca.

Trabajaré con mis delegados, con los desarrolladores y con los usuarios para identificar áreas específicas que requieren mejoría, incluyendo el manejo de nuevas versiones y el proceso de nuevo mantenedor

Daré el paso obvio descrito en la sección anterior, y formalizaré el estado de delegado de muchas personas importantes que llevan a cabo tareas críticas para nuestro proyecto y que no están reconocidas actualmente como delegados. En caso de que no pueda hacerlo, o que me convenzan que no es una buena idea, le explicaré al proyecto por qué no puedo hacerlo, y entonces, de ser necesario, propondré una Resolución General enmendando nuestra constitución para reflejar la realidad de la organización de Debian.

Informaré con regularidad a los desarrolladores acerca de mis actividades como Líder de Proyecto.

Estoy decepcionado con la frecuencia y contenido de los informes del Líder del Proyecto a los desarrolladores a lo largo de los últimos años. Como Líder de Proyecto, haré un informe acerca de mis actividades en el puesto para el cual me eligieron ante los desarrollaodres por lo menos una vez al mes. Estos reportes no se limitarán a descripciones de los congresos a los que asisto, o descripciones generales del estado del Proyecto. Además de esto, descibiré las tareas específicas en las que estoy trabajando y los problemas que me han solicitado resolver.

Respetaré y fomentaré nuestro sistema constitucional de gobierno.

Haré todo lo que esté a mi alcance para asegurar que nuestra organización real refleja nuestra Constitución, y vice versa. Un proyecto que no pone atención a sus documentos y principios fundamentales es un proyecto en problemas, y puede dañarla impresión que damos a quien no está familiarizado con cómo funciona en realidad Debian, y busque en nuestro sitio Web la información que se los explique.

Reactivaré al Comité Técnico -- que nuevamente se ha adormecido -- o enmendaré la Constitución para reemplazarlo por un cuerpo que funcione mejor. El hecho de que ha pasado casi un año sin correo a la lista (a excepción de un mensaje de prueba de Wichert Akkerman), sin mencionar una disputa pendiente de resolver, me hace sospechar que este cuerpo ha perdido la confianza en los desarrolladores. Me gustaría trabajar con los miembros del Comité que sigan interesados en servir para buscar maneras de mejorar y revitalizar a este cuerpo.

Respetaré el valor y las contribuciones de cada uno de nuestros desarrolladores.

El Proyecto Debian, según nuestro Contrato Social, existe para servir a nuestros usuarios y al Software Libre. Para lograrlo con efectividad, la organización Debian debe servir a las necesidades de todos sus desarrolladores como un grupo. Esto es a veces un reto, dado que somos un cuerpo diverso, y nuestros miembros están esparcidos por todo el mundo. Este reto a veces puede tentarnos a dar preferencia a nuestros amigos en el proyecto, o a quien está geográficamente cerca de nosotros. Caer ante tal tentación, sin embargo, lleva a la injusticia e inequidad entre los desarrolladores. Debian debe ser una meritocracia, y el mérito debe ser medido por la contribución de cada individuo al proyecto, no por su nacionalidad o por relaciones sociales no electrónicas. Debian nació en Internet y no podría haber existido sin ella. La facilidad de la comunicación electrónica es nuestra mayor fortaleza, y el mejor nivelador de las diferencias entre nosotros. No debemos abandonar este atributo esencial favoreciendo al provincialismo de cualquier tipo. Los desarrolladores que no puedan asistir a nuestras reuniones anuales u otros encuentros físicos no deben ser vistos como menos valiosos. Debemos recordar la gran contribución de Joel Klecker, la cual no fue ocultada por la casi-imposibilidad de que asistiera a una reunión presencial de desarrolladores.

Como Líder de Proyecto, buscaré asegurar que no se establezca o mantenga un sistema de privilegios especiales. Tengo la seguridad de que nuestros miembros más valiosos no requieren que se les confieran ventajas especiales, y de la misma manera no debemos ocultar el potencial de contribuidores futuros a través de prácticas que llevan en los hechos a la exclusión, aunque parezcan inocentes y expeditas.

Entre más importante sea una decisión, más crítico será que sea hecha de manera abierta y pública, sin inclinaciones en su procedimiento a favor o en contra de ningún desarrollador. Es un estándar elevado, pero esencial, y prometo hacer todo lo que esté en mi poder para mantenernos apegados a él.

Construiré relaciones con otras compañías y organizaciones de Software Libre y Open Source.

Buscaré voluntarios pra servir como delegados oficiales ante otras organizaciones cuando sea necesario. El DPL actual nombró a algunas personas para comunicarse con la Free Software Foundation en relación a las inquietudes de algunos de nuestros desarrolladores frente a la Licencia de Documentación Libre de GNU y cómo dicha licencia interactúa con las Directrices de Software Libre de Debian. El año anterior, Bdale Garbee nombró a Mark Johnson como nuestro representante ante OASIS. Creo que estos son muy buenos ejemplos, y son un fenómeno sobre del cual me gustaría construir. No veo por qué no debamos tener un «embajador» ante la FSF, por poner un ejemplo, una persona que entienda las necesidades e intereses de ambas organizaciones y que pueda evitar fricción innecesaria. Lo mismo podría ser dicho de Red Hat Software, Novell, FFII, FSF Europa, y otros.

Haré todo lo que me sea posible para hacer del Proyecto Debian un ejemplo digno de seguir.

Recientemente, una persona escribió a la lista debian-project pidiendo asesoría para usar Debian como un ejemplo organizacional para su comunidad de software sin ánimo de lucro. Me sentí halagado, así como creo que todos pudieron sentirse, al leer ese mensaje, pero como pueden ver por lo que expuse anteriormente, podríamos ser un mejor ejemplo de lo que somos. Ha habido demasiados casos en que organizaciones que quisieron seguir nuestro ejemplo llegaron a la decepcionante conclusión de que nuestra implementación no va acorde a la especificación -- que no predicamos con el ejemplo. Cada proyecto es único, y esa es la razón de que debemos hacer un mejor trabajo explicando detalladamente al resto del mundo qué hacemos -- pues de esa manera, podemos también tomarnos el tiempo para explicar por qué lo hacemos. En el proceso, podemos llegar a re-examinar los puntos que asumimos, y a través de un proceso como éste no podemos más que mejorar.

Como Líder del Proyecto Debian, me comprometeré a hacer del Proyecto Debian el tipo de organización donde las cosas se hacen bien. Ya tenemos prácticamente credibilidad universal en este punto respecto a aspectos técnicos. ¿Por qué deberíamos conformarnos con menos al tratarse de nuestra organización?

He estado a la altura de los retos con que me he enfrentado en el trabajo que he hecho para el Proyecto Debian en el pasado, y estoy a la altura del reto de ser Líder del Proyecto Debian.

Gracias por tu apoyo, y por tu participación en el proyecto en el que creo.

Valid XHTML 1.0! Valid CSS!

Validate this page's XHTML.
Validate this page's CSS.

$Id$