The 16-Week Plan
This is a calendar. It maps the nine levels, the supporting tracks (deep dives, rust-vmm, contributor mindset, the issue roadmap), and the capstone onto 16 weeks of part-time work — the realistic rhythm of a working engineer giving Firecracker 8–12 focused hours a week. It is not a race. The gates in Milestones M1–M9 decide whether you advance, not the calendar; if a week takes you two, take two. But a schedule turns "I'll get to it" into "this week I do X," and that is the difference between finishing and drifting.
The plan front-loads the foundations (KVM, the threading model, the boot path) because everything later depends on them, and it interleaves real GitHub issue practice from Week 4 onward so you are contributing — not just reading — well before the capstone. Each phase ends with an exit checkpoint you must pass before moving on.
Note: Every "reading" cell points at curriculum pages and repo docs; every "labs" cell points at the level's labs. Run the labs — reading is not doing. Where a row says "issue practice," go to the Issue Roadmap, filter the real GitHub tracker (
gh issue list), and actually engage. The roadmap stages are graded by difficulty; match them to your week.
Warning: Do not start the calendar on a broken baseline. You must have finished Overview & Prerequisites (a microVM boots from your own build) and read the Hitchhiker's Guide and Warm-Up before Week 1. Those are Week 0.
The Shape of the 16 Weeks
flowchart LR
W0[Week 0: Setup + Warm-Up] --> P1[Weeks 1-3: Foundations<br/>L1-L2]
P1 --> P2[Weeks 4-6: Architecture & KVM<br/>L3-L4]
P2 --> P3[Weeks 7-9: Testing, Boot, Virtio<br/>L5-L7]
P3 --> P4[Weeks 10-12: Real Contribution<br/>L8 + roadmap]
P4 --> P5[Weeks 13-14: Advanced Maintainer<br/>L9]
P5 --> P6[Weeks 15-16: Capstone<br/>full contribution cycle]
| Phase | Weeks | Levels / tracks | The one thing you can do at the end |
|---|---|---|---|
| 0. Setup | Week 0 | Overview, Hitchhiker's, Warm-Up | Boot, network, and snapshot a microVM as a user; locate code with rg. |
| 1. Foundations | 1–3 | L1, L2 | Build/test Firecracker, write a minimal KVM VMM, open a clean first PR. |
| 2. Architecture & KVM | 4–6 | L3, L4 | Trace API→VMM→vCPU; read the run loop and VM exits without a guide. |
| 3. Engine internals | 7–9 | L5, L6, L7 | Use the test framework; trace the boot path and a virtio I/O end to end. |
| 4. Real contribution | 10–12 | L8 + Issue Roadmap | Reproduce a real issue, root-cause it, ship a reviewed PR. |
| 5. Advanced maintainer | 13–14 | L9 | Reason about seccomp/jailer, snapshot compat, and performance regressions. |
| 6. Capstone | 15–16 | Capstone | One full contribution cycle: issue → fix → tests → PR → write-up. |
Phase 0 — Week 0: Setup & Warm-Up
| Week | Focus | Reading | Hands-on | Issue practice | Exit checkpoint |
|---|---|---|---|---|---|
| 0 | Get a working build and the mental model | Overview & Prerequisites; Hitchhiker's Guide; Warm-Up; repo CONTRIBUTING.md, docs/getting-started.md, SPECIFICATION.md | Build with tools/devtool build --release; boot a microVM; run all five warm-up scenarios (boot, net, second drive, snapshot, MMDS); wire git commit -s | Browse the Issue Roadmap and the live tracker; bookmark good first issue | The Overview "You Are Ready When…" and Warm-Up "What to Verify" checklists are fully green. This is the gate into Week 1. |
Phase 1 — Foundations (Weeks 1–3): Levels 1–2
You build the floor everything stands on: a confident build/test loop, KVM from scratch (you write a tiny VMM by hand before you read Firecracker's), and your first real PR with DCO sign-off.
| Week | Focus | Reading | Hands-on labs | Issue practice | Exit checkpoint |
|---|---|---|---|---|---|
| 1 | Build, test, boot | Level 1 index; deep dive kvm-fundamentals; rust-vmm: what-is-rust-vmm | Lab 1.1 build-from-source; Lab 1.2 run-tests; Lab 1.3 boot-first-microvm | Read 5 closed good first issue PRs end to end; note what a clean PR looks like | tools/devtool build/test/checkstyle all green; you can boot from your own binary and explain each curl |
| 2 | KVM by hand | rust-vmm: kvm-ioctls-and-kvm-bindings; deep dive guest-memory-management | Lab 1.4 minimal-kvm-vmm; rust-vmm Lab r1 build-a-kvm-vm | Pick a docs/test good first issue (Stage 1); claim it by commenting | Your hand-written VMM opens /dev/kvm, maps memory, runs KVM_RUN, handles an IO exit |
| 3 | Contributor workflow | Level 2 index; contributor-mindset: pr-quality, reading-codebase; release-governance: licensing-and-dco | Lab 2.1 navigate-repo; Lab 2.2 prepare-pr; Lab 2.3 fixit-good-first-issue; Lab 2.4 review-a-pr | Open your first real PR from Stage 1 work: DCO-signed, CHANGELOG entry, passes CI | Milestone M1 + M2: a PR is open against main, correctly signed, CI green, and you can defend every line |
Tip: Weeks 1–2 are the highest-leverage in the whole plan. An engineer who genuinely understands the three KVM fd levels and the
KVM_RUNloop reads the rest of Firecracker far faster. Do not rush Lab 1.4 — writing the ~70-line VMM yourself is worth ten pages of reading.
Phase 2 — Architecture & KVM (Weeks 4–6): Levels 3–4
Now you read Firecracker's own machinery: the three-thread model, the API→VMM action channel, and the vCPU run loop with its VM-exit taxonomy. This is where the warm-up's "under the hood" becomes code you can trace.
| Week | Focus | Reading | Hands-on labs | Issue practice | Exit checkpoint |
|---|---|---|---|---|---|
| 4 | Threading & the action channel | Level 3 index; deep dives the-vmm-threading-model, api-server-and-action-channel, the-event-manager | Lab 3.1 trace-api-to-vmm; Lab 3.2 threading-model-eventmanager | Engage a Stage 2 issue (build/logging); start a discussion on it | You can draw the API thread → VmmAction (mpsc + eventfd) → VMM epoll loop path from memory |
| 5 | A custom API action | deep dive logging-and-metrics; rust-vmm: event-manager | Lab 3.3 project-custom-api-action | Open a Stage 2 or Stage 3 (error-messages) PR | Your custom action flows socket → ParsedRequest → VmmAction → handler → response; tests pass |
| 6 | vCPUs, the run loop, VM exits | Level 4 index; deep dives vcpu-run-loop-and-vm-exits, cpu-templates-and-cpuid, interrupts-and-irqchip | Lab 4.1 read-vcpu-run-loop; Lab 4.2 vm-exits-mmio-pio; Lab 4.3 cpuid-template; Lab 4.4 fixit-vcpu-edge-case | Comment substantively on an open vCPU/KVM issue (Stage 6) | Milestone M3 + M4: trace a request to a KVM_RUN exit and back; explain MMIO vs PIO exits without notes |
Phase 3 — Engine Internals (Weeks 7–9): Levels 5–7
Testing fluency, the boot path and guest memory, and the virtio device model — block, net, vsock — from the descriptor ring up. This phase has the most labs; pace yourself.
Tip: Week 9 is the densest. If you are behind, push Lab 7.3 (building a device) into Week 10 — but do not skip Lab 7.1. Tracing one real I/O end to end is the gate skill for the contribution phase.
Phase 4 — Real Contribution (Weeks 10–12): Level 8 + the Issue Roadmap
You stop practicing and start contributing for real: select a genuine issue, reproduce it, find the root cause through execution-path analysis, fix it, test it, and shepherd a PR through ≥2 maintainer reviews.
| Week | Focus | Reading | Hands-on labs | Issue practice | Exit checkpoint |
|---|---|---|---|---|---|
| 10 | Find & reproduce a real issue | Level 8 index; contributor-mindset: design-via-github, community-interaction; Issue Roadmap index | Lab 8.1 reproduce-issue | Select a real open issue matched to your level (Stage 3–7); claim it, post a reproduction | A minimal, reliable reproduction is posted on the issue; maintainers can confirm it |
| 11 | Fix it | contributor-mindset: responding-to-feedback, compatibility | Lab 8.2 implement-fix; Lab 8.3 error-messages | Open the fix PR: DCO-signed, integration test, CHANGELOG entry, ≤72-char title | The PR is open, CI green, and your PR description ties the fix to a root cause |
| 12 | Drive it to merge | contributor-mindset: pr-quality; release-governance: github-review | Iterate on review; rebase/--amend -s cleanly; respond to every comment | Address ≥2 maintainers' feedback rounds; help review someone else's PR | Milestone M8: a PR merged (or in final review) that fixes a real, confirmed issue |
Warning: Real PRs take real calendar time — reviewers are busy and require ≥2 approvals. Open the PR early in Week 11 so the review clock starts. If it has not merged by Week 12, that is normal; the milestone is satisfied by a high-quality PR in active review, not necessarily merged.
Phase 5 — Advanced Maintainer (Weeks 13–14): Level 9
The maintainer-grade concerns: the security model end to end (jailer + seccomp + threat model), snapshot/restore compatibility, and diagnosing performance regressions.
| Week | Focus | Reading | Hands-on labs | Issue practice | Exit checkpoint |
|---|---|---|---|---|---|
| 13 | Security & snapshots | Level 9 index; deep dives the-jailer, seccomp-filtering, snapshotting; repo docs/jailer.md, docs/seccomp.md, docs/prod-host-setup.md | Lab 9.1 seccomp-jailer; Lab 9.2 snapshot-restore | Engage a Stage 11 security-seccomp or Stage 8 snapshot-compat issue | You can explain the four defense-in-depth layers and audit one device's attack surface |
| 14 | Performance & compatibility | engineering: oversubscription-and-density, boot-time-optimization, hugepages-and-memory-performance; deep dive rate-limiting-token-bucket | Lab 9.3 perf-regression | A Stage 10 performance issue: measure, bisect, write up | Milestone M9: diagnose a perf regression with measurement; reason about snapshot backward-compat correctly |
Phase 6 — Capstone (Weeks 15–16): One Full Contribution Cycle
The capstone is not new material — it is the whole apprenticeship performed once, cleanly, on a real contribution, and written up as evidence. Follow the ten capstone steps.
| Week | Focus | Steps | Deliverable | Exit checkpoint |
|---|---|---|---|---|
| 15 | Issue → reproduction → root cause → implementation | step-01 issue-selection → step-02 reproduction → step-03 execution-path → step-04 root-cause → step-05 implementation | A working fix on a branch with a written execution-path analysis | The root cause is proven (not guessed) and the fix is implemented behind tests |
| 16 | Testing → validation → PR → docs → write-up | step-06 testing → step-07 validation → step-08 pr → step-09 github-docs → step-10 writeup | A submitted PR + an engineering write-up scored against the evaluation rubric | All nine milestones satisfied; capstone PR submitted; write-up complete |
After the capstone, keep going: the capstone projects portfolio and the feature masterclasses are where you deepen toward sustained, maintainer-track contribution. The path from contributor to maintainer is months to years — this 16 weeks earns you the starting line, not the finish.
If You Only Have 8 Weeks (Compressed Track)
For an experienced VMM/kernel engineer, or anyone who must move fast, here is a compressed track. It keeps the non-negotiables — KVM by hand, the run loop, one virtio I/O traced end to end, and one real PR — and trims the depth elsewhere. Budget the same 8–12 hours/week but accept that you will revisit the skipped deep dives later.
| Week | Covers | Must-do labs | Must-pass milestone |
|---|---|---|---|
| 1 | Setup + Warm-Up + L1 build/boot | 1.1, 1.3 | Boot a microVM from your own build |
| 2 | L1 KVM by hand + L2 workflow | 1.4 minimal-kvm-vmm, 2.2 prepare-pr | M1+M2: hand-written VMM runs; clean PR mechanics |
| 3 | L3 architecture + threading | 3.1 trace-api-to-vmm, 3.2 | M3: trace API→VMM→vCPU |
| 4 | L4 KVM/vCPU run loop + VM exits | 4.1 read-vcpu-run-loop, 4.2 vm-exits | M4: run loop + exit taxonomy |
| 5 | L6 boot path (skim L5 testing) | 6.1 trace-boot-sequence, 5.2 add-unit-test | M6: trace the boot path |
| 6 | L7 virtio devices | 7.1 trace-virtio-block-io, 7.2 virtqueues | M7: trace one virtio I/O end to end |
| 7 | L8 real contribution | 8.1 reproduce-issue, 8.2 implement-fix | M8: a real fix PR in review |
| 8 | L9 essentials + mini-capstone | 9.1 seccomp-jailer, 9.2 snapshot-restore | M9; a scoped capstone PR |
What the 8-week track deliberately defers (do these later): Level 5 testing depth, the rust-vmm labs beyond r1, the engineering at scale essays, the feature masterclasses, and the integration labs. You can become a credible contributor in 8 weeks; becoming a maintainer is the longer game the full 16 weeks (and beyond) builds toward.
Note: Whichever track you take, the milestones are the real gates. If you cannot pass Milestone M4's self-checks, you are not ready for Level 6 no matter what week the calendar says. The calendar serves the milestones, not the other way around.
Where to Go Next
Read Milestones M1–M9 next — they define the competence gates this calendar is pacing you toward. Then begin Level 1. Keep this plan and the milestones page open as you go; mark each exit checkpoint as you pass it.