OpenClaw's public maintainer map: who signs releases, and what we can verify

OpenClaw's release pages put a lot of names in front of you. The 2026.9.4 release records 20 direct commits, 1,558 pull requests, and 294 contributors. It also shows GitHub Actions as the publishing account and attributes the verified tag signature to Vincent Koc. That raises a practical question: who is actually maintaining the project, and who is only being credited for a change?

The short answer is a map, not a single name. OpenClaw publicly identifies a Foundation staff, a separate group of Core Maintainers, and a much larger contributor community. Vincent Koc has the clearest person-level link between the current roster and a specific release signature. Peter Steinberger remains identified as the creator and as a person making important technical calls, but the current maintainer pages do not support calling him the sole release owner.

This profile follows the pages available on 13 September 2026. It is about public responsibility and release evidence, not private employment records or a biography.

A maintainer is not the same as a contributor

A contributor can author a pull request, fix a documentation line, or appear in a release's thanks list. A maintainer has an ongoing responsibility for review, triage, architecture, or release work. The labels overlap, but they answer different questions.

The OpenClaw Foundation people page separates those signals. It names the full-time Foundation team, a Core Maintainers group, and community contributors. The project's contribution guide points readers to that page for the current team and says maintainers are expected to triage issues, review pull requests, and help move the project forward.

The different counts matter. The people page says more than 3,324 community contributors have shipped code into OpenClaw, while the 2026.9.4 page counts 294 contributors for that release. Neither number is a maintainer count. A name in the larger group is evidence of contribution, not automatic evidence of merge or release authority.

The Foundation team is the release institution

The repository's current README says OpenClaw is developed in the open by the OpenClaw Foundation and the community. It also says the Foundation employs the core team and signs releases. That is the clearest public statement about the institution behind publication, even though it does not name every person who participates in a release.

The Foundation's 8 July 2026 announcement describes the first full-time team as people drawn from the OpenClaw community. It also distinguishes that staff from volunteer maintainers and the wider group of contributors. In other words, the project describes maintenance as paid and volunteer work around a Foundation, not as a founder working alone.

The current people page publishes these Foundation roles:

That table is a role map, not a claim that every person in it maintains code. The engineering entries are directly relevant to software work. The operations entries describe governance, partnerships, hiring, finance, and staff coordination. Those jobs can support release continuity without making their holders code reviewers.

Peter Steinberger sits in a different category. The official credits page names him as creator. The Foundation announcement says he continues to make especially important technical calls. The current people page, however, does not place him in its Foundation staff or Core Maintainers sections. That is why “creator and technical steward” is a defensible description, while “the person behind every release” is not.

The Core Maintainers group

The Foundation describes Core Maintainers as people who review pull requests, guide architecture, and keep the codebase healthy. It says they contribute on behalf of themselves and the companies building on OpenClaw. The displayed affiliations make the group easier to understand, but they do not transfer project ownership to those companies.

The published roster is:

This is useful corroboration of public project roles, but it is still a Foundation-published roster. It is not an external employment check, and it does not assign each maintainer a component or an approval limit. The safest reading is that these people are publicly designated as part of the project's review and architecture circle.

Vincent Koc has the clearest release trail

The public evidence for Vincent Koc connects three separate records. The people page calls him Chief Architect. The credits page associates him with agents, telemetry, hooks, and security. Then the 2026.9.4 GitHub release shows the tag's verified signature under the Vincent Koc account, while GitHub Actions appears as the account that released it.

The same release record includes @vincentkoc in its contributor acknowledgements. It also credits other people who appear in the Foundation roster, including Patrick Erichsen and Vyctor Brzezowski. Those cross-links show real participation in the release's change set. They do not prove that every credited person reviewed the release, or that Vincent Koc acted as the only release manager.

The distinction between publisher and signer is worth keeping. GitHub Actions tells us that automation performed the publication action. The verified signature ties the tag to a named signing identity. Neither fact, by itself, reveals who approved the candidate, who inspected the complete artifact set, or who could recover a failed publication.

The release process leaves an intentional gap

OpenClaw's release policy describes four user-facing channels: stable, extended-stable, beta, and dev. It says maintainers normally cut releases from a dedicated release branch. It also describes separate publication paths for packages, plugins, Docker images, and native applications.

The policy is unusually clear about what it does not publish. Detailed approvals, credentials, and recovery notes remain in a maintainer-only runbook. The public checklist is the shape of the process, not the list of people authorized to operate every step. It even refers to separate plugin and core package publication owners without naming them.

That gap is not evidence of a hidden arrangement. It is a limit on the public record. The sources support a distributed maintenance model with Foundation staff, Core Maintainers, automation, and contributors. They do not support a complete statement such as “these three people approve every stable release.”

Security and routing are maintenance work too

The repository's security policy says security work is shared across OpenClaw maintainers, including engineers and security researchers from organizations such as NVIDIA and Tencent. It directs researchers to report privately, either through the repository where the issue lives or through the security email address used for routing.

The contribution guide adds another boundary: do not guess whom to tag. Issue forms, labels, automation, and .github/CODEOWNERS are supposed to route work. A maintainer should be mentioned when an owned path or documented responsibility needs a decision.

Those instructions tell an operator something important. The project treats routing and security response as part of maintenance, but the public roster is not a substitute for the routing system. A person may be a Core Maintainer without being the right contact for a particular security report.

How to check a release before relying on it

For a concrete due-diligence check, start with four items: the exact version tag, its GitHub release page, the current people page, and the release policy available on the date of review. Save those links with the version you evaluated. A changing roster can make an old conclusion look current when it is not.

1. Open the exact release and record its publication account, tag signer, commit, publication date, and contributor list.
2. Match any human signer or credited handle against the Foundation people page, credits page, or an official profile linked from those pages.
3. Read the release policy for the channel involved. Stable, beta, and extended-stable publication have different paths, so do not generalize from one tag.
4. Separate contribution from approval. A person thanked for a pull request may not have reviewed the final release, and a release signer may not have authored the change.
5. Record the unanswered questions. If you need named approvers, signing-key custody, or recovery authority, ask the project directly; the public runbook does not provide those details.

Proposed paperwork test. Pick one release, build this evidence chain, and see whether every conclusion can be tied to a page or a displayed signature. This is a verification exercise, not a hands-on software test. It can clarify responsibility. It cannot prove that the binary is safe or that the release process was followed perfectly.

Failure paths and limits

• Automation looks like a person. A GitHub Actions publisher may publish the release while a human identity signs the tag. Treat those as separate events.
• A contributor list looks like a maintainer list. Release thanks show participation. They do not show merge rights, review responsibility, or access to credentials.
• An affiliation looks like authority. The Foundation displays employer labels, but that does not mean the employer owns OpenClaw or directs the person's project decisions.
• An old roster looks current. Use the access date and exact tag. Maintainer pages can change without changing historical release metadata.
• A signature looks like a full audit. A verified tag signature supports provenance for that tag. It does not prove that every dependency, installer, package, or recovery step was independently checked.

What can be verified today

OpenClaw publicly documents a Foundation staff, a Core Maintainers group, and a large contributor community. It publishes names and displayed roles for the first two groups. The README says the Foundation employs the core team and signs releases. The release policy explains the publication shape while keeping credentials and detailed approvals private.

Vincent Koc is the clearest individual release link in the sources reviewed: Chief Architect on the people page, credited for agents, telemetry, hooks, and security, and the verified signer shown on the 2026.9.4 tag. Peter Steinberger is publicly identified as creator and technical steward, not as a complete substitute for the current maintainer network.

That is enough to describe how the project is maintained in public. It is not enough to publish a definitive list of every release approver or to claim that one person controls OpenClaw. For adoption or incident review, the exact tag, the release policy, and the current routing instructions are more reliable than a founder's name or a long contributor list.

Sources

• The people building OpenClaw | OpenClaw Foundation
• Contributing to OpenClaw
• Release openclaw 2026.9.4 | openclaw/openclaw
• Release policy | OpenClaw
• OpenClaw repository README
• Credits | OpenClaw
• OpenClaw security policy
• Introducing the OpenClaw Foundation