Los caminos de Anthony hacia el código abierto - La teoría de conjuntos

Y es un gran honor estar aquí y gracias por recibirme. Y sí, permítanme presentarme un poco, supongo que soy una cara nueva para React. Así que mi nombre es Anthony Fu y soy el creador de Vitesse, LightDate, Unocss, y también el miembro coordinador de Vite, Vue y Nuxt. También mantengo algunos proyectos y actualmente trabajo en el laboratorio de Nuxt en el equipo de framework, así que también pueden encontrarme con los enlaces a continuación.

Y como pueden ver, a nivel de front-end, como a nivel de framework de front-end, soy bastante de la comunidad de Vue. Y esta es en realidad la segunda vez que asisto a un evento de React. Y este evento es increíble y realmente me hace sentir como en casa porque aquí tenemos el React con un toque de Vue. Sí. Así que gracias a todos por hacer posible este evento y es un gran honor hablar y compartir mi perspectiva con ustedes aquí. Como realmente no sé mucho sobre React para hablar, aquí está el trato. Hablaré sobre algo que les pueda resultar interesante fuera de React y ustedes me enseñarán cómo usar correctamente los ganchos de use-effect más adelante, ¿de acuerdo?

De acuerdo, como pueden ver, estoy trabajando en múltiples proyectos de código abierto y también he creado algunos proyectos que es posible que ya estén utilizando, como por ejemplo, Vitesse, un framework de pruebas único. Y como alguien que ha estado trabajando en código abierto durante un tiempo y ha ganado la vida con ello, tengo que decir que el código abierto es muy divertido y gratificante. Y creo que muchos de ustedes ya quieren contribuir al código abierto y ya lo están haciendo. Sin embargo, hay muchos factores que determinan si un proyecto de código abierto se vuelve popular o exitoso, dependiendo de cómo lo definamos. Por ejemplo, la calidad del código, la documentación, las comunidades, el marketing y demás. Todos son importantes y están relacionados entre sí y no hay una regla de oro que diga cómo se puede hacer un proyecto de código abierto exitoso. Así que aquí me gustaría compartir algo de mi experiencia e ideas para crear y mantener proyectos de código abierto, combinados con algunas observaciones que he aprendido de la comunidad. Espero que pueda darles algunas ideas nuevas para comenzar su propio viaje en el código abierto o encontrar nuevas ideas para mejorar su proyecto existente.

El código abierto es un tema bastante amplio y no puedo cubrirlo todo en una sola charla. Por eso intento dividirlo en diferentes aspectos del código abierto en cada charla y convertirlos en una serie. Esta es la primera y esta charla es la primera parte de la serie. Sé que puede sonar un poco aleatorio y pueden preguntarse qué significa eso y trataré de explicarlo. Digamos que ya tenemos un proyecto de código abierto o planeamos crear uno. Y para ser un poco prácticos, digamos que queremos obtener cierta cantidad de usuarios, cierta cantidad de adopciones o simplemente queremos que la gente disfrute usándolo y disfrute de nuestro trabajo duro. Entonces, una cosa a considerar es cómo nos imaginamos a nuestros usuarios objetivo. Por ejemplo, ¿mi herramienta es para usuarios finales o para desarrolladores? ¿Es para desarrolladores de Vue o para desarrolladores de React, etc.? Sabemos que es un hecho que, entre todos nuestros usuarios objetivo, solo una parte de ellos se convertirá en nuestros usuarios reales y también depende de muchas cosas, ¿verdad? Y depende de cómo lo estemos promocionando. Y para obtener más usuarios en nuestro proyecto, podríamos intentar convertir a más usuarios potenciales en usuarios reales, tal vez haciendo más marketing o puliéndolo. En ese caso, la cantidad de usuarios objetivo que tienes, los círculos más grandes, en realidad se convierte en el límite superior de la cantidad de usuarios reales que podrías tener. Y por otro lado, también podemos intentar encontrar una forma de ampliar nuestros usuarios objetivo para incluir a más personas.

Naturalmente, también tendrás más usuarios reales convertidos a partir de él. Bajo estas ideas, veamos algunos ejemplos de cómo podemos hacerlo. El primer ejemplo que les mostraré es en realidad mi primer proyecto de código abierto en 2019 y el repositorio se llama VS Code-View-I18-LA. Es una extensión de VS Code que ayuda a los desarrolladores a lidiar con I18, con la llamada internacionalización, como previsualizar la traducción en tu code o gestionar las claves para cada idioma, etc. Y aquí tienes una captura de pantalla de la extensión que muestra la función básica y espero que te dé una idea básica de lo que es. Y la extensión no es el tema principal hoy. Pero al comienzo de este proyecto, tenía muchas ganas de hacer que este proyecto fuera popular, ya que realmente quería demostrarme en el código abierto. Estaba súper feliz cuando obtuve las primeras 100 y 200 estrellas. Y luego recibí un reconocimiento de la comunidad. Pero después de eso, comencé a buscar metas más altas. En ese momento, soñaba con trabajar a tiempo completo en el código abierto, como tú, el creador de Vue. Así que mi ambición era crear algo tan popular como Vue. Y luego de repente vi que hay una diferencia fundamental entre mi proyecto y Vue. Y eso se refleja directamente en el nombre del proyecto. Si observas el nombre, es bastante largo y está compuesto por varias palabras, mientras que Vue es solo Vue, ¿verdad? Así que vamos a desglosarlo parte por parte. Primero, es una extensión de VS Code. Eso básicamente significa que solo los usuarios de VS Code usarán esta extensión. Podemos dibujar un círculo para indicar los usuarios de VS Code aquí. Luego tenemos Vue, porque está construido sobre mi necesidad, uso Vue, así que también podríamos tener un círculo de usuarios de Vue. Y finalmente, es una herramienta para la internacionalización. Eso significa que no todos los usuarios de Vue probarán esta extensión, porque no todas las aplicaciones necesitan internacionalización. Podemos dibujar un círculo para I18 también. Y luego descubrimos que nuestros usuarios objetivo están dentro de las intersecciones de esos tres conjuntos, lo que significa que solo los desarrolladores de Vue que están trabajando en la edición de una aplicación y que eligen VS Code como su editor probarían nuestras extensiones. Esto suena bastante limitado. Y esto es lo que se llama intersecciones de conjuntos. Antes de profundizar en la solución, también echemos un vistazo a este gráfico para ver qué significa la intersección de los demás. Y pronto nos dimos cuenta de que la intersección entre VS Code y Vue son en realidad los usuarios de Vola o Vita en ese momento, que es el soporte de IDE de VS Code para Vue. Como resultado, sabíamos que tanto Vita como Vola tienen una gran base de usuarios, porque tanto Vue como VS Code tienen una comunidad lo suficientemente grande como para hacer que la intersección sea lo suficientemente grande. De manera similar, también teníamos la intersección entre Vue e I18, un proyecto como Vue-I18-Ally, que es súper popular. Y cuando se trata de la intersección entre VS Code e I18, parece que no había tal proyecto en ese momento.

Entonces, pensando de manera sencilla, ¿qué tal si podemos hacer eso? Podemos ser ese único, ¿verdad? En la práctica, podemos intentar desacoplar las extensiones de Vue. Eso significa que también se pueden usar para otros frameworks. En resumen, podríamos hacer que las cosas sean más universales rompiendo el conjunto de círculos y expandiendo las intersecciones. Y así es como lo hice. Me tomé un tiempo para hacer grandes refactorizaciones, una interfaz de complemento y hacer que la función principal sea universal. En la versión 1.0, cambié el nombre del proyecto de Vue-I18-Ally a I18-Ally. Pasó de ser una extensión exclusiva de Vue a ser una herramienta de ayuda I18 universal para VS Code que puede admitir una amplia gama de frameworks. Incluso incluye frameworks backend como Ravel, Ruby on Rails e incluso frameworks nativos. Además, es personalizable y expansible. Puedes construir tus propias integraciones de frameworks con un archivo de configuración.

En cuanto a los números, podemos ver un aumento significativo en las estrellas en ese momento cuando hicimos el lanzamiento. Las estrellas casi se duplicaron en un mes. En ese momento, eso significaba mucho para mí. Especialmente porque estaba comenzando en el código abierto. El pensamiento de hacer las cosas universales realmente cambió la forma en que trabajo en el código abierto más adelante.

Y luego hablemos de otro ejemplo, Vite. Inicialmente, Vite fue un experimento de una herramienta de desarrollo para Vue cuando Evan comenzó. Parecía que las ideas funcionaban bastante bien. Evan decidió hacerlo independiente del framework extrayendo el manejo de Vue en complementos y puliendo la API. Y así tenemos el Vite que conocemos hoy, la infraestructura compartida bajo muchos frameworks. Diría que el éxito de Vite resultó ser mucho más de lo que imaginábamos. Ahora tiene una comunidad y un ecosistema increíblemente grandes. Básicamente, todos los meta-frameworks modernos se construyen sobre él. Tenemos Svelte, Storybook, Astro, Solstice, Nuxt, Quickcd y muchos más. También nos complace dar la bienvenida a Remix a la fiesta recientemente. Oh, es un enrutador Vue-React, ¿verdad? La colaboración entre múltiples frameworks y la comunidad es realmente impresionante. Vite se convierte en la lógica central compartida para las herramientas web. Muchos meta-frameworks ya no tienen que preocuparse por esos detalles subyacentes y pueden centrarse más en las características y capacidades que el framework puede proporcionar. Cualquier mejora realizada en Vite también beneficiará a todos estos frameworks secundarios, y eso es realmente hacer que la web sea mejor juntos. Hay muchos factores que han llevado a Vite a ser lo que es hoy, pero diría que su capacidad de ser expansible e independiente ha abierto las puertas para que la comunidad se una y contribuya.

Un ejemplo que se me ocurre es React Query. Comenzaron con una consulta para React y luego también proporcionaron una versión para Vue llamada Vue Query. Y a medida que otros frameworks front-end como Svelte y Solid entran en juego, creo que se dieron cuenta de que podría haber algo más generalizado. En algún momento, vemos que Vue Query se ha fusionado con React Queries en un solo repositorio y se amplió el alcance y se le cambió el nombre a TensorLite Query. Y al tener una solución más universal que funciona para muchos otros proyectos, otros frameworks también, según su documentación. Y hoy en día, vemos que también se admiten Solid, Svelte y Angular. Así que TensorLite parece estar tratando de expandir aún más las ideas al proporcionar bloques de construcción más universales, como enrutadores o componentes headless. Así que felicitaciones para ellos. Sabemos que al hacer que nuestro proyecto sea más universal, es decir, podemos llegar a una base de usuarios más amplia. Y naturalmente, tendremos más colaboradores que se unan a la fuerza y trabajen juntos. Y tratar de refactorizar las cosas para que sean universales también nos ayuda a revisar nuestro diseño y abstracciones. Esto a menudo resulta en una arquitectura más mantenible y extensible. Y finalmente, si nuestro proyecto comienza a tener más uso para diversas necesidades, hacer mejoras en nuestro proyecto también beneficiará a todos en el ecosistema. Con eso, realmente animo a los autores de bibliotecas a pensar más en esa dirección e intentar buscar colaboraciones incluso entre ecosistemas. Sabemos que ser universal tiene muchos beneficios. Bueno, en realidad, quiero decir que ser específico no es algo malo. Nos permite proporcionar una integración más estrecha y una mejor experiencia para el desarrollador, pero ¿cómo podemos equilibrar eso? Por ejemplo, cuando hablamos de renderizado en el servidor y API del servidor, sabemos que en esos casos necesitamos un servidor de alguna forma para trabajar junto con nuestro frontend.

Y tomemos NUX, un metaframework de vista en el que he estado trabajando, como ejemplo. Además de un servidor de alojamiento propio de Node.js, también queremos... También hay muchos servicios de alojamiento disponibles, como por ejemplo, Cloudflare, Vercel, Netlify, etc. En NUX, no queremos que nuestros usuarios estén limitados a una sola plataforma. Al escribir, queremos ofrecer la opción para que nuestros usuarios elijan según sus necesidades. Para aprovechar al máximo cada proveedor, queremos utilizar el renderizado en el borde y funciones sin servidor según lo que cada plataforma ofrezca.

Y una cosa a tener en cuenta es que cada plataforma tiene su propio formato y algunas de ellas pueden venir con herramientas específicas que es posible que deba utilizar. Eso significa que NUX debe admitir la mayor cantidad de plataformas posible integradas. Por lo tanto, realizamos las integraciones e incluso admitimos la detección automática, para que la aplicación pueda leer de manera isomórfica e implementarse en varias plataformas sin cambiar ninguna configuración. Y luego nos dimos cuenta de que este es un problema con el que probablemente todos los metaframeworks tienen que lidiar, y no tiene que ser específico de NUX. Así que extraemos esto para que sea una herramienta independiente llamada Nitrome. Es un constructor de servidor universal y es bastante similar a Vite, pero para servidores.

Y con Nitrome ocupándose de los detalles de los servidores, en realidad permite que Nux tenga una arquitectura más clara y solo maneje lo relacionado con la representación específica de la vista y las API del lado del servidor. Y además, dado que Nitrome es una herramienta de servidor de propósito general, vemos que cada vez hay más frameworks que comienzan a usarlo y colaborar con nosotros. Tenemos Angular, un popular framework de Angular. Tenemos Analog, un popular metaframework de Angular que se ha migrado a Nitrome. Y luego, el mes pasado, anunciaron el lanzamiento 1.0. Y Stack es un metaframework fantástico, y también tenemos SolidStack. El metaframework proviene del equipo de Solid. E incluso sin un framework, también encuentro que Nitrome es muy útil para construir servidores de API puros. Así que espero ver que más frameworks se unan y trabajen con nosotros.

Y, de manera similar, en cuanto a las herramientas de empaquetado, Nux 2 se construyó sobre Webpack. Y en Nux 3, queremos mantener el soporte de Webpack por compatibilidad y una migración más fácil para los usuarios existentes. Aunque también nos encantan las innovaciones y la experiencia del desarrollador en Vite. Así que intentamos admitir ambas herramientas de forma intercambiable y proporcionar integración de primera mano tanto para Webpack como para Vite, y preconfigurarlo para que idealmente una aplicación Nux pueda funcionar de la misma manera con ambas herramientas y depender de sus necesidades de herramientas. Sin embargo, sabemos que en esa arquitectura, eso significa que los sistemas de complementos son bastante diferentes entre Webpack y Vite. Por ejemplo, si necesitamos agregar algunas transformaciones a algunos modules en nuestro pipeline, deberíamos implementar esta lógica dos veces en cada formato de complemento. Esto básicamente duplica nuestro trabajo, así como el esfuerzo para que el módulo de la comunidad admita ambas herramientas de compilación. Entonces, esta es la motivación inicial para crear Unpluggin, una interfaz de complemento unificada para tanto Webpack como Vite. Con eso, podemos ahorrar mucho esfuerzo para profundizar en los detalles de las desalineaciones de cada herramienta.

Con eso, podemos ahorrar mucho esfuerzo para profundizar en los detalles de las desalineaciones de cada herramienta. Y dado que Unpluggin se extrae como una herramienta independiente, también forma su propia comunidad y amplía su alcance para admitir más herramientas de compilación como Rollup, ESView, RSPack, Rolldown, Fon, Bung plugins y posiblemente más en el futuro. Con el trabajo realizado por la comunidad de Unpluggin, también se abre la puerta para que un metaframework como Nuq admita más herramientas de compilación y una comunidad más amplia. Estos son solo dos ejemplos. También tenemos comunidades como onjs que proporcionan muchas herramientas de alta calidad en todo el ecosistema de JavaScript, y en realidad Nitrome y Unpluggin son parte de la comunidad de onjs. También tenemos vidnode, creado a partir de los ejecutores de código del lado del servidor de Nuq y que luego se convierte en un motor principal de Vitest y lo hace posible. Estas herramientas se crearon por la necesidad de Nuq, pero luego las extraímos para hacerlas universales. Desde entonces, hemos formado su propia comunidad y ecosistema que puede beneficiar a un rango más amplio de usuarios en diferentes escenarios. Y Nuq aún puede tener una opinión y ser un framework específico que brinda una mejor experiencia de desarrollo, mientras que la herramienta subyacente puede compartir y colaborar con otros frameworks y comunidades. Y ahí es donde se vuelve increíble el código abierto, ¿no es así? A diferencia de la intersección de conjuntos de la que estábamos hablando, yo llamaría a estas cosas, lo llamaría la unión de conjuntos, que extrae la parte universal, amplía el alcance y hace crecer la comunidad, lo que eventualmente nos beneficiará a nosotros mismos.

Para dar otro ejemplo más relacionado con React, elegí ChakraUI. Tuve el placer de hablar con Sage sobre la historia detrás de esto. En 2019, ChakraUI se creó como una biblioteca de componentes de React, y pronto, alguien del ecosistema de Vue creó una versión de Vue, y decidieron tener esa versión de Vue como oficial junto con ChakraUI para Vue. Con el tiempo, se dieron cuenta de que mantener el soporte para dos frameworks era básicamente duplicar su trabajo y requería mucho esfuerzo para mantenerlos sincronizados. Así que en 2021, se les ocurrió ZEC, una biblioteca universal de máquina de estados para extraer la lógica central compartida de los componentes en diferentes frameworks, que funciona con JavaScript puro y también proporciona enlaces para React, Vue y Solid. Luego, en 2022, crearon Pandas CSS para extraer su solución CSS en JS a un tiempo de compilación universal que tiene una integración de primera clase con casi todos los metaframeworks disponibles. Con esos bloques de construcción, luego crearon RQI, una biblioteca de componentes sin cabeza construida sobre ZEC. Proporciona una interfaz de componente más orientada al usuario y también admite React, Solid y Vue. Y este año, están migrando la próxima versión principal de ChakraUI para usar ARC y Pandas en su núcleo. Una vez que esté hecho, Chakra se convierte en una base más sólida heredada de ZEC y ARC, y también puede ser mucho más fácil de mantener en diferentes frameworks. En este caso, Chakra aún puede ser específico y ser una biblioteca con estilo y opinión, mientras que las herramientas que construyeron junto con él pueden servir a una comunidad más amplia y convertirse en una solución general. Será mucho más fácil agregar soporte para nuevos frameworks en el futuro, y especialmente será beneficioso para un nuevo framework en auge para obtener un mejor ecosistema sin mucho esfuerzo. Para resumir este tema, presentaré una idea llamada Teoría de Conjuntos que he compuesto con dos secciones, Intersección de Conjuntos y Unión de Conjuntos. En la intersección, aprendimos que no debemos limitar nuestro proyecto a ser solo un lugar de nicho. Debemos buscar activamente la posibilidad de hacer que los proyectos sean más universales rompiendo los círculos y ampliando nuestro alcance. Y en las uniones, aprendimos que aunque a veces debemos ser específicos para lograr algo grandioso, aún podemos buscar la unión potencial de nuestras herramientas subyacentes para expandir la comunidad y beneficiar a todo el ecosistema. Todo se trata de colaboraciones y comunidades, y tengo una fuerte creencia en el código abierto, y esta es una forma de construir un mundo mejor. Espero ver cada vez más código abierto con una mentalidad similar y encontrar una mejor manera de colaborar. Eso es todo por mi charla.

Ese es nuestro incentivo. Es como, queremos mejorar JavaScript, o la web de cualquier manera, y luego tenemos un mercado más grande, y eso se alinea con la visión de la empresa. Sí. Sí, mencioné el incentivo financiero más porque necesitas comer, ¿verdad? Es por eso... Al final del día, todos podemos ser tan buenos para el mundo como queramos, pero al final del día, necesitas comer. Oye, la página se me está bloqueando. Ahí está. Haciendo referencia al fiasco de la puerta trasera XZ para resaltar lo volátil que es el mantenimiento de código abierto módulos, ¿qué tan libre crees que deberíamos expandir el alcance de nuestros proyectos? El fiasco de la puerta trasera XZ. Eso no significa nada para mí. No directamente, sí. Creo que mi perspectiva es que, si miras una licencia, es lo mínimo para decir que el código abierto se proporciona de forma gratuita, sin ninguna garantía. Eso significa que si tienes un error y el mantenedor no es realmente responsable de solucionarlo, eso es la licencia, ¿verdad? Pero en realidad, no funciona así. Si creas problemas o si ayudas a la comunidad... De hecho, muchas comunidades de código abierto son muy activas y realmente están dispuestas a ayudar y mejorar las cosas para todos. Pero por otro lado, es como... Diría que el código abierto no es gratuito, mientras que el mantenimiento no está garantizado. Garantizamos que el proyecto funcione hasta cierto punto, mientras también requerimos algún apoyo financiero en cierta medida para que las cosas sean sostenibles. Entonces sí, creo que lo de XZ es algo que vemos, cuando se trata de las dependencias, no se reconocen realmente y no reciben suficiente apoyo de la comunidad, porque nadie sabe que realmente las están utilizando. Entonces, lo que veo es que como proyecto de código abierto, animaría al proyecto a trabajar ayudando entre sí. Entonces, ¿qué hacemos en Vite? También vemos las dependencias de ES, y también estoy haciendo lo mío. Estábamos reenviando nuestro patrocinio a nuestras dependencias y asegurándonos de que esas... Incluso si no están a la vista del público, aún reciben algún apoyo de la comunidad financieramente.

De acuerdo, para aprovechar eso. ¿Quién aquí trabaja en una empresa multimillonaria? Algunas manos. De acuerdo, una empresa de un millón de dólares. Empresa grande. Muy bien. ¿Quién también usa código abierto, si están en una empresa grande? ¿Quién apoya, o cuya empresa también apoya el código abierto? De acuerdo, de acuerdo.

Bien, bien, bien. De acuerdo, eso está bien. Es bueno verlo. Gracias.

Muy bien, siguiente pregunta. ¿Cómo encuentras tiempo para trabajar en código abierto? ¿Tu empresa te paga por trabajar en la mayoría de los proyectos? Sí, personalmente sí. Estoy en la cadena de framework. Principalmente trabajo en el framework Nuxt, y Nuxt es de código abierto. En cierto modo, me están apoyando para trabajar en código abierto. También mantener el ecosistema, como trabajar en Vite, o mejorar Vue, también es parte de mi trabajo porque todos están relacionados entre sí. Es un trabajo muy bueno de tener.

La siguiente pregunta es de Costas. ¿Cuál es tu consejo para alguien que quiere cambiar de una empresa de software a un producto de código abierto? ¿Cambiar de? ¿Así que quieren ganarse la vida como mantenedor de código abierto, supongo? Para ser completamente honesto, no te recomendaría que te fijes como objetivo trabajar a tiempo completo en código abierto. Es algo que podría suceder por casualidad. Pero diría que todo depende de las expectativas. No deberías fijarte como objetivo trabajar a tiempo completo porque el código abierto es realmente difícil financieramente. Y solo cuando tienes suficiente tiempo libre, puedes intentarlo. Pero diría que no te fijes esta expectativa. No tienes ninguna promesa en esto. Será mejor mentalmente, y en realidad es más fácil para ti lograrlo por accidente o por suerte. Quiero decir, requiere mucha suerte, diría. Sorprendentemente, tengo suerte y privilegios, y aprecio a toda la community por darme la oportunidad. Pero por otro lado, queremos que más personas se unan al código abierto. Pero también debes saber que hay problemas en el código abierto, y esas son cosas que estamos constantemente intentando diferentes soluciones y tratando de descubrir si hay una mejor forma de apoyar el código abierto y hacer que las empresas sean más conscientes de estas situaciones para que podamos tener más diversión al seguir haciéndolo. Pero de alguna manera, creo que el código abierto es súper significativo, es súper útil. Por eso seguiré haciendo esto, y mi pasión se alinea con ello. Sí, genial. Gracias.

Siguiente pregunta. ¿Cómo pueden las personas comenzar a contribuir a proyectos de código abierto existentes? Sí.

Creo que primero deberías ser usuario de bibliotecas. No te recomendaría decir: estoy buscando un proyecto para contribuir, sino más bien usar este proyecto y encontrar algo que potencialmente se pueda mejorar o algún error que pueda corregir. Como cuando te encuentras con algo y eso se convierte en tu punto de referencia, y luego tienes el incentivo para mejorarlo porque si lo solucionas, eventualmente obtendrás un beneficio. Si te está bloqueando, lo solucionas y puedes seguir adelante, algo así.

Entonces, creo que en ese caso, puedes buscar de manera más proactiva estas cosas, como si encuentras un error, puedes informarlo de manera más proactiva o intentar encontrar soluciones. Y por supuesto, cuando leas la documentación, encuentres un error tipográfico, envía un PR para corregir el error. Esa es una contribución totalmente válida y la apreciamos. También puede ser una forma de involucrarte en el código abierto, porque también debes estar familiarizado con el flujo de trabajo en GitHub, enviar PR, pero más adelante te animaría a contribuir según tus necesidades, a medida que lo uses más, a medida que te adentres más, conocerás mejor el proyecto y podrás contribuir más, o tal vez convertirte en miembro del equipo.

Creo que fue en los problemas de React en GitHub, tienen una etiqueta llamada First Good issue, ¿verdad? Sí. ¿Es algo exclusivo de React? ¿O es algo global de código abierto? En realidad, es de GitHub, si creas un nuevo repositorio, la etiqueta se agrega automáticamente por defecto. Es una práctica común en bibliotecas, algunas bibliotecas lo hacen. Y en realidad, uso otra biblioteca llamada PR Welcome. Pero quiero decir, cada proyecto tendría algo así. Pero quiero decir, si disfrutas ayudando a los demás, eso también sería genial. Y sí, como dije, te animaría más a que vengas con tus propias necesidades. Sí, soluciona tus propios problemas, básicamente. Sí. Muy bien, vamos a... Con el tiempo. De todos modos, vamos a hacer una pregunta más. ¿Cómo haces que tu código abierto llegue a la gente? ¿Y cómo obtuviste tus primeras, como tus primeras cinco estrellas? ¿Cinco estrellas? Estrellas iniciales. Vale, y creo que soy una... Creo que soy una persona muy práctica. Al principio, realmente me importaban las estrellas y realmente quería buscar el éxito en números.

Quiero decir, no deberías preocuparte, de cierta manera, pero quiero decir, yo sí lo hago. Y quiero decir, es la naturaleza humana, ¿verdad? Así que al principio, intenté pensar en cómo puedo compartir mis soluciones o... Hice algo genial, quiero compartirlo, y eso es código abierto. Así que intenté enviarlo a Reddit. Como hice una extensión, la envié a Reddit en el subreddit de Vue, y también me uní a algunos servidores de Discord y compartí mis cosas allí. Y luego, en realidad, el autor de Vue, IA Qing, me dio la primera estrella, y luego llegó el tráfico.

Sí. Eso realmente me animó mucho, porque dije, vale, fui reconocido por el autor al que admiro, y luego naturalmente me convertí en eso. Sí. Muy bien. Muy bien. Vamos a hacer una pregunta más, ¿o necesitas irte? No, puedo quedarme aquí. Genial. ¿Cómo encuentras ideas para nuevos proyectos de código abierto? Oh sí, ese es un tema muy interesante. En realidad, esta es una serie de charlas, en la tercera voy a hablar de eso, pero aún no he empezado de todos modos. Pero el punto es que usualmente comienzo desde mis propias necesidades. Como dije, si viste mi charla de ayer sobre ESLint, hay algo que intenté con ESLint, y me di cuenta de que algo no era eficiente, o que algo podría ser mejor. Entonces empecé a pensar si yo, quiero decir, soy una persona perezosa. No quiero repetir mi code. Así que si quieres tener una mejor manera de extraerlo, o si puedes crear una mejor experiencia para que los usuarios ahorren algunos boilerplates, estoy feliz de hacerlo. Así que empecé a crear algo como utilidades, algo encima de eso. Así que básicamente cada proyecto que hago es básicamente eso. Es como encontrar mi propio punto de referencia. Lo rodeo de soluciones, y a veces la solución no funciona porque no siempre tiene sentido para los demás. Pero creo que la expectativa también es importante. No tengo ninguna expectativa. Simplemente comparto. Simplemente comparto mis soluciones. Y cuando la gente encuentra que es útil, recopilarás comentarios. Verás que surgen problemas, se envían PLs, y sabrás que el proyecto está siendo utilizado por los demás, y es importante para los demás, eso significa que vale la pena tu tiempo mantenerlo. Y por otro lado, tengo muchos proyectos bajo mi nombre. Así que está totalmente bien. Sí. Pero aún así aprendes algo de eso, ¿verdad? Sí. Exacto. Eso es todo el tiempo que tenemos. Así que muchas gracias por estar aquí.