What/Why
Over the past year, we’ve encountered multiple cases of OpenSearch repositories entering a low-maintenance state due to a lack of active maintainers. This has manifested in several ways:
- Stale or non-responsive maintainers
- Growing backlog of issues and PRs
- Community contributors experiencing lack of engagement
- Difficulty onboarding new maintainers due to unclear or blocked processes
Two recent examples highlight the pattern:
- k8s-operator (surfaced ~September 2025) – resolved through ad-hoc intervention
- opensearch-net (surfaced ~March 2026) – currently ongoing, led by @epugh
In the k8s-operator case, the issue was ultimately resolved by adding new maintainers synhershko, and transitioning inactive maintainers to emeritus status. However, this required significant manual coordination (Slack DMs, meetings) and lacked a clear governance framework. More on that below.
What problems are you trying to solve?
These cases expose gaps in governance and operational oversight:
- No systematic tracking of repository health
- No defined process for handling inactive/stale maintainers
- Friction in promoting contributors to maintainers
- Lack of clear ownership/escalation path when repos degrade
This results in delayed responses, contributor frustration, and potential risk to project sustainability.
What are you proposing?
I’d like to propose that the TSC consider formalizing the following:
- Repository Health Tracking
- Define and monitor key health metrics (e.g., PR/issue backlog, response SLAs, maintainer activity)
- Leverage tools such as LFX Insights for visibility and trend analysis
- Establish thresholds and alerting for at-risk repositories
Reference metrics example for k8s-operator:
https://insights.linuxfoundation.org/project/opensearch-foundation/development?repos=opensearch-project-dashboards-search-relevance,opensearch-project_opensearch-k8s-operator&timeRange=alltime
- Maintainer Lifecycle Governance
- Define criteria for identifying inactive/stale maintainers
- Establish a formal process for transitioning maintainers to emeritus status
- Ensure this process can proceed even when current repo leadership is inactive
- Contributor → Maintainer Promotion Path
- Define clear, transparent criteria for promotion
- Streamline nomination and approval
- Reduce dependency on unavailable maintainers for approvals
- TSC Liaison Model
- Assign a TSC member (or delegate) per repository or domain
- Provide lightweight oversight and periodic check-ins
- Serve as an escalation point when repo health deteriorates
This is a meta issue, which is likely to map to several PRs to address the various aspects.
Alignment with Industry Practices
These recommendations follow known open source governance models, such as:
Apache Software Foundation
- Project Management Committees (PMCs) with clear ownership
- Defined contributor ladder (Committer → PMC)
- Emeritus status for inactive members
- Ability to act despite maintainer inactivity
Cloud Native Computing Foundation
- Maintainer guidelines and contributor ladder frameworks
- Project health tracking via DevStats / LFX Insights
- Structured oversight (SIGs, TOC) and escalation paths
Other mature projects (e.g., Kubernetes, Prometheus, OpenTelemetry)
- OWNERS files and explicit review responsibilities
- Lazy consensus and escalation mechanisms
- Periodic maintainer activity review
Case Study: k8s-operator
7 out of 8 maintainers were inactive, contributions got stuck, and backlog increased.
Supporting repo health metrics from LFX Insights: https://insights.linuxfoundation.org/project/opensearch-foundation/development?repos=opensearch-project-dashboards-search-relevance,opensearch-project_opensearch-k8s-operator&timeRange=alltime
Resolution required high-touch coordination, including slack discussions and direct outreach and meetings with multiple stakeholders, and the following github issues:
Maintainer changes included:
- Transition to emeritus: idanl21 ido-opster dbason swoehrl-mw jochenkressin pchmielnik salyh
- Active maintainer retained: prudhvigodithi
- New maintainer added: synhershko
The process resulted with renewed activity in the repo, addressing of outstanding backlog issues, and the 3.0 release of the OpenSearch Kubernetes Operator and registration of the operator in operatorhub.io, led by the new maintainer @synhershko.
While successful, this process does not scale and highlights the need for formal governance.
What will it take to execute?
I’d like to bring this to the TSC for discussion on whether this is a priority area, and forming of a working group to discuss and come up with a lightweight governance proposal to address.
Any remaining open questions?
As OpenSearch continues to grow, ensuring repository health and maintainership continuity is critical to sustaining community trust and contribution velocity. Formalizing these processes would reduce friction, improve transparency, and strengthen the project overall.
What/Why
Over the past year, we’ve encountered multiple cases of OpenSearch repositories entering a low-maintenance state due to a lack of active maintainers. This has manifested in several ways:
Two recent examples highlight the pattern:
In the k8s-operator case, the issue was ultimately resolved by adding new maintainers synhershko, and transitioning inactive maintainers to emeritus status. However, this required significant manual coordination (Slack DMs, meetings) and lacked a clear governance framework. More on that below.
What problems are you trying to solve?
These cases expose gaps in governance and operational oversight:
This results in delayed responses, contributor frustration, and potential risk to project sustainability.
What are you proposing?
I’d like to propose that the TSC consider formalizing the following:
Reference metrics example for k8s-operator:
https://insights.linuxfoundation.org/project/opensearch-foundation/development?repos=opensearch-project-dashboards-search-relevance,opensearch-project_opensearch-k8s-operator&timeRange=alltime
This is a meta issue, which is likely to map to several PRs to address the various aspects.
Alignment with Industry Practices
These recommendations follow known open source governance models, such as:
Apache Software Foundation
Cloud Native Computing Foundation
Other mature projects (e.g., Kubernetes, Prometheus, OpenTelemetry)
Case Study: k8s-operator
7 out of 8 maintainers were inactive, contributions got stuck, and backlog increased.
Supporting repo health metrics from LFX Insights: https://insights.linuxfoundation.org/project/opensearch-foundation/development?repos=opensearch-project-dashboards-search-relevance,opensearch-project_opensearch-k8s-operator&timeRange=alltime
Resolution required high-touch coordination, including slack discussions and direct outreach and meetings with multiple stakeholders, and the following github issues:
Maintainer changes included:
The process resulted with renewed activity in the repo, addressing of outstanding backlog issues, and the 3.0 release of the OpenSearch Kubernetes Operator and registration of the operator in operatorhub.io, led by the new maintainer @synhershko.
While successful, this process does not scale and highlights the need for formal governance.
What will it take to execute?
I’d like to bring this to the TSC for discussion on whether this is a priority area, and forming of a working group to discuss and come up with a lightweight governance proposal to address.
Any remaining open questions?
As OpenSearch continues to grow, ensuring repository health and maintainership continuity is critical to sustaining community trust and contribution velocity. Formalizing these processes would reduce friction, improve transparency, and strengthen the project overall.