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 (http://subversion.tigris.org/), 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.
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 “Sobresaliente uso de los archivos” en el Cap�tulo�6, Comunicaciones.
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 [21] 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.
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.
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.[22]
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 diff, en “Vocabulario del Control de Versiones”). 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 Cap�tulo�3, Infraestructura T�cnica para obtener m�s informaci�n.
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.
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.[23]
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:
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.
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.
Seg�n “Se abierto desde el primer d�a”, 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 “Practicar Revisiones Visibles del C�digo” 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. Cap�tulo�5, Dinero explora t�cnicas para mezclar exitosamente desarrolladores asalariados y voluntarios y en Cap�tulo�9, Licencias, Copyrights y Patentes 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.
[21] 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
[22] 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.
[23] 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�.