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”
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 problem. People with the "here's my private workflow tool" mindset increasingly don't publish at all because they can't afford that tax. Meanwhile, anyone seeking brand-building benefits IS willing to take it on, because the brand-building is the point.
So the visible OSS landscape over-represents the brand category not because solution-sharing died, but because solution-sharing acquired a 10x maintenance overhead that most people now opt out of. I see it in my own dotfiles — full of small tools I'd happily share if "share" still meant "drop a gist." It doesn't, anymore.
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.
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.
Occasionally though, rather than petering out, you get a rage-fork that does something good.
The io.js fork from node back in 2014 or 2015 springs to mind. IIRC there were a bunch of changes/improvements that needed to be made to move node forward and Joyent were dragging their heels (a V8 upgrade might have been one of them but it's been so long I can't remember for sure). Some of the core devs were getting fed up with how long all of this was taking.
So a group of them forked off io.js from node, did the upgrade and a bunch of other improvements, and eventually all of that was folded back into core node, and everyone was happy with the final result.
But I think we could have found ourselves in a world where we'd all be using io.js rather than node had it turned out slightly differently.
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 change. Often, low-level engine APIs are very stable and essentially never change... So why should the software built on top change?
According to OP, the kind of reliable software that we need in the AI slop era would fall in the category of 'dead project'. So they are doomed to create AI slop on top of other AI slop. Good luck to them.
The need for security update is largely due to poor development practices where safe and unsafe code is mixed together, lots of dependencies with unclear provenance and quality, etc.
We had a recipe for a much stabler stack decades ago: separate runtime (might need to be patched regularly) from a high-level business logic (never needs to be patched if done properly).
E.g. old way of developing web front-end was like that: you code directly in JS. It never needs to be patched, only browser needs to be patched.
Same thing with Excel/VBA, etc.
But new devs don't know any of that, they just want to use latest "framework" which pre-installs whole bunch of vulns. And if there's a patch you need to rebuild. Constant churn just to satisfy the trend
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.
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)
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.
I've invested time working with a project like that and it's kind of heartbreaking to see it lose its way and become a total mess. It's tempting to fork and try and go back to its roots, but that has its own problems e.g. needing to invest a magnitude more time.
So much this. Everyone has their own idea of that the project should do and it's hard to explain that whilst that implementation is great for their specific use case, it's pretty shit for everyone else.
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.
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 Knapsack-problem solver should never update.
These are problems that are hairy enough that I don't want to write my own solution, yet tractable enough that there ought to be a solution that never needs to be touched again. Maybe someone finds a better way of doing it, but the way they're currently doing it will never be wrong.
There are a few usecases for this in some languages, where your functions might as well be class extensions. But you need a huge standard library with non-competitive types, or you end up with deep dependency stacks.
You also run into trouble if your language has side effects (ie, almost all of them). A leftPad that launches a fiber to mine cryptocurrency or sends an http call that fires nuclear missiles can still pass tests. It's hard to guarantee hygiene via tests alone.
Your comment is easily misunderstood, my first thought was also “that’s NPM” - but the idea of providing tests and types without implementation is a pretty interesting one.
I mean in my head it is 'Plugin system', at least in the context of feature bloat.
Where it can get slightly hairy is that to do it well, you need to have a LOT of seams between layers.
> but the idea of providing tests and types without implementation is a pretty interesting one.
I feel like in my head, you need to have -some- baseline/example implementation; e.x. Akka/Pekko/Akka.NET have Plugin specs for Persistence but there's still a Memory-only implementation of Persistence as a reference/baseline; after all you need to make sure the spec is possible at all.
> 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.
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
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.
I think I know the pattern they are describing, and it's a semi-unfortunate one.
People make a fairly-complex open source thing. Due to the complexity for certain environments/cases, the author(s) have a commercial support option.
Consumers from bigorg use it, and wind up opening issues wanting free help for their niche use case, no they don't want to get a support contract, but this subset of the user base causes a lot of churn dealing with communication, politely closing such issues (after all, you want to just be polite about support options, not drive them away!)...
And sometimes, it becomes easier to just flip the license.
In the .NET ecosystem, it's come up frequently. There's the cases where I get it; PDF is hell (iTextSharp), Imaging is hell (ImageSharp), Auth is hell (IdentityServer).
But then there's the cases where I just shrug my shoulders (MediatR has plenty of alternatives) or get happy it gives me permission to gleefully get rid of a poorly used lib (AutoMapper).
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.
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.
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.
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”
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 problem. People with the "here's my private workflow tool" mindset increasingly don't publish at all because they can't afford that tax. Meanwhile, anyone seeking brand-building benefits IS willing to take it on, because the brand-building is the point.
So the visible OSS landscape over-represents the brand category not because solution-sharing died, but because solution-sharing acquired a 10x maintenance overhead that most people now opt out of. I see it in my own dotfiles — full of small tools I'd happily share if "share" still meant "drop a gist." It doesn't, anymore.
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.
Its also become lots of people demanding fixes but not many contributing them.
And there was a definite shift from sharing toward evangelism.
For example C was shared, C++ was evangelized. The difference is the effort put into convincing people to adopt your stuff.
Java for instance was mega evangelized, Sun thought it might reverse their fortunes.
Linux was initially “here you go, hope it works for you” but then it attracted many people who decided to create an ecosystem around it.
I imagine there's a similar same number of those style projects out there.
However, the amount of devs have grown exponentially, and the number of non-niche problems without a solution have dramatically decreased.
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 central trauma.
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.
Occasionally though, rather than petering out, you get a rage-fork that does something good.
The io.js fork from node back in 2014 or 2015 springs to mind. IIRC there were a bunch of changes/improvements that needed to be made to move node forward and Joyent were dragging their heels (a V8 upgrade might have been one of them but it's been so long I can't remember for sure). Some of the core devs were getting fed up with how long all of this was taking.
So a group of them forked off io.js from node, did the upgrade and a bunch of other improvements, and eventually all of that was folded back into core node, and everyone was happy with the final result.
But I think we could have found ourselves in a world where we'd all be using io.js rather than node had it turned out slightly differently.
Also the ECGS fork of GCC. That one ended happily, as, IIRC, the EGCS maintainers were assigned to be the official GCC maintainers.
> 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?
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 change. Often, low-level engine APIs are very stable and essentially never change... So why should the software built on top change?
According to OP, the kind of reliable software that we need in the AI slop era would fall in the category of 'dead project'. So they are doomed to create AI slop on top of other AI slop. Good luck to them.
Different times. The need to patch for security updates alone is increasing rapidly.
The need for security update is largely due to poor development practices where safe and unsafe code is mixed together, lots of dependencies with unclear provenance and quality, etc.
We had a recipe for a much stabler stack decades ago: separate runtime (might need to be patched regularly) from a high-level business logic (never needs to be patched if done properly).
E.g. old way of developing web front-end was like that: you code directly in JS. It never needs to be patched, only browser needs to be patched.
Same thing with Excel/VBA, etc.
But new devs don't know any of that, they just want to use latest "framework" which pre-installs whole bunch of vulns. And if there's a patch you need to rebuild. Constant churn just to satisfy the trend
Some things just don’t have security issues found regularly
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.
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)
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.
I've invested time working with a project like that and it's kind of heartbreaking to see it lose its way and become a total mess. It's tempting to fork and try and go back to its roots, but that has its own problems e.g. needing to invest a magnitude more time.
So much this. Everyone has their own idea of that the project should do and it's hard to explain that whilst that implementation is great for their specific use case, it's pretty shit for everyone else.
AI has just made this so much worse.
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.
Ignoring the GitHub Pages issue, What does Jekyll 4.x not-do that you want it to do?
> 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.
I wish more projects would archive themselves to send a clear signal.
F# is arguably one of the biggest wasted opportunities in programming languaguages history
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.
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 Knapsack-problem solver should never update.
These are problems that are hairy enough that I don't want to write my own solution, yet tractable enough that there ought to be a solution that never needs to be touched again. Maybe someone finds a better way of doing it, but the way they're currently doing it will never be wrong.
There are a few usecases for this in some languages, where your functions might as well be class extensions. But you need a huge standard library with non-competitive types, or you end up with deep dependency stacks.
You also run into trouble if your language has side effects (ie, almost all of them). A leftPad that launches a fiber to mine cryptocurrency or sends an http call that fires nuclear missiles can still pass tests. It's hard to guarantee hygiene via tests alone.
Your comment is easily misunderstood, my first thought was also “that’s NPM” - but the idea of providing tests and types without implementation is a pretty interesting one.
I mean in my head it is 'Plugin system', at least in the context of feature bloat.
Where it can get slightly hairy is that to do it well, you need to have a LOT of seams between layers.
> but the idea of providing tests and types without implementation is a pretty interesting one.
I feel like in my head, you need to have -some- baseline/example implementation; e.x. Akka/Pekko/Akka.NET have Plugin specs for Persistence but there's still a Memory-only implementation of Persistence as a reference/baseline; after all you need to make sure the spec is possible at all.
> 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.
Like leftpad?
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
> Someone [...] pissed the maintainer off enough to stop working on it
FTFY, e.g nvim-treesitter:
https://github.com/nvim-treesitter/nvim-treesitter/discussio...
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."
it says so at the end of the article
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.
I think I know the pattern they are describing, and it's a semi-unfortunate one.
People make a fairly-complex open source thing. Due to the complexity for certain environments/cases, the author(s) have a commercial support option.
Consumers from bigorg use it, and wind up opening issues wanting free help for their niche use case, no they don't want to get a support contract, but this subset of the user base causes a lot of churn dealing with communication, politely closing such issues (after all, you want to just be polite about support options, not drive them away!)...
And sometimes, it becomes easier to just flip the license.
In the .NET ecosystem, it's come up frequently. There's the cases where I get it; PDF is hell (iTextSharp), Imaging is hell (ImageSharp), Auth is hell (IdentityServer).
But then there's the cases where I just shrug my shoulders (MediatR has plenty of alternatives) or get happy it gives me permission to gleefully get rid of a poorly used lib (AutoMapper).
No worries, future Skynet will publish upgrades to these.
Joke aside, these do represent surface of attack.
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.
What's the smart way?
>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.
so, just be safe about it, i guess.
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?
The key term is "responsible sunsetting".
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.
Pay people
>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.
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.
[flagged]