Primeros Pasos

Primeros Pasos El clásico modelo de cómo los proyectos de software libre deben iniciar fue propuesto por Eric Raymond, en un artículo ahora famoso sobre procesos de código abierto titulado La catedral y el bazar. Él escribió:

Todos los trabajos buenos en software comienzan tratando de paliar un problema personal de quien los programa (de )

Es de notar que Raymond no estaba diciendo que los proyectos de código abierto no sólo suceden cuando cierto individuo tiene una necesidad. En cambio, nos está diciendo que los buenos programas son resultado de que un programador tenga un interés personal en ver el problema resulto. La relevancia de esto para el software libre ha sido que ésta necesidad personal sea frecuentemente a motivación para iniciar un proyecto de software libre. Esto sigue siendo la manera cómo muchos de los proyectos libres se inician, pero menos ahora que en 1997, cuando Raymond escribió esas palabras. Hoy, tenemos el fenómeno de organizaciones —incluidas corporaciones con fines de lucro—iniciando desde cero, proyectos Open Source centralizados y a gran escala. El desarrollador solitario, tecleando algo de código para resolver un problema local y luego dándose cuenta de que los resultados tienen un mayor aplicación, sigue siendo la fuente de muchos software libre, pero esa no es la única historia. De todas formas, el objetivo de Raymond sigue siendo profundo. La condición esencial es que los productores de software libre tengan un interés directo en su éxito, porque ellos mismos lo utilizan. Si el software no hace lo que se supone debería hacer, la persona u organización que lo han producido sentirán insatisfacción en su labor diaria. Por ejemplo, el proyecto OpenAdapter (), el cual fue iniciado por el banco de inversiones Dresdner Klienwort Wasserstein es un marco de trabajo para la integración de sistemas de información financieros dispares, poco de esto puede ser considerado como un problema personal de un programador. En particular éste problema surge directamente de la experiencia de la institución y sus socios, por lo cual si el proyecto falla en aliviarlos, ellos lo sabrán. Este arreglo produce buenos programas porque el bucle de críticas fluye en la dirección correcta. El programa no está siendo escrito para ser vendido a alguien más, es solo para que sean ellos quienes resuelvan sus problemas. Está siendo desarrollado para resolver su propio problema, luego compartiéndolo con todo el mundo como si el problema fuera una enfermedad y el software la medicina, la cual debe ser distribuida para erradicar la epidemia. Este capítulo trata de cómo introducir un nuevo proyecto de software libre al mundo, pero muchas de sus recomendaciones sonarán familiares a una organización sanitaria distribuyendo medicinas. Los objetivos son muy similares: quieres dejar claro lo que hace la medicina, hacerla llegar a las manos correctas y asegurarte de que aquellos quienes la reciben saben como usarla. Pero con el software, también deseas incitar a algunos de los receptores a unirse al esfuerzo de investigación para mejorar la medicina. La distribución del software libre es una tarea a dos bandas. El programa necesita usuarios y desarrolladores. Estas dos necesidades no tienen por que estar en conflicto, pero si que añaden cierta complejidad a la presentación inicial de un proyecto. Alguna información es útil para las dos audiencias, alguna sólo lo es para alguna u otra. Ambos tipos de información deben suscribirse al principio de las presentaciones en escala, esto es, el grado de detalle con el que se presenta cada etapa debe corresponder directamente a la cantidad de tiempo y esfuerzo puesto por el lector. Un mayor esfuerzo debe tener siempre una mayor recompensa. Cuando los dos no se relacionan conjuntamente, las personas pueden perder rápidamente su fe y perder el impulso. El corolario a esto es:las apariencias importan. Los programadores en particular, no desean creer esto. Su amor por la sustancia sobre la forma es casi un punto de orgullo profesional. No es un accidente que tantos desarrolladores exhiban una antipatía hacia los trabajos en marketing y en relaciones públicas o que diseñadores gráficos profesionales usualmente se sientan horrorizados de lo que los desarrolladores ingenian. Esto es penoso, ya que hay situaciones en las que la forma es la sustancia y la presentación de proyectos es una de estas. Por ejemplo, lo primero que un visitante descubre sobre un proyecto es como se ve su sitio web. Esta información es absorbida antes de que el contenido en si sea comprendido—antes de que cualquier línea haya sido leída o enlaces pulsados. Aunque parezca injusto, las personas no pueden evitar el formarse una opinión inmediatamente después de la primera impresión. La apariencia del sitio señala si se ha tomado cuidado en la organización de la presentación del proyecto. Los humanos tenemos una antena extremadamente sensible para detectar el empeño en el cuidado. Muchos de nosotros podemos decir con sólo un vistazo si un sitio web ha sido ensamblado rápidamente o ha sido diseñado con cuidado. Ésta es la primera pieza de información que el proyecto muestra y la impresión que cree será asociada al resto del proyecto por asociación. Aunque mucho de éste capítulo habla acerca del contenido con el que se debería iniciar el proyecto, recuerde que la presentación también importa. Ya que el sitio web debe funcionar para dos tipos diferentes de visitantes—usuarios y desarrolladores— hay que ser directo y conciso. A pesar de que este no es el lugar para un tratado general acerca de diseño web, un principio es suficientemente importante para merecer nuestra atención, particularmente cuando sirve a múltiples audiencias: la gente debe tener una idea de a donde lleva un enlace antes de pulsar en el. Por ejemplo, debe ser obvio que con sólo ver el enlace a la documentación para los usuarios, que les lleve a la documentación para los usuarios, sin mencionar la documentación para los desarrolladores. Dirigir un proyecto se basa parcialmente en suministrar información, pero también en suministrar comodidad. La mera presencia de ofrecer ciertos estándares, en lugares obvios, tranquiliza a usuarios y desarrolladores quienes están decidiendo si desean involucrarse. Dice que este proyecto funciona, ha anticipado las preguntas que la gente puede hacer y ha hecho un esfuerzo en responderlas sin la necesidad del más mínimo esfuerzo por parte del visitante. Al dar ésta aura de preparación, el proyecto envía un mensaje: "Su tiempo no será malgastado si se involucra", lo que es exactamente lo que la gente desea escuchar. Primero investiga Antes de iniciar un proyecto Open Source hay un importante advertencia: Siempre investiga si existe un proyecto que hace lo que deseas. Las posibilidades son muy buenas de que cualquier problema que desees resolver ahora alguien más lo haya deseado resolver con anterioridad. Si han sido capaces de resolverlo y han liberado bajo una licencia libre entonces hoy, no será necesario inventar la rueda. Existen excepciones claro: si deseas iniciar un proyecto como experiencia educativa, el código pre-existente no es de ayuda o quizás el proyecto que deseas iniciar es muy especializado y sabes que no existe la posibilidad de que alguien más lo haya hecho ya. Pero generalmente, no hay necesidad en no investigar ya que las ganancias pueden ser grandiosas. Si los buscadores más utilizados no muestran nada, intenta tus búsquedas en: (un sitio sobre noticias de proyectos open source y del cual hablaremos un poco más adelante), en y en el directorio de proyectos de la Free Software Foundation . Incluso si no se encuentra exactamente lo que estamos buscando, podría encontrar algo parecido, a lo que tiene más sentido unirse a ese proyecto y añadir funcionalidad en lugar de empezar desde cero por si mismo. Empezando con lo que se tiene Has investigado, sin encontrar nada que realmente se adapte a tus necesidades, y decides iniciar un nuevo proyecto. ¿Ahora qué? Lo más difícil acerca de lanzar un proyecto de software libre es transformar una visión privada a una pública. Tú y tu organización quizás sepan exactamente lo que deseas pero expresar ese objetivo de una manera comprensiva al resto del mundo tiene su trabajo. De hecho, es esencial, que te tomes tu tiempo para hacerlo. Tú y los otros fundadores deben decidir sobre qué va realmente el proyecto—eso es, decidir sus limitaciones, lo que no podrá hacer como lo que sí—y escribir una declaración de objetivos. Ésta parte no suele ser usualmente difícil, aunque puede revelar afirmaciones y desacuerdos sobre la naturaleza del proyecto, lo cual esta bien: mejor resolver esto ahora que luego. El próximo paso es empaquetar el proyecto para el consumo público, y esto es, básicamente, trabajo puro y duro. Lo que lo hace laborioso es porque consiste principalmente en organizar y documentar lo que ya todo el mundo sabe—todos aquellos involucrados en el proyecto hasta ahora. Así que, para las personas trabajando ya, no existen beneficios inmediatos. Estos no necesitan de un fichero README que resuma el proyecto ni de un documento de diseño o manual de usuario. No necesitan de un árbol de código cuidadosamente ordenado conforme a los estándares informales, ampliamente utilizados para las distribuciones de fuentes. De cualquier forma como esté ordenado el código fuente estará bien, porque ya estarán acostumbrados de todas formas, y si el código funciona, saben cómo usarlo. Ni siquiera importa si las afirmaciones fundamentales sobre la arquitectura del proyecto siguen sin documentar, ya están familiarizados con lo que deben hacer. En cambio, los recién llegados, necesitan de todas estas cosas. Afortunadamente, no las necesitan todas a la vez. No es necesario proporcionar todos los recursos posibles antes de tomar un proyecto público. Quizás en un mundo perfecto, todo nuevo proyecto open source empezaría su vida con un riguroso documento de diseño, un manual de usuario completo (marcando especialmente las características planeadas pero que aun no han sido implementadas), código empaquetado hermosamente y portable, capaz de ejecutar en cualquier plataforma y así sucesivamente. En realidad, cuidar de todos estos detalles consumiría demasiado tiempo, y de todas maneras, es trabajo con el que podrían ayudar voluntarios una vez que el proyecto esté en marcha. Por otro lado, lo que sí es necesario, es que se realice una inversión apropiada en la presentación, de forma que los recién llegados puedan superar el obstáculo inicial de no estar familiarizados con el proyecto. Pensemos en ello como en el primer paso en un proceso de inicio (bootstrapping), llevar al proyecto a un tipo de activación de energía mínima. He escuchado llamar a este umbral como hacktivation energy: la cantidad de energía que debe aportar un recién llegado antes de recibir algo a cambio. Mientras menor sea ésta energía, mejor. La primera tarea es hacer descender ésta hacktivation energy a niveles que animen a la gente a involucrarse. Cada una de las siguientes secciones, describen un aspecto importante de iniciar un nuevo proyecto. Están presentadas casi en el mismo orden en el que un nuevo visitante las encontraría, aunque claro, el orden en el cual sean implementadas puede ser diferente. Incluso pueden ser tratadas como una lista de tareas. Cuando se inicie un proyecto, asegúrese de revisar la lista y de que cada uno de los elementos sean cubiertos, o al menos asegurar cierta comodidad con las posibles consecuencias de dejar alguna aparte. Escoger un buen nombre Coloque se en la posición de alguien que acaba de escuchar acerca de su proyecto, quizás por alguien quien fortuitamente tropezó con éste mientras buscaba por alguna aplicación para resolver un problema. Lo primero que encontraran será el nombre del proyecto. Un nombre genial no hará que automáticamente el proyecto tenga éxito, y un nombre malo no significa que éste acabado—bueno, en realidad un mal nombre probablemente podría hacer eso, pero empecemos asumiendo que nadie está activamente intentando hacer que su proyecto falle. De todos modos, un mal nombre puede desacelerar la adopción del programa porque la gente no se lo tome seriamente o porque simplemente les cueste recordarlos. Un buen nombre: Da cierta idea de lo que el proyecto hace, o al menos está relacionado de una manera obvia, como si alguien conoce el nombre y sabe lo que hace, después lo recordaran rápidamente. Es fácil de recordar. Veamos, no hay nada de falso en el hecho de que el ingles se a convertido en el lenguaje por defecto de Internet: "fácil de recordar" significa "fácil para alguien que sepa leer en ingles de recordar." Nombres que son calambures dependientes en la pronunciación de ingleses nativos, por ejemplo, serán opacos para muchos lectores no nativos en ingles. Si el calambur es particularmente llamativo y memorable, quizás sí valga la pena. Sólo recuerde que muchas personas al ver el nombre no lo escucharán en sus mentes de la misma manera que un ingles nativo lo haría. No tiene el mismo nombre que otro proyecto y no infringe ninguna marca comercial. Esto es por buenos modales, y tener un buen sentido legal. No desea crear confusiones de identidad. Ya es bastante difícil mantenerse al día con todo lo que hay disponible en la red, sin tener diferentes cosas con el mismo nombre. Los enlaces mencionados anteriormente en son muy útiles en descubrir si algún otro proyecto ya tiene el mismo nombre en el que estábamos pensando. Podemos encontrar buscadores gratuitos de marcas registradas en y . Está disponible como un nombre de dominio .com, .net, y .org. Hay que escoger alguno, probablemente .org, para promocionarse como el sitio oficial para el proyecto. Los otros dos deben reenviar allí simplemente para evitar que terceras partes creen una confusión de identidad sobre el nombre del proyecto. Incluso si piensa en hospedar el proyecto en otro sitio (vea ) puede registrar los dominios específicos del proyecto y direccionarlos al sitio del hospedaje. Ayuda mucho a los usuarios tener que recordar sólo un URL. Tener los objetivos claros Una vez que se ha encontrado el sitio del proyecto, lo siguiente que la gente hace es buscar por una descripción rápida, una declaración de objetivos, para poder decidir (en menos de 30 segundos) si están o no interesados en aprender más. Esto debe estar en un lugar prioritario en la página principal, preferiblemente justo debajo del nombre del proyecto. La declaración de los objetivos debe ser concreta, limitada y sobre todo, corta. Aquí tenemos un buen ejemplo, de :

Crear, como una comunidad, una suite ofimática líder a nivel internacional, que funcione en las mayores plataformas y proporcionar acceso a toda la funcionalidad y datos a través de API's basadas en componentes abiertos y un formato de ficheros basado en XML.

En pocas palabras, han logrado la máxima puntuación, sobretodo al basarse en los conocimientos previos de los lectores. Al decir "como una comunidad", señalan que ninguna corporación dominará el desarrollo. "Internacional" significa que la aplicación permitirá a personas con múltiples lenguas y localidades trabajar. "En las mayores plataformas significa que será portable a Unix, Macintosh y Windows. El resto señala que las interfaces abiertas y formatos de ficheros fáciles de comprender son una parte importante de sus objetivos. De buenas a primeras, no intentan declarar ser una alternativa libre a Microsoft Office, aunque seguramente la mayoría puede leer entre lineas. Aunque ésta declaración de objetivos pueda parecer demasiado amplia a primera vista, el hecho es que está bien circunscrita: las palabras "suite ofimática " significan algo muy concreto para aquellos familiarizados con este tipo de programas. Otra vez, el asumir sobre los conocimientos previos del lector (en este caso probablemente de MS Office) permite mantener la declaración concisa. El ámbito de una declaración de objetivos depende en gran parte de quien la escriba, no sólo del programa que intenta describir. Por ejemplo, tiene sentido para OpenOffice.org utilizar las palabras "como una comunidad", porque el proyecto fue iniciado, y sigue estando patrocinado, por Sun Microsystems. Al incluir esas palabras, Sun esta indicado sensibilidad a preocupaciones de que intente dominar el proceso de desarrollo. Con este tipo de cosas, simplemente demostrar un conocimiento ambiguo del potencial de un problema ayuda enormemente a evitar el problema completamente. Por otra parte, aquellos proyectos que no son patrocinados por una sola corporación probablemente no tengan que utilizar este lenguaje, después de todo, el desarrollo comunitario es la norma, así que normalmente no debería haber ninguna razón para señalar esto como una parte de los objetivos. Declara que el proyecto es libre Aquellos que sigan interesados después de leer la declaración de objetivos querrán más detalles, quizás un poco de documentación para usuarios o desarrolladores, y eventualmente querrán descargar algo. Pero antes que nada, necesitaran estar seguros de que es open source. La página principal debe poner claramente y sin ambigüedades que el proyecto es open source. Esto puede parecer obvio, pero es sorprendente cuantos proyectos se olvidan de esto. He visto sitios de proyectos de software libre donde la página principal no sólo no decía bajo cual licencia libre se distribuía la aplicación sino que ni siquiera declaraban que el software fuese libre. A veces, estas piezas cruciales de información eran relegadas a la página de descargas o a la página de los desarrolladores o a algún otro lugar el cual requería más de un enlace para llegar. En casos extremos, la licencia no se mostraba en ninguna parte del sitio—la única forma de encontrarla era descargando la aplicación e investigando. No cometáis estos errores. Una omisión como ésta puede haceros perder muchos desarrolladores y usuarios potenciales. Declarad desde el principio, justo debajo de la declaración de objetivos, que el proyecto es "software libre" u "open source", y mostrad la licencia exacta. Una guía rápida para escoger una licencia se encuentra en más adelante en éste capítulo, y algunos detalles sobre las licencias serán discutidos en el . Llegados a este punto, nuestro visitante hipotético ha determinado— probablemente en un minuto o menos—que está interesado en utilizar, digamos, al menos cinco minutos más investigando el proyecto. La próxima parte describe qué debería encontrar durante esos cinco minutos. Lista de características y requerimientos Debería haber una breve lista de las características que el software soporta (si algo aun no ha sido completado, se puede listar de todas formas, pero señalando "planeado" o "en progreso") y el tipo de entorno necesario para ejecutar la aplicación. Hay que pensar en ésta lista como algo que daríamos a alguien que requiere un resumen de nuestro programa. Por ejemplo, la declaración de objetivos podría decir:

Crear un controlador y sistema de búsqueda con una API, para ser utilizada por programadores suministrando servicios de búsqueda para grandes colecciones de ficheros de texto.

La lista de características y requerimientos daría detalles que permitirían esclarecer el alcance de la declaración de objetivos:

Características Búsquedas en texto plano, HTML y XML Búsqueda de palabras o frases (planeado) Emparejando borroso (Fuzzy Matching) (planeado) Actualización incremental de índices (planeado) Indexado de sitios web remotos Requerimientos: Python 2.2 o mayor Espacio en disco suficiente para contener los índices (aproximadamente 2x el tamaño original de los datos)

Con ésta información, los lectores podrán rápidamente tener una idea de si éste programa tiene alguna esperanza de trabajar para ellos, y también pueden considerar involucrarse como desarrolladores. Estado del desarrollo La gente siempre quiere saber cómo va un proyecto. Para proyectos nuevos, desean saber la separación entre las promesas del proyecto y la realidad del momento. Para proyectos maduros, desean saber cuan activamente es mantenido, cuan seguido sacan nuevas versiones, la facilidad para reportar fallos, etc. Para responder a estas dudas, se debe suministrar una página que muestre el estado del desarrollo, listando los objetivos a corto plazo del proyecto y las necesidades (por ejemplo, quizás se estén buscando desarrolladores con un expertos en un tema en particular). Ésta página también puede dar una historia de versiones anteriores, con listas de las características, de manera que los visitantes obtengan una idea de cómo el proyecto define su "progreso" y de cuan rápidamente se hacen progresos de acuerdo a esas definiciones. No hay que asustarse por parecer no estar preparado y no caer en la tentación de inflar el estado del desarrollo. Todos saben que el software evoluciona por etapas; no hay que avergonzarse en decir "Esto es software alfa con fallos conocidos. Ejecuta, y funciona algunas veces, así que uselo bajo su responsabilidad." Este lenguaje no asustará el tipo de desarrolladores que son necesarios en esta etapa. En cuanto a los usuarios, una de las peores cosas que un proyecto puede hacer es atraer usuarios antes de que el software éste listo para estos. Una reputación por inestabilidad y fallos es muy difícil de hacer desaparecer una vez adquirida. La paciencia da sus frutos a largo plazo; siempre es mejor que el software sea más estable de lo que espera el usuario ya que las sorpresas gratas producen el mejor boca a boca. Alfa y Beta El término alfa usualmente significa, la primera versión, con lo que los usuarios pueden realizar todos el trabajo teniendo todas la funcionalidad esperada, pero que se sabe tiene fallos. El principal propósito de el software alfa es generar una respuesta, de forma que los desarrolladores sepan en qué trabajar. La próxima etapa, beta, significa que han sido resueltos todos los fallos más importantes, pero que aun no ha sido intensivamente probado como para ser la versión oficial. El propósito de las betas es la de convertirse en la versión oficial, asumiendo que nuevos fallos no sean encontrados, o de suministrar un feedback para los desarrolladores para que logren la versión oficial más rápido. La diferencia entre alfa y beta es más una cuestión de juicio. Descargas EL software debe poder ser descargable como código fuente en formatos estándares, paquetes binarios (ejecutables) no son necesarios, a menos que el programa tenga requerimientos muy complicados para su compilado o dependencias que hagan hacerlo funcionar sea muy laborioso para la mayoría de las personas. (¡Aunque si es éste es el caso, el proyecto va a tenerlo muy difícil atrayendo programadores de todas maneras!) El mecanismo de distribución debe de ser de lo más conveniente, estándar y sencillo posible. Si se estuviese intentando erradicar una enfermedad, no distribuiría la medicina tal que requiriese de una jeringuilla especial para administrarse. De igual manera, un programa debe ser conforme a métodos de compilación e instalación estándar; entre más se desvíe de estos estándares, mayor será la cantidad de usuarios y desarrolladores potenciales que se den por vencidos y abandonen el proyecto confundidos. Esto parece obvio, pero muchos proyectos no se molestan en estandarizar sus procedimientos de instalación hasta mucho después, diciéndose a si mismos que esto lo pueden hacer en cualquier momento: "Ya resolveremos todas esas cosas cuando el código éste casi listo." De lo que no se dan cuenta es de que al dejar de lado el trabajo aburrido de terminar los procedimientos de compilado e instalación, en realidad están ralentizando todo—porque desalientan a los programadores que de otra manera habrían contribuido al código. Más dañino aun, no saben que están perdiendo a todos esos desarrolladores, porque el proceso es una acumulación de eventos que no suceden: alguien visita un sitios web, descarga el programa, intenta compilarlo, falla, deja de intentarlo y abandona. ¿Quién sabrá que ocurrió exceptuando a ésta persona? Nadie en el proyecto se dará cuenta que el interés y la buena voluntad de alguien a sido silenciosamente malgastada. Las tareas aburridas con un alto beneficio siempre deben ser hechos al principio y disminuyendo de manera significativa las barreras de entrada a un proyecto utilizando buenos paquetes brindan altos beneficios. Cuando se lanza un paquete descargable, es vital que se le dé un número de versión único a éste lanzamiento, de manera que la gente pueda comparar dos versiones cualquiera diferentes y saber cual reemplaza a cual. Una discusión detallada sobre la numeración de versiones puede ser encontrada en , y detalles sobre la estandarización de los procedimientos de compilado e instalación serán cubiertos en , ambos en el . Control de versiones y acceso al Bug Tracker Descargar paquetes con el código fuente está bien para aquellos que sólo desean instalar y utilizar un programa, pero no es suficiente para aquellos que desean buscar fallos o añadir nuevas mejoras. Instantáneas nocturnas del código fuente pueden ayudar, pero esto no es suficiente para una prospera comunidad de desarrollo. Estas personas necesitan de acceso en tiempo real a los últimos cambios, y la manera de proporcionarles esto es utilizando un sistema de control de versiones (version control system). La presencia de fuentes controladas, accesibles anónimamente es una señal de—para ambos, usuarios y programadores—que éste proyecto ésta haciendo un esfuerzo en proporcionar todo lo necesario para que otros participen. Si no se puede ofrecer control de versiones desde el principio, comunique la intención de montarlo pronto. La infraestructura de control de versiones es discutida en detalle en en el . Lo mismo se aplica para el seguimiento de errores del proyecto. La mayor importancia que se le dé a ésta base de datos, lo mejor que parecerá el proyecto. Esto puede parecer contra intuitivo, pero hay que recordar que el número de fallos registrados, en realidad depende en tres cosas: el número absoluto de errores presentes en el programa, el número de usuarios utilizándolo y la conveniencia con la cual esos usuarios registran nuevos fallos. De estos tres factores, los dos últimos son más significativos que el primero. Cualquier aplicación con suficiente tamaño y complejidad tiene una cantidad arbitraria de fallos esperando a ser descubiertos. La verdadera cuestión es, cuan bien serán registrados y priorizados estos errores. Un proyecto con una base de datos de fallos amplia y bien mantenida (errores importantes son atacados rápidamente, fallos duplicados son unificados, etc.) generan una mejor impresión que un proyecto sin una o vacía. Claro está, que si un proyecto está empezando, que la base de datos de fallos contenga algunos pocos, y no hay mucho que se pueda hacer al respecto. Pero si la página donde se indica el estado del proyecto, enfatiza en la juventud del proyecto y si las personas mirando los fallos pueden observar que muchos de estos han sido incluidos recientemente, pueden asumir que el proyecto tiene una proporción saludable de entradas y no serán alarmados por el mínimo absoluto de fallos registrados. Hay que señalar que los bug trackers no sólo son usados para fallos en los programas pero también para peticiones de mejoras, cambios en la documentación, tareas pendientes y mucho más. Los detalles de ejecutar un sistema de seguimiento de fallos será cubierto en en el , así que no vamos a entrar en detalles. Lo importante desde la perspectiva de la presentación está en tener un bug tracker y asegurarse de que es visible desde la página principal del proyecto. Canales de comunicación Usualmente los visitantes desean saber cómo pueden contactar con los seres humanos detrás del proyecto. Hay que suministrar direcciones de listas de correo, salas de chat, canales en IRC y cualquier otro foro donde aquellos involucrados puedan ser contactados. Hay que dejar claro que los autores del proyecto están suscritos a estas listas, de manera que la gente vea una forma de dar feedback a los desarrolladores. La presencia de estos en las listas no implica obligación alguna de responder a todas las preguntas que se formulan o de implementar todas las peticiones. A la larga, muchos de los usuarios probablemente ni siquiera se unan a los foros de todas maneras, pero estarán conformes con saber que podrían si fuese necesario. En la primeras etapas de cualquier proyecto, no existe la necesidad de que haya una diferenciación entre los foros de los usuarios y los de los desarrolladores. Es mejor tener a todos los involucrados en el proyecto hablando en conjunto en una sala. Dentro de los primeros en adoptar el proyecto, la distinción entre usuario y desarrollador será muchas veces borrosa, hasta tal punto que la distinción no se puede hacer y la proporción entre programadores y usuarios usualmente es mayor al principio que al final. Mientras que no se puede asumir que todos quienes utilicen el programa sean programadores que quieren modificarlo, sí se puede asumir que al menos estan interesados en seguir las discusiones sobre el desarrollo y en obtener una visión de la dirección del proyecto. Ya que éste capítulo es sólo sobre iniciar un proyecto, es suficiente decir que al menos estos foros de comunicación deben existir. Luego en en el , examinaremos dónde y cómo montar estos foros, cómo deben ser moderados o cualquier otro tipo de dirección y cómo separar los foros de usuarios de los foros de los desarrolladores, cuando llegue el momento, sin crear un espacio infranqueable. Pautas de Desarrollo Si alguien considera contribuir al proyecto, buscará por pautas de desarrollo. Estas pautas son más sociales que técnicas: explican como los desarrolladores interactúan entre ellos y con los usuarios y últimamente como hacer las cosas. Este tema es tratado en detalle en en , pero los elementos básicos de unas pautas de desarrollo son: enlaces a los foros para la interacción de los desarrolladores instrucciones en cómo reportar fallos y enviar parches alguna indicación de cómo el desarrollo es usualmente llevado a cabo—es el proyecto una dictadura benevolente, una democracia o algo más Ningún sentido peyorativo es intencional por lo de "dictadura" por cierto. Es perfectamente aceptable ser un tirano donde un desarrollador en particular tiene el poder de veto sobre todos los cambios. Muchos proyectos exitosos funcionan de ésta manera. Lo importante es que el proyecto sea consciente de esto y lo comunique. Una tiranía pretendiendo ser una democracia desalentara a las personas; una tiranía que dice serlo funcionará bien siempre que el tirano sea competente y de confianza. Un ejemplo de unas pautas de desarrollos particularmente exhaustivas están en o en tenemos unas pautas más amplias que se concentran más en la forma de gobierno y el espíritu de participación y menos en temas técnicos. Proveer una introducción a la aplicación para los programadores es otro tema y será discutido en más adelante en éste capítulo . Documentación La documentación es esencial. Debe haber algo para que la gente lea, aunque sea algo rudimentario e incompleto. Esto entra de lleno en la categoría antes referida y usualmente es la primera área donde un proyecto falla. Conseguir una declaración de objetivos y una lista de requerimientos, escoger una licencia, resumir el estado de desarrollo—son todas tareas relativamente pequeñas que pueden ser completadas y a las que usualmente no es necesario volver una vez terminadas. La documentación, por otra parte, nunca está terminada realmente, lo cual puede que sea una de las razones por las cuales se retrase su inicio. La cuestión más insidiosa sobre la utilidad de la documentación es que es inversamente proporcional para quienes la escriben y para quienes la leen. Lo más importante de la documentación para un usuario inicial es lo más básico: cómo configurar la aplicación, una introducción de cómo funciona y quizás algunas guías para realizar las tareas más comunes. Pero a la vez son estas cosas las más sabidas por aquellos quienes escriben la documentación— tan bien sabidas que puede ser difícil para estos ver las cosas desde el punto de vista de los lectores, dificultando listar los pasos que (para los escritores) parecen tan obvios que no merecen especial atención. No existe una solución mágica para éste problema. Alguien debe sentarse y escribir todo esto para luego presentárselo a un usuario nuevo tipo y probar la calidad. Hay que utilizar un formato simple y fácil de modificar como HTML, texto plano, Tex o alguna variante de XML—algo que sea conveniente para mejoras rápidas, ligeras e imprevisibles. Esto no es sólo para eliminar cualquier trabajo innecesario a los escritores originales realizar cambios incrementales, sino que también para quienes se unan al proyecto después y desean trabajar en la documentación. Una manera de asegurarse de que la documentación básica inicial se hace, es limitando su alcance. Al menos de ésta manera no parecerá que se está escribiendo una tarea sin fin. Una buena regla es seguir unos criterios mínimos: Avisar al lector claramente el nivel técnico que se espera que tenga. Describir clara y extensivamente cómo configurar el programa y en alguna parte al inicio de la documentación comunicarle al usuario cómo ejecutar algún tipo de prueba de diagnóstico o un simple comando para confirmar que todo funciona correctamente. La documentación inicial es a veces más importante que la documentación de uso. Mientras mayor sea el esfuerzo invertido en instalar y tener funcionando la aplicación, mayor será la persistencia en descubrir funcionalidades avanzadas o no documentadas. Cuando alguien abandona, abandonan al principio; por ello, las primeras etapas como la instalación, necesiten la mayor ayuda. Dar un ejemplo estilo tutorial de como realizar alguna tarea común. Obviamente, muchos ejemplos para muchas tareas sería mejor, pero si el tiempo es limitado, es mejor escoger una tarea en específico y llevar al usuario de la mano paso por paso. Una vez que se ve que la aplicación puede ser utilizada , empezarán a explorar qué más es lo que puede hacer—y si se tiene suerte empezar a documentarlo ellos mismos. Lo que nos lleva al siguiente punto... Indicar las áreas donde se sabe que la documentación es incompleta. Al mostrar a los lectores que se es consciente de las deficiencias, nos alineamos con su punto de vista. La empatía les da confianza en que no van a tener que luchar para convencer al proyecto de su importancia. Estas indicaciones no necesitan representar promesa alguna de completar los espacios en blanco en una fecha en particular—es igualmente legitimo tratarlas como requisitos abiertos para ayudantes voluntarios. Ese último criterio es de una especial importancia, y puede ser aplicado al proyecto entero, no sólo a la documentación. Una gestión exacta de las deficiencias conocidas es la norma en el mundo Open Source. No se debe exagerar en las faltas del proyecto, solo identificarlas escrupulosa y desapasionadamente cuando sea necesario (sea en la documentación, en la base de datos de fallos o en discusiones en la lista de correos). Nadie verá esto como derrotismo por parte del proyecto, ni como una responsabilidad explícita. Ya que cualquiera que utilice la aplicación descubrirá sus deficiencias por si mismos, es mejor que estén psicológicamente preparados—entonces parece que el proyecto tiene un sólido conocimiento acerca de como va progresando. Manteniendo un FAQ (Preguntas Más Frecuentes) Un FAQ (del ingles "Frequently Asked Questions") puede ser uno de las mejores inversiones que un proyecto puede hacer en términos de beneficios educativos. Los FAQs están enfocados a las preguntas que desarrolladores y usuarios podrían formular—opuesto a aquellas que se espera que hagan—por lo cual un FAQ bien cuidado tiende a dar a aquellos quienes lo consultan exactamente lo que están buscando. Por lo general es el primer lugar en el que se busca cuando se encuentran con un problema, incluso con preferencia sobre el manual oficial y es probablemente el documento más propenso a ser enlazado desde otros sitios. Desafortunadamente, no se puede hacer un FAQ al principio del proyecto. Los buenos FAQs no son escritos, crecen. Son por definición documentos reactivos, evolucionando con el tiempo como respuesta al uso diario del programa. Ya que es imposible anticipar correctamente las preguntas que se podrían formular, es imposible sentarse a escribir un FAQ útil desde cero. Así que no hay que malgastar el tiempo en intentarlo. En cambio, podría ser útil crear una plantilla casi en blanco del FAQ, de forma que haya un lugar obvio donde las personas contribuyan con preguntas y respuestas después de que el proyecto esté en progreso. En ésta etapa lo más importante no es tenerlo todo completo, sino la conveniencia: si es sencillo agregar contenido al FAQ, la gente lo hará. (Un mantenimiento correcto de un FAQ es un problema no trivial e intrigante y es discutido más a fondo en en el .) Disponibilidad de la documentación La documentación debe ser accesible desde dos sitios: en línea (directamente desde el sitio web), y en la distribución descargable de la aplicación (consultar en el ). Debe estar en línea y navegable porque a menudo se lee la documentación antes de descargar el programa por primera vez, como una ayuda en la decisión de descargarlo o no. Pero también debe acompañar al programa, bajo la premisa de que la descarga debe suministrar todo lo necesario para utilizar el paquete. Para la documentación en línea, hay que asegurarse de que hay un enlace que muestra toda la documentación en una página HTML (indicando algo como "monolito" o "todo-en-uno" o "sólo un gran fichero" al lado del enlace, de tal manera que se sepa que puede tardar un poco en cargar). Esto es muy útil porque a veces sólo desean buscar una sola palabra o frase en la documentación. Generalmente, las personas ya saben qué es lo que están buscando, sólo que no recuerdan en cual sección está. Para estas personas, nada es más frustrante que encontrar una página para la tabla de contenidos, luego otra diferente para la introducción, luego otra diferente para las instrucciones de instalación, etc. Cuando las páginas están divididas de esta manera, la función de búsqueda de sus navegadores es inútil. Este estilo de páginas separadas es útil para quienes ya saben cual es la sección que necesitan, o que desean leer toda la documentación de principio a fin en secuencia. Pero esta no es la forma más común en que la documentación es leída. Ocurre más a menudo que alguien que conoce algo básico de la aplicación vuelve para buscar una palabra o frase. Fallar al suministrarles un sólo documento en el que se puedan realizar búsquedas, es hacerles la vida más dura Documentación para Desarrolladores La documentación para los desarrolladores es escrita para ayudar a los programadores a entender el código y puedan arreglarlo o extenderlo. Esto es algo diferente a las pautas de desarrollo discutidas anteriormente, que son más sociales que técnicas. Estas pautas para los desarrolladores le dicen a los programadores como deben desenvolverse entre ellos. La documentación les dice como deben desenvolverse con el código en si mismo. Por conveniencia las dos vienen juntas en un sólo documento (como sucede con el ejemplo anterior ) pero no es obligatorio. A pesar de que la documentación para los desarrolladores puede ser de mucha ayuda, no existe ninguna razón para retrasar un lanzamiento por hacerla. Es suficiente para empezar que los autores originales estén disponibles (y dispuestos) a responder a preguntas sobre el código. De hecho, tener que responder la misma pregunta varias veces es una motivación muy común para escribir dicha documentación. Pero antes de que sea escrita, determinados contribuyentes serán capaces de desenvolverse con el código ya que la fuerza que hace que las persones utilicen su tiempo en leer el código base es que éste código les resulta útil. Si las personas tienen fé en ello, ninguna cantidad de documentación hará que vengan o los mantendrá. Así que si hay tiempo para escribir documentación sólo para una audiencia, que sea para los usuarios. Toda la documentación para los usuarios es, en efecto, documentación para desarrolladores también. Cualquier programador que vaya a trabajar en un proyecto necesita estar familiarizado con su uso. Luego, cuando se vea a los programadores preguntando las mismas preguntas una y otra vez, habrá que tomarse el tiempo de escribir algunos documentos aparte sólo para estos. Algunos proyectos utilizan wikis para su documentación inicial o incluso para su documentación principal. En mi experiencia, esto es efectivo si y sólo si, el wiki es editado activamente por algunas personas que se ponen de acuerdo en como la documentación debe ser organizada y la voz que debe tener. Más en en el . Ejemplos de salidas y capturas Si el proyecto implica una interfaz gráfica para el usuario o si produce una salida gráfica o distintiva, habrá que poner algunos ejemplos en el sitio web del proyecto. En el caso de las interfaces, esto significa capturas. Para salidas, pueden ser capturas o sólo ficheros. Ambos dotan al usuario de gratificación instantánea: una sola captura puede ser más convincente que párrafos de texto descriptivo y cháchara de listas de correo, porque una captura es la prueba indiscutible de que el programa funciona. Puede que tenga fallos, quizás sea difícil de instalar o que la documentación esté incompleta, pero esa captura sigue siendo la prueba de que con el esfuerzo necesario, se puede hacer funcionar. Capturas Ya que hacer las capturas puede ser algo desalentador, aquí tenéis unas instrucciones básicas sobre como hacerlas. Utilizando The Gimp (), pinchad en Archivo->Adquirir->Captura de pantalla, escoged Capturar una sola ventana o Toda la pantalla, luego pinchad en Capturar. La próxima vez que pinche la ventana o la pantalla será capturada como una imagen en The Gimp Recortad y cambiad el tamaño de la imagen según sea necesario siguiendo las instrucciones en . Existen muchas otras cosas que se pueden poner en el sitio web del proyecto, si se tiene el tiempo, o si por alguna razón u otra son especialmente apropiadas: página de noticias, historia, enlaces relacionados, función de búsqueda, enlace para donaciones, etc. Ninguno de estos es necesarios al principio, pero hay que tenerlos en mente para el futuro. Hosting enlatado Existen algunos sitios que proveen hosting gratuito e infraestructura para proyectos open source: un área web, control de versiones, gestor de errores, zona de descargas, salas de chat, backups regulares, etc. Los detalles varían entre sitio y sitio, pero los servicios básicos son ofrecidos por todos. Al utilizar uno de estos sitios, se obtiene mucho por nada, dando a cambio, obviamente, el control sobre la experiencia del usuario. Quien provee el hosting decide cuales programas el sitio acepta y puede controlar o al menos influenciar el aspecto de las páginas del proyecto. Vaya a en el para una discusión más detalladas acerca de las ventajas y desventajas del hosting enlatado y una lista de sitios que lo ofrecen. Escogiendo una licencia y aplicándola Esta sección está concebida para ser una guía rápida y amplia sobre como escoger una licencia. Leed el para entender en detalle las implicaciones legales de diferentes licencias y como la licencia escogida puede afectar la capacidad de otras personas de mezclar el programa con otros. Existen muchas licencias libres de donde escoger. Muchas de ellas no necesitamos tenerlas en consideración aquí, ya que han sido escritas para satisfacer las necesidades legales específicas de alguna corporación o persona, así que no serian apropiadas para nuestro proyecto. Por ello nos vamos a restringir a las más usadas. En la mayoría de los casos, querrás escoger una de ellas. Las licencias "Haz lo que quieras" Si se está conforme con que el código del proyecto sea potencialmente usado en programas propietarios, entonces se puede utilizar una licencia estilo MIT/X. Es la más sencilla de muchas licencias mínimas que no hacen más que declarar un copyright nominal (sin restringir la copia) y especificar que el código viene sin ninguna garantía. Id a para más detalles. Licencia GPL Si no desea que el código sea utilizado en aplicaciones propietarias utilice la Licencia Pública General o GPL (del ingles General Public License) (). La GPL es probablemente la licencia para software libre más utilizada a nivel mundial hoy en día. Esto es en si mismo una gran ventaja, ya que muchos usuarios potenciales y voluntarios ya estarán familiarizados con ella, por lo cual, no tendrán que invertir tiempo extra en leer y entender la licencia utilizada. Más detalles en en el . Cómo aplicar una licencia a nuestro software Una vez que ha sido escogida una licencia, se debe exponer en la página principal del proyecto. No se tiene que incluir el texto de la licencia aquí, sólo hay que dar el nombre de la licencia y un enlace al texto completo de ésta en otra página. Esto informa al público bajo cual licencia se pretende publicar la aplicación. Para ello, el programa en si debe incluir la licencia. La manera estándar de hacer esto es poniendo el texto completo en un fichero llamado COPYING (o LICENSE) y luego colocar un aviso al principio de cada fichero con el código fuente, listando la fecha del copyright, titular y licencia y explicando donde encontrar el texto completo de la misma. Hay muchas variaciones de éste patrón, así que miraremos a un sólo ejemplo. La GPL de GNU indica que se debe colocar un aviso como éste al principio de cada fichero con código fuente: Copyright (C) <year> <name of author> This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA No específica que una copia de la licencia adjuntada al programa está en el fichero COPYING, pero comúnmente es en éste donde se pone (Se puede cambiar lo anterior para indicar esto directamente). Esta plantilla también nos da una dirección física a donde solicitar una copia de la licencia. Otro método muy común es suministrar un enlace a una página web que contiene la licencia. Sólo hay que utilizar el sentido común y señalar algún sitio donde se crea habrá una copia permanente de la licencia. Por lo general, el aviso que se coloca al principio de cada fichero con código fuente no debe ser exacto al anteriormente expuesto, siempre y cuando se empiece con el mismo aviso de copyright, titular y fecha, se especifique el nombre de la licencia y se deje claro donde encontrar la licencia completa. Ajustar el tono Hasta ahora hemos cubierto tareas que se hacen sólo una vez durante el proyecto: escoger la licencia, acomodar el sitio web inicial, etc. Pero los aspectos más importantes al empezar un nuevo proyecto son dinámicos. Escoger la dirección para la lista de correos es fácil; asegurarse de que las conversaciones en ésta se mantengan en contexto y sean productivas es otro tema. Si el proyecto es abierto después de años de desarrollo cerrado propio, sus procesos de desarrollo cambiaran y habrá que preparar a los desarrolladores existentes para éste cambio. Los primeros pasos son los más duros, porque los precedentes y las expectaciones sobre la conducta futura aun no se han definido. La estabilidad de un proyecto no viene de políticas formales, sino de un conocimiento colectivo compartido muy difícil de definir y que se desarrolla con el tiempo. A veces existen unas reglas escritas, pero tienden a ser un destilado de los acuerdos intangibles y siempre cambiantes que realmente guían el proyecto. Las políticas escritas no definen la cultura del proyecto mas que describirla, he incluso así, sólo se aproximan. Hay algunas razones por las cuales las cosas funcionan de ésta manera. El crecimiento y los grandes cambios no son tan dañinos para la acumulación de las normas sociales como se puede pensar. Mientras que el cambio no ocurra demasiado rápido, hay tiempo para que los novatos aprendan como funcionan las cosas y después de que aprendan, ellos mismos ayudaran a reforzar este funcionamiento. Consideremos cómo las canciones infantiles sobreviven a lo largo de los siglos. Hay niños hoy en día cantando casi las mismas rimas que los niños de hace cien años, aunque no haya ninguno vivo hoy en día que haya vivido entonces. Los más pequeños escuchan estas canciones de otros niños mayores y cuando son mayores, las cantarán frente a otros niños menores que ellos. Conscientemente los niños no están iniciando un programa de transmisión, por supuesto, pero la razón por la cual las canciones sobreviven es nada más y nada menos porque son transmitidas regular y repetidamente. La escala de tiempo de un proyecto de software libre quizás no sea medido en siglos (aún no lo sabemos) pero las formas de transmisión son las mismas. Aunque el índice de cambios es más rápido y debe ser compensado con un esfuerzo deliberado de comunicación más activo. A este esfuerzo le ayuda el hecho de que las personas por lo general se presentan esperando y buscando normas sociales. Así es como los humanos estamos construidos. En cualquier grupo unido por un mismo objetivo, las personas que se unen, instintivamente buscan conductas las cuales los marcarán como parte del grupo. El objetivo temprano de sentar precedentes es hacer de esas conductas de grupo útiles para el proyecto; una vez establecidas serán perpetuas por si mismas. A continuación hay algunos ejemplos específicos de lo que se puede hacer para establecer buenos precedentes. No se supone que sea una lista exhaustiva, mas es una ilustración de la idea de que establecer un ambiente de colaboración desde el principio ayuda enormemente al proyecto. Físicamente, cada desarrollador puede que trabaje en solitario, pero se puede hacer mucho para hacerlo sentir como si todos estuviesen trabajando juntos en la misma habitación. Mientras mayor sea ésta sensación mayor será el tiempo que quieran invertir en el proyecto. He escogido estos ejemplos en particular porque han surgido en el proyecto de Subversion (), en el cual participé y observé desde sus inicios. Pero estas no son únicas a Subversion, situaciones como estas surgen en casi todos los proyectos open source, y deben ser tomadas como oportunidades para empezar de la manera correcta. Evitar discusiones privadas Incluso después de haber hecho público el proyecto, usted y los otros fundadores del proyecto se encontrarán a menudo intentado resolver preguntas difíciles vía comunicaciones privadas dentro de un circulo interno. Esto es especialmente cierto en los primeros días del proyecto, cuando hay tantas decisiones importantes que tomar y usualmente pocos voluntarios cualificados para resolverlas. Todas las obvias desventajas de una lista pública de discusión se perfilan palpablemente frente a ti: el retraso inherente en las conversaciones por correo, la necesidad de dejar que se forme un consenso, las dificultades de tratar con voluntarios crédulos que piensan que entienden todos los problemas pero que no es así (todo proyecto tiene de estos; a veces son el voluntario estrella del próximo año, a veces permanecen ingenuas durante el resto del proyecto), la persona que no puede entender por qué quieres resolver el problema X cuando es obviamente una parte del más grande problema Z y muchos otros. La tentación de tomar decisiones a puerta cerrada y presentarlas como faits accomplis, o al menos como firmes recomendaciones de un bloque unido e influyente serian geniales la verdad. No lo hagas. Por muy lentas y engorrosas que puedan ser las discusiones publicas, casi siempre son preferibles a largo plazo. Tomar decisiones importantes en privado es como esparcir repelente anti-voluntarios sobre el proyecto. Ningún voluntario serio se quedaría mucho tiempo en un ambiente donde un consejo secreto toma todas las grandes decisiones. Además, las discusiones publicas tienen efectos secundarios beneficiosos que durarán más que cualquier pregunta técnica que fuese el problema: La discusión ayudará a entrenar y educar a nuevos desarrolladores. Nunca se sabe cuantos ojos están viendo una conversación así; Incluso si muchas de las personas no participan, muchas podrían estar monitorizando silenciosamente, deduciendo información acerca de la aplicación. La discusión te entrenará en el arte de explicar temas técnicos a personas que no están tan familiarizadas con el programa. Esta es una capacidad que requiere de práctica y no se puede entrenar hablando con personas que ya saben lo mismo que tu. La discusión y sus conclusiones estarán disponibles en un archivo público para siempre, evitando que futuras discusiones caigan en los mismos problemas. Más en en el . Finalmente, existe la posibilidad de que alguien en la lista haga una contribución real a la conversación, ingeniando una idea nunca antes anticipada. Es difícil decir cuan probable es que esto suceda; depende en la complejidad del código y el nivel de especialización requerida. Pero si se me permite utilizar evidencia anecdótica, apostaría a que esto es más probable de lo que podemos esperar. En el proyecto Subversion, nosotros (los fundadores) creíamos encontrarnos ante una serie compleja y profunda de problemas, en los cuales habíamos estado pensando durante meses, y francamente, dudábamos de que alguien en la recientemente creada lista de correos fueses a dar alguna contribución útil a la discusión. Así que tomamos el camino más fácil y empezamos a lanzar ideas técnicas a diestra y siniestra en correos privados, hasta que alguien observando el proyecto No hemos llegado a la sección de los agradecimientos aún, pero sólo para practicar lo que luego voy a enseñar: el nombre del observador era Brian Behlendorf, y fue él quien no indicó la importancia de mantener todas las discusiones públicas a menos de que existiera alguna necesidad de privacidad descubrió lo que estaba pasando y pidió que se moviera la discusión a la lista pública. Torciendo un poco los ojos, lo hicimos—y fuimos asombrados por la cantidad de comentarios inspiradores y sugerencias que rápidamente resultaron. En muchos casos ofreciendo ideas que no se nos habían ocurrido anteriormente. Al final resultó que había gente muy inteligente en esa lista, sólo estaban esperando el anzuelo apropiado. Es cierto que las discusiones tomaron más tiempo de haberlas hechas en privado, pero eran mucho más productivas, lo cual hacía que valiera la pena el tiempo extra. Sin entrar en generalizaciones como "el grupo es siempre más listo que el individuo" (ya hemos conocido muchos grupos para saberlo) debe ser apuntado que hay ciertas actividades en las que un grupo sobresale. Las revisiones distribuidas masivas son una de estas. Generar un gran número de ideas rápidamente es otra. La calidad de las ideas depende en la calidad del pensamiento que se ha aplicado a estas, por supuesto, pero no vas a saber qué clase de pensadores hay hasta que los estimules con problemas desafiantes. Naturalmente, hay discusiones que deben ser llevadas a cabo en privado; a lo largo de éste libro veremos algunos ejemplos. Pero el principio que debe guiar siempre es: Si no existe razón alguna para que sea privada, debe ser pública. Hacer que esto suceda requiere acciones. No es suficiente con simplemente asegurarse de que todos los comentarios van a la lista pública. También hay que atenerse a las conversaciones privadas innecesarias en la lista. Si alguien intenta iniciar una conversación privada, y no existe razón alguna para que así sea, entonces es de tu incumbencia el abrir la discusión apropiada inmediatamente. Ni siquiera intentes comentar el tema original hasta que se haya direccionado exitosamente la conversación a un sitio público, o asegurado que el tema era necesariamente privado. Si se hace esto consistentemente, las personas se darán cuenta rápidamente y empezarań a utilizar los foros públicos por defecto. Echad a volar la mala educación Desde el primero momento de la existencia pública de un proyecto se deberá mantener una política de tolerancia cero ante la mala educación o las actitudes insultantes en los foros. Tolerancia cero no implica esfuerzos técnicos per se. No se deben eliminar personas de la lista de correos cuando ataquen a otros usuarios, o quitarles sus accesos para realizar commits porque hayan hecho comentarios peyorativos. (En teoría, habría que llegar a tomar estas acciones, pero sólo después de que todas las otras vías hayan fallado—lo cual, por definición, no significa que sea al principio del proyecto.) Tolerancia cero simplemente significa nunca permitir que este tipo de conductas pasen desapercibidas. Por ejemplo, cuando alguien envía un comentario técnico mezclado con un ataque ad hominem contra otros desarrolladores del proyecto, es imperativo que tu respuesta sea primero dirigida a ese ataque ad hominem como un tema aparte y sólo después entrar en el tema técnico. Desafortunadamente es muy fácil y típico, que conversaciones constructivas terminen en una guerra. Las personas dirán cosas en un correo electrónico que nunca dirían cara a cara. Los temas de discusión sólo ayudan a ampliar éste efecto: en cuestiones técnicas, la gente cree a menudo que sólo existe una sola respuesta correcta para la mayoría de las preguntas y que el desacuerdo ante la respuesta sólo puede ser explicado por la ignorancia o la estupidez. Hay una corta distancia entre llamar la propuesta técnica de alguien estúpida y llamar a esa persona estúpida. De hecho, es difícil definir cuando un debate técnico lo deja de ser y se convierte en ataques personales, por lo cual una respuesta drástica y el castigo no son buenas ideas. En su lugar, cuando creas que lo estas viviendo, envía un mensaje que remarque la importancia de mantener la discusión amistosa, sin acusar a nadie de ser deliberadamente venenoso. Este tipo de "política amable" de mensajes tienen la desafortunada tendencia a parecer consejos de un profesor de kindergarten sobre la buena conducta en el aula:

Primero, vamos a dejar a un lado los comentarios (potenciales) ad hominem por favor; por ejemplo, decir que el diseño para la capa de seguridad de J es "simple e ignorante de los principios de la seguridad informática." Quizás sea cierto o no, pero en cualquier caso no es la manera de mantener una discusión. J hizo su propuesta de buena fe y estoy seguro de que M no deseaba insultar a J, pero las maneras han sido inadecuadas y lo único que deseamos es mantener las cosas constructivas. Ahora, vamos con la propuesta de J. Creo que J tenía razón en decir que...

Por muy artificial que parezcan respuestas como estas, tienen un efecto notable. Si se llama la atención constantemente acerca de estas malas actitudes, pero no se pide una disculpa o conocimiento de la parte ofensora, entonces se deja a la gente calmarse y mostrar una mejor cara comportándose con más decoro la próxima vez—y lo harán. Uno de los secretos para hacer esto con éxito es nunca hacer de la discusión el tema principal. Siempre debe ser tratado a parte, una breve introducción a la mayor parte de tu respuesta. Hay que señalar que "aquí no hacemos las cosas de ésta manera" y luego continuar con el tema real, de manera que no dejemos nada a lo que los demás puedan responder. Si alguien protesta diciendo que no merecían ese reproche, simplemente hay que negarse a entrar en una disputa sobre esto. O no respondas (si crees que sólo están liberando tensión y que no requiere de una respuesta) o responde disculpándote por haber sobreactuado y que es difícil detectar matices en el correo electrónico, y ahora de vuelta al tema principal. Nunca insistas en un reconocimiento, público o privado, de alguien que se haya comportado inadecuadamente. Si deciden por voluntad propia enviar una disculpa, genial, pero solicitar que lo hagan en contra de su voluntad, sólo causará resentimiento. El objetivo principal es de hacer que la buena educación se vea como una de las actitudes del grupo. Esto ayuda al proyecto, porque otros desarrolladores pueden ser espantados (incluso de proyectos que les gustan y en los que quieren ayudar) por una flame war. Quizás ni siquiera se llegue a saber que han sido espantados; pueden estar merodeando las listas de correo, descubrir que se necesita de un grueso pelaje para participar en el proyecto y decidir en contra de involucrarse de cualquier manera. Mantener los foros amistosos es una estrategia de supervivencia a largo plazo y es más fácil mientras el proyecto siga siendo pequeño. Una vez sea parte de la cultura general, no será necesario ser la única persona promocionando esto. Será mantenido por todos. Practicad revisiones visibles del código Una de las mejores formas de fomentar una comunidad productiva de desarrollo es hacer que cada uno pueda ver el código de los demás. Una infraestructura técnica es necesaria para hacer esto efectivamente—en particular, se deben activar los correos con los avisos de cambios; más detalles en . El efecto de los correos electrónicos con los cambios es que cada vez que se envíe un cambio al código fuente, un correo es enviado mostrando un registro y las diferencias de los cambios (mirad en ). La revisión del código es la práctica de revisar los correos con cambios mientras van llegando, buscando fallos y posibles mejoras. Comunmente es así como las revisiones del código se hacen en los proyectos open source, por lo menos. En proyectos más centralizados, la revisión del código puede significar que muchas personas se sienten juntas y lean impresiones del código fuente, buscando por problemas y patrones específicos. Revisar el código sirve varios propósitos simultáneamente. Es el ejemplo más obvio de revisión en nodos en el mundo del open source y directamente ayuda a mantener la calidad del programa. Cada fallo que se envía junto a un programa llego allí después de ser comprometido y no haber sido detectado; es por esto que mientras más ojos estén revisando los cambios, menos fallos serán empaquetados. Pero indirectamente, las revisiones tienen también otro propósito: confirmar a las personas que lo que hacen importa, porque obviamente nadie se tomaría el tiempo de revisar un cambio a menos que le importara su efecto. La gente realiza una mejor labor cuando saben que otros van a tomarse el tiempo de evaluarla. En el proyecto Subversion, no hicimos de la revisión del código una práctica regular. No existía ninguna garantía de que después de cada commit éste sería revisado, aunque a veces alguien se interesa en un cambio que se realiza sobre una parte del código en el que se tiene particular interés. Fallos que deberían y podrían haber sido detectados, se colarón. Un desarrollador llamado Greg Stein, quien sabia la importancia de las revisiones del código de trabajos anteriores, decidió que iba a ser él quien diera el ejemplo revisando cada línea de uno y cada uno de los commits que hayan llegado al repositorio. Cada vez que alguien envía un cambio era seguido de un correo electrónico de Greg a las lista de los desarrolladores, diseccionándolos, analizando posibles problemas y ocasionalmente elogiando ingeniosas piezas de código. De ésta manera, estaba atrapando fallos y prácticas poco óptimas de programación que de otra manera habrían pasado desapercibidas. Deliberadamente, nunca se quejó de ser la única persona revisando cada commit, a pesar de que esto le tomaba una gran cantidad de tiempo, pero siempre alababa las revisiones de código cada vez que tenía oportunidad. Muy pronto, otros, yo incluso, empezamos a revisar los cambios regularmente también. ¿Cuál era nuestra motivación? No había sido porque Greg conscientemente nos avergonzó hacia esto. Nos había probado que revisar el código era una manera muy valiosa de utilizar nuestro tiempo y que se podía contribuir tanto al proyecto revisando los cambios de otros como escribiendo código nuevo. Una vez demostrado esto, se volvió una conducta anticipada, hasta el punto en el que cada commit que no generaba alguna reacción hacía que quien la realizaba se preocupara e incluso que preguntase a la lista si alguien había tenido la oportunidad de revisarlo aun. Luego, Greg consiguió un trabajo que no le dejaba mucho tiempo libre para Subversion y tuvo que dejar de hacer revisiones regulares. Pero llegados a éste punto, el habito se había integrado en el resto de nosotros tanto, que parecía como algo que se hacía desde tiempos inmemoriables. Hay que empezar a realizar las revisiones desde el primer commit. El tipo de problemas que son más fáciles de descubrir con sólo revisar las diferencias son las vulnerabilidades de seguridad, desbordamientos de memoria, comentarios insuficientes o documentación del API, errores off-by-one, emparejamientos mal hechos y otros problemas que requieren de un mínimo de contexto para encontrar. Aunque incluso problemas a larga escala como el fallar en abstraer patrones repetitivos a un sólo sitio sólo se pueden descubrir después de llevar mucho tiempo realizando revisiones regularmente, porque el recuerdo de diferencias anteriores ayuda a revisar las diferencias presentes. No hay que preocuparse al no poder encontrar nada sobre lo que comentar o de saber lo suficiente acerca de todas las áreas del código. Usualmente habrá algo que decir sobre casi todos los cambios; incluso donde no hay nada que criticar, se puede encontrar algo que elogiar. Lo importante es dejar claro a cada programador, que lo que hacen se ve y es entendido. Por supuesto, el revisar código no absuelve a los desarrolladores de la responsabilidad de revisar y probar su código antes de enviar los cambios; nadie debe depender en las revisiones para encontrar cosas que debería haber encontrado. Al abrir un proyecto cerrado, hay que ser sensible acerca de la magnitud de los cambios Si se reabre un proyecto existente, uno que ya tiene desarrolladores activos acostumbrados a trabajar en un ambiente de código cerrado, habrá que asegurarse de que todos entienden que grandes cambios se avecinan—y asegurarte de que entiendes como se siente desde su punto de vista. Intenta imaginar como la situación se presenta ante ellos: antes, todas las decisiones sobre el código y diseño eran hechas con un grupo de programadores quienes conocían el software más o menos al mismo nivel, quienes compartían la misma presión de los mismos directores y quienes conocían entre todos sus fuerzas y debilidades. Ahora se les pide que expongan su código al escrutinio de extraños al azar, quienes formarán un juicio basado sólo en el código, sin la conciencia de las presiones bajo las cuales se tomaron ciertas decisiones. Estos forasteros harán muchas preguntas, preguntas que harán que los desarrolladores existentes se den cuenta que la documentación en la que se han esclavizado tan duramente sigue siendo inadecuada (esto es inevitable). Para cerrar con broche de oro, todos estos forasteros son entidades desconocidas y sin cara. Si alguno de los desarrolladores ya se siente de por si inseguro sobre sus habilidades, imaginemos como éste sentimiento es exacerbado cuando recién llegados empiezan a señalar fallos en el código que han escrito, y aun peor, frente a sus colegas. A menos que se tenga un equipo con programadores perfectos, esto es inevitable—de hecho, puede que le suceda a todos ellos al principio. Esto no es porque sean malos programadores; es solo que todo programa de cierto tamaño tiene fallos y una revisión distribuida descubrirá algunos de estos fallos ( Id a anteriormente en éste capítulo). En algún momento, los recién llegados no serán sujetos a muchas revisiones al principio, ya que no pueden contribuir con código hasta que estén más familiarizados con el proyecto. Para tus desarrolladores, podrá parecer que todas las críticas van hacia ellos y no por su parte. Por esto, existe el peligro de que los viejos programadores se sientan asediados. La mejor manera de prevenir esto, es advertir a todos acerca de lo que se avecina, explicarlo, decirles que el desconcierto inicial es perfectamente normal y asegurar que todo va a mejorar. Algunas de estas advertencias deberán hacerse en privado, antes de que el proyecto se haga público. Pero también puede llegar a ser útil recordarle a la gente de las listas publicas que ésta es una nueva dirección en el desarrollo del proyecto y que tomará algo de tiempo adaptarse. Lo mejor que se puede hacer es enseñar con el ejemplo. Si no ves a tus desarrolladores respondiendo suficiente preguntas a los nuevos, decirles que deben responder más preguntas no será de gran ayuda. Quizás no tengan aún una noción acerca de que requiere una respuesta y de que no, o puede que no sepan como dar diferentes prioridades a escribir código y las nuevas tareas de comunicación exterior. La manera de hacerlos participantes es hacerlo uno mismo. Hay que estar en las listas publicas y responder algunas preguntas. Cuando no se tenga la experiencia necesaria en una materia para responder a una pregunta entonces transfierela visiblemente a un desarrollador quien pueda responderla—y vigila para asegurarte de que continua con una respuesta. Naturalmente será tentador para los desarrolladores más antiguos enfrascarse en discusiones privadas ya que a esto es a lo que están acostumbrados. Asegurate de suscribirte a las listas internas en las cuales estas discusiones puedan dar lugar, de manera que puedas pedir que la discusión se continúe en las listas publicas inmediatamente. Existen otros asuntos a largo plazo con abrir un proyecto cerrado. explora técnicas para mezclar exitosamente desarrolladores asalariados y voluntarios y en se discute la necesidad de ser diligente al abrir una base de código que puede contener programas que han sido escritos o que pertenecen a otras personas. Anunciar Una vez que el proyecto está presentable—no perfecto, sólo presentable—se está listo para anunciarlo al mundo. Esto es un proceso bastante sencillo: id a , pulsamos en Submit en la barra de navegación superior y rellenad el formulario anunciando el nuevo proyecto. Freshmeat es el sitio que todos miran a la espera de anuncios sobre nuevos proyectos. Sólo hace falta atrapar unas cuantas miradas allí para que noticias sobre el proyecto sean esparcidas de boca en boca. Si se conocen listas de correos o grupos de noticias donde el anuncio del proyecto sea un tema de interés, entonces publicalo allí, pero hay que tener cuidado en publicar sólo una vez en cada foro y dirigir a las personas a los foros del proyecto para más discusiones (configurando la cabecera Reply-to). Los comentarios en los foros deben ser cortos y directos al grano: To: discuss@lists.example.org Subject: [ANN] Scanley full-text indexer project Reply-to: dev@scanley.org Este es un sólo mensaje para anunciar la creación del proyecto Scanley, un indexador y buscador de texto open source con un extenso API para el uso de programadores quienes desean crear servicios de búsqueda en grandes colecciones de ficheros de texto. Scanley ejecuta, está siendo desarrollado activamente y buscamos nuevos desarrolladores y testers. Sitio Web: http://www.scanley.org/ Características: - Busca texto plano, HTML y XML - Búsqueda de palabras o frases - (planeado) Búsquedas borrosas - (planeado) Actualización incremental de los índices - (planeado) Indexación de sitios web remotos Requerimientos: - Python 2.2 o mayor - Suficiente espacio en disco para contener los índices (aproximadamente dos veces el tamaño ocupado en disco) Para más información, visitad scanley.org Gracias -J. Random (Más información en para consejos sobre como anunciar lanzamientos posteriores u otros eventos.) Existe un debate en el mundo del software libre sobre si es necesario empezar con código funcional o si el proyecto puede empezar a beneficiarse aun cuando está en la fase de diseño y discusión. Solía pensar que empezar con código funcional era el factor más importante, que esto es lo que separaba proyectos exitosos de los juguetes y que solo desarrolladores serios se verían atraídos que hacia algo concreto ya. Esto resulto no ser del todo cierto. En el proyecto Subversion, empezamos con un documento de diseño, un núcleo de desarrolladores interesados e interconectados, mucha fanfarria y nada de código funcional. Para mi completa sorpresa, el proyecto recibió participantes activos desde el principio y para el momento en que teníamos algo funcional ya habían unos cuantos desarrolladores voluntarios involucrados profundamente. Subversion no es el único ejemplo; el proyecto Mozilla también fue iniciado sin código funcional y ahora es un navegador exitoso y popular. En vista de ésta evidencia debo retirar mi afirmación sobre que es necesario tener código funcional para lanzar un proyecto. EL código funcional sigue siendo la mejor base para el éxito y una buena regla del pulgar sería esperar a tener el código antes de anunciar el proyecto. Por otra parte, pueden haber circunstancias cuando un anuncio temprano puede tener sentido. Si creo que al menos un documento de diseño bien desarrollado o algún otro tipo de marco de trabajo, es necesario— claro que puede ser modificado en base a las respuestas publicas, pero debe haber algo tangible, en el que las personas puedan hincar sus dientes. Cuando sea que se anuncie un proyecto, no hay que esperar una horda de voluntarios listos para unirse inmediatamente. Usualmente, el resultado de anunciar es que se obtiene algunas preguntas casuales, algunas otras personas se unen a la lista de correos y aparte de esto, todo continua como antes. Pero con el tiempo, podréis notar un incremento gradual en la participación tanto de usuarios como de nuevo código de voluntarios. Anunciar es solo plantar una semilla, puede tomar un largo tiempo para que la noticia se extienda. Si el proyecto recompensa constantemente a quienes se involucran, las noticias se extenderán, pues la gente desea compartir algo cuando han encontrado algo bueno. Si todo va bien, la dinámica de las redes exponenciales de comunicación lentamente transformaran el proyecto en una compleja comunidad donde no se conoce el nombre de todos y no se puede seguir cada una de las conversaciones. Los próximos capítulos son acerca de como trabajar en éste ambiente.