|
|
Log in / Subscribe / Register

Projects with bigger problems

Projects with bigger problems

Posted Apr 27, 2026 22:07 UTC (Mon) by rgmoore (✭ supporter ✭, #75)
In reply to: Projects with bigger problems by marcH
Parent article: Dependency-cooldown discussions warm up

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.


to post comments

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!


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds