> The "money goes to the repo part" is the problem here, as it incentivizes maintainers to refuse legitimate pull requests.
That's not true. The issue is that the system the comment you're replying to described is escrow. Escrow degenerates in the way that you describe. I explain it a bit more in this comment elsewhere on this post:
A straight up non-refundable participation payment does not have this issue, and creates a different set of incentives and a different economy, while there also exist escape hatches for free-of-charge contributions.
> The real problem here is the amount of work necessary to make this viable.
Not necessarily. This article mentions Tezos, which is capable of doing such things on-chain already:
> all the annoying KYC/AML that a normie has to get through to use it.
There are always escape hatches. If your code is so great that people will want to pull it, then you don't pay to push. If it's not really that great, then what are we talking about? Maybe it disincentivizes mid code being pushed. So be it.
You can make friends, you can make a name for yourself, you can make a fork that's very successful and upstream will want to pull it in, you can exert social pressure / marketing to get your code merged in. Lots of options that do not involve KYC/AML.
For everyone else, I'd say KYC/AML are a good idea because of the increasing amount of supply chain exploits being pushed out into repos. If pushing by randos is gated by KYC/AML, then there's at least some method of chasing the perps down and taking them to justice.
That's a win-win-win-win situation. Less mid code, less exploits, earnings for maintainers, AI slop blocked. Absolutely amazing.
escrow is a more complex system, and there are multiple possible implementations, but the nice thing is you can skip it and get the same results.
let's assume for a second that the repo owner spends time on PR review, and that time needs to be reimbursed. let's also assume that the person pushing a PR expects some sort of bounty. then as long as the review price is less than bounty price, there's no need for escrow. the pushing party goes out on a limb paying the reviewer to merge their PR, but also expects (rightly or not) to be remunerated for solving the bounty. whether they really did solve it is in the remit of the bounty originator, who might or might not be part of the group controlling the repository. if there's escrow, then the bounty giver probably has to be part of that group. not having escrow allows for crowd funding by interests outside of the repo controlling party.
escrow is only usefully different in a situation when there is no bounty, you want to push code, and then you want to say "ok, here's some money, and here's a PR, either accept the PR and give me money or don't accept it and take my money" as a means of skipping the line or getting a shot at pushing in the first place. however, at that point two things are apparent: 1. you expect the reviewer to do work required to implement your desired changes for free and 2. this might start getting abused, with PRs getting rejected (to gain money) but then modified / refactored versions of this code being pushed via commits or from another user who is the repo owner's puppet (refactoring code is becoming super cheap due to AI). so that degenerates escrow-to-push into a scam.
there are more considerations like that in the article I linked to. I agree that an economy around FOSS pushing would be desirable. it also doesn't preclude free-as-in-money contributions - there are at least two mechanisms that would allow it: 1. you get sponsored by someone who sees your talent (either gives you money to push, or they have push access to that repo and can hand it out free) 2. you create a fork that becomes so good and valuable that upstream pulls from you for free
ultimately becoming a respected developer with free push access to contended repositories should be something that you can monetize to some extent that's purely within your remit, and it would greatly reduce unserious bullshit coming from third parties (especially all those weird hardware developers) and make it easier to be a FOSS dev.
it's also going to kill the open web. nobody is going to want to share their ideas or code publicly anymore. with the natural barriers gone, the incentives to share will go to zero. everything will happen behind closed doors.
GitHub has never been a good method of clout chasing. in decades of being in this industry, I've seen < 1% of potential employers care about FLOSS contributions, as long as you have some stuff on your GH.
> Total Depravity: If your code’s correctness depends on keeping complicated interconnected structure in your head, a devastating incident is not a matter of if but when.
> Therefore, delegate these concerns to tooling and a sufficiently powerful compiler, use types to guard against errors, and free yourself to only mentally track the actual important things.
Location: EU, overlap with PST
Remote: Yes
Relocation: No
Technologies: Rust, C++, Python, Go, Zig, Haskell, TypeScript, Nix, K8s, Terraform
Email: damianjobsites+hn@gmail.com
CV: on request
Senior engineer / tech lead (20+ YOE). Former IC → EM → Director → CTO.
Multiple exits. Hands-on, or owning the whole technical org.
Highlights:
- Designed and shipped a commercial LLM end-to-end (algorithms → training → infra)
- Launched and audited major blockchain systems (incl. Tezos)
- Shipped production systems for Oracle, Shell, Time Warner, BoA, Sparkasse, Saatchi & Saatchi, Digitas
- Built and scaled a software NGO (500k+ supporters, 1k+ volunteers)
Strengths:
- Turning ambiguous problems into shipped systems
- MVPs that don’t need rewriting
- ML, LLMs, RAGs, vector DBs
- Rigorous code and infosec audits for mission-critical infra
- 10x–1000x performance wins on legacy systems
- FP, Compilers, DSLs, distributed systems, security-critical code
Credibility:
- Contributor: Rust Book, Rust By Example, Python docs, Haskell Communities and Activities Report
- Dozens of smart contract audits
- Background in cryptography, infosec, formal methods
If you need someone who can own the stack and ship reliably, email me at damianjobsites+hn@gmail.com
Infra / DevOps: NixOS/Nix, AWS, Terraform, Docker, Ansible; CI/CD, Linux internals, observability, reliability engineering.
Fintech / crypto: Launched Tezos and other blockchains; smart-contract audits; regulated, security-critical environments; built production systems for trad banks.
Yes - high-performance Haskell code looks similar. There isn't much to be said there - it's a little less clean-looking because FP optimizes for the most useful scenario and trying to do highly advanced stuff like that will be more verbose. This is in contrast to OOP where everything is verbose, and sometimes high-perf stuff that falls into the shape of globals + mutation + goto looks very succinct.
Well I still think it's something to worry about before you end in front of a "Your account has been suspended" notice. How can you be sure someone has the whole dataset locally backed up ? Plus, you still have to reconfigure the workflows and stuff like that. Not to mention that sometime, project's websites are also hosted on github, so that's something else you have to rebuild.
And also, this means devs/contributors have to give their data to MS.
Since the whole point of the project is sovereignty, it should have started with setting up their own gitea/gitlab/etc. instances and domains.
To be fair, the problems it's trying to solve are also from "yesteryear" and do not require some groundbreaking new tech. But out of interest what would you pick instead?
Rust or Haskell. Python is subpar in terms of maintainability especially when it comes to long-running, generational, massive, codebases. Python is also massively worse when it comes to performance. Haskell strikes the perfect balance here, I've worked at companies with massive codebases where maintaining is still a breeze years later. This simply does not happen with any OOP languages, the code always turns into an ingrown hedge with time.
Especially when it comes to long-running projects like what's attempted here, Python, even being a technology from yesteryear, isn't even suited for problems of yesteryear.
With projects like these maintainability is your #1 concern, so referential transparency (greatly reinforced by laziness-by-default) and purity are indispensable and irreplaceable here.
The next concern is adequate performance, and Haskell has that in heaps.
The final concern is the capability to find programmers, and there are heaps of those in Haskell land.
reply