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.
Yep, if you are going to leave a project as leader, either see if someone else wants to take over or leave a note that the project isn't being updated.
If you are really motivated, leave instructions on how someone else can pick up were you left off even if it is just an email address others can reach out to.
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.
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.
It sounds like the maintainer you're describing was underhandedly helping their users with the silent expectation that they also contribute back to the project and got bitter when it didn't happen that way.
Open source is altruistic, remember. You explicitly tell the world that you are happy for anyone to only take from the code what they want for their own needs and never contribute back. If you don't want to help users or develop your software alone, an alternative is to sell the software and support service to users and use the money to hire developers.
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
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.
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 they can keep their empire. That seems fine; they didn’t want to go east, the fork going east means that those users who also want to go east can be served.
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.
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.
> 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.
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.
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”
tomwheeler | an hour ago
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 | an hour ago
sva_ | an hour ago
HerbManic | 38 minutes ago
If you are really motivated, leave instructions on how someone else can pick up were you left off even if it is just an email address others can reach out to.
john_strinlai | an hour ago
so, just be safe about it, i guess.
Lerc | 40 minutes ago
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.
ZeWaka | 18 minutes ago
one of the most viral videos from 2012 is obscure?
ndepoel | an hour ago
foxglacier | 32 minutes ago
Open source is altruistic, remember. You explicitly tell the world that you are happy for anyone to only take from the code what they want for their own needs and never contribute back. If you don't want to help users or develop your software alone, an alternative is to sell the software and support service to users and use the money to hire developers.
sva_ | an hour ago
lloeki | an hour ago
FTFY, e.g nvim-treesitter:
https://github.com/nvim-treesitter/nvim-treesitter/discussio...
Aurornis | an hour ago
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.
sokoloff | an hour ago
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 they can keep their empire. That seems fine; they didn’t want to go east, the fork going east means that those users who also want to go east can be served.
charcircuit | an hour ago
This is not dead. Open source projects don't have to be developed out in the open.
MeetingsBrowser | 58 minutes ago
[OP] chmaynard | an hour ago
Lammy | 35 minutes ago
usernametaken29 | an hour ago
MeetingsBrowser | an hour ago
It sounds like the same problems would apply, only now per type and function rather than per library.
When a function you rely on is abandoned, how do you choose from the millions of options that may or may not behave the same?
How do you scale that across a codebase itself made of thousands of types and functions.
lelanthran | 51 minutes ago
Like leftpad?
kittikitti | 49 minutes ago
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 | 25 minutes ago
prymitive | 21 minutes ago
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 | 15 minutes ago
https://m.youtube.com/watch?v=IJNR2EpS0jw
https://m.youtube.com/watch?v=eq-GYfRjxhM
https://m.youtube.com/watch?v=yhJJws3kgzY
ChrisMarshallNY | 12 minutes ago
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.