Maintainer's Role in Open Source

Soy Marc Erikson y seré su anfitrión para la charla de hoy. Gracias por acompañarnos. Estoy emocionado de estar aquí hoy y espero poder compartir algunas cosas con ustedes. Antes de comenzar, me gustaría darles un poco de antecedentes sobre lo que hago en React. Soy desarrollador y soy desarrollador web. Soy ingeniero y he estado trabajando en el equipo de React por más de 10 años, y soy un desarrollador y una comunidad.

Un par de cosas rápidas sobre mí, la mitad de las cuales Daphne ya me robó. Mi trabajo diario es como ingeniero de front-end en Replay, donde estamos construyendo un depurador de viaje en el tiempo para JavaScript. Soy un respondedor de preguntas, responderé preguntas prácticamente en cualquier lugar donde haya un cuadro de texto en internet. Recolecto todo tipo de enlaces interesantes a herramientas y artículos y recursos. Tengo una familia de publicaciones de blog sobre React y Redux, y soy un mantenedor de Redux. He escrito gran parte de nuestra documentación, creado Redux Toolkit, trabajado mucho en React Redux. Pero sí, la mayoría de la gente me conoce como ese tipo con el avatar de los Simpsons.

Así que, la charla de hoy es un poco diferente para mí. La mayoría de mis charlas tienden a ser muy técnicas, y la de hoy es realmente más sobre personas. Estaba tratando de pensar, como, ¿qué estoy realmente tratando de lograr con esta charla? Y diría que los objetivos de hoy son, si eres un desarrollador de aplicaciones, quiero darte una idea de cómo es ser un mantenedor de bibliotecas de código abierto. Si tal vez estás pensando en trabajar en una biblioteca, o averiguando cómo empezar, quiero darte algunos ejemplos de cómo es, y tal vez ofrecerte algunas sugerencias o lecciones aprendidas de años de realmente hacer esto en la vida real. Y, como siempre, seré muy breve, y te daré un poco de antecedentes. Te daré un poco de antecedentes, y te daré un poco de antecedentes. Vamos a entrar en práctica.

Entonces, cuando pensamos en programadores, ya sabes, el estereotipo es, ya sabes, un programador es una máquina que convierte café en código, estás encorvado sobre tu teclado tarde en la noche, golpeando furiosamente y tratando de construir algo. Y de la misma manera, creo que cuando la gente piensa en mantenedores, es como una máquina expendedora. Y, ya sabes, de la misma manera que los programadores hacen mucho más que solo escribir código. Estamos teniendo discusiones en canales de Slack y en issues de GitHub. Estamos planificando la arquitectura, o averiguando cómo escribir bucles y YAML o algo así.

Y así, de la misma manera, los mantenedores hacen mucho más que solo escribir características y corregir errores. Y resulta que mucho de lo que hacemos realmente tiene que ver con las personas. Ahora, con el código abierto, realmente existe esta gran dicotomía que existe. Por un lado, está la licencia de código abierto. Y la licencia básicamente se reduce a aquí hay algo de código, tú puedes usarlo gratis, y si se rompe, no es mi culpa. Eso es tu responsabilidad. Pero por otro lado, cuando publicas un paquete o una biblioteca, hay una especie de expectativa comunitaria que es muy implícita, y es esta idea de que si he hecho este proyecto, tengo que mantenerlo. Y que la gente espera que responda a los issues y corrija errores y lo mantenga. Y eso no está en la licencia, pero eso está muy presente en la cultura que hemos construido alrededor del código abierto.

Entonces, ¿qué es realmente un mantenedor? Hubo una muy buena cita de Artem Zakharchenko, quien es el creador de MSW. Entonces, un mantenedor es una persona que mantiene una biblioteca, y mantiene una biblioteca. Y un mantenedor es una persona que es diseñador, defensor del desarrollador, soporte técnico, vendedor, gerente de comunidad, creador técnico, y un ser humano todo al mismo tiempo. Eso es muchos sombreros diferentes para usar. Y para muchas bibliotecas, puede que solo haya una persona manteniéndola, lo cual es por lo que tenemos el clásico XKCD que ilustra la torre de Jenga, que es la tecnología moderna, y eso es lo que queremos.

Ahora, en un momento, estaba buscando algunas posibles situaciones de trabajo hace un tiempo. Y alguien me envió una oportunidad de trabajo para una posición de relaciones con desarrolladores. Y lo miré, y estaba muy confundido. Soy ingeniero. Quiero pasar mi tiempo escribiendo código. ¿Por qué alguien pensaría que estoy buscando una posición de dev rel? Y alguien señaló que básicamente he sido un dev rel durante tres años. Y yo estaba como, bueno, así es como comencé. Es como, oh, está bien. Y si piensas en, como, busqué algunas definiciones de lo que hace un dev rel, y son cosas como creación de contenido técnico, hablar en público, participación comunitaria. Eso realmente suena mucho a lo que muchos mantenedores de código abierto hacen. Así que, para un poco de contexto, aquí hay algunos números recientes de descargas para algunas de las principales bibliotecas en el ecosistema de React, que son React, Redux core, Redux toolkit, React router, React query.

Y lo principal que quiero que te lleves de aquí es que Redux sigue siendo una de las bibliotecas más utilizadas en el ecosistema de React. Y así, para mí como mantenedor, cualquier cosa que publique, cualquier cosa que haga, va a tener un impacto en muchas personas. Sabes, hay cientos de miles de desarrolladores usando el código que publico, si no millones de ellos. Básicamente, todo el mundo usa aplicaciones que tienen mi código en ellas. Y eso pone mucha responsabilidad en mí para asegurarme de que hago las cosas bien.

Hubo una vez que accidentalmente publiqué un console log en un camino crítico en React Redux, y eso fue reportado, como, cinco minutos después de que lo publiqué. Es como, las cosas que hago importan mucho, y por eso tengo que ser muy cuidadoso cuando publico cosas.

Entonces, ¿cuáles son algunas de las cosas que los mantenedores realmente hacen cuando interactuamos con nuestra comunidad? Y una de las más obvias y grandes es, de hecho, proporcionar soporte a nuestros usuarios. Ahora, en el caso de Redux, manejamos esto de varias maneras diferentes. La más obvia es a través de issues de GitHub, así como discusiones en GitHub. Tratamos de mantener una pequeña separación entre los issues son para informes de errores reales o solicitudes de características, y la sección de discusión es para cosas no relacionadas con informes de errores. Tenemos un canal de Discord en el Discord de React Flux, pero también, como, veo preguntas aparecer en Reddit o Hacker News o en otros lugares, y trato de responder a esas también.

Ahora, todos van a manejar esto de manera diferente. Para mí, paso mucho tiempo naturalmente leyendo cosas de todos modos. Paso mucho tiempo en Reddit y Hacker News. No soy un gran fan de Redux, pero tiendo a aparecer en cualquier hilo que mencione Redux, y básicamente es solo porque sigo actualizando las cosas mucho. Así que también paso mucho tiempo en la pestaña de notificaciones de GitHub. Tiendo a actualizar eso unas cuantas veces al día, y así, cada vez que alguien presenta un issue o deja un comentario, tiendo a verlo bastante rápido. Para mí mismo, trato de dejar un comentario inicial de inmediato, probablemente solo porque lo tengo abierto, pero también porque siento que es bastante importante tratar de hacerle saber a la gente que alguien realmente está escuchando su pregunta.

Ahora, muchas veces, podría ser solo, no entiendo lo que estás preguntando. ¿Puedes darme más detalles? O ¿por qué estás tratando de hacer eso? O ¿podrías proporcionar una reproducción en un code sandbox o repositorio de GitHub que realmente me muestre qué está saliendo mal? Pero al menos mostrarle a la gente que están siendo escuchados, creo que es bastante importante. Muchas veces veo preguntas que son enojadas o no muy útiles, y Daphne mencionó que parezco bastante paciente. Confía en mí, en mi cabeza, no siempre soy muy paciente.

es decir, la gente no puede exigir todo tu tiempo. Tienes que poder establecer los límites, no siempre dejarte absorber, y poder tener ese equilibrio entre realmente querer ayudar y saber cuándo alejarte. Otra gran cosa que hacemos es trabajar en la documentación. Di una charla grabada en React Advanced el mes pasado que cubre esto con más detalle. Pero muchas veces, la documentación es más importante que el código. Quiero decir, si tienes una característica publicada pero no está documentada, ¿realmente existe?

Hay un concepto llamado el modelo de cuatro categorías para diseñar documentación que creo que es realmente, realmente bueno, y hablé sobre esto con más detalle en esa otra charla. Es muy importante tener en cuenta qué tipo de personas esperas que lean tu documentación. En el caso de Redux, espero que muchos de nuestros lectores sean personas recién salidas de bootcamps, y por eso tengo que tener eso en cuenta mientras trato de organizar las cosas. Y diría que probablemente no hay tal cosa como demasiada documentación.

Algunas personas se han quejado legítimamente de que tenemos demasiadas páginas de documentación, pero preferiría errar del lado de tener más información y luego trabajar para tratar de organizarla que tener poca información en línea. Así que cuando realmente llega el momento de diseñar una nueva característica o una API, en última instancia estamos tratando de ofrecer una herramienta a nuestros usuarios que realmente resuelva algún problema o caso de uso que tengan. Y así, mientras tratamos de diseñarla, tenemos este caso de uso en mente, y estamos tratando de idear algo que realmente permita a los usuarios lograr este objetivo. Pero simplemente tenemos ciertas suposiciones sobre cómo la gente va a usar esta API, y luego resulta que la gente se va y hace otras cosas que realmente no tenías idea de que iban a intentar hacer, o comienzan a hacer algo y las opciones no son lo suficientemente configurables. Nunca imaginamos que una persona intentaría hacer eso con este martillo.

Hay un dicho o frase llamado la ley de Hiram, que es que cada comportamiento real de un fragmento de código será dependido por alguien incluso si nunca lo consideraste parte de la API pública. Hay un cierto bit de tiempo o comportamiento interno y la gente escribe código que depende de eso, y luego lo cambias porque es solo parte de los detalles de implementación, y luego, por supuesto, alguien se queja de que rompiste su sistema. Algunas pautas que podrías querer considerar mientras intentas diseñar APIs. Como cuál es el objetivo real que el usuario está tratando de lograr. ¿Es esto algo que se puede hacer simplemente escribiendo algo de código ya en lugar de tener que construir algo en la biblioteca? ¿Cuántas personas realmente necesitan esto? Como sí, tal vez una persona muy ruidosa lo está pidiendo, pero ¿suficientes personas se beneficiarán de esto para justificar su construcción? En última instancia, no todas las solicitudes de características tienen que ser añadidas. Cada fragmento de código que agregas a la biblioteca es más código que tienes que mantener tú mismo. Dominic Dorfmeister, también conocido como TKdodo, el mantenedor de React Query, acaba de dar una gran charla en React Advanced el mes pasado donde habló sobre algunas lecciones aprendidas al diseñar APIs para React Query. Es maravilloso cuando algunos de nuestros usuarios realmente presentan PRs para contribuciones. Y no estoy bromeando, incluso si es literalmente corregir un error de un carácter en la documentación, lo aprecio cuando la gente presenta PRs. Pero hay toda la gama desde la corrección de un error de un carácter hasta aquí hay una nueva característica que he escrito desde cero con pruebas, lo cual es como lo más raro que existe pero ha sucedido. Es maravilloso cuando eso sucede, pero lleva tiempo y esfuerzo de mi parte como mantenedor para realmente revisarlo y entenderlo y decidir que está listo para fusionarse. Si puedes agregar una página de guía de contribución a la biblioteca, eso puede ayudar a proporcionar alguna orientación a los usuarios que quieren realmente contribuir, en última instancia, cuanto más pueda hacer un usuario para facilitarme a mí, el mantenedor, entender y revisar, más probable es que realmente pueda confiar en que está listo y fusionarlo. A veces la gente presenta cosas y es como creo que esto podría ser útil, pero no tengo tiempo para darte orientación para hacer los ajustes. Tal vez es más fácil para mí simplemente tomarlo y hacerlo yo mismo, o tal vez es incluso algo valioso, pero no tengo tiempo para pensar en ello y por eso simplemente va a terminar quedándose o no siendo fusionado. Como hay un costo de tiempo para el mantenedor involucrado en esto. Versionado de paquetes.

Si lanzo una versión principal, entonces la expectativa es que van a tener que pasar mucho tiempo revisando guías de migración. Debido a esto, es muy importante como mantenedor de una biblioteca elaborar notas de lanzamiento y registros de cambios para realmente decirle a la gente aquí está lo que ha cambiado, aquí está lo que puedes esperar, aquí están las cosas en las que necesitas estar atento en tu código. Pero hay muchas consideraciones que van más allá de eso. Mientras desarrollas una característica, ¿cómo estás gestionando las versiones previas al lanzamiento?

Una cosa que he aprendido es que no importa cuántas versiones previas al lanzamiento y alphas y betas y RCs publique, eventualmente solo tendrás que publicarlo y luego la gente finalmente lo probará en vivo y te dirá todas las cosas que realmente están rotas, y me encantaría obtener más comentarios previos al lanzamiento, y en la práctica realmente no sucede. En algún momento tengo que confiar en que he hecho suficiente trabajo y luego publicarlo y luego recibir los informes de errores. ¿Qué pasa si corriges un error y técnicamente la corrección del error cambia el comportamiento? ¿Es eso una versión de parche o es una versión principal? Mucho de eso realmente depende de nosotros decidir. Para mí, básicamente ha sido lo que pretendíamos que fuera y si el comportamiento es algo que consideramos roto, entonces es una versión de parche, es una corrección de errores, incluso si el cambio de comportamiento podría argumentarse que es disruptivo en una principal. ¿Qué pasa cuando cambias el comportamiento interno? ¿Qué pasa cuando cambias los tipos de TypeScript? ¿Con qué frecuencia deberías lanzar nuevas versiones principales? Estas son todas cosas que tenemos que considerar mientras gestionamos la biblioteca. Entonces, los cambios disruptivos son a veces necesarios, pero van a costar tiempo y esfuerzo para todos nuestros usuarios.

Como dije, tenemos muchas personas que usan Redux, así que si hago un cambio disruptivo, estoy infligiendo cierta cantidad de dolor y esfuerzo a cientos de miles de desarrolladores, y por eso eso tiene que realmente valer la pena al final. Los gestores de paquetes siempre están instalando la última versión principal, y por eso tengo que pensar en si lanzo una nueva principal, ¿cuál será el impacto de que la gente instale automáticamente la versión más nueva en sus sistemas? Para mí, mi objetivo es que incluso en una versión principal donde hay cambios disruptivos, todavía estoy tratando de minimizar la cantidad de dolor y esfuerzo y ruptura que entra en los sistemas de los usuarios. Una forma de hacer esto es con code mods, pequeños scripts que pueden buscar automáticamente patrones en el código y reescribir para que puedas tal vez cambiar, como, una opción antigua rota en una versión más nueva del código. Hemos estado publicando paquetes en NPM durante, ¿qué?

, más de 15 años ahora, y en muchos sentidos, todavía nadie sabe lo que estamos haciendo. Todos están tomando prestado de todos los demás. ESM versus common JS sigue siendo bastante un desastre. Pasé casi todo el año pasado tratando de modernizar los paquetes de 3DUX, y aunque finalmente llegué a algo que funciona, fue un proceso muy largo y frustrante. Escribí un largo artículo sobre eso. Y esto todavía se reduce a las preferencias del mantenedor. Algunos mantenedores han optado por publicar solo ESM porque les facilita mucho las cosas, pero eso significa que si estás tratando de usarlo en un entorno mixto, podría ser más difícil. He tendido a ser más un maximalista de compatibilidad, donde solo quiero que mi paquete funcione desde el principio para la mayor cantidad de usuarios posible, y estoy más dispuesto a asumir el dolor y sufrimiento para que eso suceda.

Bien. Un par de minutos restantes. Un par de ejemplos del mundo real. Tengo una versión larga de esta perorata, pero la mantendré relativamente corta. Muchos bootcamps y cursos todavía están enseñando patrones obsoletos de Redux. El antiguo estilo de Redux escrito a mano en lugar del moderno Redux Tool Kit. Y queremos que todos usen RTK, pero los principiantes no van a leer nuestra documentación.

Así que hace un par de años tomé la decisión de que iba a modificar el comentario de documentación para el método create store para marcarlo como obsoleto, de modo que obtenga el pequeño tachado cuando lo importes. Ahora, no, esto no es un error de tiempo de ejecución. Ni siquiera rompe nada. Es literalmente solo hay un tachado. Y la idea era que los principiantes lo importaran, pasaran el ratón sobre él, y vieran un comentario de documentación que dijera, esto está desactualizado. Deberías usar Redux tool kit y seguir el enlace a nuestra página de documentos. Así que envié esto en Redux versión 4.2, y las notas de la versión explicaron muy claramente por qué estaba tratando de hacer esto. Así que, ya sabes, las notas de la versión diciendo, ya sabes, no estamos realmente eliminando create store, y aquí hay un ejemplo de cómo se verá esto. Y eso es todo. Y si a la gente no le gustaba esto, pueden, ya sabes, modernizarse al Redux tool kit, pueden dejarlo como está porque nada se rompe, o pueden cambiar al nuevo método heredado aliased legacy underscore create store. Y a mucha gente no le gustó esto. Tuvimos personas gritándonos porque de alguna manera no querían usar Redux tool kit. Lo que realmente me sorprendió fue la gente diciéndome, solo quieres que la gente use tu biblioteca en lugar de la de Dan Abramov. Es como, espera un minuto. Dan creó Redux, pero solo trabajó en él durante un año. En ese momento yo había estado trabajando en él durante siete años. Es como, y publiqué tanto Redux tool kit como el núcleo de Redux. ¿No tengo derecho a decir cómo se supone que debe usarse mi biblioteca? Estoy haciendo esto con el mejor interés de mis usuarios en mente. Ahora, incluso en Redux versión 5, que salió el año pasado, podría haber eliminado create store. Es una versión principal. Se me permite hacer cambios disruptivos, ¿verdad? Pero no quería realmente romper el código de usuario. Estoy tratando de darles un empujón. No estoy tratando de, como, destruir el ecosistema.

Otro ejemplo, pasé todo el año pasado trabajando en Redux tool kit 2.0. La mayor parte de esto fue sobre modernizar los paquetes para una mejor compatibilidad con ESM, eliminando el soporte para IE11, ese tipo de cosas. Este fue un esfuerzo difícil y, en última instancia, se trataba de intentar que funcionara mejor para nuestros usuarios desde el principio. Pero para hacer eso, tuve que mirar los más de 150 problemas abiertos relacionados con la función de obtención de datos de consulta de RTK y simplemente decir, no vamos a tocar nada de eso. Así que básicamente me puse el sombrero de gerente de proyecto y reduje el alcance para poder enviar y cumplir con una fecha límite. Terminamos publicando una guía de migración muy extensa con muchos detalles sobre todas las cosas que realmente cambiaron y lo que los usuarios realmente necesitarían hacer.

Así que, conclusiones. No hay un manual real para ser un mantenedor. Es algo que básicamente todos aprendemos en el trabajo a medida que avanzamos. Y es básicamente otro trabajo de tiempo completo o puede ser un trabajo de tiempo completo y realmente tenemos que imponer muchos límites nosotros mismos para mantener ese equilibrio entre trabajo y vida. Anthony Foo tiene un gran artículo sobre salud mental y lidiar con el código abierto y básicamente, respaldo todo lo que dijo en ese artículo. En última instancia, mantener se trata realmente de lidiar con personas y expectativas mucho más de lo que es realmente escribir el código. Y puede ser muy agotador y estresante, pero también es muy gratificante saber que el trabajo que he hecho está teniendo un impacto tan grande en el ecosistema y afectando las carreras de tantas personas. Así que, esos son algunos pensamientos y experiencias de mi tiempo manteniendo Redux. Espero que eso sea útil o perspicaz o tal vez incluso te anime a trabajar en una biblioteca de algún tipo. Gracias.

Bien. Así que, tenemos algunas preguntas llegando. La gente se pregunta, bien, esta es de, oh, todas son anónimas. Bien. ¿Cuál es tu opinión sobre si o cómo los mantenedores deberían ser compensados por los usuarios? Específicamente, ¿alguna opinión sobre el drama de core JS?

Bien. Un par de preguntas diferentes. Así que, esto vuelve a ese tipo de cosa de contrato legal versus social. Como, cuando publico código abierto, estoy diciendo explícitamente que legalmente cualquiera puede usar este código, ya sea importando el paquete o copiando y pegando, modificándolo, lo que sea, y no soy responsable si se rompe, pero tampoco estás obligado a devolverme nada. Por otro lado, tenemos paquetes ampliamente usados que están siendo utilizados por enormes corporaciones que ganan miles de millones de dólares, y conceptualmente parece que, especialmente las grandes empresas deberían retribuir al ecosistema y al mismo tiempo legalmente no están obligadas a hacerlo.

Y no hay una buena respuesta para esto. Soy afortunado de tener un trabajo diario donde no estoy tratando de depender de mi trabajo de código abierto para pagar mis cuentas. Hay muchas personas que han puesto tiempo y esfuerzo y quieren ser compensadas por eso, y creo que esa es una posición muy comprensible también. El concepto de pagar a los mantenedores de código abierto es algo que ha sido debatido interminablemente en línea.

No hay una buena respuesta final para eso en este momento. Sí. Bien. La siguiente pregunta votada por Nicholas. ¿Alguna recomendación para crear code moths para enviar junto con versiones principales? Veamos. Hay varias herramientas para code moths por ahí. Creo que una de las más antiguas se llama JS code shift. Hay una empresa que ha creado un poco de SDK para crear code moths que literalmente es solo code mod, creo. Creo que simplemente tomaron la propiedad de los varios code moths relacionados con React. No tengo más enlaces en la cabeza, pero probablemente sea un buen punto de partida para mirar. Bien.

Así que code moth. Genial. Gracias por eso.

para mirar. Bien. Así que code moth. Genial.

Gracias por eso. ¿Cómo mantienes tu GitHub de mantenedor separado de tu GitHub de trabajo diario? No lo hago, lo que significa que cuando me despierto en la mañana y presiono el botón F5 en la página de notificaciones por primera vez, tengo una mezcla de cosas relacionadas con los repositorios de trabajo, los varios repositorios relacionados con Redux, el hilo de comentarios en el que comenté hace cinco años que acaba de recibir un comentario necro. Me encantaría una versión más avanzada de la pestaña de notificaciones de GitHub. En mi caso, todo se mezcla junto. Bien. Así que todo se mezcla. Bien. De acuerdo. Entonces ¿cómo manejas el análisis parálisis al diseñar una interfaz sabiendo que es imposible cambiarla en el futuro? No es imposible de cambiar, pero definitivamente estás un poco bloqueado hasta la próxima versión principal, lo cual podría tardar un tiempo. Quiero decir, aquí está el ejemplo actual. Así que como dije, tenemos algo así como, teníamos algo así como 150 problemas abiertos relacionados con solicitudes de características de RTK query, correcciones de errores, lo que sea. La característica más solicitada en este momento es la consulta infinita o el soporte de paginación, que es algo que React query y SWR tienen que no tenemos en RTK query. Y ha estado en mi mente por un tiempo, pero he estado demasiado ocupado con la vida y otras responsabilidades para echar un vistazo. Finalmente tuve tiempo para intentar hacer algo de investigación y ponerme al día en ese dominio hace aproximadamente un mes y medio. Alguien más había presentado un borrador de PR a principios de este año que básicamente intentaba imitar la API de React query sobre los internos de RTK query. Y lo miré como, bien, genial, el PR existe. No tengo tiempo para entender esto. Hola. Y finalmente tuve tiempo el mes pasado para sentarme y revisar el PR, probarlo, entender lo que está haciendo hasta ahora, averiguar como, entender por mí mismo dónde está roto, qué necesita cambiar, cuáles son los próximos pasos, tuve una discusión con Dominic, el mantenedor de React query sobre por qué tomaron ciertas decisiones al diseñar su API. Sí. Como dije, no hay un punto de parada. En última instancia estás mirando el código, y es como cualquier otra cosa. Como pensamos que esto es lo suficientemente bueno, lo enviamos, y luego estás atrapado con lo que enviaste. Sí. Seguro. Bien. Tenemos tiempo para una última pregunta.

Y esto vuelve al tema de las contribuciones externas. Si alguien presenta un PR para corregir un error o añadir comportamiento, realmente quiero que incluyan algunas pruebas, tanto para que pueda ver que, el CI sigue en verde, como para que me dé más confianza al mirar su código y sentirme bien con lo que ahora estoy asumiendo la carga de mantener en el futuro.

Sí. Así que supongo que esto es un PSA. Si contribuyes, por favor escribe pruebas. Si presentas PRs a bibliotecas, por favor tómate el tiempo para incluir pruebas. Hace el trabajo del mantenedor mucho más fácil. Si quieres hacer feliz a Mark, así es como lo haces.

Genial. Muy bien. Si tienes más preguntas, no pudimos abordar todo. Por favor encuentra a Mark en la sala de preguntas y respuestas o simplemente alrededor de la conferencia. Realmente, gracias por tu tiempo, y apoya a los desarrolladores de código abierto y a los mantenedores de bibliotecas. Gracias por lo que haces.