Open source · 2026 · ongoing

59 patches sent into 44 projects I don't own.

17 are merged, and each one is a link you can check.

I'm a marketer. I read code and I patch it, and I don't call myself a developer. This started as a test of one hunch, whether an outsider can find a real defect in a large unfamiliar project without spending half a year getting into it.

It worked. Below is the table of what got merged, two cases walked through to the last step, and the method behind them. Plus an honest note on where my own tools lied.

patches sent
59
projects
44
merged
17

Checked against GitHub on August 5, 2026. GitHub profile

What got merged

The hours column is time from opening the pull request to the merge. It says more than the merge itself. A patch taken in within the hour is built differently from one that waited a day and a half.

Two cases in full

A merge on its own only shows the result. These two show the road to it.

Case one

A test that checked something other than its own name

toqito, a quantum information theory library in Python

Their ruff config turns on five rule sets and bugbear is not one of them. I ran their code with the config disabled and --select B. One real thing came out of the noise, a blind pytest.raises(Exception).

The test is called test_is_ppt_non_hermitian_matrix, so by its name it guards that the function rejects a non-Hermitian matrix. What it caught was an array reshape error. is_ppt takes subsystem dimensions as the square root of the matrix shape, for a 2×2 that gives [[1,1],[1,1]], and partial_transpose dies on the reshape. Hermitian-ness is never checked.

The proof is two probes. A Hermitian 2×2 raises the exact same error. A non-Hermitian 4×4 returns False without complaint. So the test would pass where it has to fail, and would miss the very thing it was written for.

The patch renames the test to what it really checks and narrows pytest.raises(Exception) to ValueError with match, the way the rest of their suite does it. 598 tests green in state_props, their ruff clean. Whether is_ppt should reject a non-Hermitian matrix at all is a separate question, raised in the pull request and left to the maintainer. That one changes library behaviour.

The maintainer reproduced all three points of the proof on his own machine and wrote it out line by line in the review. Merged in 9.4 hours. That review is worth more than the merge.

Open the pull request, vprusso/toqito#1910

Case two

The guard was written in June, the feature arrived in November

traefik-helm-chart, the official Traefik Helm chart

The chart has a guard that refuses namespaced RBAC when a provider needs cluster-wide scope. Three providers are listed there. The fourth one, knative, came later and never made the list, so the chart refused a setup the code already handled.

The proof is their own commit history. The guard was written on 18 June 2025, commit 4f39c87. Knative landed on 10 November 2025, commit fbd7922, and role.yaml learned to grant its permissions the same day. The guard was never updated.

Next I had to be sure knative really has no need for cluster scope. Its permissions are purely namespaced and byte for byte identical in role.yaml and clusterrole.yaml. kubernetesGateway, which does need the scope, has its own separate guard two lines above.

Their AGENTS.md says it plainly, write a failing test first. So that came first. The test fails on main, passes with the patch, and the whole helm unittest suite is green, 734 tests.

The maintainer asked for one more fix in the same pull request. Across their suite errorMessage sits at the same indent as failedTemplate, so YAML reads them as two sibling keys and the error text is never compared, only the fact of failure. Fixed and verified by probe, with the indent corrected a swapped expected string makes the test fail. Merged in 15.7 hours.

Open the pull request, traefik/traefik-helm-chart#1955

How this gets found

The search runs wide. Learning one large project to maintainer depth costs years. Comparing what a project promises against what it does works in any project in any language and takes hours.

The promise lives in docs, docstrings, schemas, sample configs, the Removed sections of a CHANGELOG. The behaviour lives in the code. There is almost always a gap between the two, because a parameter got renamed, a flag got cut, a provider got added. The build stays green through all of it, nobody compiles documentation.

That turned into a catalogue. 14 families of defects so far. A family found in one project then gets run across the others. A comparison used where an assignment was meant showed up in a neuroscience library in Python and in the tests of an astronomy library. A stale parameter name in a docstring showed up in seven projects across three languages.

Some families a linter catches, if you run it with the project config switched off. Some nothing catches. Those only surface when a human reads two sources side by side, docs against code, wiki against code, data against schema.

Where my own tools lied

A solid share of the findings comes from scanners I wrote. The scanners were wrong, and not subtly.

The first docstring parser counted 42 mismatches in Boost.GIL and 25 in Boost.Histogram. The real numbers were 11 and 3. The broken ones made it into a pull request description and are stuck there for good, the maintainer read them. Six parser fixes later the false-positive rate on the same repos dropped close to zero. The noise came from the scanner, the defect family itself was fine all along.

Second one. The technique for finding stale copies of upstream code gave three candidates in karmada. Reading the calling code confirmed one. Another fell away because upstream had fixed handler re-registration there, and karmada never re-registers anything, so it has no use for that fix.

Hence the rule I hold hard. Script output is a hypothesis. It becomes a finding after a human reads the calling code and tries to disprove his own conclusion. Every finding goes through that before it gets sent.

That step is what separates this from a noise generator.

Why a marketer does this

Straight answer. Nobody is hiring me as a developer and I'm not aiming there. Something else works. A marketer moving into infrastructure, devtools or AI has one hard thing to prove, that he understands the product. Usually that gets proven in an interview, slowly and badly. A profile with merged patches in etcd and AFL++ closes the question before the call.

And a side effect I did not plan. In the first days the people who replied personally were the founder of rclone, the lead maintainer of AFL++, a co-founder of E2B and one of the three authors of NetworkX. A letter to a company whose repository you have already touched reads very differently.