Call for New Maintainers — Help Wanted

[Jakob3xD]

I want to use this issue to be fully transparent with the community about the current state of maintenance for this repository, and to formally call for new maintainers to step up. I believe openness here is more respectful to contributors and users than silently letting things stagnate.

---

The Maintenance Situation

We are critically low on active maintainers.

At this point, the number of people with merge rights and active responsibility over this repository is very small and not all of them are reachable.

For an open-source library that serves as the primary Go client for OpenSearch, this is a serious problem. Users and organizations depending on opensearch-go deserve a project that is actively maintained, reviewed with care, and steered with a technical vision.

---

The Volume and Complexity of Incoming Contributions

This repository has been seeing a significant number of substantial pull requests, in particular from @sean-, who has been contributing major features and architectural changes. I want to be clear: these contributions are valuable and appreciated.

However, reviewing large, complex PRs properly is not a trivial task. It requires:

• A thorough understanding of the codebase and its design decisions
• Time to test, reason about edge cases, and think about long-term implications
• The confidence to approve or request changes with a clear rationale

A PR like #787 is a good illustration of this challenge. It is a wide-ranging change that needs careful review.

---

My Personal Limitations as a Maintainer

I want to be transparent about my constraints and why we need more maintainers.

Time constraints. This repository is a side task for me. It is not part of my main job or primary responsibilities. My capacity to review PRs, triage issues, and engage with contributors is limited.

I am not a software developer by profession. I do not have a clear technical vision for where this library should go architecturally and what guidelines we should use to enforce it. Specially when it comes to complex connection handling and multi process handling.

My original motivation was pragmatic and narrow. I came to this project because I needed a working Go client to manage OpenSearch clusters with my own internal tooling. In the longer term, I also have an interest in using it as a foundation for work around the OpenSearch Kubernetes Operator. These are legitimate use cases, but they are not a substitute for the broader vision and technical expertise this library needs in a maintainer.

I am going on holiday. Starting soon, I will be away for several weeks and effectively unavailable. I don't want to leave the project in a complete void without at least raising this issue first.

---

What This Project Needs

I'd love to see one or more new maintainers step in who bring:

• Technical depth in Go and ideally experience with OpenSearch
• Availability and consistency and the ability to show up regularly, not just occasionally
• A vision for the library and an opinion on where the API should go, what the developer experience should feel like, and how to balance stability with new features
• The confidence to review large PRs and give meaningful, substantive feedback

Ideally, new maintainers would be people who are already using opensearch-go in a real project or organization and have a stake in its quality and direction.

---

Call to Action

If you are interested in becoming a maintainer, please comment on this issue. It would be helpful to know:

• How you are currently using opensearch-go
• What areas of the codebase you are most familiar with
• What your availability looks like

The steps of becoming a Maintainer are described in this article.

Thank you to everyone who has contributed, reported issues, and been patient with the slow review cycles. It is genuinely appreciated.

[krisfreedain]

Catch All Triage - 1 2

[atris]

I am currently playing with Go and do plan on using opensearch-go as well in the near future. If it helps, I can spend a couple of hours per week reviewing PRs

[sean-]

Here are ten standalone PRs against main, grouped by effort. All are independent unless noted -- feel free to start wherever you're comfortable.

Quick wins (< 30 min each)

PR	Title	Size
#810	Bump OpenSearch version to recent releases	+7/-6
#819	Skip shard routing tests on OpenSearch < 2.2.0 with security	+99/-0
#823	Include _nodes.failures in discovery error messages	+68/-5
#812	Add a doc explaining available metrics	+245/-0

These are version bumps, test guards, error-message improvements, and docs -- fast to validate, no cross-PR dependencies.

Medium (1-2 hours each)

PR	Title	Size
#809	Add generic Do[T] function for compile-time pointer enforcement	+355/-241
#803	Add polymorphic Status field to task response structs	+1134/-97

#809 introduces a type-safe generic wrapper around Client.Do() -- wide but mechanical (touches ~70 files, mostly do() -> Do[T]() call-site conversions). #803 adds a new response type system for task
status payloads -- focused on opensearchapi/api_tasks*.go and a new guide/sample.

Large (2+ hours each)

PR	Title	Size	Prerequisites
#804	Fix double-slash URL path bug across 74 GetRequest methods	+2365/-1894	None
#822	Add AddressResolver to rewrite discovered node URLs before pool entry	+1486/-23	None
#815	Add configurable shard cost multipliers via env var and RouterOption	+1318/-318	None
#801	Add adaptive max_concurrent_shard_requests for search routing	+3614/-636	#815 first

#804 is high line count but mostly repetitive -- the core fix is a new BuildPath helper, then 74 methods switch to it. Good candidate if you're comfortable with bulk review.

#822 is a self-contained new feature (address rewriting during discovery) -- clean to review in isolation.

#815 -> #801 is the only hard dependency: #801's adaptive routing uses the shard cost multipliers introduced in #815. Review #815 first if you plan to look at #801.

Suggested path for a few hours

If you have ~2 hours: knock out the four quick wins + #809 -- that's five PRs cleared.
If you have ~4 hours: add #803 and #804 -- the URL fix is the highest-impact bug fix in the set.
If you're interested in the transport/routing internals: #822, then #815 -> #801.

Thanks for volunteering time on this -- happy to answer questions on any of them.

[tender-barbarian]

I've been on a lookout for some open-source contributions so I'd love to help. I've been coding in Go for couple years now and we're using opensearch-go at my current company. That being said I'm not super familiar with this lib, never had the time to do a deep dive, just some basic usage. But I don't mind learning more about it. I could do 2-4 hours each week.

I'll have a look at PRs listed and see if I can provide some meaningful feedback.

One thing that comes to mind immediately is the size of those larger PRs... 4k+ lines changed? This should be split into smaller tasks IMHO. I suggest to introduce some PR guidelines to avoid this sort of thing.

[rios0rios0]

I'm a Go developer outside Amazon/Hetzner with no current merge rights here, but I'd like to respond to this call for maintainers — and since the four "quick wins" above are all waiting on reviewer attention rather than code changes, I spent some time today going through them.

Today's review pass (all against main at e0832fb):

• Skip shard routing tests on OpenSearch < 2.2.0 with security #819 — approved. Clean test-skip guards for the <2.2.0 + security-plugin OptionalDataException race; CI green, builds and unit tests pass locally. Suggest merging this first since it unblocks the one failing check on Update metrics and error handling docs #812.
• Include _nodes.failures in discovery error messages #823 — approved. Small, focused, well-tested helper (formatFailures) that preserves the errDiscoveryEmpty wrapping. The 5 new subtests cover nil/empty/single/multiple/malformed-JSON cleanly.
• Bump OpenSearch version to recent releases #810 — approved pending a one-line nit: the new CHANGELOG entry references #782 but this is PR Bump OpenSearch version to recent releases #810 (@Jakob3xD flagged the number back in March).
• Update metrics and error handling docs #812 — suggested holding. The doc is excellent, but it documents PolicySnapshot and ConnectionMetric.MCSR, which don't exist on main yet — grep returns zero hits. As @sean- noted, this one depends on Add adaptive max_concurrent_shard_requests for search routing #801 landing first.

Full reviews posted on each PR.

---

If the above is useful, I'd also like to express interest as a potential maintainer:

• How I use opensearch-go: I'm the principal architect of the backend platform at Arancia, where we build DarkSense. We rely on opensearch-go heavily — roughly a dozen Go services in production import github.com/opensearch-project/opensearch-go/v4@v4.6.0 today (indexing, bulk inserts, search/logs repositories, tracker and detector pipelines). The library is on our critical path, so its quality directly affects our production stability.
• Familiarity: Go is my primary language. I maintain several Go OSS projects focused on infrastructure tooling (autobump, gitforge, autoupdate), and at Arancia I lead a multi-service Go backend that is itself a heavy opensearch-go consumer. I'm most comfortable with the opensearchapi surface, Clean Architecture / DI wiring around the client, BDD-style test suites, and CI gating.
• Availability: Realistically about 2 hours/week, ongoing. I won't pretend otherwise — I'm running a large platform day-to-day — but I can make that cadence predictable and I have a genuine long-term stake in this library's health.

Per RESPONSIBILITIES.md this is an expression of interest, not a self-nomination. Happy to prove value as a reviewer first (starting with today's four) and let the existing maintainers decide if that graduates into anything more formal.

[sean-]

Thank you to everyone who has responded here -- it's great to see people stepping up.

@atris, @tender-barbarian -- welcome, and thank you for volunteering time. I'm happy to answer questions on any of the open PRs as you get oriented.

@rios0rios0 -- your review pass on the quick wins was appreciated (and turned up a few things!). Thank you.

@tender-barbarian -- fair point on PR size. The larger outstanding PRs (#801, #804) are big for different reasons: #804 is high line count but repetitive (one core fix applied across 74 methods), and #801 has reasonably complex new functionality. I've tried to sequence things so reviewers can start with smaller PRs and build context before tackling the big ones.

Part of the reason these PRs stack and grow in size is precisely attributable to the time required to get them reviewed and the speed and cadence at which we iterate at work. Instead of forking this project, we've accepted that some of these larger structural changes are self-contained (especially since they're contained within a single package). But I totally appreciate and understand that it's daunting to see larger PRs come down the pike with batched content. If the process were lighter weight and there were fewer outstanding PRs, it would be much more tractable to have smaller, discrete PRs in flight that are easy to review.

That said, I'm open to breaking things down further if it helps -- just let me know which ones feel unwieldy and I'll see what I can do.

Thanks again, all of you. This project is better for having more eyes on it.

[jeevanism]

I would like to chip in though I am not using Go for my daily work I use it side projects. I can help with big fixings, documentation etc

https://github.com/jeevanism/multi-model-rag-platform

https://github.com/jeevanism/genkit-apps

[linzeyan]

I have about three years of experience with Go. I'm not very familiar with opensearch-go yet, but I can dedicate around two hours each day. I'd be happy to help if there's an opportunity.