A Maintainer's Advice on Contributing to Open Source in 2026

The ideal contributor

As an open-source maintainer, you imagine the ideal contributor as an individual that is excited about your project, uses it and understands it, and wants to contribute to make it better for themselves, others, or because of an exciting technical problem.
You get to share ideas with them, learn from each other, maybe even get to know them a bit as a person in the process, and they inspire you to do better work. A profoundly human, intellectual interaction, inspiring and fulfilling, sometimes even resulting in a life-long relationship.

When that happens, it is an amazing experience, absolutely my favorite part of building open-source software.

I still remember when Craig, whom we didn't know yet then, came out of nowhere and shared his proposal for formal language grammar for Wasp, a proper Latex document: I had to take a week to refresh my knowledge of type inference and language grammars just to be able to respond. The whole team looked together at that document, not believing the work put into it. He ended up doing 3 summer internships in a row with us, implementing a big part of Wasp compiler and language server, and was a delight to work with.

Or, another, more recent situation, when I got somewhat stuck on pushing Windows support for Wasp forward, and @nodtem66 came in with investigation and experiments of his own, effectively unblocking me and becoming a brainstorming partner for driving the feature forward. I remember being impressed by the thoroughness of the work from his side, there was that level of rigor to it that took me back to the uni times, and it was quite an inspiration at the moment.

The reality

However, for every such interaction, there is probably 10x or more low-quality contributions.

And I don't mean low-quality because the contributor is missing technical knowledge, but low-quality because motivation was never right: no real interest for the project, focus instead being on merging the PRs for the sake of merging them, to pump up the author's GitHub account or CV with the proof of contributing to popular open-source repos, or to win some kind of award (e.g. during Hacktoberfest).

What I find most demotivating regarding such low-quality interactions is that when I see a new PR, I can't help but get excited: maybe this is a "good" one, the one where rich, inspiring interaction will happen. But what most likely follows is a dissapointment, and this is a part of what grinds the open-source maintainers down with time.

How AI made it worse

The main thing that changed for worse recently though, with the rise of AI, is that it became very easy to create open-source contributions that look good at first, but there is no real substance or quality behind them.

Before, one could quickly assess the PR for quality: if it looked complex and good, the person behind it for sure had to put the effort and obtain a certain level of understanding of the codebase and the subject matter.
Effort was put in, so you didn't feel bad putting effort from your side also, while reviewing it.

Now, you often just can't know till you dive in deeper.

Good example is Craig's contribution of a Latex document with the new formal grammar for Wasp that I mentioned above. When Craig submitted that in 2021, I didn't think twice about investing a whole week of my own time to be able to review that PR properly. I was brimming with excitement. Even though I knew nothing about Craig.

Today, if I received such a contribution, my first assumption would be that it was AI generated, with no deep understanding of the matter by the author. I wouldn't dare invest a week, or even a day of my own time, to evaluate it.

And to be clear, it's not even about purely evaluating the correctness of the submitted work: maybe it is correct, maybe it works well, maybe it is even well designed. The problem is, I can't rely on the person behind it. I can't hope that there will be a rich, fulfilling cooperation coming out of this, resulting in new ideas, in growing together, creating something together. And if so, if the whole contribution is indeed primarily AI driven, then what is the point? If I wanted to tackle it myself like that, I will prompt my own AI, likely with a better prompt and better context.

This sucks. It sucks that my first assumption these days on seeing a contribution is that it is AI generated, and I wish it wasn't so, but that is how it is at the moment. It sucks for the maintainers, and it also sucks for the honest contributors that are putting in the real work.

What can one do then, as a new contributor to an open-source project, to surpass this?
I thought about this recently, and I believe it comes down to a single thing: building trust.

How to build trust as a new open-source contributor

Before, that was relatively easy: a well-crafted, quality PR would get you a long way.

Today, more is needed, and I will give some ideas below on how to do this, that would do it for me as an open-source maintainer.

Be sincere, be human

Be an honest human and treat others as such.

This is it really. It was always important, but now it is crucial. Everything else stems from it.

Don't treat the project and people behind it as resources or means to an end, e.g. just for getting a notch for your CV. Instead find a project for which you have an honest interest, and it will immediately show.

Also don't be shy to engage in conversation. Maintainers are also humans and will appreciate sincere interaction.

Coommunicate your motivation

Communicate why you are excited about the project, what you have used it for so far, why you want to contribute. You might think it is obvious, but it's often not. It helps maintainers "place you", figure out how to best direct you, what they can expect from you.

Don't use AI for writing (e.g. PR descriptions)

Don't let the AI write for you, or even enhance your writing. This goes for any text others will have to read really. Better to have it not be perfect, than to make others doubt if there is a human behind that text or not. Even if you are not native speaker and are just using AI to "fix" your text: either prompt it to only fix the most minor grammar issues, or use something else like Grammarly, to ensure it doesn't change your tone.

Own the contribution

Check the specific project's contributing guidelines, but most projects won't mind you using AI, as long as you own the contribution: you should own and stand behind every line of code and every decision in your PR, exactly as if no AI was involved. That means you've read it, run it, understood it, and you can explain and defend it under review.

Start with easier, smaller issues

Pick issues that are not demanding on maintainers to review, so they can get to know you and your work before having to invest a lot of time. Make it as easy as possible to review, and explain your reasoning and approach.

Agree with maintainers on what to work on before you start

Learn which issues would maintainers be happy with you taking on. Old issues might have become irrelevant, issues requiring a lot of "taste" for the project or issues touching core parts of the project might be quite mentally taxing to review, etc.

That said, just asking "what are good issues for a beginner" might not be enough. Some repos might have those organized and ready, but many don't, and it also depends on your skills and interests.

What is better is to come already with some suggestions of your own and ask if any of these would be right to start with. While also explaining why each of these is interesting to you and why you would like to tackle it. Even if none of those are a good starting issue, maintainers will now have a much better idea of what you are looking for and will be able to more easily suggest some other issue.

Use the project

Ideally, this would be the reason why you want to contribute: you are a user that wants to give back, make it better for themselves and others.

But even if this is not the case and you want to contribute for some other reason, e.g. because you really like the tech stack and want to gain some experience with it, you should take some time to use the project and learn about it, understand it better.

This will also help with coming up with the ideas for the issues you want to contribute to: you will identify parts of the project you think could be better, and can start from there.

Final thoughts

While it is harder to establish trust as an open-source contributor these days than it was before due to AI, there is a silver lining to it: solution is to be more human and more mindful, which was always the right way to do it.