Discusión en Panel: Código Abierto y “Competencia Percibida” Entre Proyectos

Gracias, a todos, por unirse a este panel. Estoy seguro de que todos están muy emocionados de escuchar sus ideas sobre todo lo relacionado con el código abierto.

Así que la primera pregunta es, como contribuyentes de código abierto, involucrados en múltiples proyectos, ¿pueden compartir sus ideas sobre cómo deciden qué proyectos contribuir o crear? Podemos comenzar con Dan. Lo siento. La pregunta es, ¿en qué proyectos has trabajado? Solo ideas sobre cómo decides elegir en qué proyectos trabajar o crear. Oh. Quiero decir, creo que generalmente es, como, lo que necesitas para el trabajo. Esa tiende a ser la situación. Creo que, al menos en mi caso, no he creado muchos proyectos. He contribuido a varios. Pero en los casos donde creé algo, fue generalmente porque estaba construyendo un producto y necesitaba una pieza que no existía. Y traté de hacerlo. Y luego, a veces, intentas hacerlo utilizable por otras personas. Creo que se trata principalmente del proyecto que te inspira o intriga. Simplemente elige uno. Realmente no importa cuál. Simplemente no intentes hacer todos. Esa es la cosa más importante, creo. Y luego te conviertes en un experto en uno específico. Y eso es, como, realmente útil. Porque ves todos los diferentes entornos en los que la gente usa algo. Lo cual es a menudo realmente sorprendente. Pero eso solo requiere tiempo para acumular ese conocimiento. Así que simplemente elige uno que te intrigue.

Sí, creo que para mí fue realmente encontrar comunidades que sentía que me atraían. Al principio de mi carrera, estaba realmente interesado en datos abiertos y tecnología cívica. Y simplemente encontré personas realmente acogedoras en ese espacio. No tenía las habilidades aún en ese momento para realmente hacer un impacto significativo. Pero aún sentía que era un momento realmente interesante para estar explorando, en ese momento, estas bibliotecas de Ruby para procesamiento de datos. Y si no fuera por la comunidad alrededor de eso, tal vez ni siquiera hubiera comenzado esta carrera.

Creo que para mí siempre ha sido impulsado por el trabajo. O ahí es donde he encontrado los proyectos en los que quiero trabajar. Tuve un problema en el trabajo. Como, donde vi una pieza faltante a la que quería contribuir. Y luego lo hice. En el momento en que tenía tiempo libre. Comencé a aprender React a mediados de 2015. Algo relacionado con un proyecto laboral. Y fue casualmente el mismo momento en que salió Redux. Me ofrecí a escribir una página de preguntas frecuentes para la documentación de Redux. Dan lo aceptó y lo fusionó. Me dio derechos de commit. Me ocupé con React. Y luego me entregó las llaves de mantenedor de Redux a mí y a otro chico llamado Tim Dorr.

Le debo a Dan mi inicio en código abierto. No estaría aquí sin que él se ofreciera a decir, hey, puedes involucrarte. Y te lo debo a ti. Desde que me involucré por primera vez en Redux, también. Siempre que hablamos de esto, pienso en esta escena de Tom Sawyer. Pintando la cerca. O él pinta la cerca y la hace parecer la cosa más interesante que alguien puede hacer. Y luego alguien se hace cargo. Genial. Eso es tan genial. Y me encanta el hecho de que hablabas sobre las oportunidades que obtuviste.

Como alguien que quiere ser un contribuyente de código abierto, ¿qué oportunidades geniales has visto que otros obtengan? ¿Te has conseguido alguna? ¿Y qué le dirías a alguien que siente que no tiene suficiente tiempo para ello? ¿Cómo los convencerías para que realmente hagan tiempo para contribuir a proyectos de código abierto? Podemos ir al revés esta vez para cambiar un poco. Así que daré un ejemplo relativamente reciente. Hemos tenido dos mantenedores principales en Redux Toolkit durante los últimos par de años. Yo mismo y Lenz. Y teníamos a una persona en nuestro canal de chat respondiendo a un montón de preguntas llamada Ben.

Y hace aproximadamente un año, comenzó a contribuir con algunas pull requests reales con características. Y estaba entusiasmado y las pull requests estaban bien probadas y él estaba respondiendo preguntas y podíamos ver que estaba contribuyendo activamente. Y así que él fue como, tú eres un mantenedor, también. Bienvenido, únete a nosotros. Y es un poco así, mostrando la iniciativa y tratando de involucrarse, eso muestra a los mantenedores que estás interesado, obtienes su confianza, y estarán felices de entregar más responsabilidad.

Así que tengo una respuesta diferente. Y eso es, como, esa es una buena respuesta. Pero también tengo una diferente. Eso es, en cierto modo, verlo como parte de tu trabajo, también. Tal vez no contribuyendo con enormes cantidades de código o algo así, pero ustedes son desarrolladores de software y están usando bibliotecas de terceros. Así que si te encuentras con un error y quieres involucrarte en código abierto, lo mejor que puedes hacer es escribir una buena reproducción de ese error, presentar un problema muy bueno, y esa es una manera perfecta de involucrarte en código abierto. Y a medida que haces eso en diferentes proyectos, comienzas a aprender sobre el proyecto.

Ves las correcciones. Ves las pull requests que tal vez alguien más escribió. Y dado suficiente tiempo, podrías sentirte cómodo para realmente arreglar el problema tal vez en tu tiempo de trabajo donde te pagan por ello, si es una pequeña corrección y es algo que beneficia a tu empresa. Y cosas como presentar problemas y cosas así, no pidas permiso para hacer eso. Eso es parte de tu trabajo. Como, si estás pasando días en ello, por supuesto, es diferente. Pero sí. Sí, y otra cosa que encontré, especialmente en el curso de hacer tu trabajo diario, como, mi trabajo diario actualmente implica trabajar en un proyecto de código abierto, pero antes de eso, fui ingeniero de producto en un montón de diferentes empresas.

Y el último trabajo que tuve trabajando en un producto fue en Venmo. Así que estábamos usando muchas de las herramientas que todos usamos en esta sala, pero para pruebas, obviamente, la biblioteca de pruebas. Así que configurando todo un equipo para contribuir a un gran conjunto de pruebas, estábamos usando algunas reglas de linting de la biblioteca de pruebas ESLint plugin. Y navegando a través de los problemas de GitHub, vi que había algunas ideas para nuevas reglas para agregar a esa biblioteca y pensé, está bien, no he escrito una regla de ESLint antes. Esto parece una buena oportunidad para contribuir a algo que también beneficiará a mi equipo pero contribuir a la comunidad más grande. Y lo que fue tan genial sobre esa experiencia y, ya sabes, los increíbles mantenedores de ese proyecto es simplemente, ya sabes, salir de tu zona de confort, trabajando en, como en mi caso, ya sabes, entendiendo árboles de sintaxis abstracta, aprendiendo sobre todo el DX de desarrollar y probar reglas de linter, y luego recibiendo esta increíble revisión de código de personas que son extremadamente conocedoras en, ya sabes, en esta área en particular.

Y eso siendo como una oportunidad de aprendizaje increíble, no importa en qué etapa de tu carrera estés, ya sabes, el cliché sobre el software es que es un campo increíblemente vasto y expansivo. Y así que el código abierto para mí siempre ha presentado una oportunidad realmente divertida para salir de mi zona de confort y, ya sabes, poder dar y recibir mentoría de una manera realmente generativa, realmente productiva. Así que no creo que haya otorgado derechos de mantenedor a nadie que estuviera pidiendo por ello. Esa no es la forma en que funciona. Primero, es un poco lo opuesto, cada vez que se vuelve molesto no hacer de alguien un mantenedor, entonces yo hago de esa persona un mantenedor. Esa es básicamente la esencia. Suena muy negativo. Pero lo que quiero decir con eso es que, si las personas responden regularmente a los problemas, están como, oh, no puedo reproducir esto, o esta es la solución. Y luego responden, pero no pueden cerrar el problema.

Estoy como, Oh, sería muy conveniente si esa persona está en el lugar correcto cada vez, también cerraríamos el problema. Así que otorga los derechos para eso. Lo mismo con las pull requests. Si alguien presenta pull requests gratuitas, que son bastante buenas, entonces es molesto que esa pull request viva en su propia forma, porque no puedes comprometerte de nuevo y ese tipo de cosas. Así que los invitas a convertirse en mantenedores. Y así es como generalmente funciona, creo. Está bien, ¿puedo pedirte que repitas la pregunta? Ha pasado un tiempo. De hecho, no escribí esto. Esto vino de mi cabeza. Pero era solo sobre cómo convencerías a alguien de contribuir a código abierto y qué oportunidades has tenido. ¿Alguien más? Sí, supongo que no me veo en el negocio de convencer a las personas de contribuir a código abierto. Como, no es necesariamente una buena idea siempre. Como, tanto para tu cordura como para la de la otra persona. Como, está bien, más seriamente, creo que hay diferentes tipos de contribuciones. Y también, como, creo que algunos terminan, tú sabes, como, realísticamente, si envías la PR, a veces, ya sabes, se va a fusionar, se va a revisar.

A veces no se va a revisar, no se van a fusionar. Y a veces obtienes algo de buena experiencia de ello, o como que obtienes algo de conocimiento de ello. Y a veces simplemente desperdicias el tiempo. Así que creo que, como, en mi experiencia, siento que me he vuelto más perezoso al enviar pull requests, porque simplemente, bueno, parece que la persona que mantiene está bastante ocupada, como, sus revisiones no llegan rápido. O como, parece que el cambio que estoy a punto de hacer, como, ni siquiera sé si es un buen cambio. Así que probablemente simplemente no lo envíe. Así que no sé si, como, siempre es una buena idea. Pero creo que, como, como, creo que es importante estar preparado para la decepción de que trabajaste en esta pull request durante una semana y luego nadie la revisa, como que eso pasa. Pero en términos de, como, lo que como mantenedor, como lo que normalmente encontraría más valioso es, sí, así que como problema, cuando hay un problema, y no sé cuál es el problema, como, hay un error registrado. Y alguien dice, como, oh, esta cosa se está bloqueando, pero como, no sé cómo reproducirlo. Y luego alguien más viene y se adentra en el código y como que da una forma precisa de reproducir el error. Eso es muy valioso. Y así que, como, como mantenedor, digo, está bien, como esta persona está realmente como mirando lo que está sucediendo en el código, y está tratando de ayudar. Y simplemente confío más en esta persona. Y luego si esta persona envía un, ya sabes, un cambio de código, como, de nuevo, confío más en ellos, es más fácil de revisar.

Y creo que, si realmente quieres contribuir al open source, creo que hay como dos géneros. Como un género es que envías un pequeño cambio, y como que apenas, simplemente lo lanzas. Como, aquí está la cosa que funcionó para mí, como, buena suerte con eso. Y luego es, sigue siendo agradable, porque le da al mantenedor una oportunidad, como tal vez sea una buena idea, tal vez sea un buen cambio, o les da, ya sabes, una idea para hacer algo diferente. Pero es una contribución, ¿verdad? Simplemente envías algo ahí, y esperas que ayude a alguien, tal vez incluso a una persona al azar escaneando la pull request para encontrar la solución para el mismo problema.

Y otro género es en realidad como sumergirse en, como, cómo está escrito el resto del código del proyecto, y como que realmente probar tu cambio, realmente pensar, como, ya sabes, ¿es este el cambio correcto a hacer? ¿O rompe algo más? Y luego, como mantenedor, si veo que, ya sabes, parece que has hecho tu tarea, por así decirlo, es mucho más fácil confiar en eso, a veces estoy como, sí, como, ya sabes, se ve bien. Espero que esto no rompa nada. Pero si rompe algo, sé que hay una persona que se preocupa, que volverá y lo arreglará.

Sí, no lo sé. Eso es útil. No, gracias por eso. Esas son respuestas realmente buenas, porque hablaste mucho sobre colaboración, mejora de habilidades, y cómo puede ayudarte en tu trabajo diario a mejorar tus prácticas de codificación y cosas así. Pero estamos aquí por la competencia. Y entonces, ¿qué diferencia hay entre, porque toda competencia no es mala, ¿verdad? Hay competencia saludable. Pero, ¿qué diferencia hay entre la competencia saludable y la competencia no saludable? ¿Y cómo fomentas y aseguras que participemos en el tipo saludable? ¿Y sientes que como mantenedores, tienes un papel que desempeñar en esto? Así que empecemos con Dan.

Oh, esa es una difícil. Sí, no estoy, no lo sé. No quiero establecer las reglas. Creo que hay como una especie de código de honor, un código de honor implícito, pero creo que es diferente para diferentes personas. Como, no, ya sabes, no decir cosas malas sobre otros proyectos parece tal vez una buena idea. Pero luego hay algunas diferencias. Y a veces estas diferencias son bastante significativas. Y así hay como este equilibrio difícil de cómo, y especialmente como, hay, ya sabes, hay este equilibrio de que si todos son amables entre sí, es agradable.

Pero luego, si hay como un nuevo, ya sabes, hay como un conjunto establecido de jugadores, y luego hay un nuevo jugador que, como hace algo diferente. Y porque son pequeños, necesitan como golpear hacia arriba, porque necesitan como probar, ya sabes, aquí está por qué deberías elegir la cosa pequeña sobre algo establecido. Y así tienen que, como, exponer las fallas en el establecimiento. Y luego la cosa es, como, los jugadores establecidos no pueden realmente golpear hacia abajo porque se ve mal. Y así es como un equilibrio difícil de cómo juegas este juego. En realidad no lo sé. Escuchemos a otras personas.

Sí, creo que la competencia está un poco sobrevalorada. En algunos aspectos. Tengo como un montón de anécdotas realmente interesantes al respecto. Por ejemplo, trabajé durante bastante tiempo en mis bolsas. No me gustan mucho mis bolsas. Así que aquí está la parte divertida. Dennis está trabajando actualmente con MobX, yo estoy trabajando con Redux. No me gusta... Así que hasta ahí llega la competencia.

No, pero literalmente tuve personas que se acercaron a mí y dijeron, como, ¿por qué publicaste Immer? ¿Eso solo ayuda a Redux y MobX? Y es como, sí, ¿a quién le importa? A veces la gente piensa sobre open source como empresas, donde están como, las empresas compiten entre sí de cierta manera. Correcto. Y así también hablan como si eso fuera un problema. Y dicen, hey, si no introduces esta característica, voy a mudarme a Redux. Y es como, está bien, bien. Entonces, aparentemente Redux es mejor para el caso de uso. Así que prefiero que te mudes a Redux para que no tenga que lidiar con tus problemas. Así que la gente tiende a sobrevalorar cómo eso funciona en general, creo. Pero la regla que trato de mantener en mi mente, es como, básicamente eres un jitters ahí afuera. Como, tengo una opinión sobre otros frameworks. Todos aquí tienen una opinión sobre otros frameworks. Le pregunté a JetGPT esta mañana qué piensa Mark sobre MobX y no me hizo dormir realmente bien. Pero solo aluciné, tristemente. Pero de todos modos, como, todos estamos sesgados de cierta manera. Así que depende de ti decidir qué tipo de funciona.

Y creo que esa es la forma justa de dividirlo. Creo que eso está bien dicho. Sí, creo que toda la cuestión de la competencia, no lo sé, pienso en mi tipo de marco de referencia para la competencia es jugar deportes en la escuela secundaria. Y, ya sabes, específicamente baloncesto, fútbol, fútbol americano. Y, ya sabes, mis, como, mis entrenadores realmente inculcaron esta idea de que como, realmente quieres que la competencia en su mejor momento es cuando tu oponente realmente te empuja a evolucionar y a traer lo mejor que puedes traer a la mesa también. Así que realmente creo que, ya sabes, es como, soy un fanático del baloncesto, como dije, allí en el, en los EE. UU., que es donde vivo, originalmente canadiense. ¿Hay canadienses en la sala? ¿Puedo escuchar un par de quiénes? Ninguno. Uno. Uno. Increíble. Está bien. Uf, siempre hay un par de canadienses secretos acechando, así que solo tenía que asegurarme. Pero sí, hubo los campeonatos de la WNBA esta semana, y mi equipo, New York Liberty, perdió en un final reñido contra Las Vegas Aces, que son el mejor equipo.

Así que creo que ese es, ya sabes, el espíritu de competencia del que quiero ser parte en los ecosistemas de JavaScript y React, son como paneles como este, ya sabes, y no golpeando hacia arriba o hacia abajo o en cualquier, cualquier dirección donde estés, tratando de quitarle a lo que alguien más ha construido. Así que creo, creo que cosas como esta y reunirse en persona son simplemente súper productivas. Y como un gran recordatorio de que hay muchas, muchas, muchas otras personas que creo que comparten esa idea de competencia realmente productiva en ese sentido de que quiero sacar lo mejor de ti y de mí y al poner nuestras ideas, ya sabes, arrojándolas en el medio y viendo qué resulta, así es como vamos a obtener las mejores ideas en el final, ¿sabes? Sí, así es como lo veo.

Oh, respuestas tan geniales. Lo veo como academia, realmente, como, donde tal vez diferentes universidades compiten sobre la misma investigación, pero se trata principalmente de compartir ideas. Y se trata principalmente de las ideas compitiendo y las mejores ideas ganando si es una competencia. Así que no es una competencia entre individuos. Si es el tipo de competencia saludable que es, es una competencia de ideas. Y yo creo que, como, eso es lo que hace que sea tan genial conocerlos a todos y hablar sobre todas estas cosas. Porque es cuando las ideas pueden realmente chocar y formar algo mejor. Y pueden inspirarse mutuamente. Y compartimos muchos de los mismos problemas comunes también.

Así que como, hay esta forma de competencia donde compites y retienes información de alguien más porque quieres ganar. La competencia saludable, que es el tipo que creo que tenemos, es donde preferiríamos compartir estas ideas y discutirlas y hacer que todos nuestros frameworks sean mejores en el proceso. Así que ese es el tipo saludable, creo. Y pasé mucho tiempo leyendo hilos de discusión en Reddit y Twitter. Y veo a muchas personas fanatizando de la mala manera. Y diciendo, como, amo esta herramienta. Y cualquiera que le guste esta otra herramienta es una persona horrible. Y esa es totalmente la actitud equivocada. Yo creo que si y espero que si observas el comportamiento de los que estamos en el escenario y otros mantenedores en el ecosistema, somos amigables, nos llevamos bien, estamos compartiendo información.

Todos estamos tomando inspiración y aprendiendo ideas de las herramientas y avances y pull requests de los demás. Sabes, la biblioteca de recuperación de datos RTK query que es parte del Redux toolkit robó directamente la idea y se inspiró en React query y Apollo. He pasado trabajo este año tratando de averiguar cómo configurar correctamente los paquetes para la compatibilidad con módulos ES. Publiqué un artículo en el blog y sabes que Apollo y React query han aprendido de ello. Contribuí con los cambios a Emmer. Incluso tengo una cita en la parte superior de la documentación de Emmer diciendo lo maravillosa que es. Como, hay mucho intercambio de conocimientos de ida y vuelta.

Y sí, hay una especie de competencia en que si eliges usar React query para recuperar datos, probablemente no estés usando Redux para hacerlo. Pero está bien. Todos estamos tratando de construir herramientas que resuelvan problemas de maneras ligeramente diferentes. Y estamos tratando de hacer las mejores herramientas para que puedas decidir cuál es la mejor opción para tu situación. Me encantan esas. Oh, sí. Un aplauso por eso. Me encanta. Bueno, realmente quiero hablar sobre IA solo un poco. Simplemente me encanta. Yo solía usar copilot mucho. Y ahora que no lo estoy usando, estoy como, oh, Dios mío. Esto va a ser súper tedioso. Pero para aquellas personas que pueden sentirse intimidadas para entrar, o no entrar, sino esencialmente contribuir de una manera open source, ¿sientes que la IA y estas herramientas han ayudado a animar a estas personas a contribuir? ¿O qué piensas que ha sido el papel de la IA en términos de open source y tal vez colaboración y cosas así?

No he considerado realmente la IA y open source específicamente. Finalmente activé copilot en VS code hace unos meses. Y desde mi propia perspectiva personal, creo que la IA y el aprendizaje automático son herramientas potencialmente viables. Mi mayor preocupación es que en muchos aspectos parece que ya tienes que saber lo suficiente sobre el tema para usarlas de manera segura. He visto numerosos casos donde las personas entran y hacen preguntas y dicen, como, estoy tratando de usar una cierta API de Redux que fue sugerida por chat GPT, excepto que sugirió algo que literalmente no existe. O en un caso, una persona me preguntó sobre un artículo de blog que había escrito sobre la recuperación de datos en selectores, excepto que nunca escribí el artículo del blog. Ha visto suficientes ejemplos de mis URLs de blog para imitarlo y sugerirlo, y no existe. Y así que creo que especialmente muchos principiantes, están aprendiendo cosas geniales de, ya sabes, chat GPT y sugerencias, pero tienes que saber lo suficiente para filtrar las sugerencias tú mismo.

Así que mi propia experiencia, es como, ya sabes, copilot es genial para completar listas de código que estoy escribiendo, o, como, algunos fragmentos y piezas, pero debes tener un poco de precaución mientras usas estas cosas. Creo que mi perspectiva es que la IA puede ser utilizada para muchas cosas diferentes, ¿verdad? Hay la parte generativa donde escribe tu código por ti, pero yo creo que donde la IA podría brillar cuando se trata de open source, si quieres contribuir, es explicar esta base de código desconocida, porque los proyectos de open source son a menudo bastante complejos. El código se ve un poco diferente de lo que podrías estar acostumbrado en aplicaciones. Así que usar la IA para explicar y entender cómo un proyecto de open source funciona podría ser un caso de uso muy, muy bueno, creo.

Sí, yo tampoco he considerado realmente la IA en el contexto de open source, aunque trabajando en Apollo Client, que es un cliente de GraphQL, ya sabes, tengo algunos colegas que han estado pensando en la IA en el contexto de GraphQL, lo cual creo que es, ya sabes, un panel completamente separado y una conversación muy interesante. Pero sí, un colega mío, Patrick, tiene una charla, creo que ya está en línea, del GraphQL Summit justo sobre, ya sabes, generando, como, esquemas con IA y realmente mostrando algunos vislumbres del futuro y como pruebas de concepto. Pero ciertamente, creo que ciertas tecnologías, en particular, como un lenguaje de consulta, como GraphQL, hay, creo que habrá algunas maneras realmente interesantes en las que, ya sabes, realmente podremos convertir automáticamente comandos en lenguaje natural en consultas y realmente realizar esta idea de, como, la computadora como un verdadero, como, agente de usuario. Y así que sí, creo que es un, ya sabes, un tema fascinante en general, pero te animaría a que revises la charla de Patrick. Y, ya sabes, si estás interesado en ese nicho específico allí.

Sí, tampoco tenía muchos pensamientos al respecto. No pensé demasiado en ello. Lo único que descubrí es que, como, hay un beneficio de Brexit, y eso es que tienes más servicios de IA aquí que en la UE. No tengo mucho más que agregar, creo. Realmente estoy de acuerdo con que podría ser una forma útil de explorar la base de código. Pero sí, aparte de eso, bueno, GPT-4 es mucho mejor que GPT-3 aquí, por ejemplo, en, como, dar, como, respuestas falsas. Quiero decir, no mejor. Sí. Sí. Da menos respuestas falsas. Pero sí, no sé. Veremos. Veremos cómo va. Supongo que, como, una distinción es, como, creo que es interesante pensar que, como, open source suele ser, como, fundamentos compartidos. Pero luego siento que el lugar donde, como, la IA brilla más ahora es, como, construido sobre esos. Así que, ya sabes, es fácil, como, generar componentes de React, pero tal vez no, como, escribir React en sí. Así que no sé si hará su camino hacia, como, ser útil en los niveles más bajos donde tienes que tener esta precisión. Mientras que, como, en niveles más altos, cuando simplemente, como, compones cosas juntas, eso parece ser el, ya sabes, el lugar más cómodo para aplicar la IA ahora mismo. Gracias. Es tan interesante la forma en que la IA está, como, revolucionando la forma en que trabajamos. No diría que todos vamos a perder nuestros trabajos mañana.

Pero diré que definitivamente está ayudando, pero no es totalmente preciso, como estamos hablando. Y una cosa en la que quiero terminar es el hecho de que open source se extiende más allá del código. Y hay otras formas en las que podemos contribuir en términos de no código. ¿Pueden todos dar ejemplos para los últimos, como, ¿qué, dos minutos de formas en que las personas pueden contribuir cuando no se trata de codificación y buenos ejemplos que puedan tener? Como dije, comencé con Redux ofreciendo contribuir a una página de docs. Y cada proyecto necesita más documentación. Y a veces contribuyes, puedes contribuir a los docs sin necesidad de tener un entendimiento profundo del código. Las contribuciones a los docs son siempre, siempre bienvenidas.

Sí, estoy de acuerdo. Y comencé con Redux escribiendo las pruebas de renderizado del lado del servidor que faltaban. Así que escribir pruebas también es una buena, buena contribución. Incluso si no quieres contribuir con código que se ejecute en el navegador de otra persona, ya sabes. Además, como hablamos anteriormente, los problemas y buenas reproducciones son invaluables. Quiero realmente enfatizar ese punto. Ayudan tanto, tanto. Sí. Sí, un punto más sobre las reproducciones. Además de, sí, solo voy a agregarme a las respuestas que vinieron antes. Todas son tan importantes. Pero definitivamente, ya sabes, si estás investigando algo basado en un problema que estás enfrentando, y estás en los problemas de GitHub, y tienes unos minutos para spare y ves, ya sabes, una pregunta colgando que, ya sabes, es donde tienes la respuesta al alcance de tu mano, o tienes la capacidad de ayudar a crear esa reproducción o, ya sabes, simplemente mover la conversación de manera realmente positiva. Eso es súper, súper apreciado también.

Sí. Una cosa en la que pienso es que la competencia entre cosas a menudo puede ser vista como, o la gente la percibe como si tal vez una solución es más inteligente o moderna o más rápida o lo que sea que la otra. Pero eso generalmente no es de donde provienen los proyectos en competencia. Generalmente provienen de intentar resolver diferentes problemas. Pero esos a menudo no son muy explícitos, o son difíciles de comunicar realmente bien qué tipo de conjunto de problemas una solución está tratando de resolver. Y eso es generalmente donde está la diferencia. Así que si tienes como, un buen ángulo sobre eso, o sientes que esta solución funcionó realmente bien en estas circunstancias, eso es como súper valioso para la comunidad poder compartir eso. Porque como, a menudo tu perspectiva sobre eso es incluso mejor que la perspectiva de los mantenedores que tienen sobre tal cosa. Creo que lo que sea que te emocione. Como, si sabes, quieres hacer que una biblioteca sea más rápida, eso es como una cosa que quieres escribir un poco de docs, otra cosa, puedes simplemente ayudar a las personas en los problemas o en Twitter o lo que sea. Así que lo que sea que sientas que quieres hacer. Perfecto momento. Bueno, muchas gracias por esas respuestas y sus ideas. ¿Y podemos tener un aplauso, por favor?