Projects with bigger problems [LWN.net]

Projects with bigger problems

Posted Apr 24, 2026 18:37 UTC (Fri) by rgmoore (✭ supporter ✭, #75)
In reply to: Projects with bigger problems by farnz
Parent article: Dependency-cooldown discussions warm up

At the bottom, it's a huge free rider problem. There should never be a piece of critical infrastructure that everyone depends on that's supported by a single hardworking maintainer. Everyone who depends on that critical project needs to step up and provide some support, whether it's dedicating some of their developer time or just chipping in some money so the maintainer can afford to hire help. Much more than technical solutions, we need a change in people's expectation that they can freeload endlessly off other people's hard work.

to post comments

Projects with bigger problems

Posted Apr 24, 2026 19:08 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

> we need a change in people's expectation that they can freeload endlessly off other people's hard work.

"endlessly freeloading" is a *feature*, and IMO is the primary reason why F/OSS has been adopted so widely.

Projects with bigger problems

Posted Apr 24, 2026 19:58 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link]

And now people are discovering that zero cost comes with some downsides as well as upsides. If you want guaranteed rapid response to security problems, you're going to pay for it one way or another. In practice, chipping in to support the projects you depend on- whether that's direct financial contribution or paying for some developer time devoted to dependencies rather than your project- is still going to be way cheaper than paying for a proprietary solution.

Projects with bigger problems

Posted Apr 24, 2026 20:17 UTC (Fri) by marcH (subscriber, #57642) [Link] (34 responses)

> At the bottom, it's a huge free rider problem [...] There should never be... Everyone who ... needs to ... [...] We need a change in people's expectation [...]

Unless you live in a dictatorship (and even then...) there is no "People should just..." Social pressure has never worked beyond tribe-sized groups. People just try things, that's human nature at its core. Some people take big risks (like: depending on an orphaned project), others not. Some succeed, others not. Some learn (e.g: when hacked), others not. Some do as taught, others not. Some care, many not. Trying to stem that tide never got anywhere.

The only two effective actions are:

- Making things illegal. Vaguely effective sometimes. For instance: changing a software licence.
- Offering an alternative that people like better. For instance: DRM-protected streaming that Just Works over free P2P downloads of semi-random and possibly infected media.

In the past you could "educate" and influence a little bit but that's pretty much dead nowadays in this era of attention merchants and echo chambers. You can still publish stuff but that's more for personal "I told you so!" visibility and gain than for actual prevention.

Projects with bigger problems

Posted Apr 27, 2026 17:08 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link] (33 responses)

That's fair. Maybe a better way of making my point is to say that there's a free rider problem, and we will continue to suffer from all the knock-on effects of that free rider problem until there's some kind of solution. IMO, one part of the solution- probably the easiest part to deal with- is technical. Right now, even someone who would love to contribute to supporting all their upstream dependencies (including dependencies of dependencies to the Nth order) can't easily do it. That seems like something that could be fixed.

I'm imagining a FOSS forge that includes some kind of contribution system. Downstream projects register, and the forge can figure out what their dependencies are by looking at their code. Then they can sign up to donate, with a one-time or recurring contribution. The forge takes a little off the top to support its infrastructure and distributes the rest to whichever dependencies have registered to receive contributions. The trick is that any project that signs up to receive contributions has to agree to pass some of the money they receive upstream to their own dependencies, so indirect dependencies don't get left out. A project that doesn't want to receive contributions- maybe they decide the amount of money isn't worth the tax hassle- can decline them or just increase their pass-through to 100% so all the money gets sent to their dependencies. Any project that wants to receive contributions has an incentive to join the forge rather than some alternative, which should help build momentum for the idea. It's a purely technical solution, but at least it provides the infrastructure to make financial support for projects feasible.

Projects with bigger problems

Posted Apr 27, 2026 19:17 UTC (Mon) by marcH (subscriber, #57642) [Link] (32 responses)

Something like https://support.deezer.com/hc/en-gb/articles/360002471277... but for software - I like it!

GitHub, Gitlab and co. are currently in the best place by far to prototype something like this and get this ball rolling. Anyone working there and listening?

Of course, the devil is in the details and especially around the metrics. How do you stop the equivalent of bots listening to fake music and cashing in? As mentioned at this reference. As soon as there is money, there is an order magnitude more people trying to cheat or game the system. But still worth a try.

Projects with bigger problems

Posted Apr 27, 2026 20:53 UTC (Mon) by pizza (subscriber, #46) [Link] (7 responses)

> GitHub, Gitlab and co. are currently in the best place by far to prototype something like this and get this ball rolling. Anyone working there and listening?

Do we _really_ want to further reinforce these organizations' grip on F/OSS development?

> Of course, the devil is in the details and especially around the metrics. How do you stop the equivalent of bots listening to fake music and cashing in?

It's going to make us yearn for the good ol' days of "bug bounty" slop.

Projects with bigger problems

Posted Apr 27, 2026 21:25 UTC (Mon) by marcH (subscriber, #57642) [Link] (6 responses)

> > GitHub, Gitlab and co. are currently in the best place by far to prototype something like this and get this ball rolling. Anyone working there and listening?

> Do we _really_ want to further reinforce these organizations' grip on F/OSS development?

No, we want them to pay the initial cost of experimentation and then "steal" the lessons learned. As open-source usually does - including open-source "forges". Cause you can't really patent pure ideas yet (knock on wood) despite monopolies trying hard. Code may be flowing only one way, but you can't stop ideas from flowing in all directions.

Projects with bigger problems

Posted Apr 27, 2026 21:47 UTC (Mon) by pizza (subscriber, #46) [Link] (5 responses)

> No, we want them to pay the initial cost of experimentation and then "steal" the lessons learned.

... so you want them to take a[n ever-increasing] cut of money paid to F/OSS developers, instead of "just" advertising, datamining, and actively undercutting our professions?

The only "lesson" here is that these for-profit organizations do not, have never, and never will, have our backs. They view us as (a) a market to be captured and locked in, and (b) an expense to be minimized, if not eliminated entirely.

Projects with bigger problems

Posted Apr 27, 2026 22:42 UTC (Mon) by marcH (subscriber, #57642) [Link] (4 responses)

I'm aware this is a lost cause because antisocial media has been methodically destroying any sort of nuance or subtlety but.. the world is still a bit more complex than "they" versus "us". Yes: some things (and some people) are simple. Many others are not.

Projects with bigger problems

Posted Apr 27, 2026 23:21 UTC (Mon) by pizza (subscriber, #46) [Link] (3 responses)

> The world is still a bit more complex than "they" versus "us". Yes: some things (and some people) are simple. Many others are not.

Sure, that's fine.

What I take issue with here is that this gives the big forge[s] another lever to use to lock folks in. Their sheer size/scope means they'd be the only ones able to meaningfully implement this trickle-down payment mechanism; anyone else trying to replicate it won't have anywhere near the reach to build a competitor after the fact. A classic example of network effects.

The only way I see this working is a through a truly neutral private collection society with a "public good" charter or a governmental department. And even then I don't see why the overwhelming majority of freeloaders would ever _voluntarily_ pay in.

Projects with bigger problems

Posted Apr 28, 2026 12:13 UTC (Tue) by marcH (subscriber, #57642) [Link] (2 responses)

> Their sheer size/scope means they'd be the only ones able to meaningfully implement this trickle-down payment mechanism; anyone else trying to replicate it won't have anywhere near the reach to build a competitor after the fact. A classic example of network effects.

I agree there would be significant network effects but I don't think they would be as bad as for music for instance. If only a few artists you like are missing from your favorite streaming service, then you're unlikely to subscribe to an extra one just for those. I bet most people just _buy_ that particular music instead of streaming it in that case. Whereas with a voluntary donation system, you can split your donations anyway you like any time you want. It seems quite different from that perspective.

Also, artists are getting ripped off because there is yet another indirection layer / middlemen: record labels. Not sure why these are still dominant in our Internet age (getting off-topic) but there's no rip-off equivalent for FOSS and I don't see why there would be any there.

Projects with bigger problems

Posted May 1, 2026 9:16 UTC (Fri) by massimiliano (subscriber, #3048) [Link] (1 responses)

IIRC, the Radicle (https://radicle.xyz) project was attempting to build a "trickle" system to transfer funds from projects to dependencies.

It was all blockchain-based, so it would not give power to monopolies.

I do not know what happened to it...

Projects with bigger problems

Posted May 1, 2026 9:50 UTC (Fri) by liw (subscriber, #6379) [Link]

I believe you mean Drips, drips.network.

Projects with bigger problems

Posted Apr 27, 2026 22:07 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link] (23 responses)

How do you stop the equivalent of bots listening to fake music and cashing in?

Because there's no money in that case. There isn't some big pot of ad money that gets shared between projects depending on how many other projects depend on them. Any money that comes in is associated with the project that's willing to give it, and that money goes to the project's dependency tree. A project can only bring in money if and to the extent that other projects willing to give money actually use it as a dependency.

The one way I can see to game the system is that as I described it, the money a project sends to its dependencies is divided equally rather than based on some measure of their relative importance. That gives programmers an incentive to game the system by multiplying dependencies. For example, if I have a project with only one dependency, all my pass-through money goes to that one project. Instead, I could write all the functions in my project as dependencies, one function per dependency, so most of the pass-through money would go to me instead of the other project. Even then, my project has to do something good enough to get people to depend on it in order to bring in any money.

Projects with bigger problems

Posted Apr 28, 2026 9:19 UTC (Tue) by farnz (subscriber, #17727) [Link] (22 responses)

The other way to game it is to vendor and obfuscate your real dependencies; in other words, instead of openly depending on OpenSSL, I vendor it and make some licensing compliant changes to make it "my" library. The result is that my "EasyCryptography" library has no dependencies not owned by me, and I get all the money, instead of my fair share.

Projects with bigger problems

Posted Apr 28, 2026 12:03 UTC (Tue) by marcH (subscriber, #57642) [Link] (5 responses)

> > Instead, I could write all the functions in my project as dependencies, one function per dependency, so most of the pass-through money would go to me instead of the other project

Rewards lines of code instead of each project equally? You could still game that but it would pretty obvious and look really bad.

With good test coverage tooling you could even reward lines of code actually used, excluding optional features.

> I vendor it and make some licensing compliant changes to make it "my" library.

That one looks pretty easy to detect automatically TBH. If not automatically, at least very obvious to humans.

Projects with bigger problems

Posted Apr 28, 2026 13:56 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

Code obfuscation techniques have been a thing for a long time, and are something LLMs are good at (while introducing new bugs, of course).

That makes detecting that "EasyCrypto" is in fact a wrapper around OpenSSL, and not a bunch of carefully written new cryptography code hard - because the obfuscation stops it being obvious. And sure, a detailed inspection by a human will catch this, and it'll be a scandal - but I can just clear off and disappear with my ill-gotten gains.

Projects with bigger problems

Posted Apr 28, 2026 14:08 UTC (Tue) by marcH (subscriber, #57642) [Link] (1 responses)

But a project must have users in the first place to have any gain.

> And sure, a detailed inspection by a human will catch this, and it'll be a scandal - but I can just clear off and disappear with my ill-gotten gains.

This assumes there will be a significant number of users for long enough with NONE noticing anything weird. And no AI check noticing anything either. It's not impossible of course but that seems a bit of stretch. Definitely not "routine" enough to threaten the model as a whole.

Projects with bigger problems

Posted Apr 28, 2026 14:55 UTC (Tue) by farnz (subscriber, #17727) [Link]

If it were genuinely uncommon, then we wouldn't be seeing issues with the supply chain to begin with - people would be noticing weird, and not using it.

The whole reason we're having this discussion is that people motivated by financial gain are attacking F/OSS software sources with the intention of clearing off with their ill-gotten gains - this is just an extra money path for them to take.

Projects with bigger problems

Posted Apr 30, 2026 10:39 UTC (Thu) by taladar (subscriber, #68407) [Link] (1 responses)

We really don't want to encourage projects using more lines of code and more verbose programming languages.

Projects with bigger problems

Posted Apr 30, 2026 13:29 UTC (Thu) by marcH (subscriber, #57642) [Link]

Right, splitting across dependencies is not easy. Maybe it could simply be up to each project to value each of their own dependencies. They would be "politics" of course but projects should have the best knowledge. Also, "politics" is not always a bad word: an endangered dependency really difficult to substitute or re-implement could be valued more for no real "technical" reason and that would be OK.

Projects with bigger problems

Posted Apr 28, 2026 17:23 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (15 responses)

> The other way to game it is to vendor and obfuscate your real dependencies; in other words, instead of openly depending on OpenSSL, I vendor it and make some licensing compliant changes to make it "my" library.

And why would anyone buy your library, when OpenSSL is available?

Projects with bigger problems

Posted Apr 29, 2026 7:42 UTC (Wed) by farnz (subscriber, #17727) [Link] (14 responses)

My library is designed to be much easier to use for common tasks than OpenSSL, at the expense of removing all the power that OpenSSL exposes. In an honest world, it's a wrapper around OpenSSL to make it much easier to use; in this dishonest world, it pretends to be a simpler SSL library (and probably even points you at OpenSSL if you need the full power it exposes).

Projects with bigger problems

Posted Apr 29, 2026 16:36 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (12 responses)

So, like Boring SSL?

Your library will need to add some additional functionality for people to prefer it to raw OpenSSL, especially in the LLM age.

Projects with bigger problems

Posted Apr 30, 2026 10:41 UTC (Thu) by farnz (subscriber, #17727) [Link] (11 responses)

Sure - but if I can find such a niche, I can game the system to get all the money, rather than just the share I earn by providing a nice wrapper.

Projects with bigger problems

Posted Apr 30, 2026 13:31 UTC (Thu) by marcH (subscriber, #57642) [Link] (10 responses)

If a system can be gamed only in rare niches, then it's a pretty good system. It means "manual" policing is minimal and doable.

Projects with bigger problems

Posted Apr 30, 2026 13:48 UTC (Thu) by farnz (subscriber, #17727) [Link] (9 responses)

Quite the opposite - you'll have the spam problem, which means that manual policing is not doable (since you're flooded by possible attacks), along with attackers going for every niche they can with libraries that have everything they depend upon vendored instead of credited, so that they can get the full payment, rather than letting the people they depend upon get some income.

Projects with bigger problems

Posted Apr 30, 2026 14:34 UTC (Thu) by marcH (subscriber, #57642) [Link] (8 responses)

For money to be there you need users to give some and I still didn't get how you get a significant number of users with your scheme, sorry.

Projects with bigger problems

Posted Apr 30, 2026 14:48 UTC (Thu) by farnz (subscriber, #17727) [Link] (7 responses)

You just need to flood out the catalog with so many projects in each area of application that, while any single project doesn't get much money, anyone trying to find something useful in there is likely to pick up one of your projects, and not one that's honest.

This is also a problem in retail - if you search eBay, AliExpress, Amazon or other marketplace sites for something fairly generic (as opposed to something that has active trademark protection), you're quite likely to be overwhelmed by large numbers of apparently identical versions from lots of random companies that you don't recognise.

Projects with bigger problems

Posted Apr 30, 2026 17:33 UTC (Thu) by marcH (subscriber, #57642) [Link] (6 responses)

I have never seen anyone looking for software looking for "something generic". I really don't think this is how it works.

Projects with bigger problems

Posted Apr 30, 2026 17:37 UTC (Thu) by farnz (subscriber, #17727) [Link] (2 responses)

I see it all the time - you want a HTTPS client, or a WiFi manager, and unless you know the name of the project you want already, you search for a generic term like that. And those terms will be absolutely overloaded with automated spam options - unless you know already that cURL is your HTTPS client of choice, or that you want IWD to manage WiFi connections, you're going to be facing people flooding out the things you want.

Not to mention typosquatting and other attacks on the humans doing this - you think you're donating to cURL, but you're donating to cURI instead.

Projects with bigger problems

Posted Apr 30, 2026 17:46 UTC (Thu) by marcH (subscriber, #57642) [Link] (1 responses)

When people are overloaded with generic offers, they usually turn to stats, reviews and other reputation systems and for software that is more than enough, you just need to invest more than a few minutes.

I think you also keep losing sight that we are discussing _voluntary_ contributions to... projects randomly picked up in a list? I'm not saying this would never happen, I'm just saying it will be small enough not to harm the system as a whole. Same for typosquatting.

For a bad actor typosquatting, security and owning target systems is probably more valuable than collecting contribution pennies.

Projects with bigger problems

Posted Apr 30, 2026 18:02 UTC (Thu) by farnz (subscriber, #17727) [Link]

Right, and what I'm saying is that the system will not work, because as soon as there's money in the system, people will game stats, reviews, reputation systems, and more.

As a result, either you have no contributions (hence no money, hence no attackers), or you're faced with a flood of attackers making the system more expensive to run. The only reason Temu and places like it survive is that, with a flood of attackers, you still have people who have to pay to get the goods at all; but if I don't have to pay, why would I risk paying on a platform that's full of scams?

Projects with bigger problems

Posted Apr 30, 2026 17:42 UTC (Thu) by pizza (subscriber, #46) [Link] (2 responses)

> I have never seen anyone looking for software looking for "something generic". I really don't think this is how it works.

Even if there is only one module in the entire namespace that implements $functionality, how exactly are random software developers supposed to know what its name is without first searching for "$language module for $functionality" ?

Projects with bigger problems

Posted Apr 30, 2026 17:54 UTC (Thu) by marcH (subscriber, #57642) [Link] (1 responses)

I meant no one looking for software is going to think "Oh, I can choose between 50 'generic' options for this, I'm spoiled with choice, this is great! Lucky me".

Software being all fixed costs and network effects, when you see 50 different options you immediately know that at least 47 are garbage if not more. Once you have 3 viable left, you are still depressed because now you need even more time to evaluate the 3 left, as you know dependencies are really hard to change and picking up one is pretty long-term commitment.

This is pretty much the opposite of buying "generic" stuff on Temu.

Projects with bigger problems

Posted Apr 30, 2026 17:59 UTC (Thu) by farnz (subscriber, #17727) [Link]

No, they're going to think "oh, this platform is awful - it's got 5,000 options, and I can't see how I find the legitimate ones in all the junk, so I'm not going to donate to anything on this platform at all". And thus, the platform ends up dead.

Projects with bigger problems

Posted Apr 30, 2026 11:08 UTC (Thu) by LtWorf (subscriber, #124958) [Link]

seesms to have some good value then!