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

71–80 of 155 posts

Re: Dumb ways for an open source project to die

#71

Post by singpolyma3 »

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…

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

Re: Dumb ways for an open source project to die

#72

Post by [deleted] »

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…

[deleted]

Re: Dumb ways for an open source project to die

#73

Post by singpolyma3 »

cebert wrote: post #34
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 times. The need to patch for security updates alone is increasing rapidly.

Unless you code doesn't speak to a network or any untrusted user. But people are making software that fits this criteria less and less often.

Re: Dumb ways for an open source project to die

#74

Post by ecksii »

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.

This again! Software can be both _mature_ and _useful_. If you trip across a piece of software that's both of mature and useful, your first action should be clone it's git repo into your own storage and save project state. Then you should work against your repo posting pull requests for the greater community. But if no one consumes the pull requests, move on.

Re: Dumb ways for an open source project to die

#75

Post by singpolyma3 »

Aurornis wrote: post #7

A lot of edge cases on this list. Among projects I've used it's almost always maintainers losing interest or vanishing. Forking is always suggested as a solution, but some projects treat forks as hostile attempts to steal their project. I've hit fork deadlock before where a maintainer didn't want to merge important requests, but also became exceedingly hostile to anyone who tried to fork the project. If a maintainer…

If the license is open source there's nothing a maintainer can do except whine when you fork. Stick your fingers in yours (metaphorical) ears and keep on working.

Re: Dumb ways for an open source project to die

#76

Post by jonnyasmar »

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

You can, and sometimes that's the right answer. Where it gets hard: security CVEs that need patching but the fix is only in the new major, transitive deps that bump and bring incompatibilities, hiring a contractor who doesn't know your locked version. None of those are insurmountable, but they're real tax.

Re: Dumb ways for an open source project to die

#77

Post by singpolyma3 »

sokoloff wrote: post #9
Aurornis wrote: post #7

A lot of edge cases on this list. Among projects I've used it's almost always maintainers losing interest or vanishing. Forking is always suggested as a solution, but some projects treat forks as hostile attempts to steal their project. I've hit fork deadlock before where a maintainer didn't want to merge important requests, but also became exceedingly hostile to anyone who tried to fork the project. If a maintainer…

It seems not at all surprising that the “other side” of a fork would view it somewhat negatively. The person planning the fork presumably views the mainline project maintainers somewhat negatively in that moment as well. They can be as hostile as they want; that seems nearly irrelevant to the fork decision. If the mainline won’t take a patch or wants to go in a different direction, forking seems perfectly valid and t…

As a maintainer of a fork I don't think this is true. Upstream is perfectly fine and nice people, just with different needs than my community. So rather than try to scope creep their nice project, we work on a fork. Everyone wins.

Re: Dumb ways for an open source project to die

#79

Post by ryukoposting »

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?

In my experience, the most common problem is that a dependency changes. It drops support for something, API changing, etc. If it's 3 dependencies deep, and one of the deps in the middle isn't maintained anymore, well...

Re: Dumb ways for an open source project to die

#80

Post by Onplana »

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 against prompt injection. They were scoring legitimate documentation as a vulnerability so the report would look thorough.

The economics make sense if you squint: each accepted PR is a permanent backlink on a real OSS repo, and most maintainers don't have time to review carefully. Close one, see five more.

Combined with the Dependabot avalanche (a small repo I check in on has 15+ open dep bumps, half with stale merge conflicts because they touch the same workflow file), the modern maintainer tax isn't writing code — it's triaging bots and growth-hackers who treat your contribution policy as an SEO funnel.

Zero-dep philosophy doesn't fully escape this; the PRs come for your README badges and your transitive scanners regardless.

Post reply on HN