Local projects are useful, but they are too forgiving.
If I own the repo, I can choose the architecture, the naming, the test strategy, and the tradeoffs. That is good for building. It is not always good for proving I can work inside someone else's system.
Merged upstream PRs are different.
You do not get to decide that the repo should use your preferred style. You do not get to rewrite the surrounding code because it would make your fix prettier. You have to understand the local pattern and make the smallest change that fits.
That constraint is the value.
The most useful fixes in my OSS ledger are all narrow:
- preserve empty-string entries in Conform array submissions
- skip side-effect-free external imports in Rollup when hoisting is disabled
- avoid crashing
no-unresolvedcase checks onEACCES/EPERM - allow scoped package names in JSDoc declaration-reference inline tags
- handle object-shaped
notschemas inswagger-typescript-api - avoid false positives in
require-meta-*when meta object spreads cannot be resolved - format structured command entries in Cline history export
Each one forced a slightly different kind of reading.
Some were about parser behavior. Some were about test fixtures. Some were about error handling. Some were about not assuming a static analysis rule knows more than it actually knows.
That last part has been the recurring lesson. The fix is rarely "make the tool smarter" in the abstract. The fix is usually "make the tool honest about this one boundary."
That is also why I like OSS proof for developer-infrastructure work. A merged PR is small, but it is not private. Someone else accepted the tradeoff. Someone else decided the test was enough. Someone else now has to live with the change.
That does not make it a perfect signal. It does make it a better signal than a private screenshot.
Disclosure: I used AI assistance to organize this private article draft. The examples and current PR count should be rechecked against the OSS contribution ledger before publishing.
Top comments (0)