Dumb ways for an open source project to die
1–10 of 155 posts
Re: Dumb ways for an open source project to die
#2One 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.
Re: Dumb ways for an open source project to die
#3What's the smart way?
Re: Dumb ways for an open source project to die
#4Here'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.
Re: Dumb ways for an open source project to die
#5Another 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
Re: Dumb ways for an open source project to die
#6What's the smart way?
The key term is "responsible sunsetting".
Re: Dumb ways for an open source project to die
#7A 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.
Re: Dumb ways for an open source project to die
#8[flagged]
Re: Dumb ways for an open source project to die
#9A 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 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.
Re: Dumb ways for an open source project to die
#10>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.