What it means to contribute to open source in the AI era
Hello, I'm Seungjae Lee, a developer who loves open source. I like that the code I write and the things I build have an effect on someone, and honestly it's no exaggeration to say that this fun is why I develop at all.
Today I want to write about how I first discovered that fun, some feedback I recently received, and the thoughts it left me with.
My first open source contribution was to exercism. It was the site I learned from when I first started studying development, so I had always wanted to give back what I had received, and in November 2024 I opened PR #2863, which wrote up solution approaches for the Parallel Letter Frequency exercise on the Java track. Between my clumsy English and contribution rules I had never seen before, it was merged only after several rounds of feedback.
Afterwards I went to the site and found my code and explanation up there just as I had written them, with my name in the contributor spot. I was a student back then, and I was so happy and moved that I remember going back to look at it again and again for a while.
Drawing on this experience, I also gave a talk titled Building the skill of reading open source at a joint Sejong University × Konkuk University tech talk of the goorm-thon UNIV club, and because the memory of exercism still stays with me, I keep contributing to open source today.
Wanting to contribute to open source more often, at one point I set up agents and skills for every library and framework I used, scanned them regularly, and opened a PR whenever I found a defect. Thanks to that I really did contribute a lot: 22 PRs were merged in the Korean e-Government Standard Framework alone, and I also opened PRs to Spring Data JPA, jjwt and LangChain4j. But as the PRs piled up, at some point I started feeling uneasy without knowing why.
Then, on PR #51468 to Spring Boot, I got this feedback.
Did you use AI to produce the description? Regardless, it's unnecessarily verbose for a one-line change to main code and includes lots of details that are already available elsewhere.wilkinsona · Spring Boot maintainer
The maintainer asked whether I had written the PR description with AI, and pointed out that either way it was needlessly long for a one-line code change and included details already available elsewhere.
I use an LLM to look for bugs in projects I use, then check the bug is real and run the tests myself. … I still think it is good for open source, but I would like to know if you agree. Are LLM pull requests more tiring than helpful now? Or is it still worth it if it brings in more contributors?masiljangajji · me
I replied that I use an LLM to find and fix bugs in the projects I use day to day, and added that I hope contributions like this make open source better. Then I asked whether PRs made with an LLM actually help, and how, as a maintainer, they see the current moment, when the barrier to contributing has dropped and there are more contributors.
This was the answer.
As we have limited resources, we much prefer dealing with bugs that are causing real-world problems. The value of fixing these is much higher than fixing something that may technically be a bug but isn't have a negative impact on anyone.wilkinsona · Spring Boot maintainer
Because resources are limited, they much prefer bugs that cause problems in the real world, and fixing something that might technically be a bug but harms no one doesn't mean much.
The maintainer didn't blame LLMs themselves: a fix for a real problem is welcome whatever was used to make it, and if it's polished well you can't even tell an LLM was involved. But what matters, they said, is the quality of contributions rather than the number of contributors, and they added this.
The best way to contribute to an open source project is to use it in your day-to-day work in real-world situations. You can then propose bug fixes and enhancements that make your day-to-day work easier, benefiting both you and the rest of the community.wilkinsona · Spring Boot maintainer
The best way to contribute is to use the project every day in real work, and then propose fixes and improvements that make your own work easier, which benefits everyone.
I don't think it's wrong to find problems and improve code with an LLM either. Even for a bug an LLM found, judging it and adopting a fix still takes an engineering decision. Still, the uneasy feeling didn't go away.
After this feedback I thought it over carefully. Improving code and getting to know open source projects is still fun, and I'm glad when a PR gets merged. So why did I feel so uneasy and stuck?
The conclusion I reached was that I had been contributing to fill my résumé. I wasn't solving problems I had actually run into; I was deliberately hunting for defects to fix because I wanted my name on them. At some point, I think open source contribution had started to feel like something I had to do.
I also picked the projects to contribute to only from within the Java·Spring ecosystem. It's true that I'm a Java·Spring developer to begin with, so I know this ecosystem far better and have used it much more, but I can't say I didn't consider that it would make an impact on a résumé.
In the end, what made me uneasy wasn't the LLM but the purpose. I felt that why I contribute matters far more than where, and I decided to solve real problems.
Here are two PRs that fixed problems I actually ran into. The first is sqlglot. At work I was building an Athena-based text-to-SQL feature and validating LLM-generated queries with sqlglot before running them, but queries like LIKE 'QA3\_%' ESCAPE '\', which run fine on Athena, were rejected with a TokenError. It turned out the Athena dialect tokenizes with the Hive and Trino rules combined and only then decides which engine to send the statement to, and since \ is the escape character in Hive, '\' became an unterminated string and failed before it ever reached Trino. I opened PR #8629, which retries with each engine's own rules when tokenizing with the combined rules fails, and it was merged the same day.
The second is the Strands Agents SDK. While running an LLM service on Claude through Bedrock, I found a ValidationException in the error logs: the model had returned a stopReason of tool_use but left the tool call itself empty. Seeing tool_use, the SDK tried to run the tool and send back the result, but with no tool to run it appended an empty user message instead of a result, and the next request failed. I opened PR #5145, which ends the turn when there is no tool call, and it is still waiting for review.
These two PRs were my first contributions to Python-based open source, outside the Java·Spring ecosystem. I used LLMs the same way as before, but knowing I was solving problems I had run into myself made the uneasiness ease up a lot.
I also thought about how I could contribute more meaningfully from here on. The first way is to keep fixing problems I run into myself, as I do now, and the second is to go beyond analyzing and contributing feature by feature, and contribute after understanding the module and the overall architecture. If I keep contributing to one module, I suspect I'd build real expertise in at least that module. Spring Data seems to be nicely modular, so I'd like to write a post analyzing it too.
I believe every kind of contribution has meaning. Whatever the intent, and whether or not an LLM was used, the code ends up better. As I said earlier, finding a problem can be vibe-coded, but keeping compatibility with the existing code, convincing the maintainers and getting through review is still the engineer's job. That said, as the maintainer put it, fixing a problem you hit while actually using the project seems to be worth far more, and it means more to me too.
These days, besides open source contributions, I'm also building things that do nothing at all for my résumé. The main one is a Chiikawa pet that moves around my desktop with me. It's ridiculously, unbearably cute, and making it is a lot of fun.
With the vibe-coding era upon us, many developers are worrying about their careers. As the very definition of development changes so quickly, some struggle to find their direction or lose interest, and the market is beyond cold, frozen solid, so getting yourself noticed somehow feels desperate. I'm no different; it's true that it's less fun than when I first started learning. Even so, I hope you try building useless things. Everyone seems to be living so tightly, with no room to breathe. How about catching your breath by making a ridiculously cute Chiikawa? I'm cheering on every developer in this pioneering age of AI.
Thank you for reading.