Hacker News Reader

Use a language where you don't need to pull in 100 dependencies to create a useful application/service.

It's not a language problem. It's a cultural problem.

Last I checked create-react-app pulls around 1k transitive dependencies. Can't really blame JS for that, can we?

This whole situation reminds me of that post a little while ago

> I will pay you cash to delete your npm module

https://news.ycombinator.com/item?id=29240952

So finally F.L.O.S. Software pays out. Shame that the dev did not apply for some compensation. All in all, not very rational of him.

Keeping dependencies loosely coupled and reusable has been best practice since forever, but it is only really with NPM that it has become the default.

But actually it's more like dependency hell because you pull in the same dependency in N versions and you can't update transitive dependencies in a senseful matter? And you get a lot of libraries that are like 4 lines and computing basic operations (like there was a lib "isOdd"... i mean x% 2 === 0?).

So you won't gain anything from this type of dependency management, because it is way to complicate to understand and to manage for a developer.

unfortunately almost all languages are moving towards smaller, not bigger, standard libraries.

I do think there is space for someone to ship an "unofficial meta-package" for languages like JS to wrap all this stuff (I tried to do an analysis of npm once to figure out what would make sense but got lost in the weeds....)

Python (for me one of the gold standards on this front) has been hyping for a future with a much smaller standard lib and it makes me sad.

Cool use a lang without a developer ecosystem got it.

> My big enterprise would sign up for it in a heartbeat.

People keep on claiming there is a need for a corporation like that. But Sun didn't really make any money with Java and had to sell to Oracle. Now all these silicon valley startup complain about Oracle costs.

Eventually, Microsoft will pull the same thing with NPM (and Github), they didn't acquire the package manager just for creds, they will make it profitable.

As for Redhat they are owned by IBM now.

I could see a govermental effort be approriate too. Alot of critical infrastructure is depending on open source too. Agencies like the German BSI should embrace and invest into open-source much more strongly.

But "vetting" is still relying on the free labor of other and really doesn't change the business model and rectify the underlying problem with open source.

You really need an organization which sponsors and directly hires coders that are maintaining critical infrastructure.

(Of course the npm world is a bit insane where stuff as trivial as leftpad can be critical infrastructure. Don't really think someone needs a $200k/yr salary to maintain just that)

There's an interesting bit of social psychology here where the top reaction to this isn't "lets try to sort out how to pay all the people who are doing all the free work" (and I'm really thinking more the log4j and openssl people and the whole broader ecosystem problem this highlights) and instead it is "how do we keep being exploitative and just outsource the hard job of vetting everything?" I'm pretty sure Google will probably get some AI people onto the problem though, there's clearly a business model there.

The usecase I’ve seen similar to this has been Artifactory. If a dev wants to use a package, then a specific version gets pulled and hosted in the internal Artifactory repository and then all build tools use it to pull packages.

The way I’ve seen (and might not be the best way) people handle ownership is if a dev wants to use lets say ‘colors’ from npm, then they/their team takes ownership of that package internally. I guess an issue would arise if the big co is doing development on a public repo, so they’re forced to use npm/dockerhub/etc.

I think this could be done as a community.

Imagine if npm allowed organizations to publish "vetted pointers" to packages. So redhat could publish a "{redhat}colors", which would include only the vetted versions.

When installing, you could choose to setup your installation to allow "redhat-vetted" versions only. And that would apply even to sub-dependencies.

This becomes a community tool if "redhat" could tell npm to vet anything vetted by another org.

Organizations already solve this by mirroring repositories with tools like JFrog Artifactory.

New versions of packages are verified, approved, and mirrored.

(The revenue split part isn't really a part of that, but you're not really guaranteed revenue as soon as you choose an open source license. You have to make some kind of value-add like support or cloud services as a complementary upsell.)

I will happily provide this service to you. In fact, I already created a Linux distro specifically for rolling back all the brain damage and misfeatures in mainstream Linux that have crept in over the past 15 years. It contains just over 1,000 packages, with not a few patches/bug fixes by myself and others.

If you want to use this distro in your own company with full time support and continuous upgrades by yours truly, my yearly salary will be 220,000 USD, please--not counting any donations you decide to make to individual software authors to ensure your use case is covered by their software, as the above amount covers only my personal salary and considerable expenses.

A large discount is potentially available should other corporations avail themselves of this opportunity and also help cover my salary and expenses. Contact me at [email redacted].

I'm not holding my breath that anyone will take me up on this opportunity, so this distro will just have to remain for my exclusive use only, I'm afraid.