Seeking a path forward: co-maintainership or community fork

[arturoherrero]

Description

👋 Hi @keegancsmith and team,

We're engineers from GitLab (@raviiitb, @binarymason, @dgruzd) and have been building on top of Zoekt for a while. We rely on it heavily for code search, and we want to keep contributing upstream, but we've hit a wall with responsiveness and we'd like to have an honest conversation about the project's direction before taking action on our own.

Here's what we're observing:

• PR #1005 opened January 2026 by a GitLab engineer, explicitly describing a GitLab use case (repo: filtering and shard naming), now almost 2 months old with no maintainer response.
• PR #506 (Dec 2022) was a bugfix from @DylanGriffith (GitLab) that required three separate pings over five weeks before it was merged. Dylan explicitly cited Sourcegraph's own blog post announcing they'd accepted Zoekt maintainership and stated GitLab was planning significant Zoekt investment. The maintainer's only acknowledgement was: "Apologies, PRs in this repo don't usually fester for so long." That was January 2023. The pattern has continued since.
• Beyond these, there are currently several open PRs and issues where the community is still waiting on a maintainer response or approval to move forward.

We'd love to find a path forward together. Two concrete options we'd like to propose:

1. Add GitLab engineers as co-maintainers. We have the bandwidth and motivation to triage issues, review PRs, and keep the project healthy for the broader community.
2. If that's not workable, we would fork the project and maintain it actively, and invite you to update the README to point to the fork as the actively maintained version.

Would you be open to a quick discussion about what works best for both teams?

Thanks for everything you've put into Zoekt over the years. 🙏

[linear]

CU-2625

[keegancsmith]

You are right, I've been ignoring this repo for a while due to other commitments. Yay open source. I'll open up the discussion internally at Sourcegraph.

We rely on it heavily for code search

So do we! But as you can tell from commit history its been very stable for us for a while.

we want to keep contributing upstream, but we've hit a wall with responsiveness and we'd like to have an honest conversation about the project's direction before taking action on our own.

Once again sorry about that. We don't plan any major changes to Zoekt at the moment, so it would be interesting to know if you have more ambitious plans that affect the core of Zoekt.

The maintainer's only acknowledgement was: "Apologies, PRs in this repo don't usually fester for so long." That was January 2023. The pattern has continued since.

The pattern comes and goes, I don't always ignore the repo :P

Beyond these, there are currently several open PRs and issues where the community is still waiting on a maintainer response or approval to move forward.

More than I had in my mind! I suspect something is wrong with my email filters, will investigate. FYI you are welcome to email me directly, has a better chance to bubble up over the large amount of github notification noise. The contributions I recieve from GitLab are usually more reasonable, so easy for me to prioritize.

[arturoherrero]

Thanks for the honest response, really appreciate it. We are also concerned about the bus factor with you being the only point of contact. It would be good to have at least two maintainers and aim for a one-week response window. We are not asking for a reply/review straightaway, just enough to keep contributions moving.

On your question about ambitious plans: we are mostly driven by our use cases at GitLab scale and don't have any concrete ideas at the moment, but other folks here who work more day to day with Zoekt can also give feedback.

Thanks again for unblocking #1005. Looking forward to seeing more collaboration in the future.

[keegancsmith]

We are going to start communicating more frequently and informally. At first we are gonna try out a slack chan with ya guys. Additionally internally I've started the discussion of reducing the bus factor at Sourcegraph.

Thanks again for filing this issue. For now I am gonna close it out and lets see what develops from our slack discussions.

[arturoherrero]

Thank you so much for your help and collaboration!