Project Governance and the AWS Team

This is the chapter that decides how you should set your expectations. Every other chapter in this section describes machinery you operate; this one describes who owns the machinery and why — and the answer reshapes the entire arc of an external contributor's involvement. Firecracker is single-vendor governed. A dedicated AWS team maintains it as production infrastructure. There is no foundation, no Technical Steering Committee, no GOVERNANCE.md, no chartered cross-vendor body, and no public ladder of community committers you climb onto and eventually vote on releases. The merge button, the release, and the roadmap belong to AWS.

This is not a complaint and not a discouragement — it is the map. Plenty of external contributors do excellent, valued, sustained work on Firecracker. But the shape of influence is different from a foundation project, and a contributor who expects the OpenSearch or Kubernetes ladder and doesn't get it will conclude, wrongly, that the project is hostile. It isn't. It's just a different model, and this chapter is the honest version of it.

Note: This is the governance mirror of the maintainership chapter. That chapter is your path up; this one is the structure you are climbing into — and the realistic ceiling of that climb under single-vendor governance.

Single-Vendor vs. Multi-Stakeholder: The Core Contrast

Hold Firecracker next to the foundation model you may know (the OpenSearch curriculum documents that model in detail) and the differences are stark:

cd ~/fc-src
# The two governance artifacts that DO exist. Read both fully (verify on your branch):
sed -n '1,80p' CHARTER.md       # the project's stated scope and how it's run
sed -n '1,80p' MAINTAINERS.md   # who the maintainers are and what areas they own
# Confirm what does NOT exist:
ls GOVERNANCE.md 2>/dev/null || echo "no GOVERNANCE.md — single-vendor, by design"

CHARTER.md tells you the scope — what Firecracker is for and, by implication, what it will refuse (maintainer-mindset.md). MAINTAINERS.md tells you who decides. Between them you have the whole governance surface; there is no third document where the "real" rules live.

How Decisions Are Made

Without a committee, decisions are made the way a well-run engineering team makes them: the relevant maintainer (often the de facto owner of the area the change touches) decides, in the open, on the GitHub issue or PR, and writes the reasoning down. For most changes that is the whole story. For larger or cross-cutting decisions, the AWS team aligns internally and surfaces the outcome publicly.

flowchart TD
    A[Contributor opens issue/PR] --> B{Routine, contained change?}
    B -->|Yes| C[Area maintainer decides on the issue/PR, in public]
    B -->|No: new feature, format, device, scope question| D[Raised as a design-proposal issue first]
    D --> E[AWS maintainer team aligns - often partly internal]
    E --> F[Decision + reasoning recorded publicly on the issue]
    F --> G{Accepted?}
    G -->|Yes| H[Guidance given; contributor implements]
    G -->|No| I[Reasoning recorded; do not just open a PR anyway]

Two honest observations about this flow versus a foundation project:

• Some alignment happens inside AWS, not in public. Unlike OpenSearch — where the design discussion is required to be on a public issue — a single-vendor team can and sometimes does converge internally and then post the outcome. You see the decision and its reasoning; you may not see the whole deliberation. This is the structural reality, not a failure of openness, and pressing for the internal back-and-forth rarely helps.
• There is no body to appeal to. No TSC to escalate a maintainer disagreement to, no board, no vote. If the maintainers decline your design, the recorded reasoning is the final word. Your recourse is to reshape the change to fit, or to land it downstream / in rust-vmm.

The rust-vmm Contrast: A Different Governance Right Next Door

The most important thing to understand about Firecracker's governance is the project sitting right beside it with the opposite model. rust-vmm — the shared crates (kvm-ioctls, kvm-bindings, vm-memory, linux-loader, vm-superio, event-manager, vmm-sys-util, vm-fdt) that Firecracker is built on — is community-governed across multiple vendors (AWS, Intel, Red Hat, and others), shared with Cloud Hypervisor and other VMMs. It has its own maintainers, its own per-crate governance, and a genuinely multi-stakeholder process.

cd ~/fc-src
# The boundary: what FC consumes from rust-vmm (community-governed) vs maintains in-tree (AWS-governed):
rg -n "kvm-ioctls|kvm-bindings|vm-memory|linux-loader|vm-superio|event-manager|vmm-sys-util|vm-fdt" Cargo.toml

This is why the maintainer mindset so often redirects generic VMM machinery upstream to rust-vmm: not only does the logic get one shared home, but it lands in a project where you can actually become a maintainer through the normal route. For an external contributor who wants formal standing and merge rights, rust-vmm is the higher-ceiling target, and contributing there is also the most credible way to build the track record that makes the Firecracker team trust your judgment. See the rust-vmm section and lab-r4.

What "Ownership of an Area" Means for an External Contributor

You will very likely never be handed the Firecracker merge button if you're not on the AWS team. But that is not the only — or even the most valuable — form of influence, and fixating on the formal title misreads how this project actually distributes trust. The achievable and genuinely powerful goal is to become the trusted external expert on an area:

• The person whose reviews the maintainers weight heavily on PRs touching "their" subsystem (say, the block device, or the rate limiter, or the boot path).
• The person whose design input shapes that subsystem, who gets consulted before changes land in it.
• The person whose PRs are approved quickly because their track record is impeccable and their attack-surface/compatibility judgment is proven.

That is real ownership — de facto, not de jure — and it is fully achievable for a non-AWS engineer. It is, frankly, most of what formal maintainership is anyway: trust, expressed as the weight your word carries. The title is rarer here; the substance is not.

cd ~/fc-src
# See who reviews what — the de facto ownership map is in the PR history, not just MAINTAINERS.md:
gh pr list --state merged --limit 30 --json number,title,reviews \
  --jq '.[] | {number, title}' 2>/dev/null | head
# Find the area you could own by reading who consistently reviews it:
gh pr list --state merged --search "block in:title" --limit 15

The Realistic Ceiling — and How to Push It

Be clear-eyed, then be ambitious within the truth:

The ceiling: Formal core-maintainer status — a line in MAINTAINERS.md with merge rights — is rare for non-AWS contributors, because the core team is AWS-staffed and Firecracker is run as AWS production infrastructure. Expecting to be voted onto a committee and handed merge rights, foundation- style, will leave you disappointed because that mechanism does not exist here.

How you push it anyway — concretely, in order of leverage:

1. Build an impeccable track record in one coherent area. Not scattered one-off PRs; a sustained stream in, say, virtio-block or snapshotting, each one scoped, signed off, integration-tested, attack-surface-conscious, compatibility-aware (code-style-trust.md).
2. Review others' PRs in that area, well. Reviewing is how you demonstrate the judgment that maintainership is. The contributor whose reviews catch real problems becomes the contributor whose reviews the maintainers wait for.
3. Propose designs as issues first, and take "no" gracefully (communication-channels.md, maintainer-mindset.md). The maintainers remember who litigated a clean rejection and who absorbed it and came back with a better-shaped change.
4. Contribute upstream to rust-vmm, where the ceiling is genuinely higher and the same work earns formal standing — which then feeds back as credibility on the Firecracker side.
5. Be relentlessly security- and compatibility-aware. At a project whose entire value is a small, safe attack surface, the contributor who is visibly careful about the threat model and the snapshot/API contracts earns trust fastest.

The honest summary: under single-vendor governance you push the ceiling not by climbing a formal ladder but by becoming so trusted, in a specific area, that your de facto authority approaches a maintainer's — and by taking the rust-vmm path where a formal ladder actually exists. That is a slower, quieter ascent than a foundation project's, and it is real.

Prove You Understand This

1. List four concrete differences between Firecracker's governance and a foundation (LF/Apache) model. Which governance documents exist, and which conspicuously does not?
2. How are decisions made without a TSC? What can you see, and what might happen inside AWS that you can't?
3. Why is there "no body to appeal to," and what are your two real options when a design is declined?
4. Contrast Firecracker's governance with rust-vmm's. Why is rust-vmm the higher-ceiling target for an external contributor who wants formal standing?
5. Define "ownership of an area" as a de facto status. Why is it most of what maintainership actually is, even without the title?
6. State the realistic ceiling for a non-AWS contributor honestly, then give the concrete, ordered way to push it.

Next: Licensing and the DCO — the legal bedrock every contribution, under any governance, has to stand on.