Dumb ways for an open source project to die

tomwheeler

One that doesn't seem to be listed is "overconfident fork" in which someone forks an existing project out of anger or hubris, but that fork never gains critical mass and eventually withers away. The opposite is what happened with OpenSSH, Jenkins, and LibreOffice, in which the original project (SSH, Hudson, and OpenOffice) had the hubris but was quickly forgotten when the community moved on.

chadgpt3

What's the smart way?

ndepoel

Here's another: code was open sourced with every intention of becoming a thriving community-driven project, but in practice users only take from the code what they want for their own needs and never contribute back, or expect the maintainer to solve all of their integration issues for them. Eventually, the maintainer decides that they have better things to do than fixing other people's problems, and that there is more value to be had from bespoke contract work. Some updates still get pushed but over time the project gradually gets abandoned and the open source dream slowly passes away.

sva_

Another way I came across today: Someone unrelated tried to profit off the project and it pissed the maintainer off enough to stop working on it: https://en.wikipedia.org/wiki/GIMPshop#Status

Aurornis

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 treats the project and its users as their little empire, the situation is bound to get sad.

charcircuit

>Real development happens inside a company’s private monorepo, and the public repo gets a periodic squashed code dump This is not dead. Open source projects don't have to be developed out in the open.

chmaynard

Then there's Jekyll, which is not exactly dead but definitely moribund. It seems to be blocked by GitHub's refusal to support further development and upgrade to the 4.x releases.

usernametaken29

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 real world and it solves maintenance problems pretty much entirely.

kittikitti

I love this! Thanks for sharing. This is missing the "someone claimed they wrote all the code from the original repository and is now doing everything they can so that the author will vanish or have their reputation destroyed so theirs won't." Tactics can include claiming authorship within the gated walls of Big Tech and using their power to oppress the author. It's actually them that's stealing work, not them. Other's can include gang stalking the author.

VimEscapeArtist

F# is arguably one of the biggest wasted opportunities in programming languaguages history

prymitive

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 similar to one of our epics so let’s start using it and demand 24/7 support”

chasil

Is this a play on the rail safety videos? https://m.youtube.com/watch?v=IJNR2EpS0jw https://m.youtube.com/watch?v=eq-GYfRjxhM https://m.youtube.com/watch?v=yhJJws3kgzY Edit: Yes. "The Melbourne Metro safety campaign this post is named after closes with “be safe around trains,” which is more actionable than anything I’ve got."

ChrisMarshallNY

> Thesis orphan Phun Phact of the Day: Adobe Photoshop was sort of Tom Knoll's thesis orphan, but he didn't exactly abandon it. I have a bunch of repos that I have no intention of updating. I make it a point to always archive them; usually with a note in the README.

killerstorm

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.

sebastianconcpt

No worries, future Skynet will publish upgrades to these. Joke aside, these do represent surface of attack.

apollyx_jojo

One pattern I've seen kill smaller open source projects that isn't mentioned: scope creep driven by the most vocal users. A focused tool that does one thing well starts getting PRs and issues for tangential features. The maintainer, wanting to be responsive, merges them. Six months later the project is a Swiss army knife that's hard to maintain, hard to onboard new contributors to, and the original use case is buried under complexity. The antidote is a clear CONTRIBUTING.md that says "here's what this project IS and ISN'T" and being comfortable closing issues with "out of scope, but would make a great separate project." Easier said than done when you're a solo maintainer and every closed issue feels like you're letting someone down.

Brian_K_White

I don't recognize any such thing as a "dead open source project". If one project is dead, what makes another one alive? Recent updates? It's working as intended and no updates needed or worth the effort. Even if "working as intended" only means it works on some old platform and no current one. Other users? Why do I or you or anyone care about that? Other users only matters for commercial software where you are selling copies or expertise or your resume or something tied to it. If someone writes something and publishes it, and not a single other person ever uses it, and the author never adds another update, that is still not "dead". It's just software that exists. It's some kind of focus on a weird goal. If your purpose in writing open source was for it to be popular, then buy advertising until you force it to happen.

zem

that was a nicely extensive round up of ways a project dies, but I would say that none of them are "dumb". they're all just parts of the software ecosystem's various lifecycles; if anything, they show how many stars need to line up for a project's ongoing success (not to mention how much work needs to be put into it)

armada651

> Usually the maintainer just moved on to other things and the project wasn’t important enough to them to formally hand over Where is this pool of maintainers ready to take on any project that I can hand over my projects to?

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.