%%
%% De lo platicado con Felicia:
%%
%% El título prometido es ``Participando en proyectos de Software
%% Libre: Aspectos técnicos y sociales'' (2hr)
\documentclass{beamer}

\mode<presentation> { \usetheme{Darmstadt}
  \setbeamercovered{transparent} }

\usepackage[spanish]{babel} \usepackage[latin1]{inputenc}
\usepackage{pdfpages} \usepackage{alltt} \usepackage{verbatim}
\usepackage{hyperref}
\usepackage{graphicx}

\title[Participación en proyectos de Software Libre] {Participando
  en proyectos de Software Libre: Aspectos técnicos y sociales}

\author[Gunnar Wolf]{Gunnar Wolf --- {\tt gwolf@gwolf.org}\\
\url{http://www.gwolf.org/soft/qa_soft_libre}}

\institute[IIEc - UNAM; Debian] {Instituto de Investigaciones
Económicas, UNAM\\ Desarrollador del proyecto Debian}

\date[3 Día Linux y SL]{3er Día Linux y de Software Libre\\
  ITESM, Cuernavaca, 24 de abril, 2007} 

\pgfdeclareimage[height=2cm]{debian-logo}{debian-swirl}
\logo{\pgfuseimage{debian-logo}}

\AtBeginSection[] {
  \begin{frame}<beamer>
    \frametitle{Contenidos} \tableofcontents[currentsection]
  \end{frame}
}

% If you wish to uncover everything in a step-wise fashion, uncomment
% the following command: 
%\beamerdefaultoverlayspecification{<+->}

\begin{document}

\begin{frame}
  \titlepage
\end{frame}

%% \begin{frame}
%%   \tableofcontents
%% \end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section[¿Qué es y por qué?]{¿Qué es el Software Libre?
  ¿Por qué me interesa participar?} 

\begin{frame}
  \frametitle{Primer acercamiento}

  ¿Qué es el Software Libre?
  \begin{itemize}
    \item Un movimiento social que busca corregir una aberración
    histórica
    \item Miles de voluntarios que rompen toda predicción
    económica
    \item Un movimiento eminentemente social, con efectos técnicos
      como primer resultado
    \item Un nuevo modelo de producción de software
    \item Un esquema justo de licenciamiento de la propiedad
    intelectual
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Sí, pero... ¿Qué es el software libre?}
  
  \begin{itemize}
  \item El mundo del cómputo hasta los 70 seguía otras reglas
    \begin{itemize}
    \item El negocio está en vender hardware --- El software
      requerido va incluído
    \item Es de esperarse que los usuarios quieran modificar tanto
      hardware como software
    \item Los sistemas se venden con esquemas y código fuente
    completos
    \end{itemize}
  \item La revolución de las PCs nos trajo un licenciamiento
    injusto e ilógico
    \begin{itemize}
    \item Al pagar por un programa, no lo compramos --- Sólo
      adquirimos una licencia de uso bajo ciertas condiciones
    \item Lo compramos tal y como está --- Es imposible adecuarlo a
      nuestras necesidades específicas
    \item La compañía dueña del código no da garantía
      alguna sobre de él
    \item ¡Pero no recibimos siquiera el derecho de corregir
      problemas!
    \end{itemize}
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Sí, pero... ¿Qué es el software libre?}
  \begin{itemize}
  \item El software libre básicamente nos devuelve la propiedad y
  los derechos
    \begin{itemize}
    \item Con el software libre recuperamos el control de nuestra
    propiedad
    \item Podemos adecuar el software a nuestras necesidades
    \item Podemos corregir los problemas que presente
    \item Podemos compartir nuestro desarrollo con quien lo necesite
    \end{itemize}
  \end{itemize}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Aterrizando}

  \begin{center}
    Un programa es considerado software libre si su licencia nos
    garantiza: 
  \end{center}
  \begin{itemize}
  \item Libertad de uso
    \begin{itemize}
    \item Podemos usar el programa para el propósito que deseemos
    \end{itemize}
    
  \item Libertad de aprendizaje
    \begin{itemize}
    \item Podemos aprender cómo está hecho el programa
    \item Tenemos acceso a su código fuente
    \end{itemize}

  \item Libertad de modificación
    \begin{itemize}
    \item Podemos adecuar el programa a nuestras necesidades
      modificando su código
    \item Podemos incluir partes de su código en nuestros
      desarrollos
    \end{itemize}
  
  \item Libertad de redistribución
    \begin{itemize}
    \item Podemos compartir el programa con otras personas
    \item Podemos compartir el código fuente con otras personas
      \begin{itemize}
      \item En su estado original o modificado
      \end{itemize}
    \end{itemize}
  \end{itemize}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Aclarando}

  \begin{center}
    El software libre simplemente es diferente.
  \end{center}

  \begin{itemize}
  \item Rompe con la lógica de trabajo en la industria
    \begin{itemize}
    \item Plantea hasta cierto punto la vuelta a una forma de trabajo
    académica
    \end{itemize}

  \item Ha creado fuertes presiones sobre una industria basada en
  principios errados

  \item Va a modificar radicalmente la manera de trabajar de esta
  industria
    \begin{itemize}
    \item Para concentrarse en la venta de servicios
    (personalización, administración, etc.)
    \item Adecuaciones a las necesidades específicas del usuario
    \item Vuelta a un modelo más sano, como lo que teníamos hace
    30 años
    \end{itemize}
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Aclarando}
  \begin{center}
    Por increíble que parezca, para muchos el Software Libre se ha
    convertido de un movimiento social, político y técnico en
    una religión.
    \vskip 0.4cm
    \includegraphics[height=5cm]{saintignucius.jpg}\\
    {\scriptsize San Ignucio de la Iglesia de Emacs}
  \end{center}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{... Y a todo esto, ¿por qué participar?}

  \begin{itemize}
    \item Vamos a dejar esto para un poco más terde
    
    \item ...Hablemos primero de cómo funciona el desarrollo, de cómo
    funciona el desarrollo y cómo se estructuran las comunidades
    
    \item Seguramente ustedes irán encontrando suficientes razones para
    interesarse 
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section[La crisis]{Comprendiendo la crisis en la industria del software} 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Crisis en la... ¿{\it industria} del software?}

  \begin{itemize}
    \item Es común oir hablar de una crisis en la industria del
    software. Pero el problema no es, como veremos, el que haya una
    {\it crisis}, sino el que veamos al desarrollo de software como
    una {\it industria}.

  \item El desarrollo de software puede ---y debe--- crear y
    desarrollar fuentes de trabajo. Sin embargo, el equiparar el
    desarrollo de software con el trabajo industrial, con líneas de
    producción y procesos predecibles y repetibles es claramente un
    error
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Desarrollo de un proyecto}
  
  Dentro de la industriparalelo de a tradicional del software tienden a observarse
  metodologías, divisiones y tiempos, rígidos y claros, para las
  diferentes etapas
  
  \begin{itemize}
  \item No hay una sóla concepción de cómo debe ser el
  proceso ideal, pero todo proyecto tiene claro y definido el suyo
    
  \item La impredictibilidad y el caos son vistos como los mayores
  enemigos
  
  \item Proyección de funcionalidad (``roadmaps'' del proyecto) a
  mediano y largo plazo
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{La presión del tiempo al mercado}
  La crisis de la industria del software deriva precisamente de que es
  visto como una industria.
  \begin{itemize}
  \item Necesidad de vender los productos en un tiempo competitivo
    \begin{itemize}
    \item Resultado: Sistemas menos maduros, más vulnerables, con
    cantidades tremendas de fallos conocidos (dicen los que saben,
    decenas de miles en Windows XP)
    \item Por lo visto, Microsoft comprendió {\it algo} de sus
    graves errores --- Su nuevo sistema {\it Vista} salió al mercado con
    un retraso de cinco años, y sin funcionalidad novedosa por sobre
    su competencia
    \end{itemize}
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{La presión del tiempo al mercado}
  Competencia en vez de cooperación
  \begin{itemize}
  \item En nombre de los secretos industriales, patentes sobre
    algoritmos y, en general, la propiedad intelectual, la
    computación como disciplina científica está atascada
     desde hace más de 20 años
  \item Especialmente durante los 80 y 90 vimos una y otra
    reimplementación de las mismas ideas de diferentes maneras, con
    interfaces completamente deiferentes, en vez de cooperación
    para el desarrollo de nuevas tecnologías
  \item ¿Son esas buenas noticias? ¡No! Si hoy en día no hay
    más trabajo tirado a la basura no es por que haya competencia,
    sino porque hay un potente monopolio. En las áreas aún no
    conquistadas por éste, sigue habiendo duplicación
    innecesaria de esfuerzos.
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{La mal llamada {\it propiedad intelectual}}
  \begin{itemize}
  \item Toda empresa de desarrollo de software tiene que pagar
    grandes despachos de abogados 
  \item Toda empresa de desarrollo de software aparentemente debe
    tener una sólida cartera de patentes sobre algoritmos 
    \begin{itemize}
    \item Principalmente como defensa
    \item ...Pero también para hacerse de fondos
    \item Hay empresas que se dedican exclusivamente a la
      acumulación de patentes, actuando como {\it parásitos}
      en su entorno
    \end{itemize}

  \item Potenciando la emergencia de oligopolios/monopolios
    \begin{itemize}
    \item Las pequeñas empresas sencillamente no tienen manera de
      competir con las grandes, terminan siendo absorbidas o quebrando
    \item Y no es culpa de Microsoft --- El modelo mismo fomenta la
      creación de monopolios
    \end{itemize}
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Los engranes de la maquinaria (o cómo insultar al
    cliente sin perder sus cheques)} 

  Con el paso de los años, el cliente ha ido pasando cada vez
  más a un papel de menor importancia
  \begin{itemize}
  \item Comenzando con licencias excesivamente restrictivas
    \begin{itemize}
    \item Puede ponerse en duda su legalidad como contratos --- Yo no
    firmé en ningún lado... ¿Licencias desnudas?
    \item Me prohiben cada vez más acciones
    \item Limitan por completo mi privacidad, requiriendo que
    expresamente renuncie a ella
    \begin{itemize}
      \item ¿Alguna vez han leído un EULA/CLUF?
    \end{itemize}
    \end{itemize}

  \item El Impuesto Microsoft
    \begin{itemize}
    \item No puedo elegir una computadora de marca sin que incluya
    Windows. ¿Por qué?
    \end{itemize}
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Los engranes de la maquinaria (o cómo insultar al
    cliente sin perder sus cheques)} 
  \begin{itemize}
  \item Imposibilidad de recibir soporte técnico
    \begin{itemize}
    \item Al pagar la licencia del programa, expresamente acepto que
    carece de garantía --- Estoy dando dinero para recibir un permiso
    de uso (no estoy comprando nada), sin garantía de que sirva de
    algo
    \item Para instalaciones grandes, puedo pagar (en cientos de
    dólares) para abrir un ticket de soporte, sin garantía de
    que me resuelvan el problema (o de que intenten hacerlo)
    \end{itemize}
  \end{itemize}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{¿Debemos seguir los mandatos de la visión empresarial?}

  El cómputo históricamente siempre ha tenido su mayor impulso
  en la academia
  \begin{itemize}
  \item Hemos seguido ciegamente las tendencias del mercado

  \item Prácticamente no ha habido verdaderas inovaciones en el
  cómputo en las últimas dos décadas

  \item Las prácticas actuales de desarrollo por parte de la
  industria son ineficientes y caen en todo tipo de vicios
    \begin{itemize}
    \item Les salió más caro el caldo que las albóndigas
    \end{itemize}
  \end{itemize}


  {\Large ¿Por qué insistir en copiar un modelo inferior?}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{...Pero el término {\it industria} suena tan
    glamoroso...} 

  En ciertos círculos, los jóvenes son formados buscando crear
  en ellos una {\it visión empresarial}. ¿Qué tan real es
  hablar de la industria?

  \begin{itemize}
  \item En el desarrollo de sistemas más aún que en muchas otras
    ramas de la economía, la proporción de empresas fracasadas
    es terriblemente alta frente a la de empresas exitosas

  \item La diversidad en la oferta de productos de software es
    demasiado baja 
    \begin{itemize}
      \item ...Y el costo de reproducción es casi cero
      \item ...No hay una cultura de respeto a derechos de autor
      \item ...La competencia de monopolios efectivos es atroz
    \end{itemize}

  \item La óptica de venta de {\it productos} está equivocada
    \begin{itemize}
    \item ...Pero vamos poco a poco --- Ese tema viene más adelante ;-)
    \end{itemize}

  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{¿Y cómo es el Software Libre? ¿No lo impulsa la
    misma {\it industria}?}
    \begin{itemize}
    \item La mayor parte de los desarrollos libre siguen esquemas de
      desarrollo más cercanos al {\it académico}
      \begin{itemize}
      \item El conocimiento generado entra a formar parte del {\it
	común} al cual todos los interesados tenemos acceso pleno
      \item La recompensa directa que recibe el autor es el crédito
	a su trabajo y el reconocimiento/prestigio que de éste
	emana
      \end{itemize}
    \item Hay muchos y muy importantes proyectos de Software Libre
      cuyo desarrollo {\it es} visto con una lógica de industria
         \begin{itemize}
	 \item Mi crítica va también encaminada a ellos
	 \item Sin embargo, aunque son muchos y prominentes, no son ni
	   la generalidad de los proyectos, ni aquellos con los que
	   con mayor probabilidad colaboremos directamente
      \end{itemize}
    \end{itemize}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Y qué... ¿se supone que debo vivir de comer aire?}
  \begin{center}
    Muy bonito, muy bonito... ¿pero cómo encaja mi desarrollo
    profesional o el de mi empresa en todo esto? \\
    {\bf Cambio de la orientación de la oferta / del modelo de
    negocios } \\
    Una empresa de desarrollo de software debería orientarse a
    vender {\it servicios}, no productos.
  \end{center}
  \begin{itemize}
  \item Vender experiencia en la adecuación de soluciones
    disponibles universalmente
  \item Vender administración de un servicio requerido
    frecuentemente por los clientes --- Sobre una base perteneciente
    a los {\it comunes}
  \item ...Deja que tu trabajo te recomiende. ¡Y deja que tu
    trabajo se esparza por sí mismo!
  \end{itemize}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section[Características]{Características del desarrollo en
  proyectos de Software Libre}

\begin{frame}
  \frametitle{Modelo general de desarrollo}

  Cada comunidad de desarrolladores ha llevado la filosofía de
  desarrollo del sistema en que creció a su modo general de trabajo
  y colaboración
  \\
  Es divertido y hasta chistoso comparar lo similares que son, a
  diferentes niveles, los proyectos (chicos y grandes), las
  comunidades de desarrolladores y los usuarios del lado libre y del
  lado propietario
  \begin{itemize}
    \item Independencia/interdependencia entre componentes
    \item Relación con los pares
    \item Presunción de capacidades de quien nos sigue en la cadena
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Modelo de crecimiento orgánico}

  El modelo de desarrollo que seguimos puede ser visto como el
  crecimiento orgánico --- tiene una gran semejanza con las
  células de un ser vivo.
  \begin{itemize}
  \item Los diferentes proyectos tienden a ser tan pequeños e
  independientes como sea posible, con una interfaz consistente
    \begin{itemize}
    \item Es fácil reemplazar a uno por otro
    \item Diferentes proyectos implementando la misma funcionalidad no
    compiten --- avanzan en conjunto
    \item Comparten recursos vitales --- a los desarrolladores y a su
    experiencia
    \end{itemize}

  \item La redundancia no duele
    \begin{itemize}
    \item Hay muchos proyectos implementando la misma funcionalidad
    \item Selección natural
    \end{itemize}
  \end{itemize}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Tratar al usuario como a un colega}

  A diferencia del mundo del software propietario, en el Software
  Libre todo usuario es potencialmente un colega
  \begin{itemize}
  \item Ponemos a su disposición tanta documentación como sea
  posible

  \item Esperamos reportes de fallos por parte de nuestros usuarios
    \begin{itemize}
    \item Posiblemente incluso correcciones / mejorías
    \end{itemize}

  \item Los desarrolladores responden directamente a las
  dudas/inquietudes de los usuarios

  \item Para muchos, nuestra meta es crear más desarrolladores
    \begin{itemize}
    \item ¡En serio no es difícil! Acérquense y verán
    \end{itemize}
  \end{itemize}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Aporte por sí sólo de estos puntos al control de calidad}

  Las características antes presentadas por sí sólas ya
  definen un buen nivel de control de calidad
  \begin{itemize}
  \item Las interfaces al programador (APIs) son estables, definidas y
  bien documentadas
    \begin{itemize}
    \item Tenemos la conciencia de que proyectos de terceros pueden
    depender del nuestro
    \item No existe ventaja competitiva de esconder la información
      \begin{itemize}
      \item Aún más, no es posible esconderla
      \end{itemize}
    \end{itemize}

  \item El código es más claro, mejor comentado y documentado
    \begin{itemize}
    \item Las tres virtudes del programador: Flojera, impaciencia,
    vanidad
    \end{itemize}
  \end{itemize}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Características de los desarrolladores}

  Para entender la naturaleza de nuestro movimiento, hay que entender
  a sus miembros...
  \begin{itemize}
  \item Dispersión geográfica
    \begin{itemize}
    \item Mucho menor ceguera cultural
    \item Internacionalización de los proyectos
    \end{itemize}

  \item Alta proporcion de voluntarios
    \begin{itemize}
    \item Para bien y para mal
    \item Muchos proyectos nacen y atraen desarrolladores por ser una
    idea interesante
    \end{itemize}

  \item Potencialmente miles de colaboradores para cualquier proyecto
    \begin{itemize}
    \item Con suficientes ojos todos los fallos se vuelven obvios
      \begin{itemize}
      \item Mitos y realidades
      \end{itemize}
    \item Diferentes maneras de pensar, diferentes prioridades van
    enriqueciendo a los proyectos
    \end{itemize}
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Características de los proyectos}

  Y como resultado de las características sociales, encontramos
  claramente ciertas características técnicas
  \begin{itemize}
  \item Proyectos acotados a cumplir sus objetivos
    \begin{itemize}
    \item Con mucho menos distracciones
    \item Con libertad para definir sus prioridades
    \item Ambición focalizada --- El proyecto no intenta llegar
    más allá de lo que realmente busca
    \end{itemize}

  \item Proyectos apegados a estándares
    \begin{itemize}
    \item Para permitir la reutilización
    \item Para facilitar la comunicación sobre red en ambientes
    heterogéneos
    \end{itemize}
  \end{itemize}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Características de los proyectos}

  \begin{itemize}
  \item Retroalimentación de la comunidad
    \begin{itemize}
    \item Los usuarios se acostumbran a la posibilidad real de
    interactuar directamente con los desarrolladores
    \item Los proyectos reciben y usualmente incorporan las
    mejorías requeridas por sus diferentes grupos de usuarios
    \item Es más fácil que aparezcan a tiempo los problemas
    derivados de situaciones frontera o no contempladas
    \end{itemize}
  \end{itemize}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Problemáticas inherentes al Software Libre}

  El Software Libre también presenta importantes dificultades y
  retos que superar
  \begin{itemize}
  \item Coordinación de proyectos geográficamente dispersos
    \begin{itemize}
    \item Zonas horarias
    \item Los desarrolladores pueden no tener un idioma común ---
      Es fundamental poder leer, escribir, discutir y desarrollar en
      ingles, nos guste o no, lingua franca en nuestro campo 
    \end{itemize}

  \item Diferentes puntos de vista entre los desarrolladores:
    ¿Qué pasa cuando diferentes desarrolladores tienen visiones
    incompatibles? 
    \begin{itemize}
    \item El convencimiento, aunque sea a regañadientes
    \item La salida de uno de ellos (o un grupo) del proyecto
    \item La división del proyecto en varios
    \end{itemize}
  \end{itemize}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Problemáticas inherentes al Software Libre}

  \begin{itemize}
  \item Problemas derivados del trabajo voluntario
    \begin{itemize}
    \item El proyecto ya dejó de ser divertido
    \item Ya no tengo tiempo
    \item Prefiero desarrollar nueva funcionalidad a corregir los
      problemas existentes
    \item No me gustan tus ideas
    \item Cuando el dinero entra en juego...
    \item Contratos con/sin exclusividad
    \item ...
    \end{itemize}
  \end{itemize}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Requisitos de comunicación y colaboración a distancia}

  \begin{itemize}
  \item ¿Cómo compartir la información entre los
  desarrolladores?
    \begin{itemize}
    \item ¿Cómo compartir el código?
      \begin{itemize}
      \item ¿Cómo pueden personas en diferentes continentes
      trabajar sobre el mismo archivo?
      \end{itemize}
    \item ¿Cómo dar seguimiento a las inquietudes de los
    usuarios?
    \item ¿Cómo se va a comunicar de manera eficiente un grupo
    de desarrolladores?
    \item ¿Cómo se van a manejar los asuntos privados del
    proyecto?
      \begin{itemize}
      \item Manejo de recursos materiales
      \item Aletras de seguridad
      \item Asuntos organizativos
      \end{itemize}
    \end{itemize}
  \end{itemize}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section[Herramientas]{Herramientas de desarrollo colaborativo distribuído} 

\begin{frame}
  \frametitle{Depósito de código}

  Un proyecto colaborativo, especialmente si es geográficamente
  disperso (y más aún si tiene decenas de participantes o
  más), requiere de un depósito de código 
  \begin{itemize}
  \item Operaciones básicas
    \begin{itemize}
    \item Sincronizar cambios en el código
    \item Permitir el trabajo sobre el mismo archivo, asistir para
      solucionar problemas que requieran intervención humana
    \item Guardar las diferentes versiones y ramas que ha pasado el
      proyecto
    \item Facilitar la distribución
    \item Permitir el {\it trabajo desconectado}
    \item Ramas locales
    \end{itemize}

  \item Herramientas principales: CVS, Subversion, Git, Bzr, Arch,
    Mercurial, ...
  \end{itemize}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Seguimiento de fallos (BTS --- Bug Tracking System)}

  Un sistema que permita a desarrolladores y usuarios del proyecto
  reportar y dar seguimiento a fallas y otras solicitudes
  \begin{itemize}
  \item Que permita dar seguimiento al estado e importancia de cada
    bug y de cada componente del sistema
  \item Que permita catalogar/categorizar los diferentes fallos por
    estado, severidad, categoría, etc.
  \item Que sea amigable con el usuario final, robusto para el desarrollador
  \item Que maneje parches, listas de deseos, versiones, ...
  \item Principales herramientas: Bugzilla, Debbugs, GForge, Trac, muchos otros
  \end{itemize}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Áreas de discusión}

  Es indispensable contar con espacios donde se pueda discutir con
  tranquilidad y a profundidad respecto al proyecto. Si bien hay
  varias alternativas, la principal con mucho son las listas de correo
  \begin{itemize}
  \item Características
    \begin{itemize}
    \item Facilidad para alta/baja de usuarios
    \item Archivo histórico de mensajes enviados
    \item Opción para hacer la lista abierta, cerrada, censurada,
    irrestricta, etc.
    \end{itemize}

  \item Principales herramientas: Mailman, Majordomo, ezmlm, ...
  \end{itemize}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Herramientas de plática / comunicacizon directa}

  Aunque ha perdido mucha popularidad entre el público en general
  frente a los IMs (Yahoo, MSN, ICQ, etc.), entre los desarrolladores
  el medio inmediato favorito es por mucho el IRC.
  \begin{itemize}
  \item Plataformas abiertas, no requieren clientes específicos

  \item Conversaciones uno a uno o muchos a muchos

  \item Capacidad de archivar fácilmente las conversaciones

  \item Facilidad de {\it jugar} con el sistema (bots, scripts etc.)

  \item Redes públicas que no requieran registro para emplearlas

  \end{itemize}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section[Ejemplo: Debian]{Un ejemplo: coordinación y control de
  calidad en el proyecto Debian}

\begin{frame}
  \frametitle{Presentación general del proyecto}

  ¿Qué es el Proyecto Debian?
  \begin{itemize}
  \item Desarrollo de una distribución de Linux (y otros SOs)
  \item Un proyecto de integración --- {\it un bazar de catedrales}
  \item Más de 15,000 paquetes binarios
  \item Alrededor de 1000 desarrolladores oficiales en todo el mundo
  \end{itemize}

  \begin{center}
    \includegraphics[height=4cm]{developers_map.jpg}
  \end{center}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Un vistazo a Debian}

  ¿Cómo logramos trabajar en conjunto?
  \begin{itemize}
  \item Proyecto completamente voluntario
    \begin{itemize}
    \item Aunque base para el trabajo de empresas (Progeny, Ubuntu,
      Libranet, Linspire...)
    \item Algunos desarrolladores son empleados precisamente para
      contribuir con Debian (HP, IBM, Nokia, ...)
    \end{itemize}
    
  \item El trabajo se basa en ciertos documentos base
    \begin{itemize}
    \item Directrices del Software Libre de Debian (DFSG) y Contrato
      Social (SC)
      \begin{itemize}
      \item Qué consideramos que es Software Libre (y por tanto
	podemos incluir en Debian)
      \item Cuáles son nuestras prioridades
      \item A qué nos comprometemos ante la comunidad
      \end{itemize}
    \item Políticas
      \begin{itemize}
      \item Cómo hacemos las cosas
      \item Qué debe ir en qué parte del sistema
      \item Cómo podemos hacer que nuestros paquetes interoperen
      correctamente
      \end{itemize}
    \end{itemize}
  \end{itemize}    
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Ramas de Debian}

  En Debian se manejan tres ramas o versiones de manera simultánea
  \begin{itemize}
  \item 1- Estable
    \begin{itemize}
    \item Con las características de estabilidad antes mencionadas
    \item Se recomienda a todo usuario
    \item La liberación de una nueva versión estable se lleva a
    cabo aproximadamente cada dos años
    \end{itemize}

  \item 3- Inestable
    \begin{itemize}
    \item La rama de desarrollo, que siguen todos los desarrolladores,
    y se recomienda sólo a quien quiera participar en el desarrollo
    \item Alto volúmen de movimiento
    \item Los programas individuales que entran a Inestable deben ser
    estables (son candidatos a entrar a la versión estable)
    \item De tiempo en tiempo, algo se rompe
    \end{itemize}

  \item 2- Pruebas
    \begin{itemize}
    \item Tras cierto tiempo que una versión de un paquete vive en
    Inestable y no recibe reportes de fallos mayores, entra a Pruebas
    \item Se recomienda para quien quiera colaborar con el desarrollo
    como usuario
    \end{itemize}
  \end{itemize}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Refrescando estable}

  Además de las tres ramas oficiales, hay importantes depósitos
  extraoficiales mantenidos por miembros del proyecto --- e incluso por
  gente externa.
  \begin{itemize}
  \item volatile.debian.net
    \begin{itemize}
    \item Para software cuya naturaleza hace impráctico el manejo
      de versiones estables con un ciclo de vida largo
      (p.ej. herramientas de monitoreo de seguridad, antivirus,
      antispam, etc.)
    \end{itemize}

  \item backports.org
    \begin{itemize}
    \item Versiones actualizadas de paquetes existentes en la rama
      estable, mantenidas por desarrolladores del proyecto
    \end{itemize}

  \item apt-get.org
    \begin{itemize}
    \item Depósitos de software empaquetado para Debian
    \item Mantenidos por cualquier persona
    \item Aquí podemos encontrar software no empaquetable para
      Debian por razones de licenciamiento, de inmadurez, etc.
    \end{itemize}
  \end{itemize}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{El sistema de seguimiento de fallos (BTS)}

  La principal herramienta de Debian para el control de calidad es su
  sistema de seguimiento de fallos
  \begin{itemize}
  \item Sistema completamente público, por estatuto del proyecto
  (SC, DFSG)
    \begin{itemize}
    \item Se puede consultar en Web (http://bugs.debian.org/,
    http://bugs.debian.org/<numero\_de\_fallo>)
    \item Se manipula por correo (submit@bugs.debian.org,
    control@bugs.debian.org, <numero\_de\_fallo>@bugs.debian.org)
    \item Actualmente hay más de 275,000 fallos registrados (unos
    26,000 abiertos) desde 1997
    \end{itemize}

  \item Clasificación de fallos
    \begin{itemize}
    \item Por paquete
    \item Por mantenedor
    \item Por severidad (RC, grave, importante, normal, deseos)
    \end{itemize}

  \item Paquetes virtuales --- Principalmente WNPP y ftp.debian.org
  \end{itemize}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{BTS --- Número de bugs críticos contra la rama
    inestable (y de pruebas)} 

  \begin{center}
    \includegraphics[height=6cm]{rc_bugs.png}
  \end{center}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Comunicación entre desarrolladores}

  Debian es un proyecto que se basa muy fuertemente en la
  comunicación, y cuenta con una gran cantidad de canales
  \begin{itemize}
  \item Listas de correo
    \begin{itemize}
    \item Varias decenas de listas
    \item De todos los niveles (desde debian-user hasta listas muy
    específicas a arquitecturas, organización, etc.)
    \item Abiertas y moderadas
    \item Todos los desarrolladores están al menos en
    debian-devel-announce
    \end{itemize}

  \item Aliases específicos de correo
    \begin{itemize}
    \item Para dar con el responsable de un paquete -
    <paquete>@packages.debian.org
    \item Aliases para los roles
    \end{itemize}
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Comunicación entre desarrolladores}

  \begin{itemize}
  \item IRC
    \begin{itemize}
    \item Medio principal de comunicación inmediata entre
    desarrolladores
    \item Diferentes canales en irc.debian.org (=> irc.freenode.net) -
    debian, debian-es, debian-devel, debian-boot, etc.
    \end{itemize}

  \item Reuniones de trabajo
    \begin{itemize}
    \item Cada que son posibles, sean enfocadas a una necesidad o
    generales para el proyecto
    \item Una reunión principal al año (Debconf)
    \item Varias reuniones locales (Oldenburg, debconf-es, Linuxtag,
    d-i, etc.), oficiales o extraoficiales
    \end{itemize}
  \end{itemize}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{El equipo QA}

  Es necesario un equipo que se encargue de vigilar la calidad
  general. Sus principales actividades son:

  \begin{itemize}
  \item Mantener a los paquetes huérfanos

  \item Dar seguimiento a los bugs sobre WNPP

  \item Construir una y otra vez todos los paquetes en todas las
  arquitecturas
    \begin{itemize}
    \item Para verificar que las dependencias sigan correctas
    \end{itemize}

  \item Busca a los mantenedores aparentemente inactivos (MIA)

  \item Organizar fiestas de aplastar fallos (Bug Squishing Parties,
  BSPs)

  \item Realizar pruebas automáticas (de funcionalidad,
  actualizabilidad, etc.) sobre paquetes aleatorios
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
  \frametitle{Publicando nuevas versiones}

  Debian muchas veces lleva a niveles casi absurdos su control de
  calidad
  \begin{itemize}
  \item Para publicar una nueva versión, requerimos llevar a cero
  el número de fallos graves
    
  \item En un proyeto del tamaño de Debian, la frecuencia de
  publicación ha ido decreciendo con cada nueva versión
    \begin{itemize}
    \item La última versión tuvo una gestación de tres
    años, la actual se acerca ya a los dos
    \item ¿Principal causa? La cantidad de gente, y las diferentes
    prioridades de cada uno de ellos
    \item Una de las causas del nacimiento de proyectos como Ubuntu,
    Componentized, etc.
    \item Es un punto de constante polémica en el proyecto
    \end{itemize}

  \item Es importante tener en cuenta los hábitos de los usuarios
  fuera de nuestra comunidad
    \begin{itemize}
    \item Los linuxeros tendemos a buscar lo más nuevo y lo
    último
    \item Los usuarios en general buscan un bajo volúmen de cambios
    --- ¿Cuánta gente conocen que sigue usando Windows 98?
    \item Nuestra supuesta mayor debilidad podría convertirse en
    una gran fortaleza
    \end{itemize}
  \end{itemize}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Fin}

\begin{frame}
  \frametitle{¿Dudas?}
  \vskip 2em {\Large ¡Gracias!}
  \vskip 1em Gunnar Wolf --- {\tt gwolf@gwolf.org}\\
  \url{http://www.gwolf.org/soft/qa\_soft\_libre}
\end{frame}

\end{document}
