05 — Contributing to Open-Source C¶

This is the file you came here for. Everything up to now was preparation; this is the ninety-day plan to land a merged PR in a serious C project. The gate matters: an study partner at Cloudflare or Nvidia does not care that you read production C. They care that a maintainer somewhere took your code and merged it. That single link on your resume rearranges every study conversation you will have.

The good news: three of the four most important C projects in the world are actively hungry for contributors right now. The other one (SQLite) has structural reasons for saying no. Below is the honest map.

The 2026 target list — who takes newcomer PRs¶

Because this changes over time, values below were verified July 2026.

Project	Newcomer-friendly?	Median PR merge time	Governance	Recommended?
Valkey (valkey-io/valkey)	Yes — explicitly hungry	1–4 weeks	Linux Foundation	First choice
llama.cpp (ggml-org/llama.cpp)	Yes — high volume	Days to 2 weeks	Community, MIT	Great choice, high signal
curl (curl/curl)	Yes — famously welcoming	1–2 weeks	Benevolent dictator (Daniel Stenberg)	Excellent, more competitive
redis (redis/redis)	Partly — corporate maintainer, license drama	Weeks	Redis Inc. commercial	Consider Valkey instead
PostgreSQL	Yes but slow	2–6 months	Committer model, mailing list	High prestige, glacial
ClickHouse	Yes	1–4 weeks	Corporate (ClickHouse Inc.)	Good C++ contribution track
TigerBeetle	Yes, small community	1–2 weeks	Corporate, Zig-first	Only if you learn Zig
SQLite	No — policy	N/A	HWACI, closed	Read only

The reason SQLite says no: it is public-domain code with no copyright, which means an accepted patch needs a signed copyright-dedication affidavit mailed to the SQLite team (HWACI — Hipp, Wyrick, Aggarwal, Confluent Inc). The Dec 2025 update to sqlite.org/copyright.html softened the “open source but not open contribution” wording but the affidavit requirement remains. For this roadmap: read SQLite, do not send it your PR.

Which project should you pick?¶

Use this decision tree for the first PR. You can always contribute to multiple projects after this one lands.

If you want an ML-adjacent portfolio piece → llama.cpp. High signal for anyone hiring for inference/systems roles.
If you want distributed-systems / data-store credibility → Valkey.
If you want protocol / networking credibility → curl.
If your ambition is a database or DBMS role → PostgreSQL, but plan for 6-month cycles.

For a Zoho engineer with an Applied ML background pivoting toward systems, Valkey first is the highest-EV pick: broad hiring signal, active mentorship, weekly release cadence, and it’s the same story every AWS ElastiCache and GCP Memorystore team will care about.

The ninety-day plan¶

This is a concrete calendar. Adjust the dates but keep the sequence.

Week 1–2: Land in the community¶

Read CONTRIBUTING.md, HACKING.md, and any docs/dev*.md for your target repo. Not “skim” — read. Every one. Twice.
Clone, build, run the test suite. If any step fails on your machine, that’s your first PR (“docs: clarify build step on macOS 15”).
Watch the last 20 merged PRs in the repo. Read the review comments. Learn what the maintainers care about. This is the single highest-leverage 3-hour block you can spend.
Join the community channel: Valkey Slack (invite at valkey.io), llama.cpp GitHub Discussions, curl-library mailing list.

Week 3–4: Pick your issue¶

Filter for issues labeled good first issue, help wanted, hacktoberfest, or (in Valkey’s case) good-first-issue. Then apply this filter:

Not held by anyone else. Read the whole comment thread; often someone is quietly working on it.
Has clear reproduction steps or a design in the issue. Ambiguous scope means a long PR.
Touches C code, not just docs or CI. Doc-only PRs are welcome but do not carry the same study signal.
Small enough to ship in 15–25 h of work. Bigger scope = higher chance you never finish.
Not a security fix. Security patches go through a private disclosure channel, not a public PR.

Comment on the issue: “I’d like to take this. Plan: [3 sentences]. Timeline: [2 weeks]. Please assign to me or let me know if someone else is on it.” This is the maintainer-etiquette baseline. Do not ghost after claiming.

Week 5–8: Do the work¶

Branch. Small commits. Every commit passes make test.
Match the codebase’s style exactly — not the style you like. .clang-format is authoritative.
Add tests. A PR with no tests will get a polite “could you add a test for this?” and lose two weeks. Save yourself the round trip.
Run every sanitizer the project uses. If they run ASan in CI, you run ASan locally. First.
Open a draft PR early — as soon as you have a proof-of-concept. Maintainers will steer you before you overcommit to a wrong approach.

Week 9–12: Review cycle¶

The review cycle is where most first PRs die. Rules:

Respond within 48 hours to every reviewer comment, even if the response is “working on it, expect update Sunday.”
Never argue in the first reply. If you think the reviewer is wrong, ask a clarifying question. Nine times out of ten they saw something you missed.
Do not squash the review history mid-review. Keep the commit history readable during review; squash on maintainer request before merge.
Update the PR description as scope changes. Reviewers coming in fresh should not have to read all 60 comments to know what the PR does now.

When it merges, thank the reviewers publicly. Then wait ~24 hours and open the next issue. Momentum is real.

Contribution etiquette — the unwritten rules¶

After watching several hundred first PRs in each of these repos, the pattern is:

Do not “drive-by” refactor. “While I was in here, I also cleaned up X” is the #1 way to have a maintainer close your PR. Do one thing.
Match the emotional register of the codebase. Valkey PRs are formal-but-warm. llama.cpp PRs are technical-and-blunt. curl PRs are polite-and-detailed. Read three merged PRs first.
Attribution: cite the issue in your commit message. Fixes #12345. Not fixed the bug.
Never ask “any update?” before two weeks pass. After two weeks, ping once, politely, in the PR (not a DM).
Assume the maintainer is drowning. They almost always are. A well-scoped, well-tested, well-explained PR is a gift. An unclear one is more work than not receiving it.

What each project cares about — short version¶

Valkey cares about: performance (do not regress a benchmark), memory (do not add a per-client allocation), and API stability. Read CONTRIBUTING.md at github.com/valkey-io/valkey. Key maintainers as of 2026: Madelyn Olson (AWS, co-founder), Roberto Luna Rojas (AWS), Kyle Davis. Governance docs live at valkey.io/governance.

llama.cpp cares about: not adding new ggml_type enums (see CONTRIBUTING.md at github.com/ggml-org/llama.cpp), keeping test-backend-ops green, and cross-backend consistency. Model-architecture additions are onboarded via Discussion #16770 (by the Qwen3-Next author) — read that before you touch anything model-shaped. Key gotcha: ggml_mul_mat(a, b) computes torch.matmul(b, a.T), not a * b.

curl cares about: portability (100+ OS/arch combos), zero-warning builds, thorough test coverage in tests/. Daniel Stenberg (@bagder) reviews personally. docs/CONTRIBUTE.md is required reading. curl’s median first-PR merge time is famously fast, often under a week.

What to write in the PR description¶

A good PR description is three paragraphs:

What. “This PR fixes #NNN by validating the length of the bulklen field before allocation in readQueryFromClient().”
Why. “Without this check, a malicious client can send a bulklen of SIZE_MAX and trigger an integer wrap on the subsequent malloc call. See attached ASan trace.”
How I verified. “Added test t/unit/type/string.tcl:overflow_bulklen. Ran make test clean under ASan + UBSan on Linux x64 and macOS ARM64.”

One screenshot of the ASan trace, or a gdb bt full if it’s a crash, moves the review cycle a full week faster than words alone.

The wall of shame — five ways your first PR dies¶

Scope creep. You fixed one bug and also reformatted 400 lines.
No tests. You claim it fixes X; there is nothing that proves it stays fixed.
Ghosting on review. You disappear for 6 weeks. The issue gets reassigned.
Arguing. You push back on the maintainer’s stylistic preferences on your first PR.
Wrong project. You picked something that hasn’t merged a community PR in 8 months. Check the merge history before investing.

What most people get wrong about this¶

They wait until they “feel ready.” You never will. You are ready the day you can build the project and run its test suite. Everything else is on-the-job learning. The maintainers know you are new; the label is literally good first issue. What they do not know is whether you will follow through. Follow through, and you are ahead of 90% of first-time contributors.

Second thing: they treat the PR as the goal. It isn’t. The goal is the working relationship with the maintainers. One merged PR is table stakes; three merged PRs from the same reviewer is a reference and possibly a job.

Return to README.md · Next: 06_the_c_expert_reading_list.md