Two Weeks of Real Open Source Contributions

Five pull requests, across four projects, over about two weeks. Two of them are still open. One turned into something I didn't expect: an invitation to put my name on a project's own website. This is what actually happened in between — the part that never makes it into "I contributed to open source" posts, which is mostly review comments, a CI failure that had nothing to do with my code, and waiting.

The first review: three real findings, not one

My first PR to Nanocoder fixed a formatter that decided a file read was "metadata only" by checking whether the output started with the string "File:" — except the actual output starts with "File Information for...", so the check could never be true. Small, mechanical, verifiable. I was fairly confident going in.

The maintainer's review came back with changes requested, and it wasn't a rubber stamp. Three separate findings, each one real:

1. No regression test existed for this exact case, which is precisely how the bug shipped in the first place.
2. My fix computed the flag after reading the file, which meant a directory read still fell through to the wrong code path — a variant of the same bug, in a spot I hadn't looked at.
3. I'd written === true, but the code that actually decides whether a read is metadata-only uses a plain truthy check. He'd traced a path — an XML tool-call fallback — where that flag arrives as the string 'true', which is truthy but not strictly equal to true. He reproduced it.

That third one is the one that stuck with me. It's easy to fix a bug you're shown. It's a different skill to notice that your fix quietly reintroduces a narrower version of the same class of bug. I addressed all three, he came back with one more note — four separate comment blocks in my diff were explaining what the old code got wrong rather than what the current code does, which is what a changeset entry is for, not inline comments. I trimmed it. He said he'd approve on the next push.

The bug that wasn't a bug

While that review was in flight, both this PR and a separate one to Apache DataFusion Ballista started failing a check with an error that looked, at a glance, like something was broken in the target repository's own CI config. A workflow was fetching a file at a specific commit and getting a 404 — a file that definitely existed on the current branch.

It took a while to see the actual shape of it: a pull request's base.sha — the commit your branch is compared against — is not a live pointer to the target branch's current tip. It's the actual git merge-base between your branch and theirs, and it only moves if you merge or rebase their branch into yours. I'd opened both branches days earlier and never updated them. Meanwhile the target repos had each added a new file that my frozen comparison point simply predated.

The fix was ordinary — merge upstream's current main into my branch, resolve one small conflict, push. What made it worth remembering is that the failure had nothing to do with my code and everything to do with a git mechanic I'd never had a reason to think about before. Worth checking, next time a CI failure looks like it belongs to the wrong repository: is my branch just old?

Losing a race, honestly

Not every attempt turned into a PR. I found a real, well-scoped bug in a wire-service bot — a retry loop that caught HttpClientErrorException but not HttpMessageNotWritableException, meaning a transient "broken pipe" during a request write bypassed the retry entirely. I traced the exact exception hierarchy against the real dependency, wrote the fix, was about to push it — and found the maintainer had fixed the identical thing on their develop branch two days earlier. My search for competing work had only checked open pull requests, not commits already merged to a branch that isn't the repo's default.

I want to include this because it's the actual ratio. For every merged fix there's a bug you traced correctly and still don't submit, because someone else already had it, or because you find — after real digging — that the "small" fix you were about to make required rebuilding a native library from source and would have been worse than the original problem. Neither of those is a failure exactly. Checking first is the whole point.

The part I didn't expect

A few days after the nanocoder fix went in, the maintainer left a comment on the merged PR: an invitation to add myself to the project's contributors page. Not something I asked for, not something the process was aiming at — it happened because the second round of review went well enough that he wanted it on record.

The contributing guide for that was as concrete as any code review: a square photo under 500KB, an entry in a TypeScript array, alphabetical by convention though the actual list is really chronological. I sent over a photo that turned out to be sideways in the final crop — my own pipeline had stripped the orientation tag after cropping the raw, unrotated pixel data, so what displayed correctly in my own preview was quietly wrong in the file I'd actually committed. Caught after the fact, from a screenshot, fixed with one more commit to the same PR.

What the shape of it actually looked like

• Every review that mattered found more than the one thing I fixed. Not because I was careless, but because a maintainer who actually knows the codebase sees adjacent cases you can't see from outside it.
• The CI failure that looked worst was the one with nothing to do with my code. A stale branch produces errors that read exactly like a broken pipeline.
• Losing a race isn't wasted work if you check before you push, not just before you start. The bug I traced correctly and didn't submit taught me more about that codebase than most of the ones I did.
• The reward for a small fix, done carefully, tends to be more small fixes. Not a badge. An invitation to keep showing up.

None of this needed to be a big contribution. It needed to be a correct one, verified, with the reasoning written down where a reviewer could check it — and then it needed someone to actually look, twice, and tell me what I'd missed.