DevRel vs marketing para desarrolladores: el tercer trabajo que falta en México

Primero, las definiciones. Developer relations (DevRel) es la función que construye credibilidad y relaciones de doble vía con quienes usan tu tecnología. El developer marketing es el lado de la demanda: segmentación, campañas y programas de ciclo de vida que llevan a los desarrolladores a probar un producto. Un programa local de adopción de desarrolladores es el tercer trabajo: talleres, hackathons, activaciones en campus y horas de oficina operados en ciudades específicas, que terminan en un reporte escrito de lo que quienes construyen hicieron con tu producto.

El veredicto de entrada: si estás armando un equipo o un brief para trabajo con desarrolladores en un mercado donde tu empresa no tiene presencia local, el debate de dos columnas responde la pregunta equivocada. La confianza y la demanda importan, pero en una geografía nueva la restricción real no es ninguna de las dos. Es si alguna persona que construye ahí ha tenido alguna vez tu producto en las manos con alguien cerca para ayudar cuando se rompe. Eso exige un programa en sitio, no un organigrama.

Puntos clave

• DevRel y developer marketing resuelven problemas distintos, y la mayoría de las comparaciones los explica bien.
• En un mercado nuevo, las dos funciones chocan con el mismo muro: no hay un operador local que ponga el producto en manos de quienes construyen.
• El tercer trabajo es un programa local de adopción: talleres, créditos, activaciones en campus, hackathons y un reporte escrito.
• El orden importa: primero confianza donde nadie te conoce, luego programas. Los programas sin confianza desperdician lugares.

La comparación estándar, en breve

La imagen estándar es correcta en lo general. DevRel es trabajo basado en relaciones. El developer marketing es la disciplina del marketing aplicada a un público técnico. SlashData lo resume de forma simple: trabajo de ciclo de vida frente a trabajo de comunidad (SlashData).

	Developer Relations	Developer Marketing
Trabajo central	Credibilidad, relaciones, ciclos de retroalimentación	Demanda, segmentación, ciclo de vida
Resultados típicos	Charlas, defensa de la documentación, comunidad, embajadores	Campañas, webinars, secuencias de nutrición, lanzamientos
Se mide por	Salud de la comunidad, percepción, retroalimentación incorporada al producto	Registros, pruebas iniciadas, cuentas activadas
Falla cuando	No hay momentos de producto que los desarrolladores puedan tocar	El público es escéptico o desconocido

La tabla sirve hasta donde llega. El problema aparece en cuanto el plan cruza una frontera.

Dónde se rompe el modelo de dos columnas

Las dos funciones suponen una superficie de operación. DevRel supone una comunidad donde tu equipo puede presentarse. El developer marketing supone un embudo que tu equipo puede instrumentar. En un mercado donde tu empresa no tiene oficina, ni personal, ni historia, ninguno de los dos supuestos se cumple.

Mira la mecánica de cada formato. Un taller necesita una sala, convocatoria local, mentores y alguien que arregle problemas de entorno en el momento. Una activación en campus necesita relaciones con profesores. Un hackathon necesita diseño del reto, jurado y seguimiento. ¿Puede cubrir esto un responsable regional desde su agenda de vuelos? No. ¿Puede sustituirlo una campaña? Tampoco.

La escala de la superficie explica por qué esto sigue fallando a distancia. Octoverse de GitHub reportó que más de 36 millones de desarrolladores nuevos se unieron a la plataforma en un solo año, el mayor crecimiento absoluto registrado, lo que llevó el total a más de 180 millones (GitHub Octoverse 2025). América Latina está dentro de ese crecimiento. ¿Qué tan rápido? Octoverse 2024 documentó en la región algunas de las comunidades de desarrolladores de mayor crecimiento del mundo (GitHub Octoverse 2024). Ese crecimiento forma escenas locales, no un solo público global. ¿Quién se sienta en esas salas? No los equipos remotos.

Los desarrolladores también aprenden de formas que resisten la lógica de una campaña remota. ¿Cómo aprenden? Sobre todo haciendo, con materiales reales. La encuesta de Stack Overflow de 2025 encontró que la documentación está entre los recursos más usados y que la mayoría de los desarrolladores aprendió una técnica nueva en el último año (Stack Overflow Developer Survey 2025). Los formatos que producen práctica suelen ser físicos y locales. Por ejemplo, piensa en un taller de dos horas donde treinta ingenieros terminan una instalación que funciona. Eso es un programa local, no una campaña. El mismo patrón aparece en la investigación sobre hackathons: la mayoría de los proyectos se apaga después del demo day salvo que el seguimiento esté diseñado desde el inicio (Nolte et al., ACM GROUP 2020). Nuestro equipo lo midió contra el estado de los proyectos entregados, no contra los registros.

La tercera columna: programas locales

El trabajo que falta tiene nombre en la práctica aunque los organigramas no lo incluyan: adopción de desarrolladores operada como programa de campo. Su unidad de trabajo no es un post ni una charla, sino algo construido por una persona real, producido en un evento que tu equipo operó.

	DevRel	Developer Marketing	Programa local de adopción
Unidad de trabajo	Relación	Campaña	Proyecto construido
Dónde se opera	En línea, conferencias	Embudos, correo, anuncios	Ciudades, campus y sedes específicos
Quién lo entrega	Advocates, líderes de comunidad	Equipos de marketing, agencias	Operadores en sitio
Prueba de que funcionó	Salud de la comunidad	Conteos de registros y activación	Proyectos evaluados y un reporte escrito
Cómo falla	Confianza sin uso del producto	Clics sin builders	Un gran evento del que nadie se enteró

Las tres funciones se complementan, no compiten. Los programas locales generan las historias y la prueba que hacen creíble a DevRel; el marketing convierte el interés resultante en registros; DevRel mantiene vivas las relaciones entre un programa y otro. El error es financiar las dos primeras y suponer que la tercera llega gratis.

Qué contiene la tercera columna, en concreto

Un programa local de adopción es un portafolio de formatos, cada uno ajustado a una etapa de familiaridad de quien construye:

• Talleres. De dos a tres horas, laptops abiertas, una tarea terminada. Treinta ingenieros que terminaron una integración que funciona valen más que trescientos asistentes a un webinar.
• Créditos y kits de inicio. Uso gratuito ligado a una identidad y a un primer proyecto concreto, para que el crédito produzca algo construido y no una cuenta ociosa.
• Horas de oficina. Recurrentes, en horario local, atendidas por personas que saben leer el mensaje de error.
• Activaciones en campus. Alianzas con profesores más sesiones para estudiantes. Ahí están hoy los futuros desarrolladores profesionales.
• Hackathons y retos. Programas de varios días con rúbricas publicadas. Producen integraciones evaluadas, con calidad de portafolio.
• Showcases de proyectos. Demostración pública de lo que se construyó, que alimenta tanto las historias de DevRel como la prueba que necesita marketing.

Cada formato termina igual: un reporte de participantes únicos, proyectos producidos y lo que pasó después. Ese reporte es el artefacto que las otras dos columnas no pueden generar desde la oficina central.

En qué orden invertir

El orden depende de las condiciones de partida, y la regla honesta es corta:

Si quienes construyen en el mercado no te conocen: financia primero la construcción de confianza y un programa insignia bien operado. Un solo hackathon creíble o una serie de talleres crea la prueba local de la que dependerá cada conversación posterior. Un gasto fuerte en anuncios antes de ese punto compra impresiones de gente que no tiene intención de construir.

Si te conocen pero no han construido nada: financia programas de inmediato. Es la situación más común para herramientas establecidas que entran a América Latina, y es donde los talleres locales, los créditos y los retos se pagan más rápido.

Si tienes registros locales pero no hay actividad: el problema es operativo, no de promoción. Las horas de oficina y el apoyo con kits de inicio convierten cuentas registradas en primeros proyectos; más presupuesto de campaña hace la brecha más grande, no más chica.

¿Hacia dónde va el crecimiento? SlashData contó unos 47 millones de desarrolladores en el mundo a inicios de 2025. El crecimiento ahora se concentra en el sur de Asia, el sudeste asiático, África y América Latina (SlashData). Si ordenas bien la inversión, llegas primero.

Cómo saber si necesitas el tercer trabajo

Tres diagnósticos rápidos:

• Revisa el gasto del último trimestre. Si se repartió entre contenido y comunidad sin nada asignado a eventos o talleres en el mercado, tienes dos columnas y nada debajo.
• Pregunta quién operó tu última sesión práctica en el mercado objetivo. Si la respuesta es nadie, o una agencia aliada sin profundidad técnica, la adopción ahí depende de la esperanza.
• Cuenta artefactos construidos. Proyectos, integraciones, demos. Si el conteo está cerca de cero pese a buenos números de tráfico, la función que falta son los programas, no la promoción.

Una regla de decisión corta

¿Qué financiar primero? Confianza si nadie te conoce. Programas si te conocen pero no han construido. Horas de oficina si se registraron y luego se quedaron callados.

¿Qué dejar de financiar? Campañas dirigidas a un mercado sin un programa local debajo. Charlas que nunca terminan en una instalación que funciona. Horas de oficina remotas a las que nadie asiste.

¿Por qué este orden? Porque quienes construyen aprenden haciendo. La documentación ayuda después de que lo intentaron. Los anuncios ayudan después de que tienen una razón para intentarlo. El tercer trabajo crea esa razón.

Trabaja con nosotros

Mobil3 opera programas de adopción de desarrolladores en México y América Latina: talleres, créditos, activaciones en campus y hackathons, cada uno cerrado con un reporte escrito de lo que construyeron los participantes. Si la tercera columna es el hueco de tu plan regional, mira cómo la adopción de desarrolladores funciona como programa. Formatos cercanos: cómo organizar un hackathon para desarrolladores y cómo trabajar con universidades en México. Déjanos tus datos en la página de contacto o escribe a ian@mobil3.xyz.

Sobre esta guía

Esta guía fue escrita por Ian Lee, fundador de Mobil3, a partir de la operación directa de programas en México. Para preguntas sobre este artículo o sobre nuestro proceso editorial, escríbenos a hello@mobil3.xyz o lee más sobre nosotros.