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

61–70 of 155 posts

Re: Dumb ways for an open source project to die

#61

Post by Lerc »

ZeWaka wrote: post #27
Lerc wrote: post #21

Earlier quoted context omitted.

I was reading though thinking that only a few of these were dumb. I wondered if it was a reference to Dumb Ways to Die, but thought that was a bit obscure for a reference. Turns out, apparantly not. I think if I had have gone to all that work to write this list I would have given each one a dumbness score to communicate that circumstances are not equal.

> a bit obscure for a reference one of the most viral videos from 2012 is obscure?

Time passes. Do you know what its like talking to a group of game developers, and finding out none of them knew what an Amiga was.

I try to rage against the dying of the light, with limited success.

When my daughter went into a classroom (middle school I believe is the US term) that was not her own, a surprised teacher asked "Who are you?" She immediately responded with "I'm the new number two, you are number six"

The teacher did not get the reference, but I won parenting that day.

Re: Dumb ways for an open source project to die

#62

Post by [deleted] »

socketcluster wrote: post #49
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. The core problem is that people assume that all software is necessarily unreliable. The fact is because they themselves are not capable of producing perfectly reliable software, they assume that everyone else is the same. With this narrow-minded worldview, you would expect software to require constant updates as the maintainer is essentially playing a never-ending game of whac-a-mole. Not all technologies chang…

[deleted]

Re: Dumb ways for an open source project to die

#63

Post by jonnyasmar »

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 things twice a year."

Framework authors have their own incentives (relevance, employment, hiring funnel) and aren't optimizing for your project's longevity. The only way to write 20-year code today is either (a) work in an ecosystem that genuinely values stability (Lisp, C, parts of Erlang/OTP, Postgres) or (b) accept the tax of a modern stack and budget for it explicitly.

Most teams do neither, which is when projects rot fastest.

Re: Dumb ways for an open source project to die

#64

Post by tamimio »

Very good list, I have seen most in action. I would also add AI where some people just make their own internal tools rather than making it open source to everyone.

> Apple is the classic example of an employer that simply doesn’t let most staff do outside open source

I have been encountering this a lot recently, and I don’t know why. Last one a couple months ago, a company wanted to hire me for some work and while all verbal promises were good, when the contract was sent, it has some shady terms but workable nonetheless, except one, the company prevent you from working in any open source work, including personal ones without a written permission, and everything you do will be the company property on or off duty! Obviously I challenged that and they got offended to even dare to challenge it, no deal! Other companies too but that was the craziest one so far.

Re: Dumb ways for an open source project to die

#65

Post by lacewing »

This is a weird, evidently AI-generated article that is a middling taxonomy of how open-source projects die, but none of this strikes me as "dumb". They're just things that can happen if you're coding as a hobby. Yeah, you might end up getting a job or getting bored or whatever. So?

The LLM-author is also apparently unaware of the #1 reason why open-source projects die: they don't generate enough interest / use. I created a number of OSS projects that some people liked in theory, but that weren't taking off and weren't worth getting chained to for life.

Re: Dumb ways for an open source project to die

#66

Post by yuriks »

OkayPhysicist wrote: post #50
usernametaken29 wrote: post #14

I remember having this discussion a long time ago that instead of dependencies we should build a function and type hub that lets you pick tested function and type definitions. Each individual artefact is tiny so forking it is really simple. Instead of building a massive library you mix and match for your use case. The platform itself can host test cases decoupled from the definition. With AI this sounds much more rea…

The missing piece there, that would be a real value-add over normal package repositories, is that functions can be small enough to simply be done . Function gets marked as such, it can no longer be updated, thus eliminating the risk of supply chain attacks and their ilk. IMO, most packages I actually use, with the exception of web frameworks, ought to fall into this category. My JSON parser should never update. My Kn…

In what ways do version pining/lockfiles not solve this problem?

Re: Dumb ways for an open source project to die

#67

Post by nickjj »

Another one is how much time it takes to maintain vs how much interest it has. This is different than burnout.

I created and maintain example Docker Compose starter projects for Flask[0], Rails[1], Django[2] and Node[3]. I've had these going for 6-7 years and I maintain them at least once a week to keep everything up to date.

I used to also support Phoenix but I stopped after ~5 years because it was the least popular project but also took up more time to upgrade than all of the other example projects combined because Live View has changed in drastic ways so many times. Plus it became no longer enjoyable to work on it since I stopped using Phoenix in my day to day as well. That combined with it being the least popular example app between the 5 projects made it easy to decide to sunset it.

I put together a 6 month plan to archive the repo in https://github.com/nickjj/docker-phoenix-example/issues/16, received zero feedback and then archived it at the start of 2026.

[0]: https://github.com/nickjj/docker-flask-example

[1]: https://github.com/nickjj/docker-rails-example

[2]: https://github.com/nickjj/docker-django-example

[3]: https://github.com/nickjj/docker-node-example

Re: Dumb ways for an open source project to die

#68

Post by singpolyma3 »

fritzo wrote: post #39
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…

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?

Re: Dumb ways for an open source project to die

#69

Post by singpolyma3 »

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 still publish everything. If someone wants to come and ask me to do something they can happily find out I likely will not.

Re: Dumb ways for an open source project to die

#70

Post by jonnyasmar »

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?

Fair counter, and that's the right stance. The tax I'm pointing at is the implicit social one: feeling like you owe a response. Plenty of publishers get burned out before they figure out your model.
Post reply on HN