I like open source software. As a user, I appreciate the idea that I can ensure that the software I am using does what it is supposed to. Or someone else (or an entire community) does it for me, in case I am not familiar with a specific tech stack. Or, more in general, I like the freedom aspect of it as a philosophy. As a scientist/developer, the idea of providing lasting and concrete contributions that go beyond the single paper gives me a broader sense of service. Overall, I think that what I really see in open software is a larger sense of community, where people share what they have built with zero expectations in return. Maybe I am naïve, but I refuse to believe that I am the only one seeing it that way.
One of my favourite aspects of open source software is when I am able to make contributions to code bases that are not my own. Either I want to be part of a specific project, or I want to learn more about a certain topic; in any case, the approach I have is always similar. I start by digging into the repository to find little bugs or #TODOs. Docstrings, readmes, and links are usually the first things that I go through. Almost always, I find some small things that I can fix, and I open a pull request to address them (as a maintainer, these are usually my favourite PRs to receive). After that, I go deeper into the code and look for any threads that might have been missed by maintainers, who are usually juggling a lot of different responsibilities: maybe some variable can be better named, maybe there is a trivial extension that has been left on the shelf for lurkers like me to find. In any given codebase, there is always something to do. This exercise of opening small, self-contained PRs to correct small issues has two main benefits: I get a foot in as a contributor with low-stakes changes, and I get to understand the code while doing so.
Atomic contributions also play a vital role in the ecosystem of a code base. New contributors start having interactions with long-time maintainers. Larger PRs get drafted. Trust gets built. And over time, a sense of ownership grows among the contributors, and they feel part of the project instead of just contributing to it. Small changes are often the entry point to a community.
However, simple contributions are quickly disappearing from software bases. Coding agents fixed them all. I am not here to argue about the usefulness of artificial intelligence (AI) agents to code, also because there is not much of a discussion to have; they are good and clearly here to stay. What I lament personally is that it is becoming extremely hard for a potential contributor to, well, contribute. All the low-hanging fruits have been picked. All the easy implementations left as issues by the contributors that would have taken them minutes to some hours to implement have been implemented in seconds already. All the things new contributors can realistically do to a code base they want to get familiar with are easily done (probably even better) by agents.
Now, the AI aficionados will tell me that new contributors will just have to use agents too. Which is fair; they should. However, if all easy contributions are taken, what is left is the hard stuff. Issues that maintainers have long procrastinated on, or have not found an elegant solution for. First-time contributors solving these issues with agents are probably not going to understand why the solution worked. Or the implementation will probably not be what the contributor wanted, at which point a particular phenomenon will happen: the contributor will feed the maintainer’s replies to the LLMs and paste the changed code, creating a sort of proxied vibe coding. And at the end of the process, the person who has opened the PR and got it accepted will have a contribution under their belt. Will it feel the same as before? Are they likely to stick around?
All my previous scenarios also involve a good deal of good faith. That a given person is genuinely interested in contributing to a code base. The rise of slop PRs also shows the opposite side of the medal: people just shooting PRs, hoping one will be accepted. A nice GitHub profile is still a “nice to have” on the CV, after all. Slop PRs are equivalent to noise; they are not merged, and when pushed back on, some changes usually are not provided. Ironically, it is easier now to submit novel features through half-prompted agents than it is to submit a simple and easy fix to the code.
Of course, not all is bad. If someone takes the time to go through the software with an LLM explainer, they will understand the code faster compared to before. Code bases in general are becoming better with agents, when wielded by capable users. Little-time maintainers (like me!) have more compute power to implement things that before fell by the wayside since time is limited. I do wonder, though: while AI agents are undoubtedly making open source software better in general, are they harming the community at large? Numbers in dedicated developers’ chats and forums are already dwindling. Will this trend pass on to the larger idea of community, bleeding into the software contributors themselves?
I do not know the answer to any of the questions I scattered in this blog post. I do fear that the motivation for people to contribute to other people’s projects is diminishing. Trust on the part of the maintainers is also low. Overall, it is easy to sense a bit of tension between the two parts. In the end, I just hope that the coding agents will not take away my favourite part of the open source community: its people.