El precio del �xito es muy pesado en el mundo del Open Source. Conforme tu software se hace m�s popular, el n�mero de gente que empieza a buscar informaci�n sobre �l, se incrementa dramaticamente, mientras el n�mero de gente capaza de proporcionar informaci�n se incrementa mucho m�s despacio. Adem�s, incluso si el ratio fuera uniformemente balanceado, todav�a existir�a un problema de escalabilidad en la forma en que la mayor�a de los proyectos Open source manejan las comunicaciones. Considera por ejemplo las listas de correo. La mayor�a de los proyectos tienen una lista de correo para cuestiones generales de los usuarios; a veces los nombres de estas listas son "usuarios", "discusiones", o "ayuda" o algo similar. Cualquiera que sea su nombre, el prop�sito de esas listas es el mismo: proporcionar un lugar donde la gente pueda resolver sus cuestiones, mientras otros observan y (presumiblemente) absorben conocimiento de la observaci�n de ese intercambio de conocimiento.
Estas listas de correo funcionan muy bien hasta unos pocos miles de usuarios y/o un par de cientos de posts al d�a. Pero m�s o menos, a partir de ah� el sistema empieza a romperse, porque cada suscriptor vee cada post; si el n�mero de post a la lista empieza a exceder lo que cualquier lector individual puede procesar en un d�a, la lista se convierte en una carga para sus miembros. Imagina por ejemplo, si Microsoft tuviera tal lista de correo para Windows XP. Windows XP tiene cientos de millones de usuarios; a�n incluso si el uno por ciento de ellos tuviera cuestiones en un periodo de veinticuatro horas, entonces esta lista hipot�tica cientos de miles de posts al d�a! Por supuesto, tal lista de correo no podr�a existir, porque nadie permanecer�a subscrito. Este problema no esta limitado a las listas de correo; la misma l�gica se aplica a los canales del IRC, los foros de discusi�n online y por ende, a cualquier sistema en el cual un grupo escuche preguntas de individuos. Las implicaciones son siniestras: el modelo usual del Open Source del soporte masivamente paralelizado simplemente no escala los niveles necesarios para la dominaci�n mundial.
No habr� una explosi�n cuando los foros alcancen su punto de ruptura. Se trata simplemente de un efecto silencioso de feedback negativo: la gente se borrar� de las listas, o saldr�n de los canales del IRC, o a cualquier ritmo cesaran de preocuparse en preguntar cuestiones, porque ver�n que no se les escuchar� entre tanta gente. As� cuanta m�s gente haga de estas su principal elecci�n racional, la actividad de los foros empezar� a permanecer a un nivel inmanejable precisamente porque la gente racional o (al menos experimentada), empezar� a buscar informaci�n por otros medios, mientras la gente sin experiencia permanecer� y continuar� preguntando en foros y listas de correo. En otras palabras, uno de los efectos de continuar con el uso de modelos de comunicaci�n que no son escalables mientras que el proyecto crece es que la calidad media tanto de preguntas y respuestas tiene a disminuir, lo cual hace que los nuevos usuarios parezcan m�s tontos de lo que son, cuando de hecho probablemente no lo sean. Se trata simplemente de que el ratio beneficio/costo de el uso de esos foros masificados, disminuye, por lo que de manera natural, aquellos con experiencia, empezar�n a buscar respuestas en otros sitios. Ajustar los mecanismos de comunicaci�n para poder con el crecimiento del proyecto, implicar� dos estrategias relacionadas:
Reconociendo cuando partes especiales de un foro no sufren un crecimiento desmesurado, incluso si el foro se trata como un todo, y separando aquellas partes creando otras nuevas, en foros m�s especializados (ejem., no dejes que los buenos se arrastren por los malos).
Asegurando que existen muchas fuentes de informaci�n autom�ticas disponibles, y que se mantienen organizadas, actualizadas y f�ciles de localizar.
La estrategia (1) normalmente no es muy dura. La mayor�a de los proyectos empiezan con un foro principal: y una lista de correo para discusiones generales, en las cuales las ideas de caracter�sticas, cuestiones de dise�o y problemas de codificaci�n puedan ser discutidos. Todo el mundo involucrado en el proyecto est� en la lista. Despues de un tiempo, se comprueba que la lista ha evolucionado en varias sublistas basadas en diferentes tem�ticas. Por ejemplo, algunos hilos son claramente sobre desarrollo y dise�o; otros son dudad de usuarios del tipo �"C�mo hago tal cosa"?; quiz� exista una tercera tem�tica centrada en el registro de procesar los informes de bugs y peticiones de mejora; y as�. Un individuo dado, por supuesto puede participar en varios tipos diferentes de hilos, pero lo m�s importante de todo es que no hay mucho solapamiento entre los diferentes tipos mismos. Pueden ser divididos en listas separadas sin causar ning�n perjuicio en el proyecto, porque los hilos se mantienen repartidos por tem�ticas.
Actualmente, realizar esta divisi�n es un proceso de dos pasos. Creas la nueva lista (o el canal IRC, o lo que vaya a ser), y entonces gastas el tiempo necesario de manera educada pero insistiendo y recordando a la gente a usar los nuevos foros apropiadamente. Este paso puede llevar semanas pero finalmente la gente captar� la idea. Simplemente tienes que hacer ver a alguien que env�a un post al destino equivocado, cual es el nuevo camino y hacerlo de manera visible, animando a que otras personas ayuden tambien en los nuevos usuos. Es tambien muy �til tener una p�gina web proporcionando una gu�a hac�a todas las listas disponibles; tus respuestas simplemente pueden referenciar esta p�gina y, como gratificaci�n, el destinatario puede aprender sobre las pautas a seguir antes de escribir un correo.
La estrategia (2) es un proceso en curso, dura durante todo el tiempo de vida del proyecto e involucra a muchos participantes. Por supuesto es en parte cuesti�n de tener una documentaci�n actualizada (mira “Documentaci�n” en Cap�tulo�2, Primeros Pasos) y asegur�ndote que la gente vaya ah�. Pero es tambien mucho m�s que eso; las secciones que siguen discuten esta estrategia en detalle.
Tipicamente, todas las comunicaciones de un proyecto Open Source (excepto algunas veces conversaciones en el IRC), son archivadas. Los archivos son p�blicos y se pueden buscar, y tienen una estabilidad referencial: que significa, una vez que una pieza de informaci�n se ha grabado en una direcci�n particular, permanece en esa direcci�n para siempre.
Usa estos archivos tanto como puedas, y tan visiblemente como sea posible. Incluso cuando sepas la respuesta a alguna pregunta, si piensas que existe una referencia en los archivos que contiene la respuestas, gasta el tiempo necesario para buscarla y presentarla. Cada vez que hagas esto de una manera p�blicamente visible, algunas personas aprenderan la primera vez que significan esos archivos, y que buscando en ellos pueden encontrar respuestas. Tambien, refiri�ndose a los archivos en vez de reescribir la respuesta, refuerzas la norma social contra la duplicaci�n de informaci�n. �Por qu� obtenemos la misma respuesta en dos sitios diferentes? Cuando el n�mero de sitios que se puede encontrar es mantenido a un m�nimo, la gente que lo ha encontrado antes est�n m�s predispuestos a recordar qu� y donde buscarlo para las pr�ximas veces. Las referencias bien situadas tambien contribuyen a la calidad de los resultados de b�squeda en general, porque ellos refuerzan los recursos del objetivo en los rankings de los motores de b�squeda en Internet.
Sin embargo, hay veces en las que duplicar la informaci�n tiene sentido. Por ejemplo, supon que hay una respuesta en los archivos, que no es de t�, diciendo:
Parece que los �ndices Scanley indexes han sido corrompidos. Para devolverlos a su estado original, ejecuta estos pasos: 1. Apaga el servidor Scanley. 2. Ejecuta el programa 'descorromper' que viene con Scanley. 3. Inicia el servidor.
Entonces, meses despu�s, ves otro mail indicando que algunos indices han sido corrompidos. Buscas los archivos y presentas la vieja respuesta anterior, pero te das cuenta que faltan algunos pasos (quiz�s por error, o quiz� porque el software ha cambiado desde que se escribi� ese post). La cl�sica manera para manejar esto, es escribir un nuevo mail, con un conjunto de instrucciones m�s completo, y explicitamente dar como obsoleto el anterior post mencion�ndolo as�:
Parece que tus �ndices Scanley han sido corrompidos. Vimos este problem all� por Julio, y J. Random public� una soluci�n en http://blahblahblah/blah. Abajo hay una descripci�n m�s completa de como recuperar tus �ndices, basado en las instrucciones de J. Random pero extendi�ndolo un poco m�s: 1. Para el servidor Scanley. 2. Cambiate al usuario con el que se ejecuta el servidor Scanley. 3. Como este usuario, ejecuta el programa 'recuperar' en los �ndices. 4. Ejecuta Scanley a mano para ver si los �ndices funcionan ahora. 5. Reinicia el servidor.
(En un mundo ideal, ser�a posible poner una nota en el viejo post, indicando que existe informaci�n m�s actualizada y apuntando al nuevo post que la contiene. Sin embargo, no conozco ning�n software de archivaci�n que ofrezca una caracter�stica "obsoleto por", quiz� porque ser�a muy dif�cil de implementar de una manera en que no viole la integridad de los archivos. Esta es otra raz�n de porqu� es buena idea crear p�ginas web con respuestas a cuestiones comunes.
Los archivos probablemente son buscados m�s a menudo para respuestas a cuestiones t�cnicas, pero su importancia para el proyecto va m�s all� de eso. Si una pauta formal del proyecto son sus leyes establecidas, los archivos son su ley com�n: una grabaci�n de todas las decisiones hechas y como se lleg� hasta ellas. En cualquier discusi�n recurrente, actualmente es casi obligatorio empezar con una b�squeda en los archivos. Esto permite empezar la discusi�n con un sumario del estado actual de las cosas, anticipandose a objeciones, preparando refutaciones y posiblemente descubriendo �ngulos que no hab�as imaginado. Tambi�n los otros participantes esperan de ti que hayas hecho una b�squeda en los archivos. Incluso si las discusiones previas no llevaron a ninguna parte, t� deber�as incluir sugerencias cuando vuelvas al t�ma, para que la gente pueda ver por si mismos a) que no llegaron a ningun consenso, y b) que t� hiciste tu trabajo, y por tanto que probablemente se este diciendo algo ahora que no se dijo anteriormente.
Todos los consejos anteriores son extensibles m�s all� de los archivos de las listas de mail. Tener piezas particulares de informaci�n de manera estable, y en direcciones que se puedan encontrar convenientemente deber�a ser un principio de organizaci�n para toda la informaci�n de un proyecto. Vamos a ver la FAQ como un caso de estudio.
�C�mo usa la gente una FAQ?
Buscan palabras y frases espec�ficas.
Quieren poder navegarla, disfrutando de la informaci�n sin buscar necesariamente respuestas a cuestiones espec�ficas.
Esperan que motores de b�squeda como google conozcan el contenido de la FAQ, de manera que las b�squedas puedan ser entradas en la FAQ.
Quieren ser capaces de dirigirse directamente a otra gente en temas espec�ficos en la FAQ.
Quieren ser capaces de a�adir nuevo material a la FAQ, pero hay que ver que esto ocurre menos a menudo que la b�squeda de respuestas —Las FAQs son de lejos mucho m�s leidas que escritas.
El punto 1 implica que la FAQ deber�a estar disponible en alg�n tipo de formato textual. Los puntos 2 y 3 implican que la FAQ deber�a estar disponible en forma de p�gina HTML, con el punto 2 indicando adicionalmnente que el HTML deber�a ser dise�ado con legibilidad (ejem., necesitaras alg�n tipo de control sobre su apariencia), y deber�a tener una tabla de contenidos. El punto 4 significa que cada entrada individual en la FAQ deber�a ser asignada como un HTML named anchor, (anclas con nombre) un tag que permite a la gente alcanzar un sitio particular en la p�gina. El punto 5 significa que los ficheros fuente de la FAQ deber�an estar disponibles de una manera conveniente (ver “Versiones de todo” en Cap�tulo�3, Infraestructura T�cnica), un formato que sea f�cil de editar.
Formatenado la FAQ de esta manera es s�lo un ejemplo de como crear un recurso presentable. Las mismas propiedades—busqueda directa, disponibilidad en la mayor�a de buscadores de Internet, navegaci�n, estabilidad referencial, y (donde se aplique) edici�n—son aplicables a otras p�ginas web, el arbol del c�digo fuente, el seguimiento de bugs, etc. Simplemente ocurre que la mayor�a del software de archivado de listas de correo hace tiempo que reconocen la importancia de estas propiedades, y es por lo que las listas de correo tienden a tener estas funcionalidades de manera nativa, mientras otros formatos requieren de un esfuerzo extra en la parte de mantenimiento(Cap�tulo�8, Coordinando a los Voluntarios discute como difundir esta carga de mantenimiento a trav�s de miles de voluntarios).
Conforme un proyecto gana en complejidad y adquiere historia, la cantidad de datos que cada participante debe absorber incrementa. Aquellos que llevan en el proyecto mucho tiempo ser�n capaces de aprender, e inventar las convenciones del proyecto conforme avanza. A menudo no ser�n conscientes del gran cuerpo de tradici�n que se ha ido acumulando, y puede sorprender todos los peque�os fallos que los nuevos participantes del proyecto puedan hacer. Por supuesto, el tema no es que los reci�n llegados tengan una menor calidad que los de antes; sino que se enfrentan a una carga de cultura heredada mayor de la que ten�an los recien llegados en el pasado.
Las tradiciones que un proyecto acumula son del tipo c�mo comunicar y mantener informaci�n y sobre est�ndares de codificaci�n y otros temas t�cnicos. Ya hemos repasado ambas clases de est�ndares, en “Documentaci�n para Desarrolladores” en Cap�tulo�2, Primeros Pasos y “Tomando Nota de Todo” en Cap�tulo�4, Infraestructura Social y Pol�tica respectivamente, y se han mostrado ejemplos. Sobre lo que trata esta secci�n es de como mantener esas pautas actualizadas conforme el proyecto avanza, especialmente pautas sobre c�mo se administran las comunicaciones, porque estas son las �nicas que cambian la mayor�a conforme el proyecto crece en tama�o y complejidad.
Primero, busca patrones de c�mo la gente se equivoca. Si observas las mismas situaciones una y otra vez, especialmente con participantes nuevos, se presenta una oportunidad en forma de pauta que necesita ser documentada pero no lo est�. Segundo, no te canses de decir las mismas cosas una y otra vez, y que no parezca que est�s cansado de repetirlas. T� y otros veteranos del proyecto tendr�is que repetirlas entre vosotros mismos a menudo; este es un efecto inevitable de la llegada de nuevos participantes.
Cada p�gina web, cada mensaje de lista de correo, y cada canal del IRC, deber� ser considerado como un espacio de publicidad per no de anuncios comerciales, sino de anuncios sobre los recursos propios de tu proyecto. Lo que pongas en este espacio depender� de la procedencia de los que lo vayan a leer. Un canal IRC para cuestiones de usuario, por ejemplo, atraer� gente que nunca habr� interactuado con el proyecto antes, a menudo alguien que ha instalado el software, y tiene alguna pregunta que le gustar�a que le respondieran al momento (despu�s de todo, si puediera esperar, hubiera enviado un mail a la lista de correo la cual probablemente usa menos de su tiempo total, aunque tardar�a m�s en recibir respuesta). La gente normalmente no realiza una inversi�n permanente en el canal de IRC, aparecer�n, lanzar�n su pregunta y se ir�n.
De ah�, el tema del canal deber�a apuntar a gente buscando respuestas t�cnicas en ese momento, en vez de, gente que quiera involucrarse con el proyecto de una manera permanente y para los cuales unas pautas de interaccion ser�an m�s apropiadas. Aqu� es donde un canal verdaderamente ocupado lo maneja (comparalo con el ejemplo anterior en “IRC / Sistemas de Chat en Tiempo Real” en Cap�tulo�3, Infraestructura T�cnica):
You are now talking on #linuxhelp Topic for #linuxhelp is Please READ http://www.catb.org/~esr/faqs/smart-questions.html && http://www.tldp.org/docs.html#howto BEFORE asking questions | Channel rules are at http://www.nerdfest.org/lh_rules.html | Please consult http://kerneltrap.org/node/view/799 before asking about upgrading to a 2.6.x kernel | memory read possible: http://tinyurl.com/4s6mc -> update to 2.6.8.1 or 2.4.27 | hash algo disaster: http://tinyurl.com/6w8rf | reiser4 out
Con las listas de correo, el "espacio de AD" es un ligero pie de p�gina a�adido a cada mensaje. La mayor�a de los proyectos ponen ah� instrucciones de suscripci�n/borrado, y quiz�s un enlace a la p�gina principal del proyecto o tambi�n a la FAQ. Puedes pensar que cualquiera que est� suscrito a la lista sabr� donde encontrar esa informaci�n, y probablemente entonces lo hagan, pero mucha m�s gente que �nicamente los subscriptores ver�n esos correos de la lista. Un post archivado se puede enlazar desde diversos lugares; de hecho, algunos posts se vuelven tan famosos que eventualmente son leidos por m�s lectores fuera de la lista que de ella.
El formateo puede crear una gran diferencia. Por ejemplo, en el proyecto, tuvimos un �xito limitado utilizando la t�cnica de filtrado de bugs descrita en “Pre-filtrado del gestor de fallos” en Cap�tulo�3, Infraestructura T�cnica. Muchos de los falsos bugs reportados estaban siendo todav�a rellenados por gente sin experiencia, y ocurr�a cada vez, el informador ten�a que ser educado de la misma manera que lo hab�a sido con las 500 personas de antes. Un d�a, despu�s de que a uno de nuestros desarrolladores finalmente se le agotara la paciencia y empez� a criticar y meterse con un pobre usuario por no haberse le�do detenidamente la gu�a de uso del bug tracker, otro desarrollador decidi� que este patr�n hab�a ido ya demasiado lejos. Sugiri� que reformatearamos la p�gina frontal del bug tracker de tal forma que lo m�s importante, los mandatos para discutir los bugs en la lista de correo o en los canales IRC antes de rellenarlos, ser�an letras muy grandes, en rojo resaltado sobre un fondo amarillo y resaltado claramente sobre todo los dem�s elementos de la p�gina. As� lo hicimos (puedes ver los resultados en http://subversion.tigris.org/project_issues.html), y y el resultado fue un descenso notable en el ratio de falsos bugs relleandos. Por supuesto, todav�a los tenemos, y siempre los tendremos, pero el ratio ha descendido considerablemente, incluso aunque el n�mero de usuarios incrementa. El resultado no es solamente que la base de datos de bugs tiene menos basura, sino que aquellos que responden a los tickets de bugs lo hacen con buen car�cter, y es m�s probable permanecer amistosamente cuando se responde a uno de los pocos bugs falsos. Esto mejora tanto la imagen del proyecto como la salud mental de sus voluntarios.
La leccion para nosotros fue que �nicamente escribiendo unas gu�as de uso no era demsiado. Tambi�n tuvimos que colocarlas all� donde m�s se vieran por la gente que m�s las iba a necesitar, y formatearlas de tal manera que su estado y material introductorio estuviese inmediatamente claro para la gente que no estuviera familiarizada con el proyecto.
Las p�ginas web est�ticas no son el �nico lugar para publicar las caracter�sticas del proyecto. Una cierta cantidad de pol�ticas interactivas (en el sentido de recordatorio-amigable , no en el sentido de enjaular y atar) tambi�n son requeridas. Todas las revisiones por pares, incluso las revisiones de commits descritas en “Practicar Revisiones Visibles del C�digo” en Cap�tulo�2, Primeros Pasos, deber�an incluir revisiones de conformidad o no-conformidad con las normas del proyecto, especialmente en relaci�n a las convenciones de las comunicaciones.
Otro ejemplo del proyecto Subversion: fijamos una convenci�n de "r12908" qu� significaba "revision 12908 en el repositorio de control de versiones". El prefijo "r" es facil de escribir, y porque es la mitad de peso que los d�gitos, lo hace un bloque de texto f�cilmente reconocible combinado con digitos. Por supuesto, fij�ndolo as� en la convenci�n no significaba que todo el mundo lo empezara a usar consistentemente de la manera correcta. Hasta ahora, cuando un mail de commit viene con un log como este:
------------------------------------------------------------------------ r12908 | qsimon | 2005-02-02 14:15:06 -0600 (Wed, 02 Feb 2005) | 4 lines Patch from J. Random Contributor <jrcontrib@gmail.com> * trunk/contrib/client-side/psvn/psvn.el: Fixed some typos from revision 12828. ------------------------------------------------------------------------
...parte de la revisi�n de este comit es decir "A partir de ahora, por favor usa 'r12828', en vez de 'revision 12828' cuando te refieras a cambios del pasado." Esto no es pedante; es importante tanto para el parseo autom�tico como para los lectores humanos.
Siguiendo los principios generales, de seguir m�todos canonicos de referencia, y que estos m�todos de referencia debieran ser usados consistentemente en todos los sitios, el proyecto en efecto exporta ciertos est�ndares. Estos est�ndares hacen que la gente escriba herramientas que presenten las comunicaciones del proyecto de una manera m�s �til; por ejemplo, una revisi�n formateada como "r12828" podr�a transformarse en un enlace vivo dentro del sistema de navegaci�n del repositorio. Esto ser�a muy dif�cil de realizar si la revisi�n se hubiera escrito como "revision 12828", tanto porque la forma podr�a dividirse a trav�s de un salto de l�nea, y porque es menos distintiva (la palabra "revision", a menudo aparecer� sola, y los grupos de n�meros tambi�n apareceran solos, all� donde la combinaci�n "r12828" puede significar �nicamente un n�mero de revisi�n). Asuntos similares se aplican tambien a temas con n�meros, FAQs (truco: utiliza una URL con un named anchor, como se describe en Named Anchors y atributos ID), etc.
Incluso para las entidades en las cuales no hay una manera obvia, la forma can�nica, se deber�a recomendar a la gente el proporcionar piezas clave de informaci�n consistente. Por ejemplo, en lo que se refiere a un mensaje de lista de correo, no facilites simplemente el destinatario y el asunto; facilita tambien la URL del archivo y la cabecera Message-ID. Esto �ltimo permitir� a la gente que tenga su propia copia de la lista de correo (la gente a veces copias offline, por ejemplo para utilizarlas en el port�til mientras viajan) indentificar de manera inequivoca el mensaje correcto incluso aunque no tengan acceso a los archivos. El destinatario y asunto tampoco ser�an demasiado, porque la misma persona podr�a crear diversos posts en el mismo hilo, incluso en el mismo d�a.
Cuanto m�s crece un proyecto, m�s importante es este tipo de consistencia. Consitencia signfica que all� donde todo el mundo mire, ver�n que se siguen los mismos patrones, as� que ellos tamb�en sabran seguir por ellos mismos los patrones. Esto tambi�n reduce el n�mero de cuestiones que necesitar�n preguntar. La carga de tener un millon de lectores no es m�s grande que el tener s�lo uno; los problemas de escalabilidad empiezan a surgir solo cuando un cierto porcentage de estos lectores hacen preguntas. Conforme el proyecto crece, por tanto, se debe reducir aquel porcentage incrementando la densidad y accesibilidad de la informaci�n, de tal manera que una persona dada pueda encontrar la informaci�n que necesite sin necesidad de preguntar.