Tabla de contenidos
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
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.
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.
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.
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 “Primero Investiga” 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 “Hosting”)
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 “Poseer el nombre en los espacios de nombre importantes” para m�s informaci�n sobre esta y su relaci�n con el nombre de dominio.
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
[12], el identificador de Twitter
@gnome, el nombre de
usuario gnome en
Identi.ca[13], el
nombre de usuario gnome
en GitHub.com[14], y en la red freenode IRC
(ver “IRC / Sistemas de Chat en Tiempo Real”) 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.
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.
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 “Escogiendo una licencia y Aplic�ndola” m�s adelante en �ste cap�tulo, y algunos detalles sobre las licencias ser�n discutidos en el Cap�tulo�9, Licencias, Copyrights y Patentes.
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.
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.
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.
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.
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 “Numeraci�n de versiones liberadas”, y detalles sobre la estandarizaci�n de los procedimientos de compilado e instalaci�n ser�n cubiertos en “Packaging”, ambos en el Cap�tulo�7, Empaquetado, Liberaci�n, y Desarrollo diario.
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 proyectos[15]. La infraestructura del control de versiones se discute detalladamente en “Control de Versiones” en Cap�tulo�3, Infraestructura T�cnica.
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.[16]
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 “Seguimiento de errores” en el Cap�tulo�3, Infraestructura T�cnica, 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.
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 (Cap�tulo�3, Infraestructura T�cnica), 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 “Manejando el crecimiento” en el Cap�tulo�6, Comunicaciones, 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.
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 “Tomando Nota de Todo” en Cap�tulo�4, Infraestructura Social y Pol�tica, 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 “Forkability” en el Cap�tulo�4, Infraestructura Social y Pol�tica 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 “Documentaci�n para Desarrolladores” m�s adelante en �ste cap�tulo .
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 momento[17]. 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.
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 “Packaging” en el Cap�tulo�7, Empaquetado, Liberaci�n, y Desarrollo diario). 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
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 “Wikis” en el Cap�tulo�3, Infraestructura T�cnica.
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.
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.
�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 abierto[18]
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�. “Hosting Enlatado” en Cap�tulo�3, Infraestructura T�cnica 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.
[12] 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.
[13] Identi.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.
[14] Mientras 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
[15] Aunque 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 “Hosting Enlatado” en Cap�tulo�3, Infraestructura T�cnica
[16] 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.
[17] No 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.
[18] A 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.