The Firecracker Contributor Mindset

The Levels teach you the mechanics — how to build Firecracker with tools/devtool, trace an API request to a KVM_RUN exit, write a virtio device, instrument the boot path. This section teaches you the behavior and judgment that turns a working diff into a pull request the AWS maintainers will spend two approvals on, and — over months and years — into the standing to own an area of the codebase.

These are not soft skills. They are the difference between two contributors who write identical code. One opens a scoped, signed-off PR with an integration test, a CHANGELOG entry, and a one-line note that says "this adds no new syscalls to the seccomp filter and no new device surface." The other opens a 1,400-line PR that adds a feature, reformats three files, bumps a dependency, and has no test. The first gets reviewed. The second is asked to split it, sits for six weeks, and is eventually closed as stale. The code was the same. The judgment was not.

Firecracker raises the stakes on judgment higher than almost any open-source project you will work on, because of three facts that recur in every chapter of this section:

• It is security-critical infrastructure. Firecracker is the isolation boundary under AWS Lambda and AWS Fargate — thousands of mutually-untrusting customer workloads per host. The guest, including the guest kernel, is untrusted. Your patch is privileged host code on the attack surface. A maintainer's first question about any change is rarely "is it fast?" — it is "what does this do to the attack surface?"
• It is single-vendor governed. There is no foundation, no Technical Steering Committee, no GOVERNANCE.md. The maintainers are a dedicated AWS team. That changes how influence is earned and how proposals are received (see maintainership).
• It is deliberately minimal. The whole design thesis is do almost nothing. Proposals that add features, devices, or surface area face a structurally high bar. "QEMU has it" is not an argument here; it is closer to a red flag.

What Separates a Casual Contributor From the Maintainer Track

A casual contributor fixes a typo, gets it merged, and leaves. That is fine and welcome. But the contributor on the maintainer track behaves differently from the first PR onward, in ways a maintainer notices and remembers:

The Levels make you able to write the code. This section makes the code land, and makes you the kind of contributor whose name a maintainer recognizes as safe to merge.

The Values That Run Through Everything

Four values underpin every chapter. Internalize them; they explain nearly every "no" you will receive.

1. Security-first, always. Firecracker's reason to exist is isolation. Every emulated device is host code a malicious guest can attack; every syscall in the seccomp filter is a hole; every line in the jailer is a privilege boundary. A change that adds attack surface must earn it. When you read community-interaction, note that security vulnerabilities are reported privately to AWS Security — never as a public issue, never as a public PR. That instinct — "could this be a security issue? then it does not go in a public channel" — is the single most important reflex this section teaches.

2. Minimalism as a feature. The minimal device model philosophy is not laziness; it is the security argument made structural. Fewer devices, fewer code paths, fewer syscalls, less to audit, less to exploit. A maintainer defending the minimal device model against a "please add USB / a second serial port / arbitrary PCI passthrough" request is doing their job, not being obstructive. You will learn to make that argument yourself, and to anticipate it before you propose.

3. Tests are the contract. New functionality requires integration tests — the pytest suite in tests/, not just cargo test. A behavioral change without a test that would have failed before your change is not finished. Firecracker is the substrate under a multi-tenant cloud; an untested change is a change the maintainers cannot trust a future refactor won't silently break.

4. Sustained quality over heroics. One 5,000-line feature PR earns you nothing if it can't be reviewed. Fifteen small, clean, well-tested fixes in one area, plus thoughtful reviews of others' PRs, earn you a reputation. Trust at Firecracker is a rate, accumulated over months, not a single event.

How to Use the Seven Chapters

The chapters follow the real arc of a contributor: learn to read, learn where decisions live, learn to talk, learn to ship, learn to iterate, learn what you may break, learn how trust accrues. Read them roughly in order; the cross-links between them are deliberate.

Chapters 1–2 are pre-work — read them before opening anything. Chapters 3–5 are operational — read them before your first PR. Chapters 6–7 are strategic — read them when you start thinking beyond a single change.

How This Section Pairs With the Rest of the Book

Each mindset chapter has a hands-on counterpart. Read them together:

If you are doing the Capstone — a full contribution cycle from issue reproduction to merged PR — you should have read all seven chapters by the time you reach the PR step. The Capstone is graded in part on process: the very things this section teaches.

Prerequisites

Before this section is useful you must have:

• A local clone of Firecracker:

  git clone https://github.com/firecracker-microvm/firecracker.git ~/fc-src
  cd ~/fc-src
  

• A GitHub account — your contribution identity. There is no CLA and no JIRA.
• Git configured so git commit -s produces a correct DCO Signed-off-by: line that matches your identity:

  git config --global user.name  "Your Real Name"
  git config --global user.email "you@example.com"   # must match your sign-off
  

• A successful local build at least once — see Level 1 Lab 1: Build From Source. You cannot reason about PR quality until you have watched tools/devtool checkstyle and tools/devtool checkbuild --all pass or fail on your own machine.

You Have Absorbed This Section When…

Treat this as the gate before declaring the section "read." You have absorbed it when you can:

1. Find any feature in Firecracker in under fifteen minutes by tracing from main.rs → run_with_api → builder → Vmm, following types rather than files, using rg, rust-analyzer, and the tests as spec.
2. Recover the "why" behind any piece of code: git blame it, find the PR that introduced it ((#NNNN)), read that PR's review thread and the issue it closed, and cross-reference docs/ and the CHANGELOG.
3. File an issue or ask a question a maintainer can act on with zero follow-up — and recognize the moment a finding becomes a security report that must go privately to AWS Security.
4. Open a PR that is scoped to one logical change, signed off on every commit, has a CHANGELOG entry and integration tests, and passes tools/devtool checkstyle and checkbuild --all (clippy at -D warnings) on the first try.
5. Iterate on review the Firecracker way: amend and force-push (not pile-on commits), address every comment, push back with evidence and concede with grace, and earn the ≥2 maintainer approvals required to merge.
6. Predict, for any change, which compatibility surface it touches — the API backward- compatibility contract, the snapshot version format, or a performance gate — and what test proves it safe.
7. Articulate a realistic, area-focused, multi-month plan for earning influence and eventual ownership in a single-vendor project where the core maintainers are an AWS team.

The next chapter — Reading the Firecracker Codebase — gives you the navigation strategy you will use through everything that follows.