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í.