En la era de la IA, ¡contribuir al código abierto es más fácil que nunca!

Pero, al mismo tiempo y aunque parezca contradictorio, es más difícil que nunca.

¿Por qué? Porque ahora es más fácil enviar contribuciones, pero más difícil ganarse la confianza de los maintainers.

Antes competías con otros voluntarios increíblemente inteligentes, con desarrolladores que aportaban su experiencia y tiempo libre al código abierto, o con personas que estaban empezando. Ahora compites con todos ellos y con un ejército de agentes de IA que generan pull requests, issues, refactorizaciones y reportes de vulnerabilidades más rápido que cualquier persona.

Es tentador. Un LLM puede reducir mucho el trabajo mental necesario para entender un repositorio e incluso para proponer un cambio valioso. Cosas que antes eran «muy difíciles» ahora están a unos cuantos prompts de distancia. Eso redujo la barrera de entrada para contribuir, ¡y es genial! Pero también aumentó enormemente el volumen de contribuciones y está inundando los repositorios.

¿Cuál es el problema?

La capacidad de los maintainers no aumentó. El costo de revisión no disminuyó.

Estas dos realidades ya han llevado a maintainers a tomar medidas drásticas, como ocurrió con curl:

daniel.haxx.seDeath by a thousand slops

Entonces, ¿cómo te conviertes en un contribuidor valioso de código abierto en la era de la generación infinita de código? Aquí van algunos consejos que he aprendido al lidiar con un gran volumen de contribuciones.

Piensa antes de subir tu PR

La IA puede producir código excelente, pero también puede producir el peor código que la humanidad haya visto. Depende mucho de:

• El prompt que uses.
• La calidad del LLM.
• El contexto que compartas.

Y lo más importante:

• Tu propia capacidad para programar.

¿Por qué necesitas saber programar antes de usar LLMs para contribuir al código abierto?

Porque un LLM no puede saberlo todo.

Por ejemplo, recibimos un PR que intentaba cambiar esto:

Antes:

		} catch (error) {
			console.error('Some error:', error);
		}

Después:

		} catch (error) {
			logger.error('Some error:', error);
		}

Podrías decir: «¡Ese cambio es válido, usar logger en lugar de console es mejor!». ¿Cuál es el problema?

El LLM no sabía —y no lo comprobó, porque nadie se lo pidió— que recientemente habíamos cambiado los tipos de nuestras instancias de logger, por lo que el cambio no era válido.

Un cambio válido se habría visto así:

		} catch (err) {
			logger.error({ msg: 'Some error', err });
		}

Pero el LLM no lo sabía y habría necesitado bastante contexto para saberlo. Buenos LLMs o harnesses (Claude, Codex, etc.) lo habrían detectado, pero otros no, a menos que se lo pidieras. Pero ¿cómo vas a pedir algo que no sabías que existía? Ahí es donde entra tu capacidad para programar.

Este es el punto: no puedes pedir en un prompt lo que no sabes que existe.

Quien quiere contribuir no confía ciegamente en lo que produce el LLM. Sabe usar las herramientas —en este caso, el chequeo de tipos— para detectar esos problemas y lee el código para entender las convenciones actuales y sus particularidades.

Para estos programadores, los LLMs son una herramienta poderosa: les ayudan con la tarea mecánica de programar y les dejan tiempo para pensar.

Esto también protege tu reputación. Si los maintainers ven que constantemente envías PRs que aportan poco, con el tiempo dejarán de revisarlos. O algo peor.

Los LLMs hacen que contribuir sea más rápido, pero no reemplazan tu capacidad de pensar, a menos que tú se lo permitas.

Las revisiones no son gratis

Estás feliz. Y nosotros también estamos felices de que quieras contribuir al código abierto. Es una actividad noble que puede hacer más seguro al repositorio y ayudarte a mejorar. ¡Todos ganan!

Pero los maintainers tienen:

• Capacidad limitada.
• Tiempo limitado.
• Paciencia limitada.

Entendemos que estés feliz de haber creado tu PR. Todos hemos sentido esa emoción. Por supuesto que quieres que se integre para poder decir con orgullo: «¡Contribuí a X!».

Pero sé razonable:

• El costo de abrir un PR ahora es casi cero.
• El costo de revisarlo no lo es.

Esa asimetría es la verdadera tensión de la era de la IA.

Si:

• comentas «por favor revisen» repetidamente,
• insistes de forma agresiva a los maintainers,
• exiges fechas para integrar tu PR,

aumentas el costo mental de tu contribución. Incluso si tu PR es válido.

Y esta es la dura realidad:

Los maintainers son humanos.

Si interactuar contigo les resulta costoso, podrían darle menos prioridad a tu trabajo sin darse cuenta. Eso significa menos revisiones, menos PRs integrados y menos menciones en las notas de lanzamiento.

Esto es especialmente importante cuando usas LLMs o agentes, porque son rápidos, mucho más rápidos que los humanos. Podrías terminar haciendo 100 PRs que crees válidos, ¡y quizás lo sean! Pero si los maintainers no tienen capacidad para revisarlos todos, pues no va a pasar.

Esa es la definición de un DoS (denegación de servicio): envías más solicitudes de las que el servidor —los maintainers— puede procesar.

Todos debemos hacer nuestra parte

La capacidad de los maintainers es limitada. En el último mes cerramos alrededor de 700 issues que estaban abandonados, no eran válidos o ya estaban resueltos, pero al mismo tiempo recibimos 300 nuevos. Algunos eran válidos y otros no. El problema es que no lo sabemos de antemano: tenemos que revisarlos todos. No puedes confiar en que un LLM confirme si algo es slop, ¡porque la comprobación también podría ser slop!

Un ejemplo relacionado es este reporte de curl en HackerOne:

HackerOnecurl disclosed on HackerOne: Cookie Max-Age Integer Overflow...## Summary: The cookie parsing code in `lib/cookie.c` contains an integer overflow vulnerability when processing the `Max-Age` attribute of HTTP cookies. The vulnerable code attempts to add the max-age value to the current timestamp without adequate overflow protection While the code includes an overflow check (`CURL_OFF_T_MAX - now < co->expires`), this check itself can experience integer...

El enlace anterior y esta hermosa lista tienen algo en común:

GistAI slop security reports submitted to curlAI slop security reports submitted to curl. GitHub Gist: instantly share code, notes, and snippets.

Parecen legítimos hasta que dejan de parecerlo. Pero para darte cuenta de que algo es slop tienes que revisarlo manualmente, y eso consume tiempo y esfuerzo. A los maintainers no les gusta que desperdicien su tiempo: tienen otras cosas que hacer.

Así que sé humano, respeta el tiempo y el trabajo de los maintainers. ¿Cómo? Reduciendo el costo de revisar tu código.

Antes de enviar tu contribución:

• ¿Reprodujiste el problema tú mismo?
• ¿Ejecutaste el CI localmente?
• ¿Incluiste capturas de pantalla para los cambios de interfaz?
• ¿Incluiste benchmarks para respaldar las afirmaciones sobre rendimiento?
• ¿Incluiste una prueba de concepto para los reportes de seguridad?
• ¿Comprobaste si ya existe una solicitud para esa funcionalidad?

Si afirmas que mejoraste el rendimiento, muestra los números. Si corriges un bug, explica la causa raíz. Si propones una funcionalidad, pregunta primero.

Las contribuciones de calidad se revisan más rápido. Las contribuciones que aportan poco se acumulan.

En la era de la IA, la reputación se acumula exponencialmente. Si los maintainers pueden confiar en ti, revisarán tus PRs más rápido y tú estarás más feliz. ¡Todos ganan!

Usa tu criterio al agrupar los cambios

Los typos pasan. Somos humanos, ¿no? Por ejemplo:

Antes:

		if (!sub) {
			throw new Error('subsciption not found');
		}

Después:

		if (!sub) {
			throw new Error('subscription not found');
		}

¿Ves el error? Sí, falta una r en subscription. La contribución es válida: tenemos que escribir inglés correctamente.

¿Merece un PR? Por sí sola, no. Quizás si la combinas con algunas más. Imagina que encuentras 10 errores como ese. ¿Qué es más fácil para los maintainers: un PR con 10 cambios o 10 PRs con un cambio cada uno? Jeje.

Si tú fueras el maintainer, ¿qué preferirías?

Cada PR tiene un costo adicional: ejecución de CI, notificaciones, tiempo de revisión, tiempo para integrarlo, cambio de contexto mental, etc. Reduce ese costo agrupando el trabajo trivial.

La IA puede encontrar una enorme lista de arreglos como este en un repositorio. Y si usas un agente como Claude o Codex, puedes decirle «crea un PR por cada problema» y convertirte en el contribuyente más odiado del proyecto :(

No hagas eso. Por favor. Sé considerado. Sé humano.

No dejes que la IA reemplace tu capacidad de pensar

Estamos en la era de la IA. Por mucho que pataleemos, llegó para quedarse. Lo que sí podemos cambiar es cómo la usamos.

En GSoC, por ejemplo, valoramos las contribuciones humanas. Ese es el objetivo del programa: ¡que más personas participen en el código abierto!

Necesitamos nuevas generaciones de maintainers, de personas inteligentes que usen los LLMs con criterio. Puedes hacer cosas increíbles con ellos si los usas bien, pero recuerda: los humanos también podemos hacer cosas increíbles. No lo olvides.

Es más fácil contribuir, pero más difícil destacar entre la multitud. La reputación importa. La confianza se gana. La construyes haciendo buen trabajo.

Como nota final, esto se basa principalmente en mi experiencia personal. Algunos proyectos pueden tener reglas distintas. Quizás a algunos les guste recibir 1,000 PRs al día. ¿Quién sabe?

Pero la idea principal es esta: la IA no es humana, pero los maintainers y los que contribuyen sí. Tenlo en mente.

¡Bienvenido al código abierto!

Si quieres leer más:

Jeff GeerlingAI is destroying Open Source, and itOver the weekend Ars Technica retracted an article because the AI a writer used hallucinated quotes from an open source library maintainer. The irony here is the maintainer in question, Scott Shambaugh, was harassed by someone

In the era of AI it’s easier than ever to be an Open Source contributor!

But, at the same time, and quite paradoxically, it’s harder than ever.

Why? Because it’s now mechanically easier, but reputationally harder

Previously, you competed against other incredibly smart volunteers, or maybe against employed developers that contributed their expertise and free time to open source, or against newcomers. Now, you compete against all of that and an army of AI agents generating pull requests, issues, refactors and vulnerability reports faster than what any human can do.

It’s pretty tempting. Using an LLM can reduce significantly the cognitive work you have to do to understand a codebase, and even to produce a valuable change request. Things that were previously “very hard” to do are now a few prompts away, and that lowered the entry barrier for contributions, which is great! But also created a massive increase in volume, which is flooding repositories.

What’s the problem? Maintainer capacity did not increase Review cost did not decrease

These two truths have already led maintainer to resort to drastic measures, like what happened with curl:

daniel.haxx.seDeath by a thousand slops

So, how do you become a valuable Open Source contributor in the era of infinite code generation? Here are a few tips learned from dealing with a large volume of contributions:

1. Think. Then think again

AI can produce great code, but it can also produce the worst code ever seen by the humanity. This depends a lot on:

• The prompt that you use
• The quality of the LLM
• The context being shared

And the most important one:

• Your own coding abilities.

Why do you need to know how to code before using LLMs to contribute to open source?

Well, because an LLM cannot know everything. For example, we had a PR that attempted to change this:

Previous:

		} catch (error) {
			console.error('Some error:', error);
		}

After

		} catch (error) {
			logger.error('Some error:', error);
		}

You would say: that is a valid change, we want to use logger instead of console! What’s the problem?

The problem was that the LLM didn’t know (and didn’t check, cause it wasn’t asked to) that we recently changed the typings on our logger instances, rendering the change invalid.

What a valid change would have looked like:

		} catch (err) {
			logger.error({ msg: 'Some error', err });
		}

But, the LLM didn’t know this, and it would have required quite some context for it to know. Good LLMs (Claude, Codex, etc) would have caught, but others would not, unless you asked them. How would you ask something that you didn’t know? There’s where your coding abilities enter into play.

Here’s the key point: You cannot prompt what you don’t know exists

Someone that wants to be a contributor doesn’t trust blindly on what the LLM produces. Knows how to use the tooling (typecheck, in this case) to catch those issues, reads the code to understand current conventions, caveats, etc. For this programmers, LLMs become a powerful tool, cause it helps you with the mechanical task of coding and gives you enough time to think.

This also protects your reputation. If maintainers see a pattern of low-signal PRs from you, they’ll eventually stop reviewing them. Or worse.

LLMs make contribution faster, but they don’t replace your brain unless you let them.

2. Respect volume. Review is not free.

You are happy. We’re also happy that you want to contribute to open source. It’s a noble endeavor and it’s something that helps the repository to be safer & you to be better. It’s a win-win!

But, maintainers have:

• Limited capacity.
• Limited time.
• Limited patience.

We understand, you are happy you created your new PR, and we understand the joy in you of doing that. We’ve all being there. You want, for sure, your PR to be merged so you can say with honor: “I contributed to X!”

But, be reasonable:

• The cost of opening a PR is now near zero.
• The cost of reviewing it is not.

This asymmetry is the real tension of the AI era.

If you:

• comment “please review” repeatedly,
• ping maintainers aggressively,
• demand merging timelines,

You’re increasing the cognitive cost of your contribution. Even if your PR is valid.

And here’s the harsh truth:

Maintainers are human.

If interacting with you feels expensive, they may subconsciously deprioritize your work. That means fewer reviews, fewer merges, fewer release notes mentions.

This is specially important when you use LLMs or Agents as they are fast, way faster than humans, so you could end up doing 100 PRs that you think are valid, and maybe they are! But if the maintainers don’t have the capacity to review them all, they just won’t.

That’s the definition of a DoS (Denial of Service): you send more requests than what the server (maintainers) can process.

3. Quality that doesn’t cut corners (pls don’t sue me Wendy’s)

Maintainer capacity is low. We closed around 700 issues (stale, invalid, fixed) in the past month, but at the same time, we received 300 new issues. Some of those issues were valid, some of them were not. The problem is we don’t know beforehand, we have to check them all. You cannot trust an LLM to confirm if something is slop… cause the check may be slop too!

Related link, curl fighting against AI slop vulnerability reports:

HackerOnecurl disclosed on HackerOne: Cookie Max-Age Integer Overflow...## Summary: The cookie parsing code in `lib/cookie.c` contains an integer overflow vulnerability when processing the `Max-Age` attribute of HTTP cookies. The vulnerable code attempts to add the max-age value to the current timestamp without adequate overflow protection While the code includes an overflow check (`CURL_OFF_T_MAX - now < co->expires`), this check itself can experience integer...

As you see, maintainers won’t be happy if you waste their time, cause they have stuff to do. The link above, as well as this beautiful list

GistAI slop security reports submitted to curlAI slop security reports submitted to curl. GitHub Gist: instantly share code, notes, and snippets.

have something in common: they look legit, until they don’t. However, for realising something is slop you have to check manually, and that is time/effort wasted.

So you have to be human, respect the times maintainers have and respect their work. How you do that? Helping the maintainers reduce the cost of reviewing your code:

Before submitting:

• Did you reproduce the issue yourself?
• Did you run CI locally?
• Did you include screenshots for UI changes?
• Did you provide benchmarks for performance claims?
• Did you include a PoC for security reports?
• Did you check if a feature request already exists?

If you claim a performance improvement, show numbers. If you fix a bug, explain the root cause. If you propose a feature, ask first.

High quality contributions get reviewed faster. Low signal contributions accumulate.

In the AI era, reputation compounds. If maintainers can trust you, your PRs will be reviewed faster, and you will feel happier. Win-win!

4. Bundle trivial changes.

Typos happen. Smol mistakes happen. For example

Before:

		if (!sub) {
			throw new Error('subsciption not found');
		}

After

		if (!sub) {
			throw new Error('subscription not found');
		}

Do you spot the bug? Yep, a missing r on subscription. The contribution is valid, yes, we want to write correct words in english.

Does it deserve a PR? Not by itself, maybe if you combine a few more. Think if you find 10 of those misspellings. What’s easier for maintainers? 1 PR with 10 changes or 10 PRs with 1 change? Hehe.

If you were the maintainer, what would you prefer?

Every PR has overhead: CI runs, notifications, review time, merge time, mental context switch, etc. Reduce the overhead by batching trivial work.

AI can find an enormous list of fixes like this in a codebase, and if you use an agent like Claude or Clawd you can tell “Hey for each issue create a PR” and then become the most hated contributor on the project :(

Don’t do that. Please. Be mindful. Be human.

LLMs are fun, but human work is better.

We’re on the AI era, we cannot fight AIs anymore, they’re here to stay. What we can fight is how we use them.

For GSoC for example, we value human contributions. That’s the point of the program: more humans converting to open source contributors!

We need new generations of maintainers, of smart people that will use LLMs wisely. You can do amazing stuff with them if you use them properly, but nothing will replace your ability to do amazing stuff as a human. You have to remember that.

It’s easier to contribute, but harder to stand out from the crowd. Reputation matters. Trust is earned. You build it by doing good work.

As a final note, this is pretty much personal experience. Some projects may have different rules. Some may like to receive 1000 PRs a day (?) idk.

But, the main point is: AI is not human, but maintainers and contributors are. So remember that.

Welcome to Open Source!

If u want to read more:

Jeff GeerlingAI is destroying Open Source, and itOver the weekend Ars Technica retracted an article because the AI a writer used hallucinated quotes from an open source library maintainer. The irony here is the maintainer in question, Scott Shambaugh, was harassed by someone