The TSC and Project Governance

Every prior chapter has shown you a piece of self-organizing machinery: maintainers approve PRs, a release manager runs a train, consensus forms on issues. This chapter is about the layer above all of that — who decides the direction, who admits a new project into the org, and who owns the trademark. OpenSearch is governed by the OpenSearch Software Foundation under the Linux Foundation, with technical direction set by a Technical Steering Committee (TSC). None of this is the Apache model; there is no PMC and no board-of-an-ASF.

This is the governance mirror of the contributor maintainership chapter: that chapter was your path up; this one is the structure you are climbing into.

A Short History: AWS-Stewarded → Linux Foundation

The move to the Linux Foundation in September 2024 matters because it makes the project vendor-neutral: the trademark, the assets, and the governance no longer sit with a single company. For a contributor, the practical effect is that direction is set by a chartered committee in the open, not by any one employer.

Note: The Linux Foundation provides the legal and IP home (trademark, the foundation entity, neutral governance). The TSC provides technical direction. These are two different bodies with two different jobs — don't conflate them.

The Technical Steering Committee

The TSC is the project's technical governing body. Think of it as the layer that handles what no single repo's maintainers can decide on their own.

Composition

The TSC is a chartered group of senior contributors/maintainers drawn from across the project (historically multi-company since the LF move). Membership and the charter are documented in the project's governance repository and .github/community docs. It is small enough to decide and broad enough to represent the major subsystems.

What the TSC Decides

What the TSC does not do: review your individual PR, run the day-to-day of any one repo, or merge code. That is maintainer work.

Maintainers vs. the TSC

The two layers have clean, complementary jobs. Confusing them is the most common governance misunderstanding.

Most of what you experience as a contributor is maintainer authority. The TSC only enters your world when your work is cross-cutting enough to need project-level alignment — a new subsystem, a policy change, a new plugin joining the org.

How Decisions Escalate

flowchart TD
    A[Contributor opens issue/PR] --> B{Contained in one repo?}
    B -->|Yes| C[Maintainers decide on the issue/PR]
    B -->|No: spans repos or sets policy| D[RFC issue + community meeting]
    D --> E{Resolved by aligned maintainers?}
    E -->|Yes| F[Recorded on the issue, implemented]
    E -->|No / project-level| G[TSC]
    G --> H[TSC decision recorded in governance/issue]
    H --> F

The escalation principle is as local as possible: decisions are made at the lowest level that can make them. A bug fix is decided by the area maintainer. A new aggregation type is an RFC the search maintainers align on. A change to the project's BWC policy, or admitting a new plugin, reaches the TSC. You rarely send something to the TSC directly — a maintainer or the discussion routes it there when it genuinely needs project-level authority. The output is always written down (an issue, the governance docs), because, as everywhere in OpenSearch, a decision isn't real until it's recorded (see communication channels).

How a New Project or Plugin Joins the Org

OpenSearch is an organization of many repos, and it grows. Adding a new plugin or repo to opensearch-project — especially one that will ship in the bundle — is a TSC-level admission, because it commits the project to maintaining it, releasing it on the train, and standing behind its compatibility.

The shape of that process:

1. Proposal as an RFC describing the project, its scope, why it belongs in the org, maintainership, and licensing (must be Apache-2.0 with clean dependency licensing — see licensing).
2. Community and maintainer discussion on the RFC and in community meetings.
3. TSC review and decision on admission, including bundle inclusion and release commitments.
4. Onboarding: the repo joins the org with its own MAINTAINERS.md, CONTRIBUTING.md, SPDX headers, CHANGELOG discipline, and a slot in the opensearch-build manifests if it ships in the release (release process).

This is the formal counterpart to the casual reality that most features just need maintainer alignment. Whole projects need the TSC.

Trademarks and Branding (High Level)

The OpenSearch trademark is held by the foundation (post-LF, vendor-neutrally). You do not need to be a trademark lawyer, but two practical facts matter for a contributor:

• Use the name correctly. "OpenSearch" refers to this project; downstream products that embed it must follow the trademark/branding guidelines and not imply official endorsement.
• The trademark's neutral home is part of why the LF move happened. Holding the mark in a foundation rather than a company is what makes "OpenSearch" a community asset rather than a single vendor's product name.

For anything beyond "use the name as the project intends," consult the project's trademark and branding guidelines — this chapter is orientation, not legal advice.

The Ladder: Contributor → Maintainer → TSC

The path is earned, visible, and the same one this whole section has been preparing you for.

flowchart LR
    A[Contributor] -->|sustained quality PRs, reviews, trust| B[Maintainer]
    B -->|cross-project leadership, stewardship| C[TSC member]

Each rung is built on the one below it. You become a maintainer by behaving, over months, like the kind of contributor maintainers trust — focused PRs, good tests, compatibility awareness, helpful reviews, responsiveness. That is exactly the trust-building covered in the next chapter, and the maintainership mindset covered in the contributor section. The TSC rung, in turn, is built on having been a maintainer who reliably did the right thing for the project, not just one repo.

Note: Nobody is hired into maintainership for OpenSearch by writing one brilliant PR. The rung is granted for a track record — many PRs, many reviews, demonstrated judgment. Optimize for the track record, not the single heroic change.

Prove You Understand This

1. What changed about OpenSearch governance in September 2024, and why does vendor-neutrality matter to a contributor?
2. Distinguish the Linux Foundation's role from the TSC's role. Which one owns the trademark; which one sets the BWC policy?
3. Give two decisions a per-repo maintainer makes and two that escalate to the TSC.
4. Describe the escalation path for a change that spans three repos and proposes a new project-wide policy.
5. Outline how a new plugin gets into the opensearch-project org and the bundle, including the licensing precondition.
6. Lay out the contributor → maintainer → TSC ladder and what is earned (not granted) at each step.

Next: Licensing, SPDX Headers, and the Apache 2.0 Story — the legal bedrock the whole project, and every admission, stands on.