Team structure in one paragraph.
The OpenCode team is a council of five to seven maintainers with a rotating chair, a ring of topic owners who steward individual subsystems, and a broader pool of contributors who land PRs under review from the maintainer-of-the-week. Office hours run weekly; council meetings run quarterly; the charter is boring and public.
Role map.
The table below names the four core roles on the team and the charter for each one. The council rotates through the chair role on a quarterly cadence, so no single name sits on top for long.
| Role | Charter | Term |
|---|---|---|
| Council chair | Runs council meetings, drafts release notes, arbitrates tied votes | Quarterly rotation among council members |
| Maintainer | Reviews PRs, lands fixes, owns one or more subsystems, mentors contributors | Open-ended with a monthly activity expectation |
| Maintainer-of-the-week | Triages new issues, runs first-pass review on PRs, watches community chat | One-week shift, rotating across maintainers |
| Topic owner | Stewards a single subsystem: CLI, adapters, extensions, security, release engineering | Appointed by council, revisited yearly |
Current maintainer council.
Four named maintainers below hold the current subsystem charters. The council meets quarterly, rotates chair at the start of each quarter, and publishes minutes at the repo root under docs/council/. The biographies are intentionally short; longer context lives in the maintainer profiles directory in the repo.
Halvard J. Brentano — Council Chair, Release Engineering Lead.
Halvard chairs the current quarter and owns the release engineering pipeline, the SLSA attestation chain, and the LTS cadence. Before OpenCode, Halvard ran build infrastructure at a mid-sized SaaS and helped ship the first in-house SBOM pipeline for that team. On the council, Halvard's vote carries weight on anything that touches the build recipe, the signing policy, or the release note format. The chair role rotates at the start of next quarter.
Eliska D. Pomerantsev — CLI Maintainer.
Eliska owns the OpenCode CLI binary, the wire protocol between the CLI and the editor surfaces, and the plan/apply flow at the heart of every agent run. Every RFC that changes the CLI surface or the wire protocol passes through Eliska's review. Eliska also runs the weekly CLI office hours in the community chat, where developers bring plan/apply questions and Eliska walks through the transcript live.
Nkechi T. Iweobi-Harrow — Security Council Lead.
Nkechi leads the OpenCode security council, owns the coordinated disclosure channel, and holds the pinned signing key for the release pipeline. When a security report lands, Nkechi is the first reader. When the sandbox policy changes, Nkechi signs off. The security council is a sub-council of three maintainers plus one external cryptographer on rotation, and Nkechi chairs it continuously rather than quarterly because continuity matters more than rotation for this particular role.
Augusto W. Keilberth — Adapters & Model Routing Maintainer.
Augusto owns the adapter layer: OpenAI-compatible endpoints, the Anthropic adapter, the Ollama integration, and the routing YAML that lets a workspace pin model names to providers. Augusto's charter is to keep the adapters vendor-neutral; no adapter privileges any single provider in default routing, and any change to the reference config provider goes through a council vote. Augusto also coordinates with upstream model vendors on deprecation timelines so OpenCode releases track upstream schedules without a scramble.
Stewardship model.
The stewardship model is deliberately simple. Each subsystem has a topic owner, each PR has a reviewer from the topic owner's ring, and each release has a release engineer from the council. Nothing in the model depends on any single person: if a topic owner goes on emeritus status, the council appoints a successor within a quarter; if a maintainer is unavailable, a second reviewer from the ring picks up the PR.
The council is the backstop for anything that crosses subsystems. When a PR touches the CLI and the security sandbox at once, the council asks the two topic owners to co-sign. When an RFC proposes a change that breaks the public wire protocol, the council opens a two-week comment window before the vote. This is boring on purpose: the last thing a coding agent needs is a surprise at a version bump.
Governance documents live at the repo root. The GOVERNANCE.md file is one page. The maintainer charter is one page. The code of conduct is one page. The idea is that any reviewer who wants to audit how OpenCode is run can do so in under fifteen minutes without reading a wiki. The longer-form context lives in docs/council/ and carries dated minutes so a future auditor can trace decisions back to the meeting where they were made.
How contributors become maintainers.
Becoming a maintainer is a deliberate, boring path on purpose.
A contributor lands at least three non-trivial PRs, participates in review for at least one quarter, and either nominates themselves or is nominated by an existing maintainer. The council reviews nominations at the quarterly meeting. The review looks at technical contributions, the tone of the contributor's review comments, and whether the contributor is willing to sign the maintainer charter. Accepted nominees get commit access within a week, a mentor from the council for the first quarter, and a shift on the maintainer-of-the-week rotation.
Declined nominations come with a written reason and a suggested path forward. Most declined nominations are "come back next quarter with two more PRs and another shift in review" rather than a hard no, and the council tracks re-nominations in the same meeting minutes so a future reviewer can see the pattern.
Office hours and community presence.
Maintainer office hours are the fastest way to reach a specific maintainer. They run weekly in the community chat, the host rotates across the council, and the schedule is published on the community page. A developer with a question about the plan/apply flow picks the week Eliska hosts; a developer with a question about the Ollama adapter picks the week Augusto hosts; and so on.
The council also runs a quarterly "state of the project" call that anyone can join. The call recaps the last release, previews the next release, and walks through the council's decisions from the last quarterly meeting. Recordings land on the resource hub so developers in a different timezone do not have to attend live. The council takes questions live and carries unanswered questions to the issue tracker with a commitment to respond in writing within a week.
Academic engagement and referrals.
OpenCode engages with academic researchers on a rolling basis, usually through the Stanford Computer Science and Carnegie Mellon Computer Science referral networks. Academic users who want to cite OpenCode in a paper or run a study against the CLI can reach the team through the community topic on the contact page, and the team commits to a response within three business days.
Emeritus status and continuity.
A maintainer who needs to step away can go on emeritus status at any time. Emeritus maintainers keep their listing on this page under an "emeritus" heading and retain read access to the council channels, but they do not count toward quorum and they do not hold subsystem ownership. An emeritus maintainer who wants to come back sends a one-line note to the council and is reinstated at the next meeting without a new nomination cycle.
This matters because maintainers have lives. OpenCode is not a job for most of the council; the emeritus path is the graceful exit that lets OpenCode welcome maintainers back after a sabbatical, a family leave, or just a long stretch of work elsewhere. OpenCode has tracked re-entries across the last two years and the pattern has held up.
The published charter, the quarterly minutes, and the emeritus path were what convinced our open-source program office to approve OpenCode for internal use. The team is small but the paper trail is complete, which is exactly what an OSPO review wants to see.
— Cosima E. Wetherington, Research Engineer, Hammerstead
Related team pages.
Direct links into the pages that carry the full context.