Don't Slide Into Main Uninvited

A few years ago, the biggest headache in open source was tutorial spam. Beginners would watch videos telling them to edit a readme and submit a pull request as their first step into tech. Repositories were flooded with vanity contributions that changed nothing but the contributor list. Maintainers spent hours closing them. The advice was well-meaning but created a mess.

That trend has faded. YouTube tutorials promising easy resume lines have quieted down as AI tools took center stage. But the problem did not disappear. It evolved. Now, instead of anxious beginners following a script, maintainers receive pull requests generated in seconds by large language models. The code looks confident. The description is empty. The sender often cannot explain a single line of what they submitted. Welcome to the new era of open source noise.

I have been writing software since 2009. I started with PHP, moved through C# and Node.js, picked up Python, and now I work at an AI startup. I have been the new contributor staring at a codebase I did not understand. I have also reviewed code at midnight. I know both sides. I also know that AI is not the enemy here. The tool is just faster. The problem is still the same. People are submitting work they do not understand, hoping a maintainer will clean it up.

The maintainers I have listened to over the years all say the same thing. They want contributors who join the community first. This does not mean you need to write a thousand messages in a chat room. It means you should use the tool. Read the issues. Watch how people talk to each other. Understand what the project cares about. Every community has its own culture. Some move fast. Others support millions of users and move slow. You have to sit with it. I once wanted to reorganize a project's folders. I am glad I did not. I would have broken build scripts I never knew existed.

Once you understand the project, start small. But start with something real. Fix a bug that annoys you personally. Maybe a config value is ignored on a specific platform. Maybe an error message is misleading. These fixes save maintainer time and show you can read code, run tests, and follow style. What you should not do is rewrite a module to show how clever you are. Refactoring looks simple from the outside. It is not. The current code handles edge cases you cannot see yet. It matches patterns in other files you have not read. A new contributor who refactors early is almost always rewriting something they do not understand.

The same goes for documentation and typo fixes. For years, people told beginners to start there. I think that advice is outdated. One maintainer put it bluntly. New users should not write beginner docs because they are still beginners. That job belongs to people who have answered the same question many times. A typo fix is not harmful, but it is also not memorable. It does not build trust. Trust comes from fixing real problems.

The best features come from real-world pain. If you are building something with the tool and you hit a wall, that is the moment to open a discussion. Describe your use case and show what you tried. The best pull requests add five lines but unlock massive power. The worst stretch across dozens of files for one edge case. That ratio is what you should think about. Maximum impact. Minimum footprint. This is completely different from inventing a feature because you saw someone else's pull request get merged. Features made up in a vacuum rarely fit the project's direction. They create maintenance burden for years.

If you do not have a real bug to fix yet, consider building your own project instead. I have created repositories ranging from a task management system in Next.js to a collection of Go APIs. I also built a simple typing game for toddlers in TypeScript. These projects taught me more about maintenance and taste than any single pull request I ever sent to someone else's codebase. When you build your own thing, you learn why naming matters, why a README is more than badges, and why dependencies cost you later. Managers can see your thinking across an entire project, not just a diff.

Now we must talk about AI. At my current role, we use large language models every day. They help me explore unfamiliar languages and find patterns faster. But there is a hard line between using a tool and outsourcing your judgment. Some maintainers receive pull requests that look like an agent produced them. The code is confident and the description is empty. If you submit code you cannot explain, you are not contributing. You are littering. If you use AI to help you, say so. Explain what you understand and what you do not. Honesty builds trust. Blind automation does not.

A maintainer of a popular terminal emulator recently explained their policy. They require AI disclosure on every pull request. When contributors are honest and say they used a model but do not fully understand the language, the maintainer can give quick feedback. When people hide it and act like the code is their own, trust breaks. One maintainer said it plainly. If you cannot be honest about your AI usage, they cannot trust anything else you are doing. They will close the request.

Other maintainers report seeing multiple AI-driven refactoring pull requests every day. The titles are generic. The changes reorganize code that already works. There is no bug fixed. There is no performance gain. It is just noise that risks breaking something for no reason. One framework creator compared it to a social credit score system. People are farming contributions instead of solving problems.

Maintaining open source is emotionally expensive. The creators who stay do it because they love the work. When you send a pull request, you are entering someone's home. Wipe your feet. A real bug fix is a gift. A thoughtful question is a gift. A generated refactor with no purpose is not.

Open source is not a social credit system. It is not a networking checklist. It is a relationship between people who care about the same tool. The right way in is simple. Use the software. Feel the pain. Join the conversation. Fix something small. Build something of your own. Respect the maintainer's time. Be honest about your tools. Do not slide into main uninvited.