LIGHT

❯ Open Source Isn't Gratis

Por qué las empresas deben tratar
el open source como infraestructura

Christopher Tineo SRE @ Palantir Technologies

MÉXICO 2026 · CDMX

❯ whoami

Christopher Tineo

SRE · Palantir Technologies

CNCF Ambassador

Kubestronaut

Google Cloud Professional Cloud Architect

GCP Cloud Architect

Google Cloud Professional Cloud DevOps Engineer

GCP Cloud DevOps

Certified Kubernetes Security Specialist

CKS

MCPA

Comunidad

Cloud Native Community Groups Santo Domingo

Organizador

Upstream Kubernetes SIG Contributor Experience · Miembro

Los cinco actos

Problema

Lo "gratis" del software tiene un precio, y alguien lo paga.

Ejemplos

Cómo se ve cuando llega la cuenta.

Costo

Para las empresas, los maintainers y el ecosistema.

Solución

Tratar el open source como la infraestructura que es.

Acción

Qué hacer el lunes por la mañana.

Acto 01

El problema

"Gratis" tiene precio. Alguien siempre lo paga.

El open source está en todas partes

98%

de 947 codebases comerciales auditados por Black Duck contienen open source.

Fuentes: Black Duck OSSRA 2026, 25 feb 2026

Este es el momento de bajar la velocidad. El 98% es la entrada a todo el argumento moral: cuando tanto de tu stack es open source, la palabra "gratis" está cargando con muchísimo peso. Comprobante (revisado 2026-09-26): comunicado de prensa de Black Duck OSSRA 2026 (25 feb 2026): 947 bases de código, con open source "appearing in 98% of codebases". Cuidado: es el porcentaje de bases de código que CONTIENEN open source, no el porcentaje del código que es open source. Si quieres que pegue más fuerte: pide que levanten la mano quienes hayan hecho deploy hoy de un servicio que no dependa de al menos un paquete open source. (Nadie va a levantar la mano.) [TIEMPO: 45s. El 98% necesita un momento para aterrizar. Los números de valor están en la siguiente slide.]

Cuesta millones. Vale billones.

$4,150 M

costó escribirlo

$8.8 billones

vale para las empresas que lo usan

El 5% de los developers crea el 96% de ese valor.

Fuente: Hoffmann, Nagle & Zhou, "The Value of Open Source Software", HBS WP 24-038, ene 2024

Simplificada el 4 oct 2026: antes eran dos gráficas (cuadrados con área a escala y una franja 5% → 96%). Ahora es una sola comparación y el 5%/96% va como línea de apoyo. Slide nueva (pasada de diseño, 2026-09-27): los números de Harvard antes eran dos tarjetas y una cita en la slide anterior. Texto que salió de la slide (díganlo en voz alta): - $4,150 millones: lo que costó escribirlo una vez. - $8.8 billones: lo que les costaría a las empresas reemplazar el open source que usan. - "Áreas a escala: el punto es ~2,100× más pequeño. Dólares; 1 billón = un millón de millones." - Barra de arriba: developers de open source. Barra de abajo: valor para las empresas ($8.8 billones). Comprobantes, Harvard HBS WP 24-038 (ene 2024): - "We estimate the supply-side value of widely-used OSS is $4.15 billion, but that the demand-side value is much larger at $8.8 trillion." Lado de la oferta = lo que cuesta escribir ese código una vez. Lado de la demanda = lo que costaría si cada empresa que lo usa tuviera que reconstruirlo. - "96% of the demand-side value is created by only 5% of OSS developers." Ojo con la traducción: el "billion" en inglés son mil millones; el "trillion" en inglés es un billón en español. $4.15 billion = 4,150 millones de dólares. $8.8 trillion = 8.8 billones de dólares. Cómo leer el lado izquierdo: las ÁREAS de los cuadrados están a escala. 8.8 billones son unas 2,100 veces 4,150 millones, así que el cuadrado de 4,150 millones es un punto. Señálalo. Cómo leer el lado derecho: el mismo 5% de personas, el 96% del valor. Un puñado de personas carga con todo el ecosistema. Esto prepara ingress-nginx en el siguiente acto. Dilo así: "Escribirlo costó unos cuatro mil millones de dólares. Para las empresas que lo usan vale casi nueve billones. Y el cinco por ciento de las personas carga con casi todo." Son estimaciones del modelo del paper, no dinero que cambió de manos. Si alguien pregunta, di "estimación". [TIEMPO: 75s.]

❯ aclaración

Software libre ≠ Open source

Software libre

Un movimiento

El objetivo: la libertad del usuario
FSF · 1985 · Richard Stallman
Cuatro libertades (usar, estudiar, modificar, compartir)
Ética de licencia: copyleft

≠

Open source

Una metodología

El objetivo: beneficios prácticos
OSI · 1998 · Raymond & Perens
10 criterios de la Open Source Definition
Ética de licencia: copyright

Fuentes: FSF, "What is Free Software?" · OSI, The Open Source Definition

Texto que salió de la slide: "Dos filosofías que se cruzan, pero no son iguales. Mismo código, distinto porqué." y "La mayoría de los proyectos son ambos. Cambia el porqué, no el qué." Esta es la base conceptual para el resto de la charla. Dos términos distintos, dos comunidades distintas, dos marcos de valores distintos. Coinciden en el código (casi todo el FLOSS es ambas cosas), pero se separan en el *porqué*. "Software libre" es una postura moral: el usuario tiene derechos. "Open source" es una postura práctica: compartir el código produce mejor software. Los dos llegan a licencias parecidas, pero la *conversación* sobre sostenibilidad cambia según de qué lado vengas. El título dice "Open Source" porque es el término que usa la industria, que es a quien le hablamos. El marco moral del software libre aparece en la siguiente slide, con Stallman. [TIEMPO: 90s. No te detengas. Pasa a la slide de Stallman, que es donde aterriza la etimología.]

En inglés, "free" es una sola palabra

Retrato de Richard Stallman, fundador del Proyecto GNU y de la Free Software Foundation — Richard Stallman Foto: Ruben Rodriguez, LibrePlanet 2019 · CC BY 4.0 · Wikimedia Commons

"Free": libre, no gratis.

«…piense en "libre" como en "libertad de expresión", no como en "cerveza gratis".» Proyecto GNU, "¿Qué es el software libre?"

Libre para usar. Alguien lo sostiene.

Fuente: Proyecto GNU / FSF, "¿Qué es el software libre?", gnu.org, actualizado 10 jun 2026

Dos cosas importantes para dejar claras. Texto que salió de la slide (díganlo en voz alta): - Stallman usó "free" como libre (free speech), no como gratis (free beer). - En inglés es la misma palabra, y llevan 40 años confundiéndolas. En español tenemos dos. - Puente al slide anterior: esos $8.8 billones son libres de usar, pero alguien los sostiene. Esta charla es sobre quién. - La cita es de la traducción oficial al español de la definición de software libre en gnu.org. En inglés: "free" as in "free speech," not as in "free beer." - Stallman: fundador del Proyecto GNU y de la Free Software Foundation. Su "free software" habla de libertad, no de precio. 1. La imagen. Stallman es el origen de la idea detrás del título. Mostrar su cara hace que la etimología se sienta real, no abstracta. El pie de foto ya incluye el crédito, según CREDITS.md. 2. El giro para esta audiencia. En inglés, "free as in beer / free as in speech" es la frase de siempre en cualquier charla de open source, porque el idioma necesita aclarar qué "free" quiere decir. En español no hace falta: ya tenemos "libre" y "gratis". Úsalo a favor: "Ustedes ya tienen la palabra que a los angloparlantes les falta. Lo que no siempre tenemos es la cuenta de quién paga la diferencia." El resto de la charla le pone precio a esa diferencia. Si la imagen no carga, la slide igual funciona: el layout se acomoda solo (el texto de la derecha tiene suficiente peso). [TIEMPO: 60s. Este es el corazón conceptual de la charla. Sin prisa.]

Acto 02

Los ejemplos

Cómo se ve cuando llega la cuenta.

¿Qué es ingress-nginx?

Internet

ingress-nginx

Sus servicios

La puerta de entrada a su cluster de Kubernetes.

Fuente: kubernetes.io, "Ingress Controllers", consultado el 30 sep 2026

Texto que salió de la diapositiva (díganlo en voz alta): - Lleva el tráfico externo hacia sus servicios. - No viene incluido: Kubernetes no trae un Ingress controller por defecto. Ustedes eligen uno. - Lo mantiene un puñado de voluntarios de SIG Network. - Proyecto kubernetes/ingress-nginx · responsable Kubernetes SIG Network. Preparen el terreno. Ingress NGINX no es un proyecto oscuro: es el ingress controller que casi todos eligen por defecto. Al final de este acto, el público debería sentir un pequeño golpe de reconocimiento: "Yo uso esto. Y se va a acabar." El logo de NGINX a la izquierda es un ancla visual rápida. No se detengan en él; el público ya conoce el logo. El punto de la diapositiva es el reconocimiento, no la marca. [Reestructurado 4 oct 2026: el ~60% de CERN se movió a la siguiente diapositiva, #case-ingress-adoption. Aquí solo va qué es.] El diagrama es todo: internet entra, ingress-nginx decide a qué servicio va cada request. Si se cae o tiene un bug, todo lo de atrás queda expuesto o sin tráfico. El dato de CERN (ahora en la siguiente): El "~60% de los deployments" es la flota PROPIA de CERN, de la sección de CERN en el post del CNCF End User TAB (2 abr 2026): "As of the end of 2025 ~60% of deployments rely on ingress-nginx as an ingress controller." Digan "en CERN" en voz alta; no es un número de toda la industria. El número de la industria está en la diapositiva del costo: el "about half of cloud native environments" del Kubernetes Steering Committee. "No viene incluido": ingress-nginx nunca fue el Ingress controller oficial, porque no existe uno. kubernetes.io (consultado el 30 sep 2026): "Kubernetes as a project supports and maintains AWS, and GCE ingress controllers." Todo lo demás, más de 30 controllers, aparece como de terceros. La gente eligió ingress-nginx por lo que podía hacer: configuración dinámica de backends con OpenResty/Lua (algo que NGINX estándar no hace sin un reload), módulos extra, varios algoritmos de balanceo. Mi opinión, y díganla como opinión: "probablemente el Ingress controller con más funcionalidades que existe." No hay fuente para eso, así que no va en la diapositiva. [TIEMPO: 45s. Menos es más en esta diapositiva. El ~60% en CERN es el mensaje. Dejen que la sala lo absorba antes de avanzar.]

¿Quién lo usa?

~50% de los entornos
cloud native

41%+ de los clusters expuestos a internet lo corrían (Wiz)

~60% de los deployments en CERN, el lab del LHC

Fuentes: Kubernetes Steering statement, 29 ene 2026 · Wiz Research, IngressNightmare, 24 mar 2025 · CNCF End User TAB, "Ingress NGINX retirement: Experience from end users", 2 abr 2026 (CERN: "As of the end of 2025 ~60% of deployments rely on ingress-nginx") · CERN, "The Large Hadron Collider"

Nueva en esta edición: antes estos números estaban repartidos entre la intro y la diapositiva de CVEs. - ~50%: Kubernetes Steering + Security Response Committee, 29 ene 2026: "critical infrastructure for about half of cloud native environments." Es el número de la industria. - 41%+: Wiz Research, 24 mar 2025: "over 41% of internet-facing clusters are running Ingress-NGINX". Medido cuando salió CVE-2025-1974. - ~60% en CERN: CERN es el laboratorio europeo de física de partículas en Ginebra, el del Large Hadron Collider (LHC). Lo usamos porque es uno de los pocos end users que publicó su número real. Su sección del post del CNCF End User TAB (2 abr 2026): "Over the years we added multiple ingress controller options in our clusters." "As of the end of 2025 ~60% of deployments rely on ingress-nginx as an ingress controller." Digan "en CERN": es su flota, no la industria. El post no dice cuántos clusters tienen. - Qué hizo CERN: "Internally, we started tracking the remaining deployments relying on ingress-nginx." En 2025 pasaron a Cilium como CNI, "which brings built-in support for the Gateway API", y para lo demás: "the recommendation is to move back to Traefik and we provide a match for the most popular annotations." - Su lección, que conecta con el Acto 04: "Appropriate review and tracking of each component in the stack is essential, in particular for sub-projects of graduated projects in the CNCF." O sea: ingress-nginx vivía bajo Kubernetes, un proyecto graduado, y aun así nadie lo estaba financiando. Pregunta para la sala: "¿Quién de ustedes lo tiene en producción?" [TIEMPO: 45s.]

Cada vez más CVEs

CVEs de ingress-nginx por año

2018

2019

2020

2021

2022

2023

2024

2025

2026

crítica alta media / baja

1 crítica CVE-2025-1974 · CVSS 9.8 · 6,500+ clusters expuestos

10 de 17 en 2025–2026, y luego se archivó.

Fuentes: GitHub Advisory Database, k8s.io/ingress-nginx, consultado el 27 sep 2026 · Wiz Research, IngressNightmare, 24 mar 2025

Texto que salió de la diapositiva: - ~50%: "de los entornos cloud native dependen de él" (Steering, ene 2026). - 41%+: "de los clusters expuestos a internet lo usaban" (Wiz, mar 2025). - 6,500+: "clusters exponían su admission controller a internet" (Wiz, mar 2025). - 1 crítica: CVE-2025-1974, CVSS 9.8, ejecución remota de código a través del admission controller. - 10 altas, de 17 CVEs en total. 10 de los 17 llegaron en 2025–2026, y luego se archivó. Rehecha el 27 sep 2026: la línea de tiempo con fechas se cambió por tarjetas de adopción más grandes y una gráfica de CVEs. Digan las fechas clave en voz alta: - 11 nov 2025: se anuncia el retiro, soporte best-effort hasta marzo 2026. - 29 ene 2026: comunicado de Steering + Security Response, "critical infrastructure for about half of cloud native environments." - 19 mar 2026: último release (helm-chart-4.15.1); repo archivado el 24 mar. - Hoy: seis meses sin patches para quien lo siga usando. Tarjetas de adopción: el ~50% es del comunicado de Steering (ene 2026). El 41%+ y el 6,500+ son de Wiz Research, 24 mar 2025, medidos cuando se publicó CVE-2025-1974: "over 41% of internet-facing clusters are running Ingress-NGINX"; "over 6,500 clusters, including Fortune 500 companies, that publicly expose vulnerable Kubernetes ingress controllers' admission controllers to the public internet". El 6,500 es solo lo que Wiz pudo ver desde internet, así que es un piso, no un techo. Gráfica de CVEs: cada entrada de la GitHub Advisory Database para el paquete Go k8s.io/ingress-nginx (gh api advisories?ecosystem=go&affects= k8s.io/ingress-nginx), consultado el 2026-09-27. 17 CVEs: 1 crítica, 10 altas, 5 medias, 1 baja. Agrupados por el año del ID del CVE, porque las fechas de publicación de los viejos en la base de datos son cargas retroactivas de 2022. - 2018: CVE-2018-1002104 (media) - 2020: CVE-2020-8553 (media) - 2021: CVE-2021-25745 (alta), CVE-2021-25748 (media) - 2022: CVE-2022-4886 (alta) - 2023: CVE-2023-5043, CVE-2023-5044 (altas; inyección por annotations, "arbitrary command execution") - 2025: CVE-2025-1974 (crítica, 9.8, RCE de IngressNightmare), CVE-2025-24514, -1098, -1097 (altas, inyección de configuración), CVE-2025-24513 (media) - 2026: CVE-2026-1580, -24512, -4342 (altas, inyección de configuración), CVE-2026-24513 (baja), CVE-2026-24514 (media) "10 de los 17 llegaron en 2025–2026": 5 CVEs en 2025 + 5 en 2026. 7 de esos 10 son altas o críticas. [TIEMPO: 90s. Hagan una pausa en 2025 y 2026: la mitad de los CVEs llegaron en los últimos 18 meses del proyecto.]

Cada feature se volvió mantenimiento

Issues y PRs por año · kubernetes/ingress-nginx

issues pull requests * año parcial

9 de cada 10 PRs en 2025: un solo maintainer o un bot.

Fuentes: GitHub search API, repo:kubernetes/ingress-nginx created:<año>, consultado el 26 sep 2026 (autores 2025: 1,000 de 1,414 PRs, 30 sep 2026) · PR #2794, 27 jul 2018 · kubernetes dev list, 23 jun 2022 · issue #13002, 20 mar 2025

Texto que salió de la diapositiva: - Subtítulo: "Issues y pull requests abiertos por año en kubernetes/ingress-nginx". - * 2016 empieza el 4 nov (creación del repo) · 2026 termina con el archivo en marzo. - "Las features llegaron; el mantenimiento se quedó." Nueva en la revisión 2. No existe un dataset público de cuántos clusters en producción usaban ingress-nginx año con año, así que no digan que lo hay. Esta gráfica es el lado de la demanda: cada issue y pull request abierto en el repo, por año calendario, desde la GitHub search API (consultado el 2026-09-26). Totales (issues / PRs): 2016 52/48 (desde el 4 nov) · 2017 741/1,021 · 2018 817/927 · 2019 700/558 · 2020 957/870 · 2021 758/624 · 2022 652/721 · 2023 595/731 · 2024 455/1,342 · 2025 319/1,414 · 2026 16/366 (hasta el archivo en marzo). Suma: 14,684 (6,062 issues + 8,622 PRs). Léanla así: entre ~1,300 y 1,800 elementos al año, constantes por una década, cayendo sobre un equipo que llegó a seis maintainers como máximo y pasó años con dos. Actualizada el 30 sep 2026. Ahora las barras van lado a lado (la versión apilada se malinterpretaba). La historia es cómo las features se vuelven mantenimiento: - Jul 2018: PR #2794 "enable dynamic backend configuration by default" (release 0.18.0). Los backends se actualizan con OpenResty/Lua sin reload de NGINX, algo que NGINX estándar no puede hacer. Salió primero detrás de --enable-dynamic-configuration en 0.12.0 (Changelog.md); el PR #3198 (oct 2018) lo volvió el único modo. - 23 jun 2022, dev list: "it's time to temporarily pause accepting new features and focus on fixing and stabilizing Ingress NGINX." - 20 mar 2025, issue fijado #13002: "No new features from maintainers". - Autores de PRs en 2025, de los primeros 1,000 de 1,414 PRs (la búsqueda de GitHub corta en 1,000 resultados): Gacko (maintainer) 565, k8s-infra-cherrypick-robot 245, Dependabot 104 = 914, o sea "9 de cada 10". Los títulos de Gacko son casi todos tareas de mantenimiento: "Images: Trigger NGINX build." 219, "Go: Update dependencies." 128, CI 70, Tests 51. El siguiente autor humano: 11 PRs. 2024 se ve igual: cherry-pick robot 529, Gacko 184, Dependabot 115 de 1,000. - Entonces hay más PRs que issues porque los maintainers y los bots los abrieron para mantener el proyecto con patch, no porque los usuarios mandaran arreglos. Los números de adopción (Wiz 41%+, Steering ~50%) están en la diapositiva anterior; esta es solo sobre la demanda. [TIEMPO: 60s.]

Las personas detrás del controller

"Hacemos esto en nuestro tiempo libre, y cada vez nos cuesta más mantener este ritmo. … y los bugs que puedan salir de esas features."

James Strong (@strongjz) · maintainer de ingress-nginx · 23 jun 2022

"We do this in our spare time, and it's becoming hard for us to keep this pace. … and the bugs that may arise from this feature." (traducción propia)

Fuentes: James Strong, kubernetes dev list, 23 jun 2022 · kubernetes/org#5305, 15 dic 2024

Esta es la diapositiva humana. Reescrita el 30 sep 2026: se quitó la caja de terminal (su "we're drowning" era una paráfrasis entre comillas, no palabras de los maintainers), y una cita textual de un maintainer explica lo que estaba pasando. Cita completa (en la diapositiva va recortada con "…"): "Hacemos esto en nuestro tiempo libre, y cada vez nos cuesta más mantener este ritmo. … ahora tenemos que repartir nuestro tiempo entre issues, bug fixing, review de features nuevas y los bugs que puedan salir de esas features." Original: "We do this in our spare time, and it's becoming hard for us to keep this pace. … we now have to split our time between issues, bug fixing, new feature reviews, and the bugs that may arise from this feature." Fuente: kubernetes dev list. La cita: el correo de James Strong a la kubernetes dev list, 23 jun 2022, verificado contra la página de Google Groups el 30 sep 2026. El "…" omite una oración: "This lack of support becomes a burden to Ingress NGINX maintainers:". El mismo correo sigue: "it's time to temporarily pause accepting new features and focus on fixing and stabilizing Ingress NGINX" (la marca de pausa de features en la gráfica). La frase resaltada es la diapositiva anterior dicha por un maintainer: cada feature se vuelve mantenimiento. La traducción en pantalla es propia; el original en inglés va abajo, textual. Díganlo después de la cita (el costo personal, con su voz): dos años después, Ricardo Katz (@rikatz) dio un paso al costado. kubernetes/org#5305, 15 dic 2024: "I need some time for myself, and I am not really being able to take care of the project and my personal life together :)" ("Necesito tiempo para mí, y no estoy pudiendo cuidar del proyecto y de mi vida personal a la vez :)"). La carita feliz es lo que lo hace peor. Lo que realmente hacían, por $0, fuera de horario: triage y review, patches de CVEs, gestión de releases, soporte a usuarios. Viene de la diapositiva eliminada "Por qué colapsó" (27 sep 2026). Cuatro razones del colapso, para decirlas si hay tiempo: - Sobrecarga de CVEs: un puñado de maintainers haciendo patch de bugs de seguridad sin compensación (la gráfica de CVEs, dos diapositivas atrás). - Triage congelado: más de 50 issues con la etiqueta lifecycle/frozen porque la cola se volvió imposible de revisar. - Reemplazo abandonado: InGate, el sucesor en kubernetes-sigs con el mismo equipo de maintainers, salió y se retiró. Sin voluntarios. - Rescate corporativo rechazado: Steering rechazó una toma de control de último minuto, por confianza en seguridad. @BenTheElder, 21 ene 2026: "Building trust for owning critical software takes time, we needed that to happen years ago during the earlier pleas for support." ("Ganar la confianza para ser dueño de software crítico toma tiempo; necesitábamos que eso pasara hace años, cuando se pidió ayuda las primeras veces.") (kubernetes/ingress-nginx#14178) [TIEMPO: 60s. Lean la cita, hagan una pausa, avancen.]

Acto 03

El costo

Para las empresas, los maintainers y la IA.

No hay reemplazo directo

reemplazos directos
para ingress-nginx.

"La mitad de ustedes se verá afectada."
Kubernetes Steering + Security Response Committee · 29 ene 2026
"Half of you will be affected." (traducción propia)

Fuentes: Kubernetes Steering + Security Response Committee statement, 29 ene 2026

Simplificada el 4 oct 2026: la cita en la slide quedó solo con su última frase. La primera ("Ninguna de las alternativas disponibles es un reemplazo directo") ya la dice el número 0. Un solo número en esta diapositiva: cero reemplazos directos. El dato de "about half of cloud native environments" (comunicado de Steering, 29 ene 2026, Kat Cosgrove) ya salió en la diapositiva de la línea de tiempo; aquí regresa como la última línea de la cita: "La mitad de ustedes se verá afectada." No es un problema de nicho; afecta a la mitad de la sala. Enfaticen la cita del Steering Committee: "Ninguna de las alternativas disponibles es un reemplazo directo." Cita completa (en la diapositiva va recortada con "…"): "Ninguna de las alternativas disponibles es un reemplazo directo. Esto va a requerir planificación y tiempo de ingeniería. La mitad de ustedes se verá afectada." Original: "None of the available alternatives are direct drop-in replacements. This will require planning and engineering time. Half of you will be affected." Una migración no planeada significa revisar cada YAML de ingress para traducir las annotations de Nginx. Son meses de tiempo de ingeniería. [TIEMPO: 60s. Hagan referencia al comunicado oficial de K8s de enero 2026.]

La mayoría no cobra

60%

de los maintainers
no recibe pago

Fuente: Tidelift, 2024 State of the Open Source Maintainer Report

[4 oct 2026: se quitó del slide la línea "60% renunció o pensó en renunciar" para no mostrar dos 60% distintos. Tidelift lo publica como "almost 60% of maintainers have quit or considered quitting" (https://dev.to/tidelift/maintainer-burnout-is-real-almost-60-of-maintainers-have-quit-or-considered-quitting-maintaining-one-of-their-projects-51ma). Si lo dicen, digan "casi 60%" y que es otra pregunta de la encuesta.] Simplificada el 4 oct 2026: la cita de @BenTheElder salió de la slide; ahora va solo el 60% y la línea de "renunció o pensó en renunciar" (mismo reporte de Tidelift: "have either quit or considered quitting", 60%). Cita que salió, díganla en voz alta: "Hace tiempo que nadie le paga a nadie por trabajar en este software; ha sido totalmente voluntario y los ha rebasado." Original: "Nobody has been paying anyone to work on this software for some time, it has been entirely volunteer driven and they've been overwhelmed." @BenTheElder, Kubernetes Steering Committee, 21 ene 2026, kubernetes/ingress-nginx#14178: https://github.com/kubernetes/ingress-nginx/issues/14178#issuecomment-3779849797 Texto que salió de la diapositiva (díganlo al cerrar): - "60% de los maintainers de open source no reciben pago por su trabajo." - "Es la línea más cara de esta charla: tiempo, salud e impacto en la carrera." - "La cascada de CVEs convirtió el trabajo voluntario en un segundo empleo con responsabilidad de seguridad constante." Esta es la diapositiva que el público de Nerdearla va a sentir en el pecho. Son las personas que serían maintainers si la economía fuera distinta. El "60%" viene del reporte 2024 State of the Open Source Maintainer de Tidelift: "60% of maintainers are (still) not paid for their work", y el porcentaje que "have either quit or considered quitting" también fue 60%. Digan "2024": Tidelift (hoy parte de Sonar) no ha publicado una edición más nueva. La revisión 1 citaba ByteIota / It's FOSS, que estaban repitiendo esta misma encuesta. La cita de @BenTheElder es la línea individual más fuerte de todo el registro de kubernetes.org. Él está en el Steering Committee. El backdoor de XZ Utils es lo que hizo que el Steering Committee rechazara el rescate corporativo de último minuto: no querían respaldar a un maintainer que no hubiera pasado por la escalera de contribución. Pero el problema de fondo era: nadie le pagaba a nadie. La línea de la "cascada de CVEs" de abajo conecta con la diapositiva "Por qué colapsó". Los maintainers no solo hacían trabajo de features gratis: hacían trabajo de SEGURIDAD gratis. Esa es la parte que no aparece en un reporte de compras. [TIEMPO: 60s. El número es el titular. La cita de @BenTheElder es la moraleja. Dejen que la sala haga las cuentas.]

La IA multiplicó el inbox

3.6×

PRs merged al mes en GitHub desde 2023

Fuentes: GitHub Octoverse 2025, 28 oct 2025 (promedios mensuales 2024/2025, repos públicos) · GitHub Blog, 18 jun 2026 (PRs mergeados, ene 2023 y 2026)

Simplificada el 4 oct 2026: quedó solo el panel de PRs merged. Los paneles de Commits (65M prom. 2024, 82M prom. 2025, ~1,200M ritmo abr 2026*) y PRs abiertos (39.5M prom. 2024, 47.5M prom. 2025) salieron de la slide; los números y su explicación siguen abajo. * Fuente del ritmo de commits: Kyle Daigle (COO de GitHub), citado en Latent Space, 2 jun 2026: 275M commits/semana en abr 2026. https://www.latent.space/p/github Texto que salió de la diapositiva: - Subtítulo: "Actividad mensual en GitHub, según GitHub (cada panel tiene su propia escala)". - "PRs merged: de 25M a más de 90M al mes desde enero de 2023, unas 3.6×." - El panel "Commits" se llamaba "Commits enviados" (pushes). Gráfica de tres paneles (30 sep 2026, segunda versión). Todos los números son de GitHub, todos por mes: - Octoverse 2025 (28 oct 2025), tabla "2024 monthly average / 2025 monthly average": "Code pushes 65M 82.19M", "Pull requests merged 35M 43.2M" y "Pull requests created: +20.4% (47.5M vs 39.5M)". Octoverse dice que sus números son actividad pública salvo que se indique otra cosa. Además: "pushed nearly 1 billion commits in 2025 (+25.1% YoY)". - GitHub Blog, 18 jun 2026: "In January 2023, developers merged about 25 million pull requests a month across GitHub. Today that number tops 90 million—a roughly 3.6x increase." Ojo: el alcance dice "across GitHub" (Octoverse dice público); las etiquetas de GitHub no coinciden entre sí, así que no digan que es solo open source. - Kyle Daigle, COO de GitHub, citado en Latent Space (2 jun 2026): "There were 1 billion commits in 2025. Now, it's 275 million per week, on pace for 14 billion this year if growth remains linear". La barra de ~1,200M al mes es 275M × 52 / 12, un ritmo proyectado, no un mes medido. Díganlo en voz alta: "ritmo". - Cuidado con "billion": en español son MIL MILLONES, no billones. 1 billion commits = mil millones; 14 billion = 14 mil millones. - Todavía no hay un número oficial de PRs abiertos en 2026, así que ese panel termina en 2025. En la tabla de Octoverse, commits y PRs son pushes; el texto trata ~1,000 millones de commits y 82M de pushes al mes como lo mismo. Cada panel tiene su propia escala: comparen el crecimiento dentro de un panel, no las alturas entre paneles. Versión anterior de esta gráfica (descartada): GitHub Innovation Graph, git pushes humanos por trimestre, sin bots: de 106.3M (Q2 2021) a 319.8M (Q1 2026), 3.0×, +80% interanual. Nuevo en la revisión 2. Desde la presentación de junio, la historia de la IA cambió de "la IA encuentra bugs" a "la IA entierra a los maintainers". curl (15 jun 2026): "The curl project will not accept or otherwise handle any vulnerability reports during the month of July 2026." ("El proyecto curl no aceptará ni atenderá reportes de vulnerabilidades durante julio de 2026.") Pausa desde el 1 de julio 00:00 CEST, reanudación el 3 de agosto 09:00 CEST. Solo se pausaron los reportes de vulnerabilidades; los issue trackers siguieron abiertos. Y la frase que hace el punto de la charla por ustedes: "Everyone with a paid support contracts will of course still get full and appropriate service even during this period." (el error de dedo está en el original). Quien pagaba soporte siguió atendido; los demás esperaron. Seguimiento (3 ago): "This was possibly our best project decision in a long while." ("Posiblemente fue nuestra mejor decisión como proyecto en mucho tiempo.") "High-Quality Chaos" (22 abr): "Recently it's been about double the rate we had through 2025, which already was more than double from previous years." Y ahora los reportes son BUENOS: "somewhere in the 15-16% range" son vulnerabilidades confirmadas. El problema ya no es basura. Es volumen de trabajo real con el mismo puñado de personas. GitHub (18 jun 2026, Camilla Moraes y Ashley Wolf): "In January 2023, developers merged about 25 million pull requests a month across GitHub. Today that number tops 90 million—a roughly 3.6x increase." Quitado de la diapositiva el 27 sep 2026, vale la pena decirlo si hay tiempo: kernel.org (29 ago 2026), "git.kernel.org receives about 6M daily requests"; "legitimate requests are only about 2% of git.kernel.org traffic — everything else are scrapers." (Solo ~2% del tráfico es legítimo; el resto son scrapers.) https://people.kernel.org/monsieuricon/creepy-crawlies Advertencia sobre 25M → 90M+: son TODOS los PRs merged en GitHub (repos privados, bots y agentes incluidos), no solo open source. [TIEMPO: 90 s.]

La IA encuentra bugs más rápido de lo que los voluntarios pueden arreglarlos

Captura de pantalla de la primera actualización de Project Glasswing de Anthropic — anthropic.com · "Project Glasswing: An initial update" · 22 may 2026

Anthropic · Project Glasswing

"…algunos incluso nos pidieron bajar el ritmo de nuestras divulgaciones porque necesitan más tiempo para diseñar los patches."

"…some have even asked us to slow down our rate of our disclosures because they need more time to design patches." (traducción propia)

75 de 530 bugs altos/críticos ya tenían patch al publicar

Black Duck OSSRA 2026

El promedio de vulnerabilidades por codebase subió 107%, a 581. El 87% de los codebases tiene al menos una.

Mozilla · con equipo pagado

423 security bugs de Firefox en abril de 2026; 271 los encontró un pipeline de IA.

Patch the Planet · 22 jun

"una manguera de hallazgos de seguridad, y maintainers ya rebasados tienen que revisarlo todo"

"a firehose of security findings, and already-stretched maintainers must sift through all of it" (traducción propia)

Fuentes: Anthropic, Glasswing update, 22 may 2026 · Black Duck OSSRA 2026 · Mozilla Hacks, 7 may 2026 · Trail of Bits, 22 jun 2026

Actualizado en la revisión 2. En junio el titular era "la IA encuentra más de 10 mil bugs". Cuatro meses después el titular es: arreglarlos no escaló. Evidencia (re-verificada el 26 sep 2026): - Anthropic, "Project Glasswing: An initial update" (22 may 2026): "several maintainers have told us they're currently severely capacity constrained, and some have even asked us to slow down our rate of our disclosures because they need more time to design patches." Y "75 of the 530 high- or critical-severity bugs we've reported have now been patched". Anthropic también donó $2.5M a Alpha-Omega/OpenSSF y $1.5M a la Apache Software Foundation (anthropic.com/glasswing). NOTA: las cifras que tanto se repiten de "1,596 vulns / 281 proyectos / ~6% con patch" son de una nota de la Cloud Security Alliance, no de Anthropic. No las usen sin citar a la CSA. - Blog de Black Duck sobre OSSRA 2026: "rising 107% to an average of 581 vulnerabilities"; "87% of all audited codebases contained at least one vulnerability". - Mozilla Hacks, 7 may 2026: "We fixed a total of 423 security bugs in releases in April. In addition to the 271 bugs announced two weeks ago…" El contraste: Mozilla tiene un equipo de seguridad con presupuesto para absorber 271 bugs encontrados por IA. Un proyecto de dos personas no. - Trail of Bits, "Introducing Patch the Planet", 22 jun 2026: "Frontier models like GPT-5.5-Cyber are producing a firehose of security findings, and already-stretched maintainers must sift through all of it to separate real vulnerabilities from plausible-sounding false positives." Personas hacen el triage antes de que los maintainers vean nada, y se incluyen los patches. Ese es el modelo a aplaudir. Texto recortado de la diapositiva: "75 de los 530 bugs altos/críticos reportados a proyectos OSS estaban con patch al momento de publicar"; "423 bugs de seguridad de Firefox corregidos en abril de 2026, 271 de ellos encontrados por un pipeline de IA." El cuello de botella ya no es encontrar bugs. Es la capacidad humana de hacerles patch, y esa capacidad no se paga. [TIEMPO: 2 minutos.]

Entraron por personas, no por código

Qué cayó · 2026Cómo entraron

axios (paquete npm, ~100M descargas/semana) RAT en la PC del maintainer

trivy-action (GitHub Action de seguridad) token de CI robado · 76 de 77 tags

GitHub (sus repos internos) extensión de VS Code envenenada · ~3,800 repos

ChainDrop (worm en npm) tokens de maintainers robados · 400+ paquetes

Fuentes: post-mortem de axios, axios/axios#10636, 2 abr 2026 · Wiz, 31 mar 2026 · GHSA-69fq-xp46-6x23 · GitHub Blog, 20 may 2026 · Microsoft Security Blog, 4 ago 2026

Simplificada el 4 oct 2026: de 4 tarjetas con número grande a 4 líneas "qué cayó (qué es) · cómo entraron". El título es el mensaje: ninguno entró por un bug de código. Fechas: axios 31 mar, trivy-action 19 mar, GitHub 20 may, ChainDrop 4 ago 2026. Título anterior: "El token de un maintainer es tu producción". Explicaciones de nombres, verificadas el 4 oct 2026: Wiz describe axios como paquete npm "downloaded ~100 million times per week"; el GHSA describe aquasecurity/trivy-action como GitHub Action de Trivy, un vulnerability scanner usado en CI/CD; Microsoft llama a ChainDrop "self-propagating worm" en npm. Texto que salió de la diapositiva (una frase por tarjeta): - Subtítulo: "Los mayores ataques a open source de 2026 entraron por personas, no por código." - axios: ingeniería social metió un RAT en la PC del maintainer principal. Robó el login de npm. - trivy-action: un token de CI robado convirtió un scanner de seguridad en malware. - GitHub: un empleado instaló una extensión de VS Code envenenada (Nx Console). - ChainDrop worm: con tokens robados republicaron keyv, cache-manager y más. Reescrita el 30 sep 2026: los cuatro mayores ataques a open source de 2026, cada uno contado como proyecto → un número → una línea. Todos entraron por una persona o su credencial, no por un bug de código. - axios (31 mar 2026, sin CVE). Post-mortem del maintainer Jason Saayman, axios/axios#10636 (2 abr): "The attacker gained access to the lead maintainer's PC through a targeted social engineering campaign and RAT malware. This gave them access to the npm account credentials, which they used to publish the malicious versions." Versiones maliciosas 1.14.1 y 0.30.4. Wiz (31 mar): "present in ~80% of cloud and code environments and downloaded ~100 million times per week"; "observed execution in 3% of affected environments". La lección del propio post-mortem: "Open source maintainers with high-impact packages are active targets for sophisticated social engineering." (Los maintainers de paquetes de alto impacto son blancos activos de ingeniería social sofisticada.) - trivy-action (CVE-2026-33634, GHSA-69fq-xp46-6x23, CVSS 9.4). Ataque activo del 19 al 20 de marzo; advisory publicado el 21. "force-push 76 of 77 version tags in aquasecurity/trivy-action to credential-stealing malware". Aqua: los atacantes extrajeron un token de acceso privilegiado, y la rotación "was not fully comprehensive". Efecto dominó: LiteLLM en PyPI (24 mar): "the compromise originated from the Trivy dependency used in our CI/CD security scanning workflow". - GitHub (20 may 2026, actualizado el 26 de mayo; CVE-2026-48027, GHSA-c9j4-9m59-847w para Nx Console 18.95.0). GitHub Blog, Alexis Wales: "a compromise of an employee device involving a poisoned VS Code extension published by a third party." "The attacker's current claims of ~3,800 repositories are directionally consistent with our investigation so far." Y: "no evidence of impact to customer information stored outside of GitHub's internal repositories". La cadena: TanStack (CVE-2026-45321, 11 may, 84 versiones maliciosas en 42 paquetes @tanstack) filtró las credenciales de GitHub de un desarrollador de Nx, con eso se publicó el Nx Console envenenado, que llegó a un empleado de GitHub. - ChainDrop (4 ago 2026), Microsoft Threat Intelligence: "a large-scale npm supply chain attack affecting more than 400 packages across multiple unrelated publishers, including packages associated with major enterprise software ecosystems such as keyv, flat-cache, cache-manager, and others." "Evidence points towards stolen maintainer credentials as the attack vector for initial compromise." Datadog Security Labs (el mismo día) muestra que la primera ola salió por un commit malicioso y por trusted publishing legítimo con OIDC, con provenance genuina: "Some of these npm packages have over 150 million weekly downloads." "Many malicious versions had no corresponding source-code commit, pull request, tag, or legitimate release" (Microsoft). Lo que quedó fuera de las tarjetas, díganlo si hay tiempo: - Red Hat RHSB-2026-006 (1 jun): 32 paquetes npm de @redhat-cloud-services, cuenta de GitHub "compromised via a VS code extension containing malware". El mismo patrón que GitHub, con una víctima más chica. - La respuesta de npm (changelog de GitHub, 3 y 18 sep): publicación por etapas, tokens solo para staging; los tokens que se saltan el 2FA para publicar directo desaparecen en enero de 2027. Cada maintainer tiene tarea de migración. - Contraste, si preguntan "¿y los bugs de verdad?": Copy Fail, CVE-2026-31431 (29 abr), un root local en el kernel de Linux con 9 años de antigüedad, en el CISA KEV desde el 1 de mayo. El peor bug de código del año, y aun así no fue la historia del año. [TIEMPO: 90 s. Una frase por tarjeta.]

Acto 04

La solución

Dejen de llamarlo gratis. Trátenlo como infraestructura.

Operen sus dependencias como infra

1 · Medir

OpenSSF Scorecard de github.com/kubernetes/ingress-nginx: puntaje 6.9, generado el 2026-03-20, check Maintained en 10 — scorecard.dev · 27 sep 2026

Scorecard: nota de salud del repo, en CI

2 · Definir SLOs

endoflife.date/kubernetes: fechas de soporte activo y de mantenimiento por versión, actualizado el 24 sep 2026 — endoflife.date · 27 sep 2026

Nada EOL en producción

3 · Asignar gente

Post del blog de la CNCF: Sustaining OpenTelemetry: What a 10-week contributor cohort actually looks like, 23 jul 2026, por Alyssa Wright, OSPO de Bloomberg — cncf.io · 23 jul 2026

2 h/semana upstream por ingeniero

Fuentes: OpenSSF Scorecard, ingress-nginx · endoflife.date, Kubernetes · CNCF Blog, Alyssa Wright (Bloomberg OSPO), 23 jul 2026 · Capturas recortadas · Los SLOs son ejemplos

4 oct 2026: volvieron las capturas, una por paso. La tercera es el post de la CNCF sobre la cohorte de Bloomberg × OpenTelemetry (Alyssa Wright, OSPO de Bloomberg, 23 jul 2026): 48 ingenieros, 10 semanas. Es la prueba de "asignar gente"; el detalle va en #bloomberg-cohort, no lo repitan aquí. Antes (simplificación): flujo de 3 pasos sin capturas; salieron de la slide las dos capturas (Scorecard de ingress-nginx y endoflife.date/kubernetes) y la columna de fundaciones (Linux Foundation, CNCF, AAIF). Todo sigue abajo. Fuentes que salieron del footer: Linux Foundation, lanzamiento de AAIF, 9 dic 2025 (https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation) y Proyectos de la CNCF (https://www.cncf.io/projects/). - Antes: "Open source es infraestructura crítica". - Monitorear (ahora "Medir"): alerten también por archived y EOL. - Definir SLOs: CVE crítico, patch en 7 días. - Asignar gente: súmense a la fundación detrás de lo que corren. Texto que salió de la slide (díganlo en voz alta si hace falta): - Subtítulo: "Sus dependencias son su infraestructura. Opérenlas como tal." - Monitorear: un SBOM por servicio (Syft), más Scorecard y OSV-Scanner en CI. Alerten también por archived y EOL: el último scan aún dice Maintained 10/10. - Definir SLOs: CVE crítico en una dependencia, patched en 7 días. Nada después de su EOL en producción; alerta 90 días antes. - Asignar gente: un owner por cada dependencia tier-1, con 2 h/semana upstream. Súmense a la fundación detrás de lo que corren. Las fundaciones de la columna son ejemplos. Rehecha el 27 sep 2026 con una herramienta real por práctica. Recórranla de izquierda a derecha; cada columna es algo que un equipo de plataforma puede empezar este trimestre. Ninguna es una disciplina nueva: es SRE aplicado a las dependencias. MONITOREAR. Captura: el visor de OpenSSF Scorecard para github.com/kubernetes/ingress-nginx, tomada el 27 sep 2026. Puntaje total 6.9. "Generated at 2026-03-20", cuatro días antes de que archivaran el repo (24 mar), y nada más reciente. Todavía muestra el check Maintained en 10/10. Esa es la lección: un puntaje de salud por sí solo no les habría avisado. Alerten también cuando un repo se archiva y cuando se anuncia un EOL. Stack práctico: un SBOM por servicio (Syft o CycloneDX), OSV-Scanner o Dependabot/Renovate para CVEs, Scorecard o deps.dev para la salud del proyecto, métricas de CHAOSS para el riesgo de maintainers. DEFINIR SLOs. Captura: endoflife.date/kubernetes, "Last updated on 24 September 2026", con las fechas de fin de soporte activo y de mantenimiento por release. El EOL es una fecha, así que se puede alertar. Los dos SLOs de la diapositiva son EJEMPLOS, no un estándar de la industria; díganlo. Otros buenos: nada con más de 12 meses o una versión mayor de atraso; Scorecard de 6 o más y al menos 2 maintainers activos en dependencias tier-1. Usen un error budget: cuando se agota, el trabajo en dependencias va antes que las features. ASIGNAR GENTE (30 sep 2026: las fundaciones reemplazaron la captura de Open Source Pledge). Responsables: uno por dependencia tier-1, como un service owner. 2 h/semana: la cohorte de OpenTelemetry de Bloomberg, más adelante en la charla. Luego súmense a la fundación que aloja lo que corren. Las tres son ejemplos, elijan según su stack: - Linux Foundation: la sombrilla. CNCF y AAIF son proyectos de la Linux Foundation (aaif.io: "a neutral, open foundation under the Linux Foundation"). - CNCF: Kubernetes, OpenTelemetry (cncf.io/projects). Los precios de membresía están en la escalera de financiamiento, dos diapositivas más adelante; no los repitan aquí. - AAIF, la Agentic AI Foundation: lanzada el 9 dic 2025 (comunicado de la Linux Foundation) con MCP de Anthropic, goose de Block y AGENTS.md de OpenAI. Miembros Platinum: AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, OpenAI. Relevante si sus equipos construyen sobre agentes. Open Source Pledge, si preguntan: las empresas pagan a maintainers al menos $2,000 USD por desarrollador al año; los miembros han pagado $7,408,535 USD desde el lanzamiento (opensourcepledge.com/members, 30 sep 2026). Una OSPO, aunque sea de 1 o 2 personas, sostiene todo esto. [TIEMPO: 90 s. El giro debe sentirse como alivio, no como más trabajo.]

❯ nuevo desde junio

La industria por fin lo dijo en voz alta

Gráfico de OpenSSF: We're In: Enterprise Commitment to Sustainable Package Registries, firmado por Arm, Datadog, Dell Technologies, Ericsson, GitHub, Google, IBM, Kusari, Microsoft, Red Hat, Rust Foundation y Sonatype — openssf.org · "We're In: Enterprise Commitment to Sustainable Package Registries" · 16 sep 2026

12 firmantes pagarán a los registries según su uso empresarial.

OpenSSF · 16 sep 2026

"…los esfuerzos heroicos de equipos pequeños, muchas veces de solo dos o tres personas."

"…the heroic efforts of small teams, often just two or three people." (traducción propia)

1.8 millones de paquetes maliciosos que requirieron baja manual "en lo que va de 2026"

Brian Fox · Sonatype / Maven Central · 16 jun 2026

"Pero abierto no significa infinito. Y gratis no significa sin costo."

"But open does not mean infinite. And free does not mean costless." (traducción propia)

Límites de publicación + plan pago "Publisher Pro" para escala comercial · vigente desde el 1 oct 2026

Fuentes: OpenSSF, 16 sep 2026 · Sonatype, "Sustaining Open Publishing at Commercial Scale", 16 jun 2026

Texto que salió de la slide (díganlo en voz alta si hace falta): - 12 firmantes se comprometen a pagar cuotas a los registries según su uso empresarial, como inversión de negocio, manteniendo el acceso gratis para personas y organizaciones pequeñas. Incluye PyPI, npm, Maven Central, crates.io, RubyGems, NuGet, Open VSX, Packagist. Nuevo en la revisión 2, y la evidencia más fuerte de toda la charla. El 16 de septiembre, doce organizaciones, entre ellas Google, Microsoft, GitHub, IBM y Red Hat, firmaron una declaración pública: los registros de paquetes son infraestructura por la que las empresas deberían pagar. Esa es la tesis de esta charla, en sus propias palabras. Evidencia: - Blog de OpenSSF, 16 sep 2026. Firmantes: Arm, Datadog, Dell Technologies, Ericsson, GitHub, Google, IBM, Kusari, Microsoft, Red Hat, Rust Foundation, Sonatype. Citas: los registros dependen de "the heroic efforts of small teams, often just two or three people." "The number of malicious components that require human analysis and takedown has reached 1.8 million packages so far in 2026". El gráfico de la izquierda es la imagen oficial de OpenSSF en el post. - Sonatype, "Sustaining Open Publishing at Commercial Scale", Brian Fox, 16 jun 2026: "But open does not mean infinite. And free does not mean costless." La aplicación estricta se fijó primero para el 11 de agosto; la actualización del 23 de julio la movió al 1 oct 2026. Gratis para open source comunitario; los límites apuntan a la publicación a escala comercial. - Esta frase de Brian Fox es el título de la charla dicho por alguien más. Si la usan, háganlo explícito: "free" aquí es "gratis", no "libre". Pregúntenle a la sala: ¿su empresa está en esa lista? Si no, ¿por qué no? [TIEMPO: 2 minutos.]

❯ hecho en Latinoamérica

FastAPI: noches y fines de semana

~800K

downloads al día (2023) de FastAPI, framework web de Python hecho en Colombia.

Sebastián Ramírez (@tiangolo) · creador de FastAPI

"Estaba trabajando como loco"… tanto, que un dedo se le durmió por completo.

"I was just working like crazy," … so much so that … one of his fingers went completely numb. (traducción propia)

Fuente: Natalie So, "Keeping an Open-Source Mind", Sequoia Capital, 3 ago 2023

Texto que salió de la slide (díganlo en voz alta si hace falta): - ~800K downloads al día de FastAPI en 2023, creado por Sebastián Ramírez, desde Colombia. - Lo construyó en noches y fines de semana, con un trabajo de tiempo completo. Antes de que se le durmiera el dedo, también le empezó a temblar un ojo. Quién: Sebastián Ramírez (@tiangolo), vía Sequoia, 3 ago 2023. - Lo que cambió: una fellowship pagada. "Por primera vez en su vida" pudo dedicarse de tiempo completo a su open source. Nuevo en esta edición, para Nerdearla. Un ejemplo de nuestra región: esto no es solo un problema de Silicon Valley. FastAPI es uno de los frameworks web de Python más usados. Lo creó Sebastián Ramírez, colombiano. Lo hizo en sus noches y fines de semana mientras trabajaba tiempo completo en otra cosa, y el costo fue físico: un ojo que temblaba y un dedo dormido. Lo que lo cambió fue que alguien pagara. Con la Sequoia Open Source Fellowship, "for the first time in his life", pudo dedicarse de tiempo completo a su trabajo open source. Esa es la tesis del Acto 04: cuando alguien paga, el proyecto deja de depender de la salud de una persona. Evidencia (Sequoia Capital, "Keeping an Open-Source Mind", Natalie So, 3 ago 2023): - "As of 2023, FastAPI is downloaded roughly 800,000 times per day." - "He was still working for his brother-in-law full-time, with nights and weekends devoted to this passion project." - "'I was just working like crazy,' he recalled later, so much so that he developed a twitch in his eye, and one of his fingers went completely numb." - "The fellowship means that, for the first time in his life, Ramirez can focus full-time on his open-source work." Ojo: la fuente es de 2023 y la publica Sequoia, que creó la fellowship. Digan "según Sequoia" si alguien pregunta. El 800K es de 2023, no de hoy. [TIEMPO: 75 s.]

Poco dinero, resultados medibles

GitHub Secure Open Source Fund · fondo de seguridad

533 CVEs encontrados por 188 proyectos
con ~$10K cada uno

ROI 2–5× para empresas que contribuyen vs. solo consumir (Linux Foundation)

Fuentes: GitHub, 13 ago 2026 · Linux Foundation, 24 feb 2026

Simplificada el 4 oct 2026: un solo hero (533 CVEs con ~$10K por proyecto: $1.88M entre 188 proyectos) más el ROI. Salieron de la slide Alpha-Omega y el EU CRA; díganlos en voz alta si hay tiempo. Fuentes que salieron del footer: - OpenSSF, 17 mar 2026: https://openssf.org/press-release/2026/03/17/linux-foundation-announces-12-5-million-in-grant-funding-from-leading-organizations-to-advance-open-source-security/ (Alpha-Omega es el fondo de seguridad de OpenSSF). - EU CRA, obligaciones de reporte: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting (EU CRA = ley europea de ciberseguridad). Texto que salió de la slide (díganlo en voz alta si hace falta): - Subtítulo: "Lo que realmente compraron los programas de financiamiento de 2026." - GitHub Secure OSS Fund: 533 CVEs encontrados y divulgados por 188 proyectos financiados, con $1.88M USD en total. - Alpha-Omega · OpenSSF: $12.5M USD en grants para maintainers golpeados por bugs encontrados por IA. - Linux Foundation: ROI 2–5× para empresas que contribuyen en vez de solo consumir. - EU Cyber Resilience Act (Ley de Ciberresiliencia), desde el 11 sep 2026: reportar vulnerabilidades explotadas en 24 horas. La obligación es de quien distribuye el open source. Nuevo en la revisión 2. La respuesta a "no tenemos presupuesto": los montos que funcionan son pequeños, y el ROI está publicado. Evidencia: - GitHub, "What 50 open source projects taught us about security in the AI era", Gregg Cochran, 13 ago 2026: "The Secure Fund invested more than $500,000 across 50 projects", $10,000 USD cada uno. Los 533 CVEs son de TODOS los proyectos participantes en todas las cohortes (188 proyectos, $1.88M USD), no solo de estos 50: "Participating projects have identified and disclosed 533 new CVEs". Además, "participating and Alumni projects fixed 4,210 CodeQL alerts" en los seis meses que terminaron en julio de 2026. - Comunicado de OpenSSF, 17 mar 2026: "$12.5 million in total grants from Anthropic, AWS, GitHub, Google, Google DeepMind, Microsoft, and OpenAI". Es anterior a junio, pero son los laboratorios de IA pagando por el desorden que crearon sus herramientas. - Linux Foundation, "ROI for Open Source Software Contribution" (Boysel y Lawson, feb 2026, 567 respuestas): "active contribution delivers a 2-5x return on investment"; "Foundation membership stands out with a 4.8x ratio". Los números de forks privados del mismo reporte están en la diapositiva del "impuesto del fork", en el Acto 05. - Obligaciones de reporte del EU CRA (página de la Comisión, 11 sep 2026): "As of 11 September 2026, manufacturers are required to report actively exploited vulnerabilities and severe incidents". Alerta temprana en 24 horas, notificación en 72 horas, reporte final dentro de 14 días después del fix. Las obligaciones completas del CRA aplican desde el 11 dic 2027. - Para una audiencia en México: el CRA aplica a quien vende productos con elementos digitales en la Unión Europea. Si su empresa exporta software o hardware a la UE, les toca. [TIEMPO: 90 s.]

Empiecen donde alcance el presupuesto

Sepan qué corren

$0 · unas horas

Suban sus fixes upstream

$0 · su tiempo

Financien lo que usan

cualquier monto

Únanse a la fundación

desde $2K al año

Fuente: Membresía CNCF

Simplificada el 4 oct 2026: cada escalón es número + acción + costo. Las etiquetas Conocer / Upstream / Pagar / Unirse salieron; la acción ya lo dice. Fuentes que salieron del footer (sus datos solo están aquí en las notas): - Linux Foundation, "ROI for Open Source Software Contribution", feb 2026: https://www.linuxfoundation.org/research/contribution-roi - Bloomberg FOSS Contributor Fund, Open Collective, 30 sep 2026: https://opencollective.com/bloomberg-foss-fund Texto que salió de la slide (díganlo en voz alta si hace falta): - Subtítulo: "Dos de los cuatro solo cuestan tiempo. Cada uno ya lo hace alguna empresa." - 01 Conocer: un SBOM por servicio, más los forks y patches que cargan. El 45% de las organizaciones mantiene forks privados (LF, 2026). - 02 Upstream: manden el patch en vez de cargarlo. El 66% dice que los maintainers responden más rápido a quien contribuye. - 03 Pagar: aportes pequeños y regulares a los proyectos de los que dependen. Bloomberg FOSS Fund: aportes de $10K, ~$320K pagados, p. ej. a Let's Encrypt. - 04 Unirse: un lugar en la mesa donde se decide el roadmap. CNCF Silver desde $2K al año. La membresía rinde 4.8×. Replanteada el 30 sep 2026 como consejo, no como pitch de ventas: las tarjetas tienen la misma altura y cada una muestra su costo. No toda empresa tiene presupuesto, y está bien. Los escalones 01 y 02 solo cuestan tiempo de ingeniería, y el 02 es tiempo que ya gastan cargando el patch. Digan: "Empiecen por el escalón que permita su presupuesto. La mayoría puede hacer los dos primeros el lunes sin pedirle dinero a nadie." Financiar y unirse a fundaciones es para cuando estén listos, no un costo de entrada. Los $750K de Sentry (abajo) van en las notas, no en la slide, para que no se lea como "gasten mucho". Evidencia (todo verificado en la página fuente, sep 2026): - LF, "ROI for Open Source Software Contribution: Insight from the Open Source ROI Survey and Economic Model", Sam Boysel y Adrienn Lawson, feb 2026, 567 respuestas (oct-nov 2025). 45% mantiene forks privados. "66% of respondents noted that upstream maintainers respond more quickly to security issues". "Foundation membership stands out with a 4.8x ratio"; la membresía "increases overall OSS contribution rates by 24% on average". - Escalón 02: la historia de Percona (PR #2315) se cuenta una sola vez, en #one-less-fork. Comentario opcional aquí: "al final les muestro el mío." - Ejemplo de la tarjeta 03: Bloomberg FOSS Contributor Fund en Open Collective (opencollective.com/bloomberg-foss-fund, 30 sep 2026): "$319,902.13" desembolsados, $360,021.98 recaudados; aportes recientes de $10,000 a Let's Encrypt y pURL. La página de Bloomberg bloquea las descargas, así que el registro de Open Collective es la fuente pública. - Ejemplo alternativo, Microsoft FOSS Fund (github.com/microsoft/foss-fund): "Every quarter a new fund and selection process will distribute up to $12,500 USD across one or more open source project(s)." Solo votan empleados que han contribuido a open source. Existe desde 2020. Indeed (2019) y Bloomberg (2023, aportes de $10K) usan el mismo modelo. - Sentry, 6 ene 2026: $750K a maintainers por 2025, quinto año seguido. Open Source Pledge ($2,000 por developer al año): los miembros han pagado $7,408,535 desde el lanzamiento (opensourcepledge.com/members, 30 sep 2026). - Página de membresía CNCF: Silver de $2K a $50K al año según el tamaño de la empresa, Gold $100K, Platinum $350K; el contador dice "722 CNCF Members". [TIEMPO: 90s. Esta es la slide a la que le toman foto.]

❯ la nueva realidad

La ecuación construir-vs-comprar se invirtió

La IA abarata construir. Los márgenes del SaaS se erosionan.

~$1T de valor perdido por el mercado de software en siete días (feb 2026)

+10% empleos proyectados de developers de software en EE. UU., 2025–35 (BLS)

OSS es el motor

Construimos sobre open source, y ahora toca pagar nuestra parte subiendo fixes upstream.

Caso · rol anterior en Game Plan Tech

Agregamos GCS Workload Identity al Percona MongoDB Operator.

Upstream, no un fork privado.

Fuentes: "Build vs. Buy Is Dead" (YouTube) · Fortune / Bloomberg, 5 feb 2026 · BLS OOH · percona-server-mongodb-operator#2315

Texto que salió de la slide (díganlo en voz alta si hace falta): - La IA está bajando el costo de desarrollar e invierte la ecuación construir-vs-comprar. Los márgenes del SaaS tradicional se erosionan. - Agregamos soporte de GCS Workload Identity al Percona MongoDB Operator para un workload con requisitos federales de compliance. En vez de mantener un fork privado, contribuir upstream lo resolvió para nosotros y para la comunidad. [TIEMPO: 2 minutos. Es el puente entre el framework y la acción. El video sostiene que la IA hace que construir sea más barato que comprar, pero el corolario es que sus CLIENTES ahora pueden usar IA para construir sobre sus APIs, así que el modelo de negocio del vendor se rompe. La otra cara: no escribimos operators de MongoDB desde cero, usamos el de Percona. Cuando necesitamos una feature (Workload Identity para IL4/FedRAMP), la contribuimos upstream como el PR #2315. Esa contribución es cómo "pagamos" lo que usamos. Misma lógica que el framework, pero aterrizada en un ejemplo real de mi trabajo.] [Los dos números son la evidencia, ambos corregidos en la revisión 2: - ~$1T: Bloomberg vía Fortune, 5 feb 2026, sobre la venta masiva de software ("SaaSpocalypse"): "the value of those tracked in an iShares ETF has now dropped almost $1 trillion over the past seven days." La revisión 1 decía "$1T+ en un solo mes", y estaba mal. - +10%: BLS Occupational Outlook Handbook, software developers, página actualizada el 27 ago 2026: "projected to grow 10 percent from 2025 to 2035". La revisión 1 usaba la cifra anterior, 2024–34 (15%). El contraste es el punto: las empresas de software sangrando, y aun así se sigue contratando ingenieros.] [El ejemplo de Game Plan Tech es el caso concreto. IL4 es un nivel federal de cumplimiento donde no pueden exportar llaves JSON de service accounts. Workload Identity es el enfoque que recomienda Google para autenticación entre servicios en GKE. El operator no lo soportaba. En vez de hacer fork, lo contribuimos upstream. Todos los clientes de GKE recibieron la feature, no solo nosotros.]

Acto 05

La acción

Lo que hacen el lunes en la mañana.

El impuesto del fork

Fork privado: su propia copia del proyecto

5,160 h

de rework en cada release, solo para que sigan compilando.

86 forks × 60 h cada uno

Fuente: Linux Foundation, "ROI for Open Source Software Contribution", feb 2026 (preguntas sobre forks n=238)

[Simplificada 4 oct 2026: la columna de Android salió de la slide. Cuéntenla en voz alta si hay tiempo: - 18 meses desde un release upstream del kernel hasta los teléfonos. - 90% de los security bugs del kernel ya estaban corregidos upstream. - La solución de Android/ChromeOS: Upstream First, el patch llega upstream antes de salir. Fuentes: Documentación de Android GKI, https://source.android.com/docs/core/architecture/kernel/generic-kernel-image · ChromeOS, Upstream First, https://www.chromium.org/chromium-os/chromiumos-design-docs/upstream-first/ ] Texto que salió de la slide (díganlo en voz alta si hace falta): - 5,160 h de rework en cada ciclo de release, solo para que los forks sigan compilando (86 forks × 60 h cada uno · ≈ $258K a $50/h). - 18 meses desde un release upstream del kernel hasta los teléfonos. - 90% de los security bugs del kernel ya estaban corregidos upstream. - La solución: Upstream First. El patch llega upstream antes de salir. Nueva el 27 sep 2026. Es el argumento más realista para la sala: probablemente ya están pagando por open source, solo que de la forma más cara, cargando patches. Evidencia: - Reporte de ROI de la LF (feb 2026): "On average, an organization maintains 86 private forks … Each … requires 60 labor hours for maintenance and integration per release cycle." 86 × 60 = 5,160 horas. Los $258K son la estimación del propio reporte con un supuesto de $50/hora (salario mediano de Stack Overflow), NO gasto reportado. Las preguntas sobre forks tuvieron n=238 de las 567 respuestas. Escala con el tamaño: 147 horas en organizaciones chicas, 11,152 en las de más de 5,000 empleados. Razones para hacer fork: features a la medida 54%, integración interna 44%, "security patches or compliance requirements" 37%. Prólogo de Aniszczyk: "Organizations that rely on internal patches without upstreaming them create private forks leading to technical debt". - Documentación de Android GKI (source.android.com, actualizada jun 2026): hasta 50% del código del kernel fuera del árbol; "a delay of up to 18 months from the point where an LTS release was available upstream, to when it was in a device"; el 90% de los problemas de seguridad del kernel reportados en el Android Security Bulletin ya estaban corregidos en dispositivos que se mantienen actualizados. - ChromeOS "Upstream First": los patches de drivers deben aceptarse upstream primero. LWN, sep 2019, Doug Anderson: "We're trying not to do what Android did 10 years ago." Pregunten a la sala: ¿cuántos patches internos carga su equipo? [TIEMPO: 75s.]

❯ cómo se ve en la práctica

Dos horas a la semana

Bloomberg × OpenTelemetry · 2026

70 PRs

merged en 10 semanas, con 2 h/semana por ingeniero.

Bloomberg: empresa de datos financieros · OpenTelemetry: estándar de observabilidad de la CNCF

Fuentes: Blog de CNCF, 23 jul 2026 · Blog de CNCF, 31 mar 2026

[Simplificada 4 oct 2026: 94% y "hasta 2×" salieron de la slide. Díganlos si hay tiempo. Fuente del 2×: Nagle, "Learning by Contributing", Organization Science 2018, vía HBS Working Knowledge, https://www.library.hbs.edu/working-knowledge/the-hidden-benefit-of-giving-back-to-open-source-software ] Texto que salió de la slide (díganlo en voz alta si hace falta): - 70 PRs merged en 10 semanas por 48 ingenieros, con 2 horas a la semana cada uno. La mayoría contribuía por primera vez. - 94% de los participantes se sintió con más confianza para contribuir. - Hasta 2× de productividad en empresas que le pagan a su gente por contribuir (Nagle, 2018). Nueva el 27 sep 2026. La respuesta realista a "no tenemos tiempo": una empresa grande lo hizo con dos horas a la semana por ingeniero. Evidencia: - Alyssa Wright (OSPO de Bloomberg), blog de CNCF, 23 jul 2026: "48 Bloomberg engineers participated in the initiative. Most had never contributed to open source before." "118 pull requests (PRs) were submitted to the OpenTelemetry project. 70 were merged". "842 volunteer hours were logged by participants". 94% con más confianza, 88% planea seguir. Un equipo construyó una extensión de rotación de credenciales para el Collector para resolver un problema real de su trabajo (todavía en revisión de los maintainers). - Blog de CNCF, 31 mar 2026: "~2 hours/week per Bloomberg participant" y la cita sobre stewardship. - Bloomberg también tiene un FOSS Contributor Fund (desde ene 2023, aportes de $10K votados cada trimestre; Open Collective muestra ~$320K desembolsados). - Frank Nagle, "Learning by Contributing", Organization Science 29(4), 2018, vía HBS Working Knowledge (5 sep 2018): pagarle a la gente por contribuir aumenta la "productivity from using the software by as much as 100 percent, when compared with free-riding competitors." "Hasta 2×" en la slide = "as much as 100 percent". Nota: el sitio de Bloomberg bloqueó nuestras descargas; estos números vienen de los posts de Bloomberg en el blog de CNCF. [TIEMPO: 60s.]

❯ git log --author=me

Un fork menos

Pull request de GitHub percona/percona-server-mongodb-operator #2315, K8SPSMDB-1602: soporte de Workload Identity para el almacenamiento de backups en GCS, merged el 22 jun 2026 — github.com · percona/percona-server-mongodb-operator #2315 · merged el 22 jun 2026

1 · Problema

Bloqueado

Las normas de seguridad del gobierno de EE. UU. prohíben key files.

2 · Upstream

PR al operator

de Percona, empresa de bases de datos open source.

3 · Merge

67 días

del issue al merge. Cero patches que cargar.

Fuentes: percona/percona-server-mongodb-operator issue #2314, 16 abr 2026 · PR #2315, mergeado el 22 jun 2026 · captura recortada, 30 sep 2026

[Simplificada 4 oct 2026: la slide ahora cuenta la historia en 3 pasos. "Normas de seguridad del gobierno de EE. UU." = IL4 (Impact Level 4 del Departamento de Defensa) y FedRAMP (programa de seguridad cloud del gobierno federal). El PR dice: "IL4/FedRAMP environments where exporting service account JSON keys is not permitted."] Texto que salió de la slide (díganlo en voz alta si hace falta): - El gap: los backups pedían un key file que IL4/FedRAMP prohíbe. Nueva el 30 sep 2026; recortada el mismo día alrededor de la captura del PR. El impuesto del fork a escala de un solo ingeniero. El reporte de la LF dice que el 37% de los forks existe por "security patches or compliance requirements" (notas de fork-tax); este es uno que nunca llegó a ser fork. Digan la frase de la slide anterior: "Su requisito de cumplimiento probablemente también es el de alguien más." Evidencia: - Issue #2314 abierto el 16 abr 2026 02:22 UTC; PR #2315 abierto a las 02:52 UTC; merged el 22 jun 2026 13:06 UTC. Del 16 abr al 22 jun = 67 días. - Cuerpo del PR: "This is blocking for IL4/FedRAMP environments where exporting service account JSON keys is not permitted." El operator siempre leía credentialsSecret; PBM fallaba con "clientEmail and privateKey are required for GCS credentials". Fix: un flag opcional credentials.workloadIdentity, y PBM cae a Application Default Credentials. Incluye una prueba e2e (demand-backup-gcs-workload-identity). - El PR se escribió con ayuda de IA (el cuerpo del PR lo dice). Si preguntan: una persona lo revisó, salió con pruebas y los maintainers lo hicieron merge de. Esa es la versión buena de la historia sobre la que advierte la slide de la avalancha de IA. Digan: "Pude haber cargado este patch. En cambio, abrí el issue esa misma noche." Y cierren. [TIEMPO: 60s.]

Lo que hacen el lunes

Líderes y equipos SRE

Cuenten sus forks y patches, con horas.
Reserven 2 h/semana para upstream.
Elijan una fundación o fondo.

Contribuidores individuales

¿Cargan un patch? Abran el issue upstream.
Un patch merged es un fork menos.
Hagan review del PR de alguien más.

Fuentes: Linux Foundation, "ROI for Open Source Software Contribution", feb 2026 · OSPO de Bloomberg, blog de CNCF, 31 mar 2026

Texto que salió de la slide (díganlo en voz alta si hace falta): - Cuenten sus forks y patches cargados. Pongan las horas al lado de cada uno. - Reserven 2 horas a la semana para upstream, como hizo Bloomberg. - Elijan una fundación o fondo para lo que corren en producción. - ¿Cargan un patch? Abran el issue upstream esta semana. - Conviertan el fix en un PR. Un patch merged es un fork menos. - Revisen el PR de alguien más. Los reviewers son el recurso más escaso. Reescrita el 27 sep 2026: la pregunta del lottery factor y las slides de gh/glab y ORT se reemplazaron por acciones respaldadas por la evidencia del fork tax y de Bloomberg. Cada viñeta apunta a una slide: - Cuenten sus forks: el impuesto del fork (86 forks × 60 horas por ciclo de release en promedio). - 2 horas a la semana: la cohorte de Bloomberg en OpenTelemetry. - Una fundación o fondo: la escalera (CNCF desde $2K al año; la LF dice que la membresía rinde 4.8x). - Los reviewers escasean: Godot Foundation, 30 jun 2026, "This reviewer shortage was already a problem, but it was one that we successfully ignored. We can no longer ignore it." [TIEMPO: 90s. Cierren con "un patch merged es un fork menos."]

Nadia Eghbal hablando en Strange Loop 2017 frente a su slide: 2017, dos tercios de los proyectos populares tienen solo 1-2 maintainers — Nadia Eghbal at Strange Loop 2017 · Photo: Chris Koerner, CC BY-SA 2.0, Wikimedia Commons · cropped

"Para mantener nuestro ritmo de progreso, necesitamos reinvertir en las herramientas que nos ayudan a construir cosas más grandes y mejores."

"In order to maintain our pace of progress, we need to invest back into the tools that help us build bigger and better things." (traducción propia)

Nadia Eghbal · Roads and Bridges, Ford Foundation, 2016

Gracias · Christopher Tineo

La frase de cierre se dice una vez y luego silencio. No la diluyan con agradecimientos. El gracias es la línea siguiente; la pregunta a la sala es lo último que recuerdan. Cita (1 oct 2026, reemplazó "It's only fine if we pay for it"): Nadia Eghbal, "Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure", Ford Foundation, julio 2016, conclusión. Verificada palabra por palabra contra el PDF de la Ford Foundation. La traducción al español es propia; el original en inglés va debajo. "Invertir" es tiempo, patches o dinero, que es el punto de la slide del framework. Si la sala está con ustedes, tomen 2-3 preguntas. Si está callada, no lo fuercen. Lean la cita, hagan una pausa y dejen que el silencio haga el trabajo. [TIEMPO: 45s. Que aterrice. Paren. Preguntas.]

Encuéntrenme · llévense las slides

Sigamos en contacto

Código QR a linkedin.com/in/christopher-tineo

LinkedIn linkedin.com/in/
christopher‑tineo

Código QR a tineoc.github.io/talks/nerdearla-mx-2026

Slides tineoc.github.io/talks/
nerdearla-mx-2026

Código QR a k8s.dev/docs/orientation, la Kubernetes New Contributor Orientation

Contribuye k8s.dev/
docs/orientation

Código QR a la lista de capítulos de la comunidad CNCF en México

CNCF MX CDMX · GDL
QRO · Colima

Enlaces: linkedin.com/in/christopher-tineo · tineoc.github.io/talks/nerdearla-mx-2026 · Kubernetes New Contributor Orientation · Grupos de la comunidad CNCF en México · github.com/TineoC/talks

Cuatro códigos QR: LinkedIn, las slides de esta revisión en GitHub Pages (https://tineoc.github.io/talks/nerdearla-mx-2026/), la Kubernetes New Contributor Orientation y los capítulos de CNCF en México. QR: Kubernetes New Contributor Orientation (NCO), mentoría de SIG ContribEx, empezó en sep 2024 (kubernetes.dev/docs/orientation, verificado el 1 oct 2026). El QR codifica https://k8s.dev/docs/orientation/, que redirige ahí. Digan: "Si quieren un primer escalón, es este." QR: capítulos de CNCF en México (búsqueda en Open Community Groups, ocgroups.dev, que es donde ahora vive community.cncf.io). Hoy aparecen Cloud Native Mexico City, Cloud Native Guadalajara, Cloud Native Querétaro y Cloud Native Colima, más Cloud Native LATAM con sede en CDMX. Digan: "No tienen que empezar solos. Hay un capítulo cerca; únanse, vayan a un meetup y ahí encuentran a la gente que mantiene lo que ustedes usan." [TIEMPO: 30s. Pasen a preguntas o cierren.]