What 1,000 Contributors Taught Me About Open-Source

In the open-source world, a contribution from someone outside your team can take many forms: giving feedback, reporting bugs, requesting features, suggesting improvements to the code structure… or directly contributing to the code by opening a pull request (PR)!

While PRs are not the only way to contribute, they’re one of the most valuable. They bring in external expertise (sometimes from people who know more about a topic than you) and they can save you a lot of time… if handled well!

Why you should aim for recurring contributors

I’ve been working at Meilisearch for 6 years as an open-source maintainer, and I’ve learned a lot from the experience. If you maintain an open-source project, your goal with code contributions should be to build a community of recurring contributors. The more people contribute, the more they understand the project, and the more consistency and stability your project will gain.

At Meilisearch, we’ve had almost 1,000 unique contributors, and more than one-third of them have made two or more code contributions (PRs) that were merged. We’re proud of this, and it’s something we’ve built up over the years. We now have a strong and self-sustaining community, thriving around our fully open-source core product, with minimal effort needed on our side.

Let me explain you how we built this community of recurring contributors and how you can do it too!

Create a place of generosity

This might sound a bit cheesy or obvious, but it’s the core principle we agreed to follow at Meilisearch, and it’s made a big difference in creating a positive experience for contributors.

Be kind, friendly, and grateful. People contribute in their free time. Gratitude is the least we can offer. Kindness helps create a welcoming and respectful space. It also makes discussions and disagreements much smoother. Ideally, you want the community to be able to manage the project without needing you all the time. That starts with setting the tone.

Be as responsive as you can, but don’t expect contributors to match your speed. Some will only have time to work on weekends or late at night. If you also maintain your project in your spare time, you’ll have similar expectations. It’s okay that some PRs will take weeks (with some back and forth) before they can be merged. That’s just how open-source works sometimes.

Be ready to help. At first, you might feel like you’re losing time (“If I did it myself, it would be faster”), but that’s short-term thinking. In the medium term, if you build the right environment, people will come back, and you’ll get those valuable recurring contributors that make a project healthy.

Also, by helping others, you’ll learn how to improve the contribution experience. For example, helping beginners often shows you where your documentation needs improvement (like your CONTRIBUTING.md). This makes it easier to welcome more people in the future.

And remember, some of your best contributors will leave sometimes. That’s okay. Be grateful for what they gave and stay flexible. They might even come back at some point!

Be crystal clear

Clarity and simplicity are essential to save time and support your contributors.

Start by writing clear, simple issues and tagging them with good first issue. This label attracts contributors, especially on GitHub. But make sure the issue is really suitable as a first one and easy to understand.

Add as many details as you can about what you expect. Don’t assume the contributor has any context! List what method to add, what it should do, how to name it, where to put it in the code, and whether it needs tests. The larger your codebase is, the more specific you need to be. For example, in our SDKs, it’s usually obvious where a function should go. But in the Meilisearch repository (over 30k lines of Rust!), it’s crucial to point to the exact part of the code that needs to change. If we forget, contributors often ask anyway.

I encourage to always keeping a friendly tone and encourage people to ask questions if anything is unclear.

I also recommend opening several small issues instead of one big one. This makes it easier to contribute, and it simplifies your job too: smaller PRs are quicker to review and merge, which improves and fasters the whole deployment loop.

Simplify the first steps to contribute

I’ve contributed to open-source projects where commit hooks blocked my pushes or where I had to go through a long list of steps before finally opening my first PR… only to see the maintainer has to close it because I missed a specific step. I get it, some projects have different objectives, or have been burned in the past and now protect their code strictly.

But my advice is to do the opposite: make it as easy as possible to contribute. At Meilisearch, we choose to keep contribution rules minimal. We try to remove blockers because our goal is to receive PRs.

Our setup is simple: automatic PR templates remind contributors to read the CONTRIBUTING.md and link their PR to an issue. Nothing more. This reminder helps avoid discussions about the purpose of the PR (those are better handled in issues). But people can still open PRs without following everything, and that’s the most important part for us.

Also, when you remove blockers, make sure there’s guidance along the way. A lack of structure can also be a blocker. “Is my PR okay? Did I miss something?” are questions the contributors can have you want to provide answers in their contributing journey.

Hence my recommendation about what should be present in any open-source repository:

• The README.md file: explains the goal of the repository.

• The CONTRIBUTING.md file: explains how to contribute. Include tools, commands to run tests or build, and be detailed so beginners can join.

• A good CI that is running for each open PR: tests help you (and the contributor) see quickly what’s wrong. They build trust and motivation. I would already recommend to remind contributors to add tests when opening a PR changing the code base.

Don’t work with the community… collaborate with them!

People contributing to your repository may have deep expertise in their language or field. It’s important to recognize and value that.

That’s why you should dare to rely on your community. You can’t know everything!

At Meilisearch, we maintain 10 libraries in 10 different languages. Obviously, we don’t have experts for every language in-house (we don’t even have 10 developers 😄). So we rely on the community. We know the product (and contributors expect us to make decisions), but they know the language! They help us make our libraries feel more natural and idiomatic. We ask for their opinion regularly, whether it’s about a big refactor, removing something, or even choosing between npm and yarn for a new project.

Also, I would recommend giving responsibilities to the community. Trust recurring and reliable contributors by giving more access to the repository. If someone has both the mindset and the technical skills to handle the repository, make them a maintainer. You can give a little bit of control without giving away everything.

At Meilisearch, we did this a bit late, but we should have done it earlier! It’s one of the best ways to grow your open-source project. Today, external maintainers in our repositories can approve and merge PRs without internal approval. They can even make releases. We’re proud of this, and we’ve never regretted it: they’re reliable, and they communicate clearly.

Of course, we never expect this level of involvement. Open-source contributors work on their own time, and we respect that. As the main maintainer, be prepared to manage the repository alone when needed, and be grateful when others help.

My final advice about community collaboration would be: don’t accept every contribution! Contributors bring expertise, but you have the context: the project’s goals & vision, or the company’s context. If you accept everything, your best contributors might leave because they lose trust in the project’s direction. Contributors expect this clarity and this decision-making from you, it’s important to keep the role.

When hesitating with a contribution, try to keep things simple. Ask yourself or to the contributor: does this PR bring real value? Is it aligned with project best practices and objectives? You can reject a PR with kindness and gratitude, as long as you explain your reasoning. We’ve never had issues closing PRs at Meilisearch.

That said, we’ve made mistakes: we once accepted a big refactor that made the code more complex. A few months later, the contributor left, and we had to fix the mess. Lesson learned: contributors can leave, but their code stays, and you’ll be responsible for it.

Encourage cross-contributing

This tip is more useful for large open-source organizations like Meilisearch, but if you maintain several repositories, you probably have different levels of difficulty across them. In that case, guide contributors to the right place.

For example, Meilisearch is our most famous repository, but also the hardest to contribute to. it’s indeed a project of 30k lines of code written in Rust, composed of complex algorithms. Thus, many people enter our community through it, but get frustrated if they can’t find a task for their level. When we notice this, we redirect them to other repositories in the same language, but with easier issues.

Also, I recommend, when possible, to mention other repositories in your issues. For example, our SDKs all have similar goals (being a client of Meilisearch) but use different languages. Sometimes we open an issue and say, “In meilisearch-js, we did it this way,” to show that other implementations in other repositories exist. We’ve seen contributors who enjoyed their first contribution so much that they tried another one in a different repository, just to keep learning!

Give back to the community

The open-source community will give you a lot, so it’s important to give back as much as possible.

You already provide your project for free, and if you follow the tips in this article, you’ll already be giving your time and attention. But if you are an open-source company like Meilisearch, you can do more!

Join community events like Hacktoberfest when you can. These events are fun, motivating, and a great way to say thank you to contributors. They also bring a lot of attention to your project.

If you work at a company like Meilisearch, consider starting a rewards program or sending swag to contributors when possible. Not everyone wants stickers or t-shirts, but some do, and it’s a nice way to show appreciation.

Lessons from the journey

Maintaining an open-source project is not just about reviewing code, it’s about building a space where people feel welcome, supported, and proud to contribute. If you want recurring contributions, start by creating a positive and generous environment, make it easy to get involved, and be ready to truly collaborate with your community.

Set clear expectations, stay kind (even when rejecting PRs), and trust your contributors with responsibility when they’ve earned it. Over time, this builds a strong, engaged community around your project, one that grows with you.

Happy maintaining 💛