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 catb.org/~esr/writings/cathedral-bazaar/
)
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 de software libre 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, de gobierno, sin fines de lucro, etc—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, usualmente porque ellos
mismos lo utilizan o trabajan directamente con personas que lo usan. 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 software libre desarrollado por la Fundación Kuali (kuali.org), utilizado por
instituciones educativas para manejar sus finanzas, becas de
investigación, sistemas de recursos humanos, información de estudiantes, etc,
poco de esto puede ser considerado como un
problema personal de un programador. En particular éste problema
surge directamente de la experiencia de las instituciones interesada, por lo cual si el proyecto
falla en satisfacerlos, 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 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 los diseños
que los desarrolladores hacen por su cuenta.
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 directamente en: github.com, ohloh.net, freecode.com, code.google.com, sourceforge.net, y en el
directorio de software libre de la Free Software Foundation en directory.fsf.org.
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 otros 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
Colócate 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 de recordar para alguien que sepa leer en ingles."
Los nombres que son juegos de palabras dependientes
de la pronunciación en ingles nativo, por ejemplo, serán opacos
para muchos lectores no nativos en ingles. Si el juego de palabras
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.
Para los Estados Unidos, podemos encontrar buscadores gratuitos
de marcas registradas en uspto.gov.
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.
Si es posible, está disponible como un nombre de
usuario en Twitter
y otros sitios de microblog. Ver
para más información sobre esta y su relación con el nombre de
dominio.
Poseer el nombre en los espacios de nombre importantes
Para los proyectos grandes, es una buena idea de poseer el
nombre del proyecto en tantos espacios de nombre relevantes en
Internet como puedas. Por espacios de nombres, me refiero no sólo al
sistema de nombres de dominio, sino también a los servicios en línea
en el que los nombres de la cuenta (nombres de usuario) son los
manejadores visibles públicamente por el cual la gente se refiere al
proyecto. Si tienes el mismo nombre en todos los lugares donde la
gente te buscaría, haces fácil para las personas a mantener un leve
interés en el proyecto hasta que estén listos para involucrarse
más.
Por ejemplo, el proyecto de escritorio Gnome tiene el nombre de
dominio gnome.org
Ellos no lograron obtener gnome.com o gnome.net, pero eso está
bien — si sólo tienes uno, y es .org, está bien. Ese
es por lo general el primero que la gente busca cuando está buscando
un proyecto de código abierto con ese nombre. Si no podían conseguir
"gnome.org" en sí, una solución típica sería la de obtener
"gnomeproject.org" en su lugar, y muchos proyectos resuelven el
problema de esa manera., el identificador de Twitter
@gnome, el nombre de
usuario gnome en
Identi.caIdenti.ca es un microblog / red
social que un número de desarrolladores de software libre usa; su
código es de fuente abierta y está disponible en pump.io. Para los proyectos orientados a
desarrolladores, recomiendo al menos hacer todas las micro
actualizaciones de estado — coloquialmente conocidas
como "tweets" — tanto en Identi.ca como en Twitter.
Mientras que el número total de personas en Identi.ca es mucho menor
que en Twitter, el porcentaje de ellos que son susceptibles de estar
interesados en las noticias acerca de un proyecto de código abierto
es mucho más alto, por lo menos a partir de este escrito en el año
2013 y durante algunos años anteriores a este., el
nombre de usuario gnome
en GitHub.comMientras que la copia maestra del
código fuente de Gnome está en git.gnome.org, ellos mantienen un
espejo en GitHub, ya que muchos desarrolladores ya están
familiarizados con GitHub, y en la red freenode IRC
(ver ) tienen el canal #gnome,
aunque también mantienen sus propios servidores de IRC (donde, por
supuesto, controlan el espacio de nombres de canal de todos
modos).
Todo esto hace al proyecto Gnome espléndidamente fácil de
encontrar: por lo general está justo donde un contribuyente potencial
esperaría que estuviera. Por supuesto, Gnome es un proyecto grande y
complejo con miles de colaboradores y muchas subdivisiones; la ventaja
para Gnome de sea fácil de encontrar es mayor de lo que sería para un
proyecto nuevo, ya que por ahora hay muchas maneras de participar en
Gnome. Pero, sin duda, nunca dañará tu proyecto
el poseer su nombre en la mayor cantidad de espacios de nombres
relevantes como se pueda, y esto a veces puede ayudar. Así que cuando
inicies un proyecto, piensa en cual debería ser su identificador en
línea y registra ese identificador con los servicios de red que
pienses que probablemente te interesan. Los mencionados anteriormente
son probablemente una buena lista inicial, pero tu podrías conocer de
otros que sean relevantes para el tema particular de tu
proyecto.
Tener los objetivos claros
Una vez que se ha encontrado el sitio del proyecto, lo siguiente
que la gente hace es buscar una descripción rápida o 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 descripción de los objetivos debe ser concreta, limitada y
sobre todo, corta. Aquí tenemos un buen ejemplo, de hadoop.apache.org:
El proyecto Hadoop® de Apache™ desarrolla software
de código abierto para una computación distribuida confiable y
escalable.
La biblioteca de software Apache Hadoop es un framework
que permite el procesamiento distribuido de grandes conjuntos de datos
a través de grupos de ordenadores que utilizan modelos de programación
simples. Está diseñado para escalar de servidores individuales a miles
de máquinas, cada uno ofreciendo computación y almacenamiento local. En
lugar de confiar en el hardware para ofrecer alta disponibilidad, la
biblioteca en sí está diseñado para detectar y controlar los errores en
la capa de aplicación, de esa manera entregar un servicio de alta
disponibilidad en la parte superior de un grupo de computadoras, cada
una de las cuales puede ser propensa a fallas.
En pocas palabras, han logrado la máxima puntuación, en gran
parte recurriendo a los conocimientos previos del lector. Ese es un
punto importante: que está bien asumir un lector mínimamente informado
con un nivel básico de preparación. Un lector que no sabe lo que
significa "grupos de computadora" y "alta disponibilidad" en este
contexto probablemente no puede hacer mucho uso de Hadoop de todos
modos, así que no hay razon de escribir para un lector que sabe menos
que eso. La frase "diseñado para detectar y controlar los errores en
la capa de aplicación" destacará ante los ingenieros que tienen
experiencia con la informática a gran escala de grupos—cuando
vean esas palabras, sabrán que la gente detrás de Hadoop entiende ese
mundo, y en consecuencia, estarán más dispuestos a tomar en cuanta a
Hadoop.
Declara Que el Proyecto es Libre
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 y buscar adentr un archivo de licencia.
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.
Hay un par vías de diferentes para dar respuestas a estas preguntas,
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 esa
definición. Algunos proyectos estructuran su página de estado de
desarrollo como una hoja de ruta que incluye el futuro: los
acontecimientos pasados se muestran en las fechas en que realmente
sucedieron, los futuros sobre las fechas aproximadas en que el
proyecto espera que vayan a pasar.
La otra manera — no mutuamente exclusiva con
la primera, y de hecho, probablemente mejor realizarla en combinación
con ella — es tener varios contadores e indicadores
mantenidos de forma automática incrustados en la portada y/o la página
destinada a desarrolladores del proyecto, que muestre varias piezas de
información que, en conjunto, den una sensación del estado de
desarrollo del proyecto y el progreso. Por ejemplo, un anuncio o grupo
de noticias que muestran las noticias recientes, una cuenta de Twitter
o de otro microblog mostrando avisos que coincidan con hashtags
designados para el proyecto, una línea de tiempo de los últimos
lanzamientos, un panel que muestra la actividad reciente en el gestor
de fallos (fallos registrados, fallos respondidos), otro que muestre
la actividad de la lista de correo o foro de discusión, etc. Cada uno
de estos indicadores debería ser una puerta de entrada a más
información de este tipo: por ejemplo, al hacer clic en el panel
"fallos recientes" debe llevar al gestor de fallos completo, o por lo
menos a una vista panorámica a la actividad de seguimiento de
errores.
En realidad, hay dos significados ligeramente diferentes de
"estado del desarrollo" que se confunden aquí. Uno de ellos es el
sentido formal: ¿dónde se sitúa el proyecto en relación con sus
objetivos declarados, y qué tan rápido está progresando. El otro es
menos formal pero igual de útil: qué tan activo es este proyecto?
¿Hay personas aquí, están haciendo cosas?, A menudo, esta última
noción es en lo que un visitante está más interesado. Ya sea que un
proyecto cumplia su último hito o no a veces no es tan interesante
como la cuestión más fundamental de si tiene una comunidad activa
de desarrolladores alrededor.
Las dos nociones de estado de desarrollo están, por supuesto,
relacionadas, y un proyecto bien presentado muestra los dos tipos. La
información se puede dividir entre la portada del proyecto (mostrar
suficiente allí para dar una visión general de los dos tipos de estado
de desarrollo) y una página más orientado al desarrollador.
Ejemplo: Indicadores de estado de Launchpad
Un sitio que hace un muy buen trabajo de mostrar indicadores de
estado orientado al desarrollador es Launchpad.net. Launchpad.net es
un poco inusual, ya que es a la vez una plataforma de alojamiento
principal para algunos proyectos, y en segundo lugar, un sitio
orientado al empaquetado para los demás (o más bien, para los demás,
es el sitio primario para el "proyecto" de conseguir que el programa
en particular sea empaquetado para el sistema operativo Ubuntu
GNU/Linux, al cual Launchpad fue diseñado para apoyar específicamente).
En cualquier caso, la página de destino de un proyecto en Launchpad
muestra una variedad de indicadores de estado mantenidos de forma
automática para dar rápidamente una idea de donde se encuentra el
proyecto. Aunque simplemente imitar una página de Launchpad no es
probablemente una buena dea — su propio proyecto debe
pensar cuidadosamente acerca de cuales son sus mejores indicadores del
estado de desarrollo son — las páginas del proyecto de
Launchpad proporcionan buenos ejemplos de las posibilidades. Empiece
desde la parte superior de una página del proyecto allí y desplácese
hacia abajo: launchpad.net/drizzle
o launchpad.net/inkscape,
por escoger dos al azar.
El estado del desarrollo debe reflejar siempre la realidad.
No hay que asustarse por parecer no estar preparado y nunca 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, si tan sólo pudieran construir y probarlo. 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, dale un número de versión único,
de manera que la gente pueda comparar dos versiones cualquiera diferentes y saber cual reemplaza a cual.
De esa manera pueden informar de los errores en contra de un lanzamiento
en particular (que ayuda a los que responden a averiguar si el error ya
está solucionado o no). 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 una manera de enviar cambios basados en esas fuentes.
La solución es utilizar un sistema de control de
versiones — en concreto, una repositorio controlado
por versiones, en línea, de acceso público, del que cualquiera
puede echar un vistazo al proyecto y, posteriormente, obtener
actualizaciones. Un repositorio de control de versiones es una señal
— para usuarios y desarrolladores — de
que este proyecto está haciendo un esfuerzo para dar a la gente lo que
necesitan para participar. Al escribir estas líneas, muchos proyectos
de código abierto usan GitHub.com, que ofrece alojamiento
ilimitado y gratuito de control de versiones públicas para proyectos de
código abierto. Mientras GitHub no es la única opción, ni siquiera la
única buena elección, es bastante razonable para la mayoría de los
proyectosAunque GitHub se basa en Git, un sistema de
control de versiones de código abierto muy popular, el código que
ejecuta los servicios web de GitHub no es en sí mismo fuente abierta.
Si esto es importante para su proyecto es una cuestión compleja, y
se aborda con mayor profundidad en en .
La infraestructura del control de versiones se discute detalladamente
en en .
Lo mismo ocurre con rastreador de errores del proyecto. La
importancia de un sistema de seguimiento de fallos no sólo radica en su
utilidad en el día a día para los desarrolladores, sino en lo que
significa para los observadores del proyecto. Para muchas personas, una
base de datos de errores accesible es uno de los signos más fuertes de
que un proyecto se debe tomar en serio: cuanto mayor sea el número de
errores en la base de datos, mejor se ve el
proyecto. Esto puede parecer contrario a la intuición, pero recuerde
que el número de informes de fallos archivados en realidad depende de
tres cosas: el número absoluto de defectos de software reales presentes
en el código, el número de personas que utilizan el software, y la
comodidad con la que las personas pueden denunciar nuevos errores. De
estos tres factores, los dos últimos son mucho más importante que el
primero. Cualquier software de suficiente tamaño y complejidad tiene
un número esencialmente arbitrario de fallos esperando a ser
descubiertos. La verdadera pregunta es, ¿qué tan bien va a hacer el
proyecto el registro y la priorización de esos fallos? Un proyecto con
una base de datos de errores grandes y bien cuidada (que significa que
los fallos sean atendidas sin demora, los errores duplicados están
unificados, etc.), produce por lo tanto una mejor impresión que un
proyecto con ninguna base de datos de errores, o de una base de datos
casi 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 de estado destaca la juventud del proyecto, y si la
gente que busca en la base de datos de errores puede ver que la mayoría
de los documentos presentados han tenido lugar recientemente, pueden
extrapolar a partir de ahí que el proyecto sigue teniendo una
tasa saludable de incidencias, y no van a alarmarse
indebidamente por el bajo número absoluto de errores
registrados.Para una discusión más a fondo de que los
informes de fallos deben ser tratados como una buena noticia, consulte en
rants.org/2010/01/10/bugs-users-and-tech-debt,
un artículo que escribí en 2010 sobre cómo los informes de error no
no representan una "deuda técnica"
sino más bien participación de los usuarios.
Hay que señalar que los bug trackers no sólo son usados para fallos en los programas sino 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, probablemente solo una fraccción de los usuarios se unan
a los foros de todas maneras, pero los demás 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
finalmente cómo 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 y cómo se toman las decisiones—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.
(Ver en el
para conocer por qué la dictadura en proyectos de código abierto
no tiene las mismas implicaciones que dictadura en otras áreas de
la vida.)
subversion.apache.org/docs/community-guide
es un ejemplo de pautas de desarrollo particularmente exhaustivas;
las directrices de LibreOffice en wiki.documentfoundation.org/Development son también un
buen ejemplo.
Proveer a los programadores una introducción a la aplicación 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, y lo más importante,
incorporar los comentarios de los lectores
nuevo tipo y probar la calidad. Hay que utilizar un formato simple y
fácil de modificar como HTML, texto plano, Markdown, ReStructuredText, o alguna variante de
XML—algo que sea conveniente para mejoras rápidas, ligeras e
imprevisibles para el momentoNo te preocupes demasiado
por elegir el formato correcto la primera vez. Si cambias de opinión más
tarde, siempre se puede hacer una conversión automatizada usando Pandoc..
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
a las preguntas que la gente hace. Ya que es imposible anticipar
correctamente esas preguntas, 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 con sólo
algunas preguntas y respuestas, 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: Ver en el
,
en el
, y 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 subversion.apache.org/docs/community-guide)
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 .
Demos, Capturas de Pantalla, Videos y Ejemplos de Salidas
Si el proyecto incluye una interfaz gráfica de usuario, o si
produce una salida gráfica o alguna salida peculiar, coloca algunas
muestras en el sitio web del proyecto. En el caso de la interfaz, esto
significa capturas o, mejor aún, un breve video (de 4 minutos o menos)
con subtítulos o un narrador. Para la salida, podría ser capturas de
pantalla o sólo archivos de ejemplo para descargar. Para el software
basado en web, el patrón de oro es un sitio de demostración, por
supuesto, asumiendo que el software se presta para eso.
Lo principal es atender el deseo de gratificación que tiene la
gente de la manera más probable que ellos puedan esperar. Una sola
pantalla o video pueden ser más convincente que párrafos de texto
descriptivo y charlas en listas de correo, ya que es una prueba de
que el software funciona. El código todavía puede
tener errores, puede ser difícil de instalar, puede estar documentado de
forma incompleta, pero la evidencia basada en la imagen muestra a la
gente que si uno pone en el esfuerzo suficiente, se puede conseguir que
se ejecute.
Mantén Breves los Videos y <emphasis>Di</emphasis> Son Breves
Si tienes un video de demostración de tu proyecto, mantén el
video de 4 minutos de duración, y asegurate de que la gente pueda ver
la duración antes de que haga clic en él. Esto
va de acuerdo con el "principio de la presentación a escala"
mencionada anteriormente: tienes que hacer que tomar la decisión de
ver el video sea fácil, eliminando todos los riesgos. Los visitantes
son más propensos a hacer clic en un enlace que dice "Mira nuestro
video de 3 minutos" que en uno que sólo dice "Mira nuestro video",
porque en el primer caso saben en lo que se están metiendo antes de
hacer clic — y van a verlo mejor, porque han
preparado mentalmente de antemano la cantidad necesaria de
compromiso, por lo que no se cansan a mitad de camino.
En relación a el límite de cuatro minutos y de donde viene: es
un hecho científico, determinado a través de muchos intentos por parte
del mismo sujeto experimental (que permanecerá sin nombre) para ver
videos de proyectos. Este límite no se aplica a tutoriales u otros
materiales de instrucción, por supuesto; es sólo para los vídeos
introductorios.
En caso de que no tengas un software preferido para la grabación
de vídeos de interacción de escritorio: He tenido buena suerte
con gtk-recordmydesktop en Debian GNU/Linux, y
luego el editor de videos OpenShot para la edición
posterior a la captura.
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
¿Dónde en Internet hay que poner los materiales del proyecto?
Un sitio web, obviamente — pero la respuesta
completa es un poco más complicada que esa.
Muchos proyectos distinguen entre su sitio web público primario de
cara al usuario — el que tiene las fotos bonitas y la
página "Acerca de..." y las presentaciones suaves y videos y visitas
guiadas y todo eso — y sus sitio para desarrolladores,
donde todo está sucio y lleno de texto estrechamente espaciado en fuentes
de espacio sencillo y abreviaturas impenetrables.
Bueno, estoy exagerando. Un poco. En cualquier caso, en las
primeras etapas de tu proyecto, no es tan importante distinguir entre
estos dos tipos de público. La mayoría de los visitantes interesados
que consigues son los desarrolladores, o por lo menos la gente que se
sienten cómodos probando nuevo código. Con el tiempo, puede que tenga
sentido tener un sitio de cara a los usuarios (por supuesto, si tu
proyecto es una biblioteca de código, los "usuarios" podrían ser otros
programadores) y un área de colaboración algo distinto para los
interesados en participar en el desarrollo. El sitio de colaboración
tendría el repositorio de código, gestor de fallos, wiki desarrollo,
enlaces a listas de correo de desarrollo, etc. Los dos sitios deben
unirse entre sí, y, en particular, es importante que el sitio
orientado al usuario deje en claro que el proyecto es código abierto
y dónde se puede encontrar la actividad de desarrollo de ese código
abiertoA partir de agosto de 2013, un buen ejemplo
de un proyecto con los sitios primarios y de desarrolladores
independientes pero bien vinculados es el Ozone Widget Framework:
comparar su sitio principal orientado al usuario en ozoneplatform.org, con su
área de desarrollo en github.com/ozoneplatform/spf.
En el pasado, muchos proyectos crearon su sitio de
desarrolladores y la infraestructura por sí mismos. Durante la última
década, sin embargo, la mayoría de los proyectos de código
abierto — y casi todos los nuevos — sólo
tienen que utilizar uno de los sitios de "alojamiento enlatado" que han
surgido para ofrecer estos servicios de forma gratuita a proyectos de
código abierto. Con mucho, el más popular de estos sitios, mientras
escribo esto, a mediados de 2013, es GitHub.com, y si usted no tiene una fuerte preferencia sobre
dónde alojar, probablemente debería simplemente elegir GitHub; muchos
desarrolladores ya están familiarizados con él y tienen cuentas
personales allí.
en tiene una discusión
más detallada de las cuestiones a considerar al elegir un sitio de
alojamiento enlatado, y un resumen de los más populares.
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 otro software.
Sinónimos: "licencia de software libre", "aprobadas por la
FSF", "licencia de fuente abierta", y "aprobadas por la OSI"
Los términos "licencia de software libre" y "licencia de
fuente abierta" son esencialmente sinónimos, y los trato así a lo
largo de este libro.
Técnicamente, el primer término se refiere a las licencias
confirmadas por la Free Software Foundation como las que ofrecen las
"cuatro libertades" necesarias para el software libre (vea gnu.org/philosophy/free-sw.html), mientras que el segundo
término se refiere a las licencias aprobadas por el Open Source
Initiative como las que cumplen la Definición de Open Source (opensource.org/osd). Sin
embargo, si usted lee la definición de la FSF de software libre, y
la definición de la OSI del software de código abierto, se hace
evidente que las dos definiciones delinean las mismas
libertades — no es sorprendente, como lo
explica
en el . El resultado inevitable,
y en cierto sentido deliberado, es que las dos organizaciones han
aprobado el mismo conjunto de licencias.En realidad,
hay algunas diferencias menores entre los grupos de las licencias
aprobadas, pero no son significativos para nuestros
propósitos — o de hecho, a efectos prácticos. En
algunos casos, una u otra organización simplemente no ha llegado a
considerar una licencia determinada, por lo general una licencia que
que no se utiliza ampliamente de todos modos. Y al parecer
(eso me han dicho) hubo históricamente una licencia que, al menos,
una de las organizaciones, y posiblemente ambas, acordó que encajaba
una definición pero no la otra. Siempre que trato de obtener los
detalles sobre esto, sin embargo, me parece que obtengo una
respuesta diferente en cuanto a cuál era esa licencia, salvo que la
licencia mencionada es siempre una que no tenía mucha gente
utilizandola de todos modos. Así que hoy, para cualquier licencia
que probablemente sea utilizada, los términos "aprobada por OSI" y
"aprobada por la FSF" pueden ser tratados como que una implica la
otra.
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"
29 August 2013: If you're reading this note, then
you've encountered this subsection while it's undergoing substantial
revision; see producingoss.com/v2.html for details. TODO: is
MIT or BSD still really the best default, given the modern patent
landscape? Would Apache-2.0 be better — but then what
about the FSF's claim of GPL-incompatibility? Need to get some advice
here.
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.
La GPL
Si no desea que el código sea utilizado en aplicaciones propietarias
utilice la Licencia Pública General o GPL, versión 3 (gnu.org/licenses/gpl.html). La GPL es
probablemente la licencia para software libre más reconocida 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 .
Si los usuarios interactúan con tu código, principalmente a
través de una red—es decir, el software es generalmente parte de
un servicio alojado, en lugar de ser distribuido como binario, entonces
considera el uso de la GNU Affero GPL en su lugar.
La AGPL es sólo la GPL con una cláusula adicional en la que se establece
la accesibilidad en la red como una forma de distribución a los efectos
de la licencia. Ver en el para más
información.
Cómo aplicar una licencia a nuestro software
Una vez que hayas elegido una licencia, tendrás que aplicarla
al software.
Lo primero que debes hacer es presentar la licencia claramente
en la primera página del proyecto. No es necesario incluir el texto
real de la licencia allí; sólo dar su nombre y hacer que enlace con el
texto de la licencia completa en otra página. Eso le dice al público
bajo cuál licencia pretende distribuirse el
software—pero esto no es suficiente para los efectos legales. El
otro paso es que el propio software debe incluir la licencia.
La manera estándar de hacer esto es poner el texto de la licencia
completa en un archivo llamado COPYING (o
LICENSE) incluido con el código fuente, y luego
poner un pequeño anuncio en un comentario en la parte superior de cada
archivo fuente, mencionando la fecha de copyright, titular, y la licencia,
y diciendo dónde encontrar el texto completo de la licencia.
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 3 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, see <http://www.gnu.org/licenses/>
No dice específicamente que la copia de la licencia que recibió
junto con el programa se encuentra en el archivo
COPYING, o LICENSE, pero ahí
es donde se suele poner. (Puede cambiar el aviso anterior para
indicarlo directamente, pero no hay necesidad real de hacerlo)
En general, el aviso que se coloca en cada archivo fuente no tiene
que ser exactamente como la de arriba, siempre que se inice con el mismo
aviso de titular del copyright y fechaLa fecha debe
mostrar la fecha en que el archivo se modificó, para los propósitos de
derechos de autor. En otras palabras, para un archivo modificado en 2008,
2009 y 2013, podrías escribir "2008, 2009, 2013" —
no "2008-2013", ya que el archivo no ha sido
modificado en la mayoría de los años en ese rango.,
indicar el nombre de la licencia, y dejar claro donde ver los términos
completos de la licencia. Siempre es mejor consultar a un abogado, por
supuesto, si es posible costear uno.
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. Por ejemplo, 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.
A continuación hay son algunos ejemplos de cosas que puedes hacer
para establecer buenos precedentes. No están pensados como una lista
exhaustiva, sólo como ilustraciones de la idea de que establecer un
temprano estado de ánimo de colaboración ayuda a un proyecto
tremendamente. Físicamente, cada desarrollador puede trabajar solo en
una habitación por sí mismo, pero se puede hacer mucho para que ellos
se sientan como que están todos trabajando juntos
en la misma habitación. Cuanto más se sientan de esta manera, más tiempo
querrán invertir en el proyecto. Elegí estos ejemplos particulares,
porque surgieron en el proyecto Subversion (subversion.apache.org),
en el cual he participado y he observado desde su inicio. Pero no son
exclusivos de Subversion; situaciones como estas se van a plantear en la
mayoría de los proyectos de código abierto, y debe ser visto como una
oportunidad para empezar las cosas con el pie derecho.
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 contribuidor 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
él fue enfático acerca de 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 contigo, 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.
Cortar de Raíz 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,
aparte del 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.
Practicar 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 — idealmente, para conseguir que se
observen los cambios de código de cada uno
mientras llegan. La revisión de commits
(algunas veces llamada simplemente la revisión de
código) es la práctica de la revisar los cambios a
medida que entran, en busca de errores y posibles mejoras.
Hay un par de razones para centrarse en la revisión de cambios,
en lugar de revisar el código que ha estado alrededor por un tiempo.
En primer lugar, simplemente funciona mejor socialmente: cuando alguien
revisa tu cambio, está interactuando con el trabajo que has hecho
recientemente. Esto significa que si comenta de inmediato, estarás
máximamente interesados en escuchar lo que tiene que decir; seis meses
más tarde, podrías no sentirte tan motivado a participar, y en todo
caso puede ser que no recuerdes el cambio muy bien. En segundo lugar,
mirar lo que cambia en un código base es una puerta a mirar el resto del
código — la revisión de un cambios a menudo hace que uno
mire el código de alrededor, los llamados y receptores afectados en
otros lugares, las interfaces de modulos relacionadas,
etc.Nada de esto es un argumento en contra de las
revisiones de código top-to-bottom (De arriba hacia abajo), por supuesto,
por ejemplo, para hacer una auditoría de seguridad. Pero si bien ese
tipo de revisión es importante también, es más bien una buena
práctica genérica, y no es tan relevante específicamente con respecto
a la ejecución de un proyecto de código abierto como lo es la revisión
cambio por cambio.
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.
Las revisiones deben ser públicas. Incluso en las ocasiones en
que he estado sentado en el mismo espacio físico con otro
desarrollador, y uno de nosotros ha hecho un commit, nosotros nos
encargamos de no hacer la revisión verbalmente en la habitación, en
vez de eso la enviamos al foro de opinión en línea adecuado.
Todos se benefician de ver como sucede la revisión. La gente sigue
el comentario y a veces encuentra fallas en el; aun cuando no lo
hacen, todavía les recuerda que la revisión es una actividad
esperarada y regular, como lavar los platos o cortar el césped.
Se requiere cierta infraestructura técnica para hacer
eficazmente la revisión cambio por cambio. En particular, la creación
de correos de commits es extremadamente útil. El efecto de los correos
con los commits es que cada vez que alguien hace un cambio al
repositorio central, un correo electrónico se envía mostrando el
mensaje de registro y los diffs o diferencias (a menos que el diff sea
demasiado grande; ver , en ). La revisión en sí puede tener lugar en una
lista de correo, o en una herramienta de revisión, como Gerrit o la
interfaz "pull request" de GitHub. Ver en para obtener más
información.
Caso de Estudio
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 es visto y entendido, que se
está prestando atención. 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 de las revisiones para
encontrar cosas que debería haber encontrado por sí mismo.
Se abierto desde el primer día
Comienza tu proyecto como algo abierto desde el primer día.
Cuanto más tiempo un proyecto se ejecuta en un modo de código cerrado,
más difícil es abrir el código más tarde.Esta sección
comenzó como un blog, blog.civiccommons.org/2011/01/be-open-from-day-one, aunque ha
sido editado mucho para su inclusión aquí.
Ser de código abierto desde el principio no significa que los
desarrolladores deben tomar de inmediato las responsabilidades
adicionales de gestión de la comunidad. La gente suele pensar que
"fuente abierta" significa "extraños distrayendonos con preguntas",
pero eso es opcional — es algo que podrías hacer en el
futuro, siempre y cuando tenga sentido para tu proyecto. Está bajo tu
control. Todavía hay grandes ventajas que se tendrán al ejecutar el
proyecto en foros abiertos y visibles públicamente desde el principio.
Contrariamente, cuanto más tiempo el proyecto se ejecuta como código
cerrado, más difícil será para abrirlo más tarde.
Creo que hay una causa subyacente para ello:
En cada paso de un proyecto, los programadores se enfrentan a una
elección: hacer ese paso de una forma compatible con una hipotética
apertura del código en el futuro, o lo hacen de una manera incompatible
con la apertura del código. Y cada vez que eligen la segunda, el
proyecto se vuelve un poco más difícil para liberar su código.
Lo crucial es, que ellos no pueden ayudar eligiendo la
última — todas las presiones de desarrollo los
impulsan por ese camino. Es muy difícil dar un evento futuro el mismo
peso que al día actual, por ejemplo, solucionar los errores entrantes
reportados por los probadores, o finalizar esa característica nueva
que el cliente acaba de agregar a la especificación. Además, los
programadores que luchan por mantenerse dentro del presupuesto
inevitablemente cortan las esquinas aquí y allá (en palabras de Ward
Cunningham, incurriren en una "deuda técnica"), con la intención de solucionarlo más
tarde.
Por lo tanto, cuando llega el momento de abrir la fuente,
encontrarás de repente que hay cosas como:
-->
Configuraciones específicas del cliente y contraseñas
controladas en el repositorio de código;
Datos de ejemplo construidas a partir de información en
tiempo real (y confidencial);
Informes de fallos que contienen información sensible que
no puede hacerse pública;
Comentarios en el código que expresan tal vez reacciones
excesivamente honestas a última petición urgente del
cliente;
Archivos de correspondencia entre el equipo de desarrollo,
en los que la información técnica de utilidad se intercala
con opiniones personales no destinados a extraños;
Temas sobre licencia debido a bibliotecas de dependencia
cuyos términos podrían haber estado bien para la
implementación interna (o ni siquiera eso), pero no son
compatibles con la distribución de código abierto;
Documentación escrita en el formato incorrecto (por
ejemplo, una wiki privativa interna que utiliza tu
departamento), sin ninguna herramienta de traducción
sencilla disponible para convertirla a formatos adecuados
para su distribución pública;
Dependencias de construcción para no portables que sólo
se manifiestan cuando intentas mover el software de su
entorno de compilación interna;
Violaciónes modularidad que todo el mundo sabe que
necesitan limpieza, pero que simplemente aún no ha
habido tiempo para ocuparse de eso...
(La lista podŕia seguir)
El problema no es sólo el trabajo de hacer las limpiezas; es
la toma de decisiones extra que a veces se requieren. Por ejemplo, si
el material sensible se registró en el repositorio de código en el
pasado, su equipo se enfrenta ahora a una elección entre la limpieza de
las revisiones históricas por completo, por lo que puede abrir la fuente
de toda la historia (saneada), o simplemente la limpieza de la
última revisión y abriendo el código desde ahí (a veces llamado un
"top-skim"). Ningún método es correcto o incorrecto — y
ese es el problema: ahora usted tiene una discusión más a tener y una
decisión más que tomar. En algunos proyectos, la decisión es realizada e
devuelta varias veces antes de la versión final. La auto goleada es parte
del costo.
Esperar sólo crea un evento de exposición
El otro problema con la apertura de una base de código
desarrollado es que crea un evento de exposición innecesariamente grande.
Cualquiera que sea problema que pueda haber en el código (atajos de
modularidad, vulnerabilidades de seguridad, etc), todos ellos estarán
expuestos al escrutinio público a la vez — el evento de
apertura del código se convierte en una oportunidad para la blogosfera
técnica de abalanzarse sobre el código y ver lo que pueden
encontrar.
Esto contrasta con el escenario donde el desarrollo se llevó a cabo
al aire libre desde el principio: los cambios de código vienen en uno a la
vez, así que los problemas se manejan a medida que surgen (y se atrapan
a menudo antes, ya que hay más ojos en el código). Dado que los cambios
llegan al público a una velocidad baja y constante de exposición, nadie
culpa a su equipo de desarrollo de los atajos ocasionales o chequeo
defectuoso del código. Todo el mundo ha estado allí, después de todo; estas
compensaciones son inevitables en el desarrollo del mundo real. Mientras la
deuda técnica sea registrada correctamente en los comentarios "FIXME" y
informes de errores, y los problemas de seguridad sean abordados prontamente,
está bien. Sin embargo, si esas mismas cuestiones hubieren aparecido
de repente todos a la vez, los observadores poco comprensivos pueden
saltar sobre la exposición global de una manera que nunca harían si los
problemas hubiesen surgido poco a poco en el curso normal del
desarrollo.
(Estas preocupaciones se aplican incluso con más fuerza a los
proyectos de software de gobierno; ver en el
)
La buena noticia es que estos son todos errores no forzados. Un
proyecto incurre en un pequeño coste adicional al evitarlos de la
manera más sencilla posible: mediante la ejecución abierta desde el
primer día.
"Abierto", significa que las cosas siguientes son de
acceso público, en formatos estándar, desde el primer día del proyecto:
el repositorio de código, rastreador de errores, documentos de diseño,
documentación del usuario, wiki y foros de discusión para
desarrolladores. También significa que el código y la documentación se
encuentran bajo una licencia de código abierto, por supuesto. Significa
también que el trabajo del día a día de su equipo se lleva a cabo en una
zona visible públicamente.
"Abierto" no tiene por qué significar: permitir a extraños
comprobar el código en tu repositorio (son libres de copiar en su propio
repositorio, si quieren, y trabajar con él allí); permitiendo que
cualquiera pueda presentar informes de errores en su tracker (Eres libre
de elegir tu propio proceso de control de calidad, y si permitir
informes de extraños no te ayuda, no tienes que hacerlo); leer y
responder a todos los informes de errores presentada, incluso si
permites que extraños los creen; responder a cada pregunta que la gente
haga en los foros (incluso si son moderados); la revisión de cualquier
parche o sugerencia publicado, al hacerlo puede costar valioso tiempo
de desarrollo; etc.
Una forma de pensar en ello es que estás abriendo tu código, no
tu tiempo. Uno de esos recursos es infinitamente replicable, el otro no
los es. Vas a tener que determinar el punto en el que la participación
con los usuarios y los desarrolladores externos tiene sentido para tu
proyecto. A la larga lo tiene, y la mayor parte de este libro trata de
cómo hacerlo con eficacia. Pero está todavía bajo tu control.
Desarrollar de modo abierto no cambia esto, simplemente se asegura de
que todo lo hecho en el proyecto es, por definición, hecho de una
manera que sea compatible con ser de código abierto.
Al abrir un proyecto cerrado, hay que ser sensible acerca de
la magnitud de los cambios
Según , lo mejor es
evitar estar en la situación de abrir por primera vez un proyecto
cerrado; comienza el proyecto siendo abierto, si puedes. Pero si es
demasiado tarde para eso, y te encuentras en la apertura de un proyecto
existente que ya tiene desarrolladores activos acostumbrados a trabajar
en un entorno de código cerrado, asegúrate de que todo el mundo
entiende que un gran cambio está llegando—y asegúrate de entender
cómo se va sentir 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.
Anunciando
Una vez que el proyecto está presentable—no perfecto,
sólo presentable—se está listo para anunciarlo al mundo.
Este es un proceso tan simple como se podría esperar. Hay dos
tipos de foros para hacer anuncios: foros genéricos que muestran un
flujo constante de nuevos anuncios de proyectos, y foros sobre temas
específicos donde su proyecto sería una noticia apropiada.
El lugar genérico más útil es probablemente freecode.com — simplemente haga clic en el
enlace Enviar nuevo proyecto en la barra
de navegación superior. La lista los nuevos proyectos de Freecode está
incrustado en la página principal de la popular Slashdot.org, lo cual significa
que es probable que alguien interesado lo note y ayude a difundir la
noticia de boca en boca. (Ten en cuenta que Freecode era conocido como
Freshmeat.net hasta que fue rebautizado en octubre de 2011) También
puede ser que desee registrar su proyecto en OhLoh.net, que es lo más cercano que
hay a una base de datos mundial integrada de proyectos de software
libre y sus colaboradores. (Algunos proyectos también suben con
éxito el árbol del boca a boca y votos positivos hasta el punto en que
se presentan en la página principal de news.ycombinator.com, uno
de los foros subreddit relacionados con reddit.com/r/technology/, o alguna página pública similar que
sea popular. Aunque es una buena noticia para tu proyecto si puedes
conseguir ser mencionado en un lugar como ese, me niego a contribuir
a la carrera armamentista del marketing al sugerir alguna medida
concreta para lograr esto. Utilice su juicio y evite hacer spam.)
Los foros sobre temas específicos son, probablemente, donde se
obtendrá el máximo interés. Piensa en las listas de correo o frums
web donde el anuncio de tu proyecto sea un tema a tratar y sea de
interés — es posible que ya seas miembro de alguna
de ellos — y publícalo allí. Ten el cuidado de hacer
exactamente un mensaje por cada foro, y de
dirigir a la gente a las propias áreas de discusión de tu proyecto
para continuar la discusión (al publicar por correo electrónico,
puedes hacer esto mediante el establecimiento de la
cabecera Reply-To). Tu anuncio debe ser
corto y dejar claro el punto, y la línea de asunto debe dejar en claro
que se trata de un anuncio de un nuevo proyecto:
To: discusion@algun.foro.sobre.indexadores
Subject: [ANUNCIO] Scanley, un nuevo proyecto de indexado full-text
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 difusas
- (planeado) Actualización incremental de los índices
- (planeado) Indexación de sitios web remotos
- (planeado) Lectura de la mente a largas distancia
Requerimientos:
- Python 3.2 o mayor
- SQLite 3.8.1 o mayor
Para más información, ¡visitanos en scanley.org!
Gracias,
-J. Random
(Más información
en para consejos sobre como
anunciar lanzamientos subsiguientes y 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 de ser abierto 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
Ten en cuenta que el anuncio
tu proyecto puede venir mucho después de que has abierto el código
fuente. Mi consejo de considerar cuidadosamente el tiempo de su
anuncio no debe ser tomado como consejo para retrasar la liberación del
código fuente — idealmente, tu proyecto debe ser de
código abierto y visible públicamente desde el primer momento de su
existencia, y esto es totalmente independiente de si lo anuncias. Ver
para más..
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.