Joining the OpenSearch Technical Steering Committee and Ambassador Program

This year I was elected to the OpenSearch Technical Steering Committee (TSC) and named a 2026 OpenSearch Software Foundation Ambassador. The two roles sound similar from the outside, but they sit on opposite sides of the project. One is about how the code gets built and the other is about how people find, learn, and adopt it. This post covers what each role actually involves and why I think both matter to anyone running OpenSearch in production.

Some context on governance

OpenSearch moved to the OpenSearch Software Foundation in September 2024, as a project of the Linux Foundation. That move separated two kinds of decision-making. A governing board handles budget, events, and the business side of the foundation. Technical direction belongs to the TSC, which replaced the older OpenSearch Leadership Committee when the foundation was formed.

The split matters because it means the people deciding what goes into the code are contributors to the code. The project’s technical charter gives the TSC responsibility for all technical oversight of the project, and it says TSC meetings are intended to be open to the public.

What the Technical Steering Committee does

The charter lists the TSC’s responsibilities, and they read like the list of things that decide whether a large open source project stays coherent.

• Coordinating the technical direction of the project across its repositories.
• Approving proposals to incubate, deprecate, or change the scope of sub-projects.
• Creating working groups for technical issues that cut across projects.
• Setting community norms, release processes, and security reporting policies.
• Seeking consensus, and voting when needed, on technical matters that affect multiple projects.

That last item is where much of the real work happens. OpenSearch is not one repository. It is the core engine, Dashboards, Data Prepper, the k-NN and neural search plugins, ML Commons, the migration tooling, and dozens of other repositories maintained by different people at different companies. A change in one place often has consequences somewhere else, and the TSC is where those tradeoffs get discussed in the open. The committee has also chartered technical advisory groups for build, observability, security, and search.

How the seats are filled

The TSC has 15 seats, and every member now holds an elected two-year term. The process is written down in the repository’s ELECTIONS.md. Candidates have to be active maintainers or contributors who have shown technical leadership in the project, and each one submits a statement describing their contributions and where they want to take the project.

No more than five seats can be held by employees of the same organization. The current member list includes people from AWS, Apple, SAP, IBM, Uber, and several smaller companies, plus independents like me. That diversity is a core strength of OpenSearch.

Privacy as a cross-project concern

My candidate statement was about privacy across the OpenSearch ecosystem. Search and analytics clusters end up holding some of the most sensitive data an organization has, including logs full of user identifiers, support tickets, clickstreams, and documents that describe people in detail. Every plugin, ingest pipeline, and dashboard that touches that data makes a privacy decision, whether or not anyone thought of it that way. I want privacy to be something the project considers across repositories rather than something each team bolts on afterward.

That focus comes straight out of my own OpenSearch work. I’m a maintainer on User Behavior Insights, which captures how users search and what they click so teams can measure search relevance. That data is valuable precisely because it is behavioral, which is also what makes it sensitive. My OpenSearchCon talk on local differential privacy for UBI was about collecting it without having to trust the collector. My entry in the Agent Skills Hackathon handled right-to-be-forgotten requests against an OpenSearch index, where the hard part is finding the documents that describe a person without naming them. I’m also a maintainer on opensearch-migrations, and moving a cluster is one of the moments when data handling gets tested hardest.

I also come to the committee as a consultant rather than as an employee of a vendor. I spend my days inside other people’s clusters, which means I see the problems teams hit after the release notes are written, and compliance questions under regulations like GDPR come up in those engagements far more often than they come up in feature discussions. That perspective is what I want to represent on the TSC.

What an OpenSearch Ambassador does

The ambassador program is run by the foundation and recognizes people who grow the OpenSearch community outside the code. In the program’s own words, ambassadors “help others learn, create, and collaborate by sharing expertise, supporting community members, and representing OpenSearch around the world.” The 2026 ambassador badge is issued through the Linux Foundation.

In practice that means the work I already do in public. I speak at conferences like OpenSearchCon, most recently on using local differential privacy with UBI. I write posts like the ones on this blog about hybrid search, neural sparse search, and agent skills. I also answer questions from teams trying to figure out whether OpenSearch fits their problem. My listed focus areas in the program are search and analytics and machine learning, which is where most of that writing and speaking already lands.

The ambassador role also runs in the other direction. Ambassadors hear directly from users at meetups and in consulting engagements, and part of the job is carrying that feedback back into the project. For me that loop is short, since I can raise a recurring user problem at the TSC myself.

How the two roles fit together

The TSC is about where the project goes and the ambassador program is about who comes along. Put together, they form a loop that I think is healthy for an open source project. Talking with users surfaces the problems that matter, the committee decides which of those the project should solve, and the resulting features become the next round of talks and posts. I have spent a long time on the contributor side of that loop. At the first OpenSearchCon in 2022 I gave a talk on getting the most from your OpenSearch contributions. These two roles let me work on the rest of the loop.

What this means if you run OpenSearch

For teams building on OpenSearch, the practical value is context. I follow the roadmap discussions, proposals, and deprecations as they happen rather than after they land in a release. That helps when you are deciding whether to build on a feature that is still experimental, planning an upgrade across major versions, or choosing between a plugin and a custom approach. I can also tell you when OpenSearch is not the right tool, which is part of the job too.

If your team is working on privacy and compliance in OpenSearch, search relevance, a migration, or getting more out of a cluster you already have, I would be glad to talk it through. And if you want to get involved with the project yourself, the TSC meeting minutes and the OpenSearch Slack are good places to start.