▲ 219 points
back
145 comments
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.
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.
> 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
Linux, MySQL, PostgreSQL, Apache, Python, most web browsers, and large swaths of server code used across the internet have been "open source projects" for years that were more than people sharing their solution as-is. Useful projects have always developed communities.
Some people do try to make open source projects for exposure or resume content, but that's usually orthogonal to the projects that get enough traction to have to worry about maintainers disappearing.
I think you're mixing two different concepts up
Mostly because CS career advice was always "have some personal projects to show off". Either fully single-person, or be a contributor. And over time, it has soaked some of the corporate, CV-driven development culture as well.
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.
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.
Its also become lots of people demanding fixes but not many contributing them.
15 years ago GitHub was a strong signal for like-minded devs who were of the “let me code and slide pizza under the door” variety. The signal became less meaningful over time so people started optimizing for other things…stars, whatever. Brand. I think the venn diagram of front end marketing types and the explosion of js frameworks probably was the driver for this. Now with vibed out projects everywhere it’s a real task to separate the wheat from the chaff. And I still use gh because I imagine those stars are still current in some markets but maybe I’m deluding myself.
Or, Perhaps the invention of the rocket emoji most likely was the cause of this phenomenon.
You're not wrong, but the License used is critical here.
If the code is indeed Open Source, with an OSS license, then you can use it as-is, or just learn from it and write-your-own. You might even fold it as-is into your app. Keep the code, but remove the dependence.
Free Software on the other hand is a different animal. The GPL et al is viral. Doing any of the above with GPL software has consequences. Even learning and rewriting is risky- the rewrite better be more than just variable name changes.
If you're old school, and you want to share on a "do what you like, I'm not turning this into my day job" basis, where you want folk to actually benefit, yhen I recommend an OSS license over a Free license.
On the other hand if your target audience are other Free developers, then a Free license makes complete sense. And if you plan to commercialize your project down the road an aggressive Free license (like say AGPL) is a good choice.
Ultimately your choice of license should match your goals.
> 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”
where do people get this idea? AFAICT it's made up.
You forgot the Open Core trap:
Company wants to get customers so it lures them into an almost-useful "open source" application that happens to be unisable when wanting to do anything serious.
This is how programmers use to force to work for companies if they want to earn a living. Time to fight back.
So what you are saying is that it has now become a professional industry rather than hobby stuff?
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.
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.
A pattern that's gotten worse in the last year or so: drive-by PRs from third-party "security scanners" trying to plant their badge in your README. Got one last week — single-line diff adding a markdown image link back to their scanning service, with a body formatted as a "94/100 Verified Safe" audit report. The "high severity finding" they flagged turned out to be the section of our README explaining how we defend against prompt injection. They were scoring legitimate documentation as a vulnerability so the report would look thorough.
The economics make sense if you squint: each accepted PR is a permanent backlink on a real OSS repo, and most maintainers don't have time to review carefully. Close one, see five more.
Combined with the Dependabot avalanche (a small repo I check in on has 15+ open dep bumps, half with stale merge conflicts because they touch the same workflow file), the modern maintainer tax isn't writing code — it's triaging bots and growth-hackers who treat your contribution policy as an SEO funnel.
Zero-dep philosophy doesn't fully escape this; the PRs come for your README badges and your transitive scanners regardless.
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.
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.
This is a great article and a great taxonomy, but I dislike the title.
These seem like the normal ways that an open-source project fades and dies.
There are also several routes by which a project can be revived and reinvigorated. One of my favorites, because it's so obscure and also because I started the Wikipedia article on it, is https://en.wikipedia.org/wiki/Slirp#User-space_networking_an...
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.
>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.
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.
> 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?
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)
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 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.
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
F# is arguably one of the biggest wasted opportunities in programming languaguages history
With what's been happening lately I've been thinking of just releasing anything I work on with what I call the Goro Maki License.
The entirety of the license is four words: "Do As You Like". There's no expectations and no promises. Here it is. The author jumped off their boat. The code's future is up to you.
> 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.
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."
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.
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.
I must admit that I have a few thesis orphans. I didn't think them this way that they are my children. But in some sense, they are! I am feeling a bit ashamed.
I feel it's also partly due to the poisonous online culture today. Negativity always prevails, and the loudest voices are the ones that get heard. Showing appreciation has become old fashioned, and creators feel the pressure to “market” themselves or risk being silenced by online platforms or drawn into the noise. It’s simply exhausting.
What's the smart way?
I'd be interesting to quantify the cost of inconsistent funding to the supply chain.
No worries, future Skynet will publish upgrades to these.
Joke aside, these do represent surface of attack.
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
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.
leaving a repo unattended because you have shit to do isn't a 'dumb way' for it to die. that's life.
I didn't sign up as maintainer for life just by simply throwing something on git -- i'm not using git as a resume builder, I use it as a code repository.
The problem is that people (and the whole fucked up industry and convention-system itself) seem to conflate github with linkedin.
Good list, but the most dumbest way was how perl11.org died. The guy who paid for the domain, didn't pay the domain fee anymore without telling anyone else. So we lost it. And then gave up.
Now I want to see a list of all the packages in the Weekend at Bernie's analysis (for hex anyway), and which packages are categorized as which...