Lo que empezó como un experimento personal se transformó rápido en un proyecto de código abierto global con un impulso extraordinario. OpenClaw es un asistente personal de IA que corre en los dispositivos de los usuarios y se conecta con los canales de mensajería que ya usan. Iniciado por Peter Steinberger como un proyecto de fin de semana en noviembre de 2025, su repositorio en GitHub creció hasta aproximadamente 388.000 estrellas, 81.000 bifurcaciones y más de 80.000 commits al 26 de agosto de 2026.
En una entrevista en video, filmada apenas seis meses después del inicio del proyecto, Steinberger y varios mantenedores de OpenClaw conversan sobre cómo gestionar una avalancha de propuestas de código, repensar la confianza en los colaboradores y la revisión de código, abordar los riesgos de la cadena de suministro de software, y equilibrar capacidades potentes de agentes con la seguridad. También comparten lecciones de seguridad del GitHub Secure Open Source Fund y el valor de conectarse con mantenedores que enfrentan desafíos similares.
| Métrica del repositorio | Valor al 26 de agosto de 2026 |
|---|---|
| Estrellas | aproximadamente 388.000 |
| Bifurcaciones | 81.000 |
| Commits | más de 80.000 |
| Tiempo desde el inicio | 9 meses |
¿Quiénes hablan en la entrevista?
Los siguientes mantenedores compartieron su experiencia manteniendo y asegurando OpenClaw: Peter Steinberger, creador de OpenClaw; Brad Groux, director ejecutivo de Digital Meld; Josh Avant, del equipo técnico de la OpenClaw Foundation; Josh Lehman, de Martian Engineering; Sally O'Malley, ingeniera de software principal en Red Hat; Val Alexandar, de OpenCoven; y Vincent Koc, arquitecto jefe de la OpenClaw Foundation.
Cómo la IA cambió las contribuciones y la comunidad
1. Las propuestas de código se volvieron pedidos a un modelo
Los mantenedores de OpenClaw se encontraron administrando miles de propuestas de código e incidencias, con algunos colaboradores abriendo cientos de propuestas de una sola vez.
"Ni siquiera las llamo pull requests. Las llamo prompt requests", dice Peter Steinberger.
"Había colaboradores con varios cientos de propuestas de código corriendo estas especies de fábricas de software automatizadas, que simplemente minaban todo en busca de incidencias", agrega Josh Lehman.
El desafío se desplazó desde atraer participación hacia encontrar contribuciones valiosas en medio de un torrente de actividad capaz de desbordar la revisión humana.
2. Mantener la puerta abierta a nuevos colaboradores
Los mantenedores querían que el proyecto siguiera siendo acogedor para nuevos participantes, ya fueran personas que contribuían por primera vez al código abierto, gente sin perfil técnico resolviendo un problema puntual, o quienes usaban agentes de IA como ayuda. En lugar de descartar contribuciones imperfectas, buscaron ideas prometedoras y trabajaron con los colaboradores para refinarlas, reescribirlas o completar ellos mismos los cambios finales.
"Sé cómo se sintió, hace muchos años, que mi primera propuesta de código fuera aceptada en un proyecto", recuerda Steinberger.
Algunas de las primeras contribuciones que se integraron vinieron de personas sin formación en desarrollo, que usaron un agente para crear la propuesta y luego trabajaron con los mantenedores para terminar el cambio.
"Una buena proporción de esas primeras propuestas que se integraron vienen de gente que no es desarrolladora. Son simplemente personas con un problema y una necesidad específica", señala Vincent Koc.
3. Los agentes ahorran tiempo, pero cuesta más parar
Los mantenedores describieron dos resultados muy distintos de la misma tecnología: los agentes pueden ayudar a recuperar tiempo, pero también pueden hacer más difícil dejar de trabajar.
"He visto el otro lado, donde la gente está tan enamorada de esto que se da cuenta de que, guau, si no duermo esta noche, puedo hacer lo que antes me tomaba una semana", dice Val Alexandar.
"Tengo tres hijos. Son muy chicos. OpenClaw me deja administrar agentes que trabajan por mí para que yo pueda volver a jugar con ellos", cuenta Josh Lehman.
"A veces los mantenedores entran al canal y dicen: voy a tocar pasto ahora. Me tomo unas horas libres", agrega Sally O'Malley.
Los agentes no son buenos ni malos para el equilibrio entre trabajo y vida personal, pero amplifican tanto la oportunidad de hacer más como la importancia de saber cuándo alejarse.
Cómo se adaptaron los mantenedores
4. La confianza se gana encontrando dónde aportar valor
No hubo un camino único para convertirse en mantenedor de OpenClaw. Algunos colaboradores llegaron por el trabajo de seguridad, otros por integraciones o por participación comunitaria, pero el hilo común fue encontrar una forma de aportar valor y hacerse cargo.
"Peter me ignoraba, así que pensé: ¿de qué otra forma consigo su atención? Seguridad", cuenta Vincent Koc.
"Yo soy un tipo de Microsoft, así que pensé: ¿habrá un complemento para Microsoft Teams?", dice Brad Groux.
5. La nueva señal de confianza es mostrar el trabajo
A medida que el número de contribuciones se volvió menos informativo, el equipo identificó qué evidencia puede hacer destacar una propuesta de código: las transcripciones del agente, capturas de pantalla, pruebas y una explicación del razonamiento del colaborador.
"Si nos entregas las transcripciones, efectivamente vemos cómo llegaste a la propuesta y tu discusión con el agente. Increíblemente valioso. Si agregas capturas de pantalla, puedes demostrar que probaste esto", explica Steinberger.
La pregunta importante no era simplemente si el código lo escribió una persona o un agente, sino si el colaborador entendía la funcionalidad y había considerado cómo interactuaba con el resto del proyecto.
"A nadie le importa si escribiste el código o no, pero sí nos importa si realmente pensaste sobre esta funcionalidad", resume Steinberger.
6. Los mantenedores revisan código de agentes con agentes
Los mantenedores recurrieron cada vez más a herramientas de IA para revisar contribuciones generadas por IA, además de adoptar un enfoque más práctico para mejorar el código enviado.
"Cada vez que recibo una propuesta de código de una IA, algo que me encanta hacer ahora es usar GitHub Copilot para todas las revisiones", dice Val Alexandar.
"Este es el primer proyecto donde vi que se normalizó que, cuando alguien envía una propuesta, tú como mantenedor simplemente la editas. La dejas bien y listo", apunta Josh Lehman.
Los desafíos de seguridad
7. La reputación se convirtió en superficie de ataque
El historial de contribuciones en sí mismo podía manipularse. Los mantenedores vieron cómo se duplicaban propuestas de código existentes.
"La gente básicamente duplicaba las propuestas de otras personas. Lo que intentaban hacer era construir credibilidad, porque teníamos estas insignias de cuántas propuestas habías integrado. Mientras más integraciones tuvieras, era como una señal de confianza para nosotros", explica Vincent Koc.
Steinberger describió el caso de una empresa que usó una propuesta automatizada para promocionar su producto. El equipo tuvo que identificar el trabajo duplicado y determinar cuál era la propuesta original. El código no era lo único que el proyecto necesitaba evaluar: los mantenedores también debieron reconsiderar las señales sociales que usaban para decidir en qué, y en quién, confiar.
8. Lo seguro por defecto depende de a quién se le pregunte
Lo que a un usuario le parece seguro puede resultarle innecesariamente restrictivo a otro. La disyuntiva quedó clara en la práctica: restricciones más estrictas en el espacio de trabajo generaban reclamos de los usuarios, mientras que menos restricciones podían exponer al proyecto a incidentes de seguridad.
"Muchas veces es un juego difícil encontrar el equilibrio correcto entre hacerlo realmente conveniente para los usuarios y construir algo que sea lo suficientemente seguro por defecto", dice Steinberger.
Los valores predeterminados seguros deben considerar las capacidades del agente, lo que los usuarios entienden y lo que un entorno particular está preparado para permitir.
9. Saber quién mantiene tus dependencias
Los ataques recientes a la cadena de suministro empujaron a los mantenedores a pensar con más cuidado tanto en las dependencias de las que dependían como en su relación con los proyectos detrás de ellas.
"Revisamos nuestras dependencias con lupa. Lo que eso nos ha empujado a hacer es reducir las dependencias centrales, pero también crear una relación con los mantenedores de los que dependemos", cuenta Vincent Koc.
"No es lo habitual que las empresas efectivamente intenten contribuir de vuelta, en lugar de solo mantener una bifurcación y no preocuparse de nada más", agrega Steinberger.
10. Qué aportó el fondo de seguridad de GitHub
Los participantes describieron el GitHub Secure Open Source Fund como una experiencia de aprendizaje en seguridad y también como una forma de conectarse con mantenedores que enfrentaban problemas similares, a menudo abrumadores.
"El presentador dijo: primero, anda a buscar una taza de café. Paso uno, respira. Eso nos conectó con el elemento humano de ser mantenedor", recuerda Josh Avant.
El programa entregó mayor conciencia sobre prácticas de seguridad y ayudó a los mantenedores participantes a entender cómo instruir a los agentes. "Ahora tenemos agentes, y pueden hacer prácticamente cualquier cosa que les pidas, pero igual tienes que saber qué pedirles. Ahora tengo la capacidad de saber qué pedir", dice Josh Lehman.
OpenClaw participó en la Sesión 4 del GitHub Secure Open Source Fund, junto a otros 50 proyectos de código abierto.
Lo que esto significa para proyectos más chicos
La cifra que ordena todo el relato es la relación entre 388.000 estrellas y nueve meses de vida. Es un crecimiento que ningún equipo de mantenedores humano puede absorber con los procesos habituales de revisión, y por eso el proyecto sirve como laboratorio adelantado de un problema que va a llegar a repositorios mucho más modestos.
La lección más portable para un proyecto regional no es ninguna de las herramientas mencionadas, sino el cambio de criterio: pasar de contar contribuciones integradas a exigir evidencia del proceso. Un contador de integraciones es trivial de inflar cuando cualquiera puede generar cien propuestas en una tarde, mientras que una transcripción del agente y una captura de la prueba ejecutada son costosas de falsificar y baratas de revisar. Ese cambio no requiere presupuesto ni infraestructura: se implementa editando la plantilla de propuestas del repositorio.
