rndhouse

They still matter in the sense that they impose a cost. In other words, they buy time, which is all the users need before updating.

I'm not sure if the cat and mouse game resolves clearly one way or another. Since the obfuscation can be hardened against LLMs during development.

There are many techniques for making a closed-source binary harder to reverse engineer: polymorphism, symbol stripping, code encryption, packing, and so on. Closed-source binaries at least stand a chance of being effectively obfuscated, unlike open-source code.

I built a tool that monitors commits and tries to detect silent bug fixes. With GPT-5.5-class models, it can identify fixes hidden within otherwise routine commits quite reliably. Obfuscating the code changes enough to avoid detection is difficult.

I have heard of at least one project (c-lightning?) temporarily releasing a closed-source binary as a workaround until users could update safely.

Whay do you want traffic to go back to estate agents?

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.