The goal of Thirdpass as a service is to coordinate the collaborative review effort necessary to lower software supply-chain risks.
Multi-ecosystem support: crates.io, pypi.org, npmjs.com, and galaxy.ansible.com.
Thirdpass should enable anyone to review by pointing their spare AI capacity at dependencies.
Some thoughts over the years whilst working on this off and on:
* A coordination node can add a lot of value.
* It's difficult to motivate human reviewers.
* A review which adds partial coverage is still valuable.
* The supply-chain risk is not unique to JavaScript.
This project started in 2021 and was recently revived. I've honestly had a lot of fun working on this. I'm looking for contributors to help build and review.
I've been playing around with agent-native source annotation to specifically address the massively parallel work problem. Check it out here: https://github.com/draxl-org/draxl
VCamper: use LLMs to spot security fixes before CVE publication
Once a patch for a security vulnerability is public, the patch itself can reveal the vulnerability before the CVE is published. VCamper uses a staged LLM pipeline to analyze a Git commit range and flag likely vulnerability patches, even when they look like routine changes.
It’s still a proof of concept, but on known cases like curl CVE-2025-0725 it got close to the published root cause from the patch alone.
This matters because LLMs could make it much harder to keep security fixes quiet: once the patch is public, the bug may be recoverable almost immediately. Quietly shipping a fix and hoping it stays under the radar may stop being a reliable strategy.
OpenFare is attempting to solve this problem. It allows developers to effectively invoice by adding a file to their software package. No need to modify package managers.
> the cost of adding them (INCLUDING the transaction costs, the cost of dev hours spend on convincing the procurement dept, etc etc etc) is cheaper than the cost in dev hours
I think this gets to the heart of the matter. The goal with OpenFare (for non-FOSS) is to minimize this overhead cost. I believe that it can be minimized to a point where it is negligible. For FOSS it is already negligible. The method for minimizing that cost is to make a predictable pattern familiar and ubiquitous.
> had better respond quickly to security vulnerabilities and feature requests
That depends on the deal. If you buy software for $.01 what do you expect beyond your expectations had you paid nothing? Software support can't be assumed just because money is trading hands.
I really like that idea. I think it's really compelling. The latest features/bug fix can be made available at a price before a certain time limit. And then of course you eventually end up with the advantages of FOSS.
I need to think about it a bit more. And I'd like to hear more opinions on ideas like this.
Changes to the lock file (`OPENFARE.lock`) need to be reviewed. The lock file needs to survive a project fork. Changes to the lock file need to be tracked on a contributor level. The lock file needs to be signed by those who care about the project.
> If you, a contributor, want to change your funding preferences, you have to file a PR with the project?
Yes, or, a bot could track your funding preferences from some repo and submit a PR for you. (Cryptographic verification permitting.)
> If you update your preferences, other branches of the same project can still have different preferences?
Yes but those other branches will be outdated and git will make that clear. Only the commit from which the software package is derived matters. Donation schemes are derived from software packages.
## Forking a project
Contributors could get a share of donations by proposing a change to a project's lock file via a pull request. Or they could fork and make a change. But their fork would have to stand on it's own as a software package.
Umm, I could be wrong, and you might be referring to what I have in mind. But your dream sounds an awful lot like the OpenFare Commercial License (non-FOSS) idea:
I imagine the distribution curve of funding. If it shifts one way, more developers become full time open source maintainers. Those who previously received nothing might start receiving coffee money.
If we can normalize a low friction mechanism for receiving funds for developers then the curve might be shiftable.
But I think mechanisms for rating software packages already exist (GitHub stars for instance). And we have reasonable metrics for whether a software package is under active development/maintenance. If we combine those two factors in deciding which dependencies to fund we might be in a reasonable place.
I don't believe enough public software developers ask for or expect to receive donations.
The macro goal of OpenFare is to put in place a mechanism that developers can use to receive funds for developing public software. If there is a demand for donations, it needs to be brought to the surface. I don't think we're adequately over that hurdle.
Many content creators (youtubers, gamers, ...) get paid a lot. I think that there is room for public software engineers to ask for their share.
> 2. the maintainers are surely not the only ones contributing; how to pay all the rest?
This is certainly a problem that I would like to address. It's important to reward/fund contributors as much as maintainers.
Donation schemes defined in code are as modifiable as any other code in the software. I would like to build a bot which will open a pull request on behalf of contributors and propose a share of donations.
OpenFare does open the door to an alternative non-FOSS strategy for funding for small software libraries.
Commercial payment plans defined in code can be managed programmatically. Which means that small payment obligations can be managed at scale. Consequently, trivial software dependencies could raise meaningful capital from micropayments.
Also supports npm, PyPI, and Ansible Galaxy.