In 2025, impact became more visible. We improved monetization, built more enterprise trust, made scalability central, and moved AI Search closer to production reality. And we did it while staying true to what makes Meilisearch special: open-source, and the community around it.

This is my retrospective of 2025, from a Head of Engineering perspective, focused on what created lasting value.

1) Pricing is an engineering topic

Pricing is often treated as a “business” subject. In 2025, it became a very concrete engineering lever.

As anyone who has ever built billing, subscriptions, or payments knows: pricing is not something you can “just change”. It is deeply tied to your product, your systems, your data, and your ability to run safe iterations.

In 2025, we rolled out a new pricing model in Meilisearch Cloud early in the year. Revenue increased fast in Q1, which validated the direction. But most of that uplift came from usage-based revenue, which is powerful and also volatile. In the second half of the year, growth slowed and the limits became more visible. We had to react!

Later in the year, we rolled out resource-based plans in our Cloud offering. It performed better, because it scales more predictably and aligns more directly with customer value.

What I take from this is not “usage-based pricing is bad”. It’s that pricing should evolve with customers. People want to adjust their plan as they grow, as their usage changes, and as their constraints change. They want something they can customize.

And for that, we had to adapt parts of our stack and our codebase so we can evolve faster, test ideas safely, and support more flexible plans. 2025 was the year where we got ready for what comes next.

That’s where Meilisearch is heading in 2026: a more flexible pricing model, designed to adapt to different customers instead of expecting all customers to fit the same shape. And more than ever, we’re technically ready to iterate.

2) Enterprise readiness is built with proof

Enterprise growth is not only about features. It’s about trust, proof, and reducing friction.

In 2025, one of the clearest impact areas was security maturity. We achieved and completed SOC2 Type 2. Beyond the certification, it improved our internal practices and reduced procurement friction for bigger accounts.

We also leaned more into design partner collaborations. This approach helped us build closer to real enterprise constraints. In 2025, we worked with customers to improve our AI capabilities, deploy our new sharding system, release a new advanced geo-search feature, and revamp our analytics dashboard. This is expensive in terms of engineering bandwidth, but it yields high-quality outcomes. It shortens feedback loops and increases credibility.

We want to keep making this bet in 2026: Building with enterprise customers is one of the fastest ways to deliver real value. But it only works if we protect our bandwidth. The challenge is to stay close to enterprise needs without letting them redefine everything we do.

3) Scaling work became a business enabler

Performance has always been at the core of Meilisearch. We are building search that feels instant. But fast search has a hidden cost: indexing.

To deliver great query speed, we need to ingest and index documents efficiently. And indexing is hard. It consumes resources, it requires deep engine work, and it becomes more challenging as datasets grow and workloads evolve.

Since the beginning of Meilisearch, indexing has been one of our hardest daily challenges. It was always there, always important, but for a long time, it also felt like something we could postpone, or treat as a secondary priority. We had to change that.

In mid-2025, I led a team reorganization to create a dedicated team focused entirely on scalability. Instead of treating scale as a background constraint, we made it a daily priority. That’s when scalability stopped being a “future problem”. It became a business capability, and a central topic for Meilisearch.

In the last six months of the year, we made more progress than ever. The most visible milestone was the implementation of the Meilisearch sharding system. It moved quickly from delivery to production proof, and it was used in production by our largest customer. It directly enabled the deal and validated the strategy of investing in scale.

One sentence from my notes captures the year well: hard problems require dedicated focus.

4) AI Search: building for what comes next

Search is evolving fast. AI is evolving even faster. One of the bets we made in 2025 was to keep Meilisearch future-proof. Not by chasing AI trends, but by building solid foundations, so customers can rely on us as new capabilities become standard.

In 2025, we made Meilisearch’s hybrid and semantic search even more production-ready. These features are particularly appreciated by our users, and we focused on making them easier to adopt, including by making them available out of the box in our Cloud offering.

We also kept pushing innovation forward:

• we shipped multimodal search, unlocking image search use cases

• we introduced a chat route, laying early foundations for RAG

These newer capabilities come with a different kind of challenge: accessibility. The features are there, and we have the internal expertise to make them even better. But putting them in the hands of everyone is a different problem. It requires clearer guidance, simpler setup, and a smoother path from “I want this” to “it works”.

That is one of our main challenges for 2026: making our AI capabilities not only powerful, but easy to use.

5) Execution: shipping faster, increasing team leverage

I used to think execution was mostly about process and tooling. In 2025, I was reminded that it starts with something more fundamental: how teams are structured.

In mid-2025, we made one of the biggest changes of the year: we reorganized the engineering team. We moved from teams organized around parts of the codebase to teams organized around objectives.

We created:

• a Scale team, dedicated to product scalability, to support long-term business growth

• an Experience team, focused on user experience, including support

This shift had a direct impact. In 2025, the Experience team helped us improve the quality of our support significantly. The Scale team also became a key driver of our progress on scalability, as I mentioned earlier.

In each team, we made sure all the technical skills were present, so the team could stay autonomous across the whole delivery chain, from shaping an idea to shipping it to production. This reduced friction a lot, because teams did not need to “wait for someone else” to move forward.

Once we made that change, it became easier to reconsider everything. Step by step, we started improving delivery speed and reducing friction. One of the most impactful changes was moving our engine release cycle from every 8 weeks to weekly releases, which is definitely not trivial for open-source software.

This is what we aim to maintain in 2026: a mindset of constant reconsideration, iteration, and improvement. It was one of the key drivers behind our execution progress in 2025, and it needs to stay part of how we operate.

6) The community behind Meilisearch

Meilisearch is open-source, and that changes everything. It shapes how we build, how we communicate, and how we learn. It creates a different relationship with users: people don’t just use the product, they contribute to it.

As a Head of Engineering, I see the community as a long-term advantage because it compounds:

• It helps validate what matters early

• It raises quality standards

• It strengthens trust through transparency

• It expands adoption beyond what a team can reach alone

And this is not just a feeling. In 2025, contributions from external contributors grew again, with around 450 PRs merged. On average, 31% of the PRs merged across our open-source repositories were opened by external contributors.

In a year where we focused heavily on scale, enterprise readiness, and monetization, the community remained one of the strongest anchors.

What I’m taking into 2026

2025 made our impact more visible: we improved monetization foundations, strengthened enterprise trust, made scalability central, and pushed AI Search forward while keeping Meilisearch future-proof. We also improved execution by reorganizing teams around objectives and autonomy.

What I take into 2026 is simple: keep building for real customer needs, keep iterating on how we ship, and keep investing in the foundations that make Meilisearch scale. Because the goal is not only to move fast. It’s to build something customers can grow with.

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 💛

Personally, I’ve been at Meilisearch for almost 6 years now. I started as a developer on the integration team, building our very first libraries for the community, collaborating with them on daily basis. Today, I’m Head of Engineering, and I’m still convinced that working with the open-source community is one of the best and safest ways to build a great product.

In this article, I’ll share what we’ve built with our open-source community over the past six years, and why it still matters today.

What does open-source contribution mean at Meilisearch?

Today, the Meilisearch GitHub organization gathers more than 60,000 stars across all our open-source repositories (with over 50,000 on the main Meilisearch repository alone).

I still remember when I joined Meilisearch and admired the Elasticsearch repository and its 40,000 stars. Today, Meilisearch has reached and even passed that milestone!

But stars are just the visible part of the story, and honestly, the easiest and least important part of building an open-source community.

In our GitHub organization, we have more than 30 repositories that have actively been receiving open-source contributions. And when we talk about "open-source contributions," we often think about code since it shows strong community interest. That’s why my articles will mostly focus on this type of contribution. But every interaction, big or small, improves the project, saves us time, and strengthens the product: creating issues, commenting, reviewing pull requests, all these actions help the product move forward, and they’re just as important.

A few key numbers

Over the past 5 years, from 2020 to 2024 included, we’ve merged more than 1,800 external pull requests (PR). That’s about one PR every single day for 5 years!

We always knew the community was a key part of our story, but these numbers really prove it.

And it’s not just something from our early days. In 2024, almost 30% of merged PRs in our open-source repositories came from external contributors. This part was only 15% in 2021!

Another interesting fact: most of these contributions weren’t on the main Meilisearch repository! About 70% were on our integration libraries (the clients and SDKs we provide for different languages). These integrations are crucial for the Meilisearch experience (90% of users use one), but cover so many languages that we couldn’t handle them all without help. The community’s involvement here has been absolutely critical.

Recurring & cross contributions

Once you start attracting contributors to your project, you naturally want them to stay. That’s why it’s important to look at how often contributors come back and stay involved in your open-source project.

Over the years, we’ve had almost 1000 unique contributors at the Meilisearch’s organization. About one-third of them contributed more than once, and 15% even contributed to more than one repository. This shows that we offer a good contribution experience (something we often hear directly from our users).

Our most active contributor, @sanders41, made an impressive 119 pull requests over 4 years, including 50 pull requests just in 2021! 😱

At Meilisearch, we offer a variety of repositories to contribute to. Some are complex, like the main Meilisearch Rust codebase. Others are smaller and more accessible, like Charabia (our tokenizer library), our integrations & libraries or our documentation. This makes it easy for anyone to start their open-source journey with us, whether they are experienced developers or just getting started.

Our contributors come from different backgrounds. Some are interested in learning a new programming language. Others are passionate about open-source and want to support projects they believe in. Some contributors use Meilisearch for their personal projects, while others contribute during their working hours because they use Meilisearch at work.

What we build behind the numbers…

At first glance, it could be easy to think that most contributions are simple documentation fixes. But that’s far from the truth. Our documentation is one of the most important parts of our product, and we maintain very high quality standards for it. Every contribution to our docs is carefully reviewed, and only the best ones are merged.

Also, our most contributed repository is not a documentation project… it’s Meilisearch itself! Written in Rust and containing more than 30,000 lines of code, it’s a complex and demanding project. Contributing there is far from easy, and yet many contributors are actively involved! Today, for each release of Meilisearch, around 8 external contributors take part; a sign of a strong and engaged open-source community, although the complexity of the project!

Another common assumption is that most contributions are tiny or “just typo fixes”. In reality, every contribution, even a small one, helps improve the product. But what’s even more impressive is that most external PRs we got bring real value through meaningful fixes and additions.

Here are major examples of what we achieved thanks to the community:

• Charabia, our tokenizer library, was largely built with help from contributors speaking languages other than English and French (our main languages internally).

• The ability to connect Meilisearch with Prometheus: initially started by a Meilisearch developer, then improved continuously by the community.

• SDKs & integrations improvements: our integrations are mostly maintained and improved by contributors. Even when we lacked the time and bandwidth internally, the community kept the SDKs alive and high-quality. Today, many of the best PRs on the SDKs come from the community. We mostly supervise and review.

Our proudest achievement: hiring from our community

From the outside, our 50k stars might seem like the biggest success. But for me, the proudest achievement is that we hired one of our contributors as a full-time developer more than three years ago… and he’s still with us today!

Hiring someone from the open-source community is amazing, especially for a remote company like Meilisearch:

• You already know how they work.

• You see their code quality and communication style.

• Onboarding is fast and efficient, especially in a remote-first company like ours.

And we’re about to welcome a new intern who started contributing when he was still in high school! He’s now studying computer science at the University, and will be part of the Meilisearch journey in another way for a couple of months.

We are proud to stay connected with contributors over time and support them in their professional growth. The Meilisearch team is currently full, but if I had to hire developers, I already know I would contact our main contributors first. We appreciate keeping in touch with many other contributors, following their careers, celebrating their milestones, and sometimes meeting them in person (although it’s rare, that’s the drawback of open-source: the community is spread all over the world!).

Giving back to open-source

We’ve received a lot from the open-source community, so it’s important for us, as a company, to give back in multiple ways, as much as we can:

• Every Meilisearch employee can support open-source projects financially (up to €50/month).

• We heavily use open-source libraries, and sometimes Meilisearch is even one of the main users, like for Actix. Thanks to Meilisearch, these libraries can improve their product by pushing the limits of their own project with us.

• We contribute back to projects, like Lindera (our Japanese tokenizer) or LMDB (our internal database). Also, Kero, CTO of Meilisarch, is the maintainer of Roaring-rs, the Rust version Roaring Bitmap.

• We open-source the tools we build internally when they can be useful for others, like:

  • Segment, the Rust library for Segment tool (forked and improved from an abandoned project)

  • Cargo-flaky, a Rust tool to spot flaky tests

A heartfelt thank you!

Building an open-source project like Meilisearch has never been just about writing code. It’s about building a community: a group of people who care about the product, contribute their ideas, and help move it forward, one step at a time.

Looking back over the past six years, it’s clear we couldn’t have achieved everything we did without our contributors. They helped us grow faster, make better decisions, and create a stronger, more reliable product. They challenged us, supported us, and sometimes even joined us as full team members.

We are deeply grateful for everything the community has brought us. And we are proud to keep giving back whenever we can.

Thank you for being part of this journey.

I’m already working on a follow-up article with our top tips and good practices for managing open-source projects. Stay tuned! 🚀

Edit: here is the article! ✨