Lo que le debemos a los demás

Hola, JS Nation. Mi nombre es Brian Hughes y soy un ingeniero de front-end en Patreon. He sido parte de la comunidad de código abierto durante aproximadamente una década, lo cual es bastante sorprendente si lo piensas. Sabes, he visto cómo esta comunidad ha crecido mucho durante ese tiempo. Y sabes, he tenido la suerte de poder desempeñar diversos roles dentro de la comunidad. Sabes, he iniciado mis propios proyectos de código abierto más pequeños. Solía estar bastante involucrado en el proyecto Node.js. También he trabajado en relaciones con desarrolladores en la comunidad. He presentado en muchas conferencias y, sabes, he utilizado el código abierto en mi trabajo diario mucho. Y a lo largo de este tiempo, he pensado mucho en lo que se necesita para construir una buena comunidad y cómo podemos ayudar a que esta comunidad prospere porque realmente somos independientes al final del día. Así que quiero dedicar esta charla a hablar exactamente de eso. ¿Cómo ayudamos a hacer crecer esta comunidad? ¿Cómo nos ayudamos mutuamente? Básicamente, sabes, ¿qué nos debemos unos a otros?

Esta charla está inspirada en el libro del mismo título de T. M. Scanlon. Scanlon es un profesor de filosofía moral, escribió este libro hace unos 25 años. No espero que muchos de ustedes hayan leído este libro en realidad. Admito que yo mismo solo he leído aproximadamente un tercio de este libro hasta ahora, pero muchos de ustedes han visto este programa, The Good Place. Resulta que The Good Place está realmente inspirado en el libro de T. M. Scanlon y tiene esa filosofía en el núcleo del programa y la serie. Me encanta el programa porque trata sobre crecer y mejorar cada día y cómo nos unimos, nos apoyamos mutuamente. Y es, sabes, a través de todos estos personajes que se acercan cada vez más que logran, sabes, tener éxito en todas sus locas aventuras en las que se embarcan. Y se trata simplemente de la comunidad. Sabes, eso es lo que hacen es formar su propia pequeña comunidad. Y sabes qué, nosotros también somos una comunidad. Puede que no siempre parezca así, pero realmente lo somos. Incluso si solo estamos usando código abierto, todavía estamos participando en esta comunidad. Y, por supuesto, para todos ustedes que están escuchando en este momento, esta es una conferencia para que nos unamos como una comunidad. Y creo que esto es muy importante. Y me ha llevado a reflexionar sobre esta pregunta de qué significa ser una buena comunidad

Comencemos hablando de las empresas y el papel que tienen en la comunidad JavaScript. Porque en realidad, en estos días, las empresas se benefician del código abierto. Cada aplicación web que se me ocurre hoy en día seguramente tiene el código abierto en su núcleo. ¿Cuántas aplicaciones web que las empresas han creado están llegando a los clientes y todo eso, cuántos de esos productos se basan en Node.js o Python u otros entornos de ejecución de servidor de código abierto? ¿Cuántas aplicaciones se escriben usando React? ¿Cuántas se escriben usando Webpack para construir? ¿Cuántas usan TypeScript? ¿VS Code? Todos estos son de código abierto. Algunos de ellos fueron creados por empresas, sí, pero no todos. Pero todos son de código abierto de todos modos. Y así, sabes, el hecho de que podamos construir código mucho más rápido, podemos construir aplicaciones más complicadas más rápido de lo que solíamos poder, incluso si todavía se siente como si estuviera, sabes, sacando dientes a veces, hay tantas opciones. Hemos mejorado mucho gracias al código abierto. Y las empresas se benefician de esto. Y así, sabes, creo que es realmente importante que las empresas devuelvan. Y la principal forma en que las empresas pueden hacer esto es apoyando con tiempo y dinero. Y, sabes, sé que suena como si las empresas deberían ser altruistas, pero no es realmente el caso. Hay una simbiosis entre las empresas y la comunidad de código abierto. Y el apoyo de las empresas al código abierto en última instancia también les ayuda a ellas. Un buen ejemplo es que solía trabajar en una startup llamada Observable. Y basamos nuestro editor de código en el proyecto de código abierto CodeMirror, que es un gran proyecto, por cierto. Mucho trabajo excelente de Ren, el mantenedor principal, y todos los demás que trabajaron en él. Y porque lo estábamos usando como una parte fundamental de nuestro producto, Observable terminó patrocinando el proyecto. Donamos dinero específicamente para que todos los mantenedores del proyecto pudieran dedicarse a él a tiempo completo. Y al hacerlo, el proyecto creció más rápido, se volvió más confiable, se corrigieron errores, todo eso que al final nos ayudó a nosotros también. No tuvimos que contratar a alguien para hacerlo nosotros mismos porque pudimos permitir que el proyecto lo hiciera por nosotros. Fue una gran relación simbiótica entre los dos. Creo que todas las empresas, al menos si el código abierto es una parte fundamental de lo que hacen, si hay especialmente uno o dos proyectos que están en el corazón de lo que hacen, deberían pensar en cómo pueden contribuir. Con el proyecto Node.js, por ejemplo, las empresas pueden convertirse en miembros de la OpenJS Foundation,

Entonces, lo que hace DevRel, que lo llamamos DevRel abreviado, relaciones con los desarrolladores, es conectar a las empresas y a la community entre sí. La idea es que cuando alguien está trabajando como defensor de desarrolladores, estamos saliendo a la community. Y esto implica asistir a conferencias y dar charlas, dirigir talleres, todas estas cosas para ayudar a la community a aprender más sobre los productos que la empresa ofrece. Y por lo general, los profesionales de DevRel están asociados con un producto específico o un par de productos en el área de experiencia de IOS. Y también están tratando de hacer que las personas de la community utilicen esos productos. Hay un poco de aspecto de ventas en ello. Aunque no creo que eso sea algo malo. Creo que las ventas a menudo tienen mala reputación. ¿Quién pensaría que estaría defendiendo las ventas en esta charla hoy? Pero eso es solo una parte de lo que hace DevRel. Entonces, DevRel también recibe comentarios de la community y los lleva de vuelta a la empresa. Y así hay una comunicación bidireccional entre la community y las empresas que DevRel facilita. Bueno, al menos en teoría. Desafortunadamente, lo que he visto en la práctica no es eso. Es realmente difícil ser DevRel y equilibrar las cosas de manera que el trabajo que hace DevRel beneficie tanto a la empresa como a la community. Y hay mucha presión sobre los DevRels y también muchos incentivos que no son buenos. Pero aquí es donde, como DevRel, es donde tenemos cierta influencia. Y aquí es donde debemos asegurarnos, cuando eres un DevRel, de que estás siendo un buen miembro de la community. Y lo primero y más importante que debes hacer es ser honesto y transparente acerca de lo que estás haciendo. Entonces, si estás dando una charla en una conferencia, dirigiendo un taller, cualquier cosa de ese tipo,

Y de alguna manera, no puedo creer que tenga que decir esto, pero en mi experiencia, es necesario decirlo. Es muy fácil, desde la perspectiva de incentivos de la empresa, que DevRel intente obtener ganancias a corto plazo para la empresa, y esto a menudo se hace a expensas de la community. Cuando trabajaba como DevRel en una empresa que no mencionaré, intentaron implementar un programa en el que buscaban a los mayores detractores de los productos en los que estábamos trabajando y que tenían cierta cantidad de seguidores o notoriedad en la community. Luego, querían que nosotros, como DevRel, aprovecháramos nuestra amistad para hacer que cambiaran de opinión. No se nos permitía decirles que estábamos haciendo eso. Incluso se suponía que debíamos rastrear conversaciones privadas sin el conocimiento o consentimiento de las personas involucradas. Por supuesto, nos opusimos rotundamente a eso y logramos que cancelaran el proyecto, pero este tipo de cosas sucede. Algo que deben tener en cuenta aquellos que no son DevRel es que la mayoría de las organizaciones de DevRel, rastrean en gran medida todo lo que las personas dicen en línea en Twitter, en GitHub y en otros lugares de código abierto. Realizan análisis de sentimientos y cosas por el estilo. Todos estos son datos públicos, así que supongo que no deberíamos sorprendernos demasiado. Casi todas las organizaciones que tienen un poco de enfoque en ventas hacen esto. Pero, ya sabes, algo que todos deben recordar. Y siempre habrá algo de eso.

Como DevRel, es importante que te resistas cuando las cosas cruzan una línea. Y lo último que creo que es importante que haga DevRel es asegurarse de que esta comunicación bidireccional sea realmente bidireccional. Muchas veces, es muy fácil salir a la community y hablar de lo que la empresa quiere que hables, para eso te contrataron. Y eso, ya sabes, hace que la empresa esté contenta. Pero luego está esa otra parte de recibir comentarios de la community y llevarlos de vuelta a la empresa. Y ahí es donde a menudo veo que las cosas fallan. Esto puede ser informes de errores y comentarios típicos, ¿verdad? Esperemos que DevRel tenga buenos canales para eso. Pero donde veo que esto falla más es a un nivel más alto. Y esto no se trata de, oh, esta característica específica en este producto es un poco extraña. Se trata más de cosas como, este producto que están vendiendo no es bueno para la community. Fomenta malas prácticas, fomenta el encierro o cualquiera de estas cosas. Creo que todos conocemos esos productos. Esos que parecen un poco depredadores, digamos. Y lo que he notado y lo que suele suceder, desafortunadamente, es que cuando esos comentarios se hacen desde la community a DevRel, DevRel los devuelve y simplemente caen en oídos sordos.

Entonces, como DevRel, es importante que hagas todo lo posible para asegurarte de que tu empleador realmente esté escuchando esos comentarios.

Muy bien, ahora pasemos a los mantenedores del proyecto y colaboradores de proyectos de código abierto. Y los colaboradores son una parte importante de esto, pero me voy a centrar principalmente en los mantenedores en esta parte de la charla. Los mantenedores hacen que la web funcione. Los mantenedores son tan críticamente importantes que, ya sabes, suena como una afirmación grandiosa, pero es verdad. Ya sabes, sin los mantenedores, no tenemos código abierto. Y sin código abierto, no tenemos la web moderna. Así de simple. Y sé que esto es algo obvio de decir, ¿verdad? Ya sabes, si no hay nadie que desarrolle código abierto, no hay código. Pero siento que tendemos a darlo por sentado muchas veces. Nosotros, como empresas, desarrolladores que trabajan allí, simplemente damos por sentado que el código abierto es tan común ahora. Casi no podemos imaginar un mundo sin él. Así que no pensamos en lo que a menudo está en juego. Y los mantenedores son simplemente tan, tan críticamente importantes.

Y desde el papel de un mantenedor, hay un par de cosas que creo que son realmente importantes para que los mantenedores hagan para asegurarse, en nuestro caso, de que los proyectos de código abierto sigan funcionando. Lo primero que hay que recordar es que los proyectos de código abierto son más que solo código. Algo que siempre me ha gustado decir desde hace mucho tiempo es que puedes escribir el mejor código del mundo. Puede ser eficiente, escalable, extensible. Puede tener una API increíblemente elegante. Puede tener todas esas cosas. Puede ser lo mejor que hay. Pero si no está documentado, prácticamente no existe. Porque la verdad es que la documentación es más importante que el código. Lo sé, puede ser difícil de aceptar. A la mayoría de nosotros no nos gusta escribir documentación. Ciertamente, a mí no me gusta. Pero es tan importante para el éxito de un proyecto. Y ya sabes, necesitamos todo tipo de documentación. Necesitamos tener esas guías de API que tienen, ya sabes, la referencia de todos los detalles de cómo funciona. También tenemos que tener las guías de inicio, ya sabes, los tutoriales.

Ya sabes, también necesitamos, ya sabes, registros de cambios y guías de actualización y cosas así. Y es sorprendente la cantidad de proyectos de código abierto con los que me he encontrado que ni siquiera tienen un registro de cambios. Y así que veo que hay, ya sabes, una actualización importante de la versión. No tengo idea de qué se rompió a menos que vaya y lea los commits que a veces hago, pero a veces simplemente me rindo y uso otro proyecto o algo así. Así que es importante que tengamos esa documentación para nuestros proyectos para poder atraer a las personas a nuestros proyectos y, ya sabes, hacer que se unan y utilicen nuestros proyectos y estén contentos con ellos. Ya sabes, y al menos con suerte, ya sabes, esa es toda la razón por la que incluso creamos estas cosas como código abierto en primer lugar es compartir nuestro código con otros para que otras personas, con suerte, lo utilicen.

Y lo siguiente es ser inclusivo porque realmente te ayudará si puedes ser inclusivo y dar la bienvenida a nuevas personas a tu proyecto. Y sé que esto es algo de lo que se ha hablado mucho. Algunas personas pueden pensar que demasiado, pero no creo que realmente se haya entendido completamente. La inclusividad es tan importante, y me refiero a la inclusividad en el sentido clásico de, ¿estamos dando la bienvenida a personas de diferentes géneros, personas de diferentes razas y cosas así? Hay otras partes de las que siento que se habla incluso menos en el código abierto y que son igual de importantes. Y por ejemplo, ¿qué tan inclusivos somos con las zonas horarias? Para el tipo de proyecto en el que, digamos, una vez a la semana todos nos reunimos en una llamada, lo cual, ya sabes, es bastante común. Digamos que somos un proyecto centrado en América del Norte. ¿A qué horas realizamos esas llamadas? ¿Nos aseguramos de tener horarios disponibles para personas en Europa para que no tengan que unirse a estas llamadas en medio de la noche? ¿Y qué pasa con las personas en Asia que tienen que unirse temprano, temprano en la mañana? Sabes, es importante que pensemos en cómo podemos atraer a más personas. Porque al final del día, ser más inclusivo y acogedor significa que más personas nos ayudan con nuestros proyectos, ¿verdad? Nunca he visto un solo proyecto del que tenga conocimiento que tenga demasiados desarrolladores. Demasiados desarrolladores y no suficiente trabajo por hacer. Siempre es lo contrario. Siempre hay mucho más trabajo por hacer de lo que hay personas para hacerlo. Y cuando nos enfocamos en la inclusividad en nuestro proyecto, significa que obtenemos más personas para hacer el trabajo, ¿verdad? Y eso ayuda a nuestros proyectos. Ayuda a que los proyectos sean más exitosos.

Y lo siguiente que quiero recomendar es aceptar el cambio. Como sabemos, la mejor manera de gestionar un proyecto cambia con el tiempo. Cuando comenzamos con ese proyecto, generalmente somos solo nosotros. Estamos programando en nuestra propia computadora portátil. Hacemos commits directamente en la rama principal y los subimos. Ya sabes, simplemente publicamos en NPM cuando queremos. Y eso es genial en los primeros días. Nos permite avanzar rápido. Pero a medida que incorporamos más colaboradores, eso se vuelve menos cierto. Entonces tenemos que empezar a pensar en cosas como, ¿cuál es nuestro proceso de pull request y cosas así, asegurándonos de que esté documentado. Y a medida que el proyecto continúa creciendo, entonces tenemos que empezar a pensar en, bueno, ¿cómo delegamos la toma de decisiones? ¿Tenemos que empezar a pensar en algo como, ya sabes, los grandes proyectos tienen, que generalmente es un comité técnico de dirección, y luego varios grupos de trabajo por debajo de eso. La forma en que abordamos el trabajo y a quiénes incorporamos como colaboradores y cómo se ve ese proceso necesita cambiar con el tiempo. Y si no estamos adaptando nuestro proyecto a medida que crece, entonces es una buena manera de asegurarnos de que se vuelva sin mantenimiento más adelante porque, ya sabes, colapsa bajo su propio peso. Lamentablemente, he visto algunos proyectos realmente grandes que han hecho esto, algunos que a veces incluso son algunos de los proyectos de código abierto más populares, ya sabes, en su área.

Y así, quiero terminar esta charla centrándome un poco en lo que nos debemos a nosotros mismos. ¿Cómo nos apoyamos en este proceso? Porque, sabes, la triste realidad es que en este momento los incentivos en el software de código abierto son inhumanos. Es extraño pensar que, sabes, pasamos todo este tiempo, sabes, contribuyendo y, sabes, solo para descubrir que nuestros proyectos son, sabes, utilizados por empresas que se llevan todo este dinero cuando, sabes, especialmente para aquellos que se dedican a tiempo completo al código abierto, sabes, pueden estar realmente luchando para llegar a fin de mes. Y sabes, nuevamente, como mencioné al hablar de informar errores, hay mucha virulencia. Hay mucha gente enojada. Sabes, es una de esas cosas donde, sabes, la triste realidad del código abierto es que si hacemos el mejor trabajo posible, nadie lo notará. La gente solo se da cuenta cuando cometemos errores. Y como somos humanos, cometemos errores. Y es difícil y brutal. Sabes, todos están sobrecargados de trabajo. Muchos mantenedores de código abierto que conozco están agotados. Las cosas no están bien en el mundo del código abierto. Me duele decirlo, pero es verdad. Realmente necesitamos trabajar en solucionar las cosas. Necesitamos trabajar en apoyar mejor a esta community. Y, sabes, no solo se trata de los mantenedores de código abierto que están luchando. También es DevRel. Sabes, como mencioné, realmente es difícil ser un DevRel ético en estos días. Las cosas necesitan cambiar. Pero, entonces, ¿qué podemos hacer al respecto? Bueno, sabes, la respuesta ha estado de alguna manera presente durante miles de años. Sabes, el dicho clásico de `conócete a ti mismo`. Sabes, mencioné que muchos mantenedores y profesionales de DevRel que conozco están agotados. Sabes, están agotados. Y creo que una de las cosas que he notado es que muchos ni siquiera se dan cuenta de que están agotados. Así que creo que una de las cosas realmente importantes para todos nosotros es aprender a reconocer, sabes, los signos de agotamiento o aprender y reconocer cuando estamos haciendo un trabajo que no es sostenible para nosotros o haciendo un trabajo que en última instancia no nos brinda satisfacción. Y todo se trata de entendernos a nosotros mismos porque solo cuando nos entendemos a nosotros mismos podemos comenzar a pensar en cómo podemos contribuir mejor y cómo podemos ser más sostenibles y más efectivos y ayudar a la community en su conjunto. Sabes, a veces significa que tenemos que replantearnos cómo nos involucramos. Sabes, tal vez necesitemos comenzar a delegar parte del trabajo a otras personas. Tal vez necesitemos, si somos mantenedores de código abierto, realmente comenzar a priorizar la incorporación de otros mantenedores a expensas de desarrollar nuevas características. A veces en DevRel, tal vez signifique que necesitamos cambiar de equipo o cambiar de empresa para seguir haciéndolo.

Pero sabes, al mismo tiempo, a veces lo mejor es simplemente irse porque la verdad es que dejé DevRel hace varios años y nunca volveré. En realidad, estaba en otra conferencia, una que era realmente importante para mí y tuve este momento de revelación donde me di cuenta de que no había forma posible de hacer el trabajo en la empresa para la que trabajaba y ser un miembro ético de la community. Siempre tenía que luchar contra ambas cosas. Y así que lo mejor para mí fue irme.

También he dejado en su mayoría el código abierto. Todavía hago algunos proyectos personales, pero dejé un proyecto de OJS. Ya no estoy involucrado en el día a día en absoluto. De ninguna forma en ese proyecto. Ciertamente sigo en contacto con la gente. Me encanta hablar con ellos, pero ya no estoy involucrado. Y esa fue la decisión correcta para mí. Esa fue un área de crecimiento tan importante para mí y ahora soy mucho más feliz y saludable por eso. Pero eso apesta. Pero el código abierto debería ser parte de nuestra vida y no todo. Todo se trata de cómo encontramos ese equilibrio saludable. Porque si estamos agotados, si apenas estamos aguantando, no le estamos haciendo ningún favor a nadie, incluidos nuestros proyectos. Si estamos agotados, eso hace que sea mucho más difícil para nosotros como mantenedores ser amables y comprensivos en los informes de errores. Si estamos agotados como DevRel, es mucho más difícil asegurarnos de que estamos haciendo lo correcto y resistirnos a nuestros empleadores cuando es necesario.

Pero a pesar de toda esta negatividad, en última instancia, todavía tengo esperanza. Estoy empezando a ver señales de que esto está cambiando. Estoy viendo que se habla mucho más sobre el agotamiento con los mantenedores de código abierto. Estoy empezando a ver más discusiones sobre DevRel y cómo hacerlo de manera ética. Y la razón por la que veo que esto sucede es porque estamos hablando más entre nosotros. Sabes, estamos empezando a apoyarnos más y ayudarnos mutuamente, y creo que esa es la salida. Así que quiero terminar con una cita de The Good Place nuevamente de Thierry Hennigan, quien dijo, ¿por qué deberíamos elegir ser buenos? Es por nuestros vínculos con otras personas y nuestro deseo innato de tratarlos con dignidad. En pocas palabras, no estamos solos en esto. Creo que esa es la clave. Cuando recordamos que somos una community juntos, si podemos ayudarnos mutuamente, así es como llevamos a nuestra community a un lugar mejor y más feliz y saludable en general. Y al ayudar a todos, ya sabes, incluidas las empresas. Gracias.