Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dumb ways for an open source project to die

nesbitt.io

Post reply on HN
Print view View original

81–90 of 155 posts

Re: Dumb ways for an open source project to die

#81

Post by d1l »

prymitive wrote: post #26

Call me old but there was a time when “open source project” meant “I had a problem, this is my solution, if someone has the same problem then you are free to use my solution”. These days is more: - building personal brand - showcasing your skills - trying to outsmart somebody else, often because they didn’t merge your pr - sometimes just having fun And if you work for big org it’s also often “this looks vaguely simil…

15 years ago GitHub was a strong signal for like-minded devs who were of the “let me code and slide pizza under the door” variety. The signal became less meaningful over time so people started optimizing for other things…stars, whatever. Brand. I think the venn diagram of front end marketing types and the explosion of js frameworks probably was the driver for this. Now with vibed out projects everywhere it’s a real task to separate the wheat from the chaff. And I still use gh because I imagine those stars are still current in some markets but maybe I’m deluding myself.

Or, Perhaps the invention of the rocket emoji most likely was the cause of this phenomenon.

Re: Dumb ways for an open source project to die

#82

Post by em-bee »

singpolyma3 wrote: post #68
fritzo wrote: post #39

Earlier quoted context omitted.

Dependency bloat and dependency bitrot have made solutions less permanent, have increased the maintenance burden. My ancient projects with zero dependencies still stand. But projects I built on shifting dependencies are rotting and cracking.

Do the versions of the dependencies that you used no longer exist anywhere?

they exist, but they are likely unmaintained, and may have known security issues.

i have a project that suffers from that. the version of a library it is built with is old and unsecure, but the newer supported version has a completely different API that would require me to rewrite the code that uses the library.

i had a second such case where i discovered a fork of the old version of the library which was still maintained. otherwise there too a rewrite would have been required.

Re: Dumb ways for an open source project to die

#83

Post by rectang »

Onplana wrote: post #80

A pattern that's gotten worse in the last year or so: drive-by PRs from third-party "security scanners" trying to plant their badge in your README. Got one last week — single-line diff adding a markdown image link back to their scanning service, with a body formatted as a "94/100 Verified Safe" audit report. The "high severity finding" they flagged turned out to be the section of our README explaining how we defend a…

This is basically a problem with Open Source hosted at Github, right? Because Github doesn't allow you to turn off PRs for people outside your organization.

Since Github has been asked to change this policy since time immemorial and has not responded, another possible response is to host your project somewhere else that doesn't have the same policy and/or doesn't have the same volume of spammers. Of course that means that you don't get the benefits of hosting at Github, but the cost/benefit ratio of hosting there has changed over time.

Re: Dumb ways for an open source project to die

#84

Post by em-bee »

singpolyma3 wrote: post #71
jonnyasmar wrote: post #63

Earlier quoted context omitted.

The reality I keep running into: software that "just works for years" requires dependency hygiene at the ecosystem level, not just the application level. You can write Common Lisp or C or even most of Go that way and your code will still run in 20 years. The moment you depend on a modern frontend framework or even a modern backend one, you've committed to following its release cadence — which is often "we deprecate t…

Unless you just... Keep using the old version of the framework? No one is making you upgrade

the problem is that you have to keep all the artifacts around so you can keep building with the old framework. especially in the npm world that is incredibly annoying. my solution for javascript at least is to avoid build tools alltogether, and build the site in such a way that it runs without a build step only using frameworks that support that. since the code runs in the browser there are no security concerns because you can't trust that code anyways.

Re: Dumb ways for an open source project to die

#85

Post by chamomeal »

killerstorm wrote: post #32

It's ridiculous that everything is expected to be maintained on a weekly basis. In the past we had software stacks where once code is written it's just done, it will keep working years and even decades later. E.g. https://sapaclisp.common-lisp.dev/ you can download code written in 1993 and just load it in latest SBCL.

Different languages definitely have differently expectations and cultures around this stuff. If an npm package hasn’t been updated in 2 years, I’m suspicious. I’m gonna check the downloads, check GitHub issues and stuff to see kind of problems people are having, Google around to see if people are using something else.

If a clojars package hasn’t been updated in 6 years, I don’t even think about it!!

Re: Dumb ways for an open source project to die

#86

Post by david_allison »

jonnyasmar wrote: post #55
prymitive wrote: post #26

Call me old but there was a time when “open source project” meant “I had a problem, this is my solution, if someone has the same problem then you are free to use my solution”. These days is more: - building personal brand - showcasing your skills - trying to outsmart somebody else, often because they didn’t merge your pr - sometimes just having fun And if you work for big org it’s also often “this looks vaguely simil…

The framing assumes the ratio of "problem-and-solution" projects to "personal-brand" projects has shifted. I'd push back: I think the underlying ratio is roughly the same — what's shifted is what gets published. The work of running an open-source project (issue triage, security disclosures, contribution guidelines, CI, release cadence, dependency maintenance) is way higher than the work of solving the original proble…

> I'd happily share if "share" still meant "drop a gist." It doesn't, anymore.

It still does. Feel free to use https://unmaintained.tech/ on your repo.

Re: Dumb ways for an open source project to die

#87

Post by marcus_holmes »

avaer wrote: post #35
prymitive wrote: post #26

Call me old but there was a time when “open source project” meant “I had a problem, this is my solution, if someone has the same problem then you are free to use my solution”. These days is more: - building personal brand - showcasing your skills - trying to outsmart somebody else, often because they didn’t merge your pr - sometimes just having fun And if you work for big org it’s also often “this looks vaguely simil…

There was a time when web meant sharing your hobbies with supportive anonymous strangers, a time when crypto meant doing clever things with numbers. In my experience you can pretty much always bet on greed, money, and psychopathy to ruin anything that reaches beyond Dunbar's number. It's sad when your playground gets overrun by drug lords (metaphorically speaking); I don't really have an answer to that. It's my centr…

I found Mastodon, feels like usenet in about 1993.

There are odd corners of the web that still work on RSS, and just have people sharing stuff.

But yeah, the entire of mainstream internet discourse can be safely ignored.

HN, though, I still like it here :)

Re: Dumb ways for an open source project to die

#88

Post by materielle »

em-bee wrote: post #84
singpolyma3 wrote: post #71

Earlier quoted context omitted.

Unless you just... Keep using the old version of the framework? No one is making you upgrade

the problem is that you have to keep all the artifacts around so you can keep building with the old framework. especially in the npm world that is incredibly annoying. my solution for javascript at least is to avoid build tools alltogether, and build the site in such a way that it runs without a build step only using frameworks that support that. since the code runs in the browser there are no security concerns becau…

Which brings us to the next layer of modern dependency management insanity:

The fact that basically none of these multi-million dollar companies are vendoring their entire dependency tree.

At most companies, even ones worth millions of dollars, it would be impossible for them to rebuild their software if someone ripped a package off of npm’s registry or whatever.

Re: Dumb ways for an open source project to die

#90

Post by mickael-kerjean »

jonnyasmar wrote: post #63
killerstorm wrote: post #32

It's ridiculous that everything is expected to be maintained on a weekly basis. In the past we had software stacks where once code is written it's just done, it will keep working years and even decades later. E.g. https://sapaclisp.common-lisp.dev/ you can download code written in 1993 and just load it in latest SBCL.

The reality I keep running into: software that "just works for years" requires dependency hygiene at the ecosystem level, not just the application level. You can write Common Lisp or C or even most of Go that way and your code will still run in 20 years. The moment you depend on a modern frontend framework or even a modern backend one, you've committed to following its release cadence — which is often "we deprecate t…

> even most of Go that way and your code will still run in 20 years

While reading this, I was literally working on patching my open source go app [1] because this is what came out of the stdlib in the last few months: CVE-2025-30204, CVE-2026-33487, CVE-2026-25679, CVE-2026-27137, CVE-2026-32280, CVE-2026-32281, CVE-2026-32283, CVE-2026-33810, CVE-2026-33811, CVE-2026-33814, CVE-2026-39820, CVE-2026-39836, CVE-2026-42499

ref: https://github.com/mickael-kerjean/filestash

Post reply on HN