 Hola y bienvenidos a esta sesión en Open Source Summit Latin America en la que vamos a estar viendo cinco formas de fallar al construir comunidades. Mi nombre es David Espejo y trabajo como Open Source Community Manager en VMware donde apoyo varios proyectos de código abierto tanto en la construcción como en el soporte de sus comunidades de usuarios, contribuidores, maintainers, entre otros. Pueden contactarme en Twitter como arroba David Miller. Un poco lo que veremos hoy en primer lugar es por qué este tema es importante, por qué hablar de comunidad en el contexto de código abierto es importante. Explorearemos un poco esas cinco formas de fallar que he encontrado a lo largo de mi experiencia y algunos recursos adicionales que considero útiles en caso que quieran indagar un poco más. Bien, en primer lugar entonces por qué este tema es importante. Bien, creo que aquí habría que dar un paso atrás y proveer una definición más o menos estándar de lo que aquello que nos referimos cuando hablamos de código abierto o Open Source. Diferente a lo que quizá a veces se piensa que simplemente quizás publicar el código fuente de una pieza de software. Open Source tiene más que ver con la madera en que se distribuye sí, pero también cómo se consume ese software y no dice mucho acerca de cómo ese código se produce. Esta definición la provee de the Open Source Way que es una guía referencial construida por varias personas de la industria y que dejo al final en las referencias y es muy importante porque va a tener algunas implicaciones en las recomendaciones que vamos a ver en esta sesión. Bien, entonces lo importante no es exactamente cómo se produce ese código sino que se pueda distribuir de una manera en que quienes lo van a consumir encuentren las maneras de modificarlo dentro de los términos de una licencia y poderlo ampliar y seguir redistribuyendo a libertad. Esa es una verdad. La otra verdad que va a estar transversal a lo largo de esta conversación es el asunto de que en las comunidades Open Source la moneda o el pilar fundamental no es el dinero ni es el poder y ni siquiera es la tecnología. Es la confianza. Es aquello que buscamos formar, consolidar y ciertamente no afectar. Es la confianza lo que nos permitirá construir y escalar una comunidad saludable alrededor de un proyecto Open Source. Así que espero mantengamos estas dos definiciones y estas dos verdades a lo largo de esta conversación. Bien, ahora sí, esas cinco formas de no hacer comunidad. La primera, no comunicar las decisiones y no comunicarlas pronto y abiertamente. Ejemplo, se reúne el comité técnico de un proyecto de código abierto y toma una decisión. Estas personas dentro del esquema de gobierno de ese proyecto son las encargadas de tomar esa decisión, pero esa reunión no fue pública. ¿Vio la esto, la definición o la filosofía de código abierto? No necesariamente. El problema viene es si esa decisión que tomaron, porque entre otras cosas eran lo responsable de tomarla. Si esa decisión que tomamos o que ellos tomaron entre comillas a puertas cerrada no se comunica en un formato en la que otros puedan participar y dar retroalimentación, por ejemplo un issue de GitHub o un blog post y no se comunica prontamente, entonces se va a afectar, se va a erosionar la confianza que la comunidad tiene en el proyecto. ¿Por qué? Porque todo el tiempo que pasa entre que la decisión se tomó y se comunique, va a ser tiempo que probablemente haya al menos una persona en la comunidad haciendo un esfuerzo que resulta ahora irrelevante o innecesario porque una decisión diferente ya se tomó. Y en todo caso las decisiones deben estar abiertas a la retroalimentación, al feedback de la comunidad, de manera que publicarlos en un formato en la que otros puedan opinar, también es necesario para fortalecer esa confianza. Entonces lo contrario, pues afecta la construcción de la comunidad saludable, no comunicar decisiones pronto y abiertamente. Segundo, enfocarse en las métricas incorrectas. En más de una ocasión me ha encontrado que cuando las personas piensan en community manager piensan en alguien que está publicando contenido en redes sociales. Si bien en el contexto de un proyecto de código abierto, esto hace parte de la estrategia de difusión, ciertamente no es ahí donde están las métricas de éxito. Por ejemplo, ¿cuántas visualizaciones está teniendo un blog post que publicamos acerca del proyecto? ¿O cuántas interacciones tuvo una publicación en redes sociales? O más común aún, en el medio de open source, ¿cuántas estrellas tienen mi repositorio en GitHub? Todas esas métricas no son relevantes, entre otras razones, porque es imposible relacionarlas o trazarlas a números de adopción. Por ejemplo, un repositorio que tiene mil estrellas en GitHub no quiere decir que ese software esté siendo utilizado por mil usuarios y estén satisfechos con él. No. Y mucho menos que una, así sea una fracción de esos usuarios, tengan el conocimiento o estén interesados en contribuir al proyecto, de manera que no hay una relación ahí como para tomar decisiones. Hay ejemplos, por otro lado, de métricas que sí nos pueden llevar a planes mucho más detallados, por ejemplo, las métricas que mantienen Chaos. Chaos es una organización sin fines de lucro integrada por varias personas de la industria y, periódicamente, publican o actualizan un compendio de métricas. El documento tiene alrededor de 200 páginas un poco más y va en la descripción de por qué cada métrica es importante y cómo implementarla. Aquí en la imagen se ve un ejemplo, una parte de una implementación de algunas de esas métricas utilizando Vitergia y explorando aspectos, por ejemplo, líneas de tendencia. ¿Cómo ha ido comportándose las contribuciones al proyecto al que nos estamos refiriendo aquí? O, por ejemplo, podríamos explorar métricas como el tiempo de respuesta. ¿Cuánto tiempo pasa entre que una persona de la comunidad cree un issue y alguien le responda? ¿O cuánto tiempo pasa en que un contribuidor envía un PR, un pull request, un github y alguien lo revise? Ese tiempo es importante porque entre más eficiente o más atentos están las personas que mantienen el proyecto, entonces va a haber mayor motivación para nuevos usuarios envolverse contribuidores en contribuir al proyecto. Bien, entonces enfocarse en métricas correctas nos va a llevar también a planes de acción mucho más concretos. No enfocarse en métricas de vanidad. Esas métricas superficiales ya las que hablamos iniciales. Eso es el punto dos. Punto tres, no ser consistente. Entonces un ejemplo, digamos que tenemos un proyecto de código abierto en el que iniciamos con, arrancamos con una iniciativa de cada tres meses, reconocer públicamente a las personas que más han contribuido al proyecto, ya sea código o presentando en eventos o simplemente estando ahí para responder las preguntas de otros usuarios. Lo hacemos la primera vez, lo reconocemos públicamente, lo hacemos a los siguientes tres meses, lo volvemos a hacer, pero después ya no lo volvemos a hacer. Sin previo aviso, simplemente no lo volvemos a hacer. Eso afecta también la confiabilidad que los usuarios puedan tener en la comunidad, porque si no hubo de nuevo, si se ha decidido no continuar con esa iniciativa, eso debe anunciarse pronto y abiertamente, conectado con punto uno o a menos que haya un reemplazo de esta iniciativa por una mejor, también debe comunicarse pronto y abiertamente. De lo contrario, en los momentos buenos y en los momentos difíciles de un proyecto, hay que continuar ejecutando con disciplina las iniciativas que hayamos arrancado. La consistencia también fortalece la confianza que puedan tener los usuarios acerca de este proyecto. Número cuatro, muy común, pero lamentablemente, muchas veces el ojo no está lo suficientemente entrenado para detectarlo y es, nos enfocamos mucho en el proyecto. Entonces, propusimos un nuevo proyecto de código abierto en un campo en el que hay una explosión de tecnología, por ejemplo, idea del campo de cadena de suministro de software o software supply chain. Es un campo en explosión, materia, tecnología, propusimos un nuevo proyecto ahí y queremos salir a cada evento que haya a contarle a la comunidad acerca de este proyecto tan interesante. Sin embargo, muchas ocasiones antes de salir a contarle al mundo fallamos en detenernos y tratar de destilar el porqué de este proyecto. ¿Cuál es ese problema o ese conjunto muy concreto de problemas que este proyecto está diseñado para resolver y también cuál es esa idea novedas, cuál es ese enfoque diferente bajo el cual este proyecto busca resolver ese problema? Si nos tomamos el tiempo de llegar a ese concreto al porqué del proyecto, entonces, muy probablemente las personas allá afuera se van a conectar mejor con la idea. Es decir, todos los que tengan ese mismo problema que hemos definido muy bien van a resonar con esta idea, esta manera diferente de hacerlo y van a involucrarse mejor con el proyecto. Es una manera también de orgánicamente ir formando una comunidad alrededor de una idea porque finalmente el proyecto, y esto es importante recordar, el proyecto es solo una implementación de una idea. El proyecto es el cómo, el cómo la implementa, pero lo importante es el porqué. Y generalmente la tecnología a lo largo del tiempo cambia, es decir, ese cómo va a cambiar, pero las ideas perduran mucho más en el tiempo y en general los seres humanos tendemos a suscribirnos mucho más a una idea en la cual creemos, es prácticamente la definición de comunidad. Tendemos a hacerlo mejor así que simplemente suscribirnos a un método o una manera específica de cómo hacer las cosas, de manera que es importante más que enfocarse en el proyecto, enfocarse en el problema que resuelve y en la idea central nuclear del proyecto y poderla comunicar. Esa es el número 4. Y finalmente el número 5, lamentablemente muy común no tener un plan. Por los ejemplos de algunas comunidades y proyectos muy exitosos como por ejemplo Linux, que nos tiene hoy aquí en este evento, o Kubernetes o muchos otros, solemos pensar que esas comunidades surgieron algo así como espontáneamente, de manera orgánica, casi arbitraria y como que sin que nadie lo hubiera exactamente planeado y eso no corresponde con la realidad. Para que esto ocurra, para que se forme una comunidad saludable alrededor de un proyecto, es necesario ser intencional, es necesario contar con un plan. En los planes que he visto adoptarse con éxito en el campo, por un lado estos contienen metas, metas muy específicas y más en el campo de lo pesimista que lo optimista, es decir, tratando de lograr pequeñas metas en corto tiempo, más que grandes metas que van a tomar quizá mucho tiempo, metas muy concretas y unas métricas, de nuevo las un tuelas métricas que nos permitan sobre todo saber si vamos en la dirección correcta o no. Por otro lado, estos planes suelen contar con una estrategia de difusión y sea una tecnología tradicional, hablaríamos de un plan de marketing, pero en Open Source llamémoslo difusión, es decir, cómo vamos a llegar a la comunidad a la que le interesa esto. Entonces, por ejemplo, nuestro proyecto de código abierto busca resolver un problema particular para desarrolladores.net. ¿Dónde están los desarrolladores.net? ¿A qué eventos van? ¿En qué meetups suelen reunirse? Vamos a escribir propuestas y vamos a enviar propuestas a esos eventos para ir a ir a hablar y contarles la idea y definir muy bien el problema y si esto resuena poder empezar a reunir estas personas alrededor del proyecto. Entonces, es un plan de difusión, pero también muy pensado, muy definida en si ya está claro el problema y ya está claro la idea que tenemos para resolverlo. Lo siguiente que debería estar claro es quiénes son nuestros usuarios potenciales y dónde están. Lo otro es que todo esto debería aterrizarse a tareas lo más específicas posible, lo más pequeñas posible, lo más granulares de tal manera que podamos ir teniendo este sentido de progreso continuo a medida que ejecutamos el plan y sobre todo muy importante un aspecto aquí es el tiempo. Deberíamos tener claro en qué momento queremos lograr esas primeras metas y en qué momento vamos a hacer una primera revisión de las métricas para saber si estamos en la dirección correcta o si hay que corregir el rumbo, especialmente que sea a tiempo para poder corregir el rumbo. Entonces, importante tener un plan para formar una comunidad saludable. Finalmente algunos recursos adicionales que he encontrado muy útiles en el camino de Open Source Way y esta guía referencial que pueden encontrar y sin costo alguno y arranca desde definir qué es código abierto, qué es una comunidad, por qué las personas suelen unirse a una comunidad y ahí va agregando más que todo el cómo hacerlo. Por otro lado, un clásico en el campo, The Art of Community, por John O'Bacon, yo no es una persona muy experimentada en la materia comunidad del bien de la comunidad de Linux, de Ubuntu, entre otras, y el libro lo puede encontrar gratuito en formato digital en ese link. Y finalmente el libro de Nadie Aikbal que va un poco más en el asunto del punto de vista de quién mantiene el código abierto. El verdadero desafío, el reto que es crear y mantener software de código abierto. Bien. Si tienen alguna pregunta, algún comentario pueden dejarlo aquí en el chat de la sesión o buscarnos luego para poder tener una conversación en lo que sea que podamos colaborar. Quiero agradecer Linux Foundation por la oportunidad al equipo de Open Source Summit Latin America en su primera edición. Estoy muy feliz de haber participado. Gracias.