rndhouse

I'm working on a tool for collaboratively reviewing Rust crate dependencies: https://github.com/thirdpass-org/thirdpass

Also supports npm, PyPI, and Ansible Galaxy.

Hello,

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 hope the community finds this valuable!

https://github.com/thirdpass-org/thirdpass

https://thirdpass.dev/

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.

https://github.com/rndhouse/vcamper

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.

https://github.com/openfare/openfare

Two more alternatives to crev:

https://github.com/vouch-dev/vouch

https://github.com/mozilla/cargo-vet

I haven't heard about librepay before, thanks for letting me know. I'll take a look!

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:

https://github.com/openfare/openfare#micropriced-commercial-...

For a user of the software, free might have downsides that micropayment-funded-at-scale might not have.

If all users chip in $1/month, perhaps it adds up to something significant.

I think the challenge is to minimize the overhead costs of that process.

I agree with your view.

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.

Will update, thanks.

It's a tough problem.

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.

Any metric can be gamed of course.

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.

There is so much variety in how people contribute and what they hope to get out of it in a perfect world!

My goal is to put the mechanisms in place. And give people another means of self expression.

Yes, I agree. There are two different audiences: public software developers and public companies. And they both need different interfaces. I love it.

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.

See: https://github.com/openfare/openfare#micropriced-commercial-...

However, software for a fee is not FOSS.

Thank you for taking a look at what I've shared so far.

My intent is to create a community around the idea and to get early feedback. It's true that there are many problems outstanding. I'm yet to share a payment portal for instance that will effectively outsource the infrastructure necessary to distribute funds.

You asked:

But if your license isn't open source, then what good is it for monetizing open source programs?

The OpenFare License is the commercial license that I believe should be used in the dual licensing circumstance described in the article. Thereby helping to monetizing open source programs.

The OpenFare License intends to provide that commercial aspect whilst being equivalent to the MIT License where possible.

I think the entire point of the article is dual license FOSS and some other commercial license.

That's great to hear! Yes, we've wondered across the same sort of idea with your "DONATIONS.txt" file. I post updates when I can to the Matrix chatroom:

#openfare:matrix.org

But feel free to follow along however!

Sponsorship and donations are the popularity driven funding mechanisms. I want to fund the unpopular long tail of software maintainers (like the log4j guys who were not well known before the incident).

I want to fund maintainers based on whether the software is *used* commercially or not. Not on whether it's popular or not.

OpenFare doesn't lead to extreme individualism. It aims to fund collaborative software development. The OpenFare scheme is flexible enough to reflect how the collective wants to manage funding.

The OpenFare is *equivalent* to the MIT License in non-commercial settings. It isn't even close to a closed source license.

Honestly, your comment is the most useful I've had so far.

I agree with what you've said. I don't expect any company to pay anyone with PayPal, BTC (or even lightning, can you imagine!), but I want to leave the door open for that.

Proper invoicing is key. And I think I can avoid the "kingmakes" problem you've mentioned.

The longer term view that I have includes a payment portal service. A company would submit a report (via the openfare tool) of the OpenFare licensed dependencies that they use. The service will then invoice them and facilitate a single lump sum charge via Stripe (credit card) or similar. Then forward to the developers or refund.

I think I can avoid the "kingmakes" problem because of the following: anyone could start a OpenFare payment portal. The OpenFare licensed dependencies report could be sent to anyone.

I don't claim that this is a free or open source license. The OpenFare license is about monetizing software in the most convenient way possible. I agree with the open source definition as given here:

https://opensource.org/osd

There are many advantages to defining the payment plan in code. Whether it's defined in the OPENFARE.lock file or the LICENSE file only matters for the sake of simplicity. The LICENSE needs to be the same across many packages so that it can be approved by lawyers once.

The idea is to put (very narrow) customizations of the terms in the OPENFARE.lock file.

I've been working on a solution along the lines described in the article: OpenFare.

With OpenFare, payment plans are defined in code. Which means that the dependency tree can be priced by direct inspection. I've got a working example for NPM dependencies.

I'm working on a solution where the "FOSS collective" aspect can be decentralized and represented as a protocol. I think it simplifies a lot of things.