Lo que le debemos a los demás

Rate this content
Bookmark

El código abierto ha ganado y es el centro de gravedad de nuestra comunidad. Ya sea que seamos contribuyentes a proyectos de código abierto, ingenieros de productos comerciales, empresas, defensores de desarrolladores o cualquier otra cosa, todos somos parte de esta comunidad. Y le debemos a los demás, y a nosotros mismos, dejar la comunidad mejor de lo que la encontramos.


Pero, ¿cómo lo hacemos? ¿Qué responsabilidades tienen las empresas con la comunidad? ¿O los defensores de desarrolladores? ¿O los contribuyentes de código abierto? ¿En qué estamos fallando en esas responsabilidades y cómo podemos mejorar?


En resumen, ¿qué le debemos a los demás? Descubrámoslo.

24 min
05 Jun, 2023

Video Summary and Transcription

La charla trata sobre la construcción y el apoyo a la comunidad de JavaScript, el papel de las empresas en el código abierto, la importancia del tiempo y la colaboración, informar errores con amabilidad, los desafíos de las relaciones con los desarrolladores, el papel de los mantenedores y la documentación, la importancia de la inclusión, aceptar el cambio en el desarrollo de proyectos, apoyarnos a nosotros mismos y a la comunidad, y encontrar esperanza para una comunidad mejor.

Available in English

1. Construyendo una Comunidad JavaScript Próspera

Short description:

Hola, JS Nation. Soy Brian Hughes, un ingeniero de front-end en Patreon. He sido parte de la comunidad de código abierto durante una década, desempeñando diversos roles y contribuyendo a proyectos como Node.js. En esta charla, discutiré cómo podemos hacer crecer y apoyar nuestra comunidad y lo que significa ser un ciudadano ejemplar.

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

2. El Papel de las Empresas en la Comunidad JavaScript

Short description:

Esta es una pregunta complicada. Y no hay una respuesta única para todos. Mucho depende del tipo de papel que tengas dentro de la comunidad. Me voy a centrar en tres roles específicos: el papel de las empresas, las relaciones con los desarrolladores y los mantenedores de proyectos. Las empresas se benefician del código abierto y es importante que devuelvan apoyando el código abierto con tiempo y dinero. Las empresas y la comunidad de código abierto tienen una relación simbiótica. Un buen ejemplo es Observable patrocinando el proyecto CodeMirror, lo cual mejoró su producto y ayudó al crecimiento del proyecto. Las empresas deberían considerar contribuir a proyectos de código abierto, como convertirse en miembros de la OpenJS Foundation.

ser un ciudadano ejemplar en la comunidad JavaScript. Esta es una pregunta complicada. Y no hay una respuesta única para todos. Mucho depende del tipo de papel que tengas dentro de la comunidad. Y podríamos pasar todo el día hablando de los diferentes roles que las personas pueden desempeñar. Pero solo tenemos un tiempo limitado juntos, así que me voy a centrar en tres roles específicos. Me voy a centrar en el papel de las empresas, en el papel de las relaciones con los desarrolladores y en el de los propios mantenedores de proyectos.

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,

3. La Importancia del Tiempo y la Colaboración

Short description:

Las empresas deben dar a los desarrolladores tiempo para contribuir a proyectos de código abierto que utilizan. Esto fortalece la relación simbiótica entre las empresas y el código abierto. Ayuda a los proyectos a comprender el uso del producto y a las empresas a comprender el mundo del código abierto.

que supervisa el proyecto. Esa es una excelente manera de devolver. Pero no se trata solo de dinero. El dinero es importante, pero el tiempo también lo es. Sabes, lo que me encantaría ver más, esto no es muy común, pero lo que me encantaría ver más es cuando las empresas dan a los desarrolladores, sabes, un 5%, 10% de la semana para contribuir a proyectos de código abierto que esa empresa utiliza. Esta es otra forma de enriquecer aún más esa relación simbiótica entre los dos. Porque, ya sabes, cuando las empresas devuelven a proyectos de código abierto, ayuda, ya sabes, los propios proyectos tienen una mejor comprensión de cómo se utilizan los productos, o sus proyectos, dentro de los productos. Pero también en sentido contrario, ayuda a las empresas a comprender mejor el mundo del código abierto y esos proyectos de código abierto. Y poder planificar mejor cómo se mueven las cosas, qué tan rápido o lento suceden las cosas

4. Reportar Errores y Ser Amable

Short description:

Un papel para nosotros como desarrolladores es reportar errores en proyectos de código abierto. Sin embargo, al hacerlo, es importante abordarlo con amabilidad y no desahogar nuestras frustraciones en los mantenedores. Muchos mantenedores trabajan en proyectos en su tiempo libre o como parte de su trabajo, que generalmente es a tiempo parcial. Debemos ser conscientes de sus recursos limitados y ser considerados en nuestros informes de errores.

lanzados, corregidos y actualizados. Pero, sabes, muchos de nosotros no ocupamos una posición de poder tal que podamos tomar estas decisiones, ya sabes. Donde veo que a menudo, ya sabes, esto está un poco por encima de nuestro nivel salarial. Pero también tenemos un papel que desempeñar. Y ese papel es que los desarrolladores deben reportar errores. Siempre que nos encontremos con errores en código abierto, como todos lo hacemos, ciertamente he encontrado algunos. Debemos asegurarnos de informar sobre esos errores en esos proyectos, de hacerles saber, eh, nos encontramos con este problema. Pero cuando lo hagamos, debemos hacerlo con amabilidad. Ya sabes, también he estado involucrado en código abierto. Así que, he estado en el otro lado de esto. Y desafortunadamente, una cosa que noté es que muchas personas que informan errores se sienten un poco con derecho, de alguna manera, a recibir soporte inmediato. Y entiendo de dónde viene eso. Cuando nos encontramos con estos errores, ya sabes, nos frustramos. Y comprensiblemente. Estos errores son las cosas que nos impiden, ya sabes, lanzar las funciones que necesitamos lanzar, especialmente cuando tenemos un plazo. Pero debemos asegurarnos de no desahogar eso en los propios mantenedores de código abierto. Y desafortunadamente, veo que eso sucede con demasiada frecuencia. Así que, cuando informamos errores, debemos recordar que muchas veces estas personas, lo hacen en su tiempo libre. E incluso si lo hacen como parte de su trabajo, su trabajo remunerado real, generalmente es solo a tiempo parcial. Y, ya sabes, estos proyectos son

5. Developer Relations and Balancing Interests

Short description:

Las relaciones con los desarrolladores, también conocidas como DevRel, es un campo más nuevo que conecta a las empresas con la comunidad. Los profesionales de DevRel asisten a conferencias, dan charlas y dirigen talleres para ayudar a la comunidad a aprender sobre los productos de la empresa. También recopilan comentarios de la comunidad y facilitan la comunicación entre la comunidad y la empresa. Sin embargo, ser un DevRel es un desafío debido a la necesidad de equilibrar los intereses tanto de la empresa como de la comunidad. Es importante que los DevRels sean honestos y transparentes en sus interacciones con la comunidad.

típicamente con recursos limitados. Por lo tanto, debemos recordar eso y simplemente ser amables. Siguiendo adelante. Y ahora, quiero hablar sobre las relaciones con los desarrolladores. Es posible que no hayas oído hablar de esto antes. Es un campo más nuevo. Definitivamente es mucho más pequeño. Y también se le conoce con muchos nombres. También se le llama evangelismo de desarrolladores, defensa de desarrolladores, evangelismo técnico. Y, ya sabes, estos son solo los títulos que tuve cuando trabajaba en ese trabajo. Hay incluso más por ahí. Pero es una parte realmente importante y grande de la community en estos días.

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,

6. The Role of DevRel and Feedback

Short description:

Estoy aquí para hablar sobre el apoyo a los productos como DevRel. Es importante ser abierto, honesto y transparente. DevRel no debe ser explotador. Algunas empresas pueden intentar aprovechar las amistades para cambiar la opinión de los detractores. Las organizaciones de DevRel rastrean en gran medida los datos públicos, pero deben resistirse cuando se cruza una línea. DevRel debe garantizar una comunicación bidireccional para recibir comentarios, especialmente sobre productos que pueden ser perjudiciales para la comunidad.

Sé abierto y honesto. Di, soy un DevRel en esta empresa. Estoy apoyando estos productos, y hoy estoy aquí para hablar de ellos. Esto no tiene por qué ser algo malo, pero debemos ser abiertos, honestos y transparentes sobre el trabajo que realiza DevRel. Y específicamente, como parte de eso, no debemos ser explotadores.

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.

7. The Role of Maintainers and Documentation

Short description:

Entonces, como DevRel, es importante que hagas todo lo posible para asegurarte de que tu empleador realmente esté escuchando esos comentarios. Los mantenedores hacen que la web funcione. Sin los mantenedores, no tenemos código abierto. Y sin código abierto, no tenemos la web moderna. Los proyectos de código abierto son más que solo código. La documentación es más importante que el código. Es tan importante para el éxito de un proyecto.

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.

8. Importance of Documentation in Open Source

Short description:

Necesitamos registros de cambios y guías de actualización para nuestros proyectos de código abierto. Sin documentación, es difícil para los usuarios entender qué cambios se han realizado y qué puede haberse roto. La documentación es crucial para incorporar a los usuarios y garantizar su satisfacción. El objetivo del código abierto es compartir código y que otros lo utilicen.

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.

9. Importance of Inclusivity and Welcoming

Short description:

Ser inclusivo es crucial en proyectos de código abierto. Va más allá de dar la bienvenida a personas de diferentes géneros y razas. También debemos considerar la inclusividad en términos de zonas horarias. Al acomodar diferentes zonas horarias, podemos involucrar a más personas y beneficiarnos de sus contribuciones. La inclusividad lleva a que más desarrolladores trabajen en proyectos, lo que en última instancia los hace más exitosos.

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.

10. Embracing Change in Project Development

Short description:

Acepta el cambio como la mejor manera de gestionar un proyecto que evoluciona con el tiempo. Inicialmente, solo somos nosotros programando en nuestra propia computadora portátil, haciendo commits directamente en la rama principal y publicando en NPM cuando queramos. Pero a medida que incorporamos más colaboradores, necesitamos establecer un proceso de pull request, documentarlo y delegar la toma de decisiones. Adaptar el proyecto a medida que crece es crucial para evitar que quede sin mantenimiento.

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.

11. Supporting Ourselves and the Community

Short description:

Los incentivos en el software de código abierto son inhumanos. Contribuimos mucho, pero las empresas se llevan todo el dinero. Los mantenedores de código abierto y los profesionales de DevRel están agotados. Necesitamos trabajar en solucionar las cosas y apoyar mejor a la comunidad. Es importante reconocer los signos de agotamiento y entendernos a nosotros mismos para contribuir de manera efectiva. A veces necesitamos delegar trabajo o traer a otros mantenedores. Los profesionales de DevRel pueden necesitar cambiar de equipo o de empresa.

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.

12. Leaving DevRel and Finding Hope

Short description:

Hace varios años dejé DevRel porque no podía equilibrar mi trabajo en la empresa y ser un miembro ético de la comunidad. También he dejado en su mayoría el código abierto, excepto por proyectos personales. El agotamiento dificulta ser amable como mantenedores o resistirse como DevRel. Sin embargo, tengo esperanza porque veo más discusiones sobre el agotamiento y las prácticas éticas. Al apoyarnos y ayudarnos mutuamente, podemos crear una mejor comunidad para todos, incluyendo a las empresas.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
16 min
How to Build Your Own Open Source Project
We all used open source projects every day such as npm packages, editors, web applications, and even operating systems... Have you ever thought of building one of your own? In this talk, I will share my journey building jest-preview, from when it was just a vague idea, to currently a well-adopted library to help frontend engineers write tests faster. I will share with you how to come up with an idea for a project to work on, what is the struggles you have to overcome as an author of an open source project, how to manage time efficiently, and how you get attention from engineers around the world.
Vue.js London 2023Vue.js London 2023
11 min
The Hidden Cost of Open Source
There is a cost that many companies don’t consider when using open source. It can cost a lot of money and time to keep upgrading sunsetted versions.Open source is free for companies to use until the author sunsets a version.These are some best practices that we we recommend when considering open source adoption:        - Who is the author? Do they have a strong reputation that is going to be around for a long time? Do they have the resources to support an enterprise library?        - How much online support is there in the community for this library? How many dependencies are on this library?        - Does it have an end of life policy? What’s going to happen when they rev on a version? Will companies have an option to stay on older versions for a long time?        - What should you consider when migrating to a supported framework after a version has been sunsetted?
TypeScript Congress 2022TypeScript Congress 2022
30 min
Lessons from Maintaining TypeScript Libraries
Maintaining widely-used JS libraries is already complicated, and TypeScript adds an additional set of challenges.

Join Redux maintainer Mark Erikson for a look at some of the unique problems TS library maintainers face, and how the Redux team has handled those problems. We'll cover:

- Tradeoffs of different ways to define TS types for a library
- How to target different versions of TS, and considerations for determining the supported version range
- Migrating existing JS libraries to TS
- Differences between writing "app" types and "library" types
- Managing and versioning public types APIs
- Tips and tricks used by types from the Redux libraries
- TS limitations and possible language-level improvements
Vue.js London 2023Vue.js London 2023
24 min
Patterns for Large Scale Vue.js Applications
What is the best way to structure a Vue.js application so that it can scale to meet all your users' needs? There are multiple patterns established by the Vue community and the programming community at large that can be adopted in order to make your codebases more predictable, maintainable, and extendable.
Vue.js London 2023Vue.js London 2023
31 min
Nuxt 3 Modules and Open-Source
Nuxt modules are the de-facto way of extending our Nuxt applications with new behaviors and functionalities. Have you ever built your own? Why would you bother with hundreds of modules already out there? Let's answer those questions together and see why making your own modules in Nuxt 3 can both help you have a deeper understanding of how Nuxt works while also paving the way for you to get into open source!
React Day Berlin 2022React Day Berlin 2022
8 min
Making an Open Source Library Financially Sustainable
React Flow is an open source library used by thousands of developers and hundreds of companies. How do we make sure it stays alive, and also free? I’ll share some insights along our journey from open sourcing React Flow to passing the “black zero,” including findings from our user research where we spoke to some of the people who support us every month.

Workshops on related topic

Node Congress 2023Node Congress 2023
85 min
Node.js: Landing your first Open Source contribution & how the Node.js project works
Workshop
This workshop aims to give you an introductory module on the general aspects of Open Source. Follow Claudio Wunder from the OpenJS Foundation to guide you on how the governance model of Node.js work, how high-level decisions are made, and how to land your very first contribution. At the end of the workshop, you'll have a general understanding of all the kinds of work that the Node.js project does (From Bug triage to deciding the Next-10 years of Node.js) and how you can be part of the bigger picture of the JavaScript ecosystem.

The following technologies and soft skills might be needed):
  - Basic understanding of Git & GitHub interface
  - Professional/Intermediate English knowledge for communication and for allowing you to contribute to the Node.js org (As all contributions require communication within GitHub Issues/PRs)
  - The workshop requires you to have a computer (Otherwise, it becomes difficult to collaborate, but tablets are also OK) with an IDE setup, and we recommend VS Code and we recommend the GitHub Pull Requests & Issues Extension for collaborating with Issues and Pull Requests straight from the IDE.

The following themes will be covered during the workshop:
- A recap of some of GitHub UI features, such as GitHub projects and GitHub Issues
- We will cover the basics of Open Source and go through Open Source Guide
- We will recap Markdown
- We will cover Open Source governance and how the Node.js project works and talk about the OpenJS Foundation
  - Including all the ways one might contribute to the Node.js project and how their contributions can be valued
- During this Workshop, we will cover Issues from the nodejs/nodejs.dev as most of them are entry-level and do not require C++ or deep technical knowledge of Node.js.
  - Having that said, we still recommend enthusiast attendees that want to challenge themselves to "Good First Issues" from the nodejs/node (core repository) if they wish.
  - We're going to allow each attendee to choose an issue or to sit together with other attendees and tackle issues together with Pair Programming through VS Code Live Share feature
    - We can also do Zoom breakrooms for people that want to collaborate together
  - Claudio will be there to give support to all attendees and, of course, answer any questions regarding Issues and technical challenges they might face
  - The technologies used within nodejs/nodejs.dev are React/JSX, Markdown, MDX and Gatsby. (No need any knowledge of Gatsby, as most of the issues are platform agnostic)
- By the end of the Workshop, we'll collect all (make a list) the contributors who successfully opened a Pull Request (even if it's a draft) and recognise their participation on Social media.