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”
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.
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.
Do you all really have your random public git repos accidentally being used in production by Facebook? No one’s ever made one of my one-commit git repos a key component of corporate infrastructure.
Or do you mean that the meaning of what it is to “publish” something has shifted?
Exactly, I’m confused why people are feeling obligated to put more effort than they have interest for these projects. If Facebook did start using my project in production, then that would of course be their dumb decision that they would be responsible to fix!
Love this. Gonna add it to a few of mine that are quasi abandoned because I'm too burned-out to wade back into them in any detail, per one of the categories described in the article.
> 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.
Some tools I use, like msmtp[0] just publish tarballs and maybe have git repo browser. I strongly believe that github is a tarpit for opensource work. Especially when a new developer is brainwashed in behaving like they’re a business under contract.
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.
This is why is like pure C/C++ projects with zero dependencies beyond the standard library, and this is certainly what I do for my numerical work. If some external library is needed, the source files of the dependency are downloaded, compiled, and kept as part of the project itself, so that it can always be rebuilt and reused if necessary. Of course, depending on what you do, this may not be practical, although LLMs certainly have made it much easier to generate the dependencies in house, so to speak.
Fair counter, and that's the right stance. The tax I'm pointing at is the implicit social one: feeling like you owe a response. Plenty of publishers get burned out before they figure out your model.
they exist, but they are likely unmaintained, and may have known security issues.
i have a project that suffers from that. the version of a library it is built with is old and unsecure, but the newer supported version has a completely different API that would require me to rewrite the code that uses the library.
i had a second such case where i discovered a fork of the old version of the library which was still maintained. otherwise there too a rewrite would have been required.
In my experience, the most common problem is that a dependency changes. It drops support for something, API changing, etc. If it's 3 dependencies deep, and one of the deps in the middle isn't maintained anymore, well...
> 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.
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.
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.
The signal of quality for me is the number of contributors and the age of the repo. If I see a repo that's several years old and has many contributes over that time it's very likely a reputable project with some value. If I see a 1 month old repo with one user who has dumped the whole thing and then done nothing since, it's likely vibeslop that will be abandoned in a month.
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.
This is basically a problem with Open Source hosted at Github, right? Because Github doesn't allow you to turn off PRs for people outside your organization.
Since Github has been asked to change this policy since time immemorial and has not responded, another possible response is to host your project somewhere else that doesn't have the same policy and/or doesn't have the same volume of spammers. Of course that means that you don't get the benefits of hosting at Github, but the cost/benefit ratio of hosting there has changed over time.
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 EGCS fork of GCC. That one ended happily, as, IIRC, the EGCS maintainers were assigned (by the GNU project) to be the new official GCC maintainers.
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.
You also get people who dump a feature in a PR you don't particularly care about, then that submitter leaves and ages later people start reporting bugs or requests on the feature you didn't even want in the first place.
It's even worse when you are telling the solo maintainer that this is where its going and they just keep accepting every minor contribution to make people happy and boost them if they can.
It's not a bad idea but it ends with just a huge mess of crap.
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.
The reality I keep running into: software that "just works for years" requires dependency hygiene at the ecosystem level, not just the application level. You can write Common Lisp or C or even most of Go that way and your code will still run in 20 years. The moment you depend on a modern frontend framework or even a modern backend one, you've committed to following its release cadence — which is often "we deprecate things twice a year."
Framework authors have their own incentives (relevance, employment, hiring funnel) and aren't optimizing for your project's longevity. The only way to write 20-year code today is either (a) work in an ecosystem that genuinely values stability (Lisp, C, parts of Erlang/OTP, Postgres) or (b) accept the tax of a modern stack and budget for it explicitly.
Most teams do neither, which is when projects rot fastest.
> even most of Go that way and your code will still run in 20 years
While reading this, I was literally working on patching my open source go app [1] because this is what came out of the stdlib in the last few months: CVE-2025-30204, CVE-2026-33487, CVE-2026-25679, CVE-2026-27137, CVE-2026-32280, CVE-2026-32281, CVE-2026-32283, CVE-2026-33810, CVE-2026-33811, CVE-2026-33814, CVE-2026-39820, CVE-2026-39836, CVE-2026-42499
Until you run out of hardware that can run an OS old enough that the old version of the framework works, sure. Even then, you may find it hard to add new dependencies without getting current on the framework, since most ecosystems require you to pick a winning version in the case of a "diamond" transitive dependency.
You can, and sometimes that's the right answer. Where it gets hard: security CVEs that need patching but the fix is only in the new major, transitive deps that bump and bring incompatibilities, hiring a contractor who doesn't know your locked version. None of those are insurmountable, but they're real tax.
the problem is that you have to keep all the artifacts around so you can keep building with the old framework. especially in the npm world that is incredibly annoying. my solution for javascript at least is to avoid build tools alltogether, and build the site in such a way that it runs without a build step only using frameworks that support that. since the code runs in the browser there are no security concerns because you can't trust that code anyways.
Which brings us to the next layer of modern dependency management insanity:
The fact that basically none of these multi-million dollar companies are vendoring their entire dependency tree.
At most companies, even ones worth millions of dollars, it would be impossible for them to rebuild their software if someone ripped a package off of npm’s registry or whatever.
Different languages definitely have differently expectations and cultures around this stuff. If an npm package hasn’t been updated in 2 years, I’m suspicious. I’m gonna check the downloads, check GitHub issues and stuff to see kind of problems people are having, Google around to see if people are using something else.
If a clojars package hasn’t been updated in 6 years, I don’t even think about it!!
Anything connected to the internet or integrated with 3rd party systems will have to be maintained regularly forever. Anything that is self contained will last forever.
Main reason I avoid buying anything that requires an app. Because one day that app won't be maintained anymore and it just wont work, bricking the hardware in the process.
This again! Software can be both _mature_ and _useful_. If you trip across a piece of software that's both of mature and useful, your first action should be clone it's git repo into your own storage and save project state. Then you should work against your repo posting pull requests for the greater community. But if no one consumes the pull requests, move on.
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
Or in the past code just sat unpatched via obscurity because fewer people were looking. After all there are plenty of exploits from injection to CSS that we have fixed or migrated away from for code from the far past
Separating the runtime from the business logic doesn't really work because the business logic has the authority to do anything it has the authority to do. It's the https://xkcd.com/1200/ problem all over again.
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.
> The person planning the fork presumably views the mainline project maintainers somewhat negatively in that moment as well.
This isn’t necessary. Maybe not even common. Forks can start as a testing ground or an experimental feature fork and grow from there.
We see headlines about the angry forks, but usually it’s just friendly differences.
The problems arise when one person wants to control the project, deny contributions, but also gets angry when someone forks the project to implement those things. They put the open source license on the repo but didn’t expect other people to actually do open source things with it.
As a maintainer of a fork I don't think this is true. Upstream is perfectly fine and nice people, just with different needs than my community. So rather than try to scope creep their nice project, we work on a fork. Everyone wins.
If the license is open source there's nothing a maintainer can do except whine when you fork. Stick your fingers in yours (metaphorical) ears and keep on working.
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 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.
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.
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 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.
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.
The person I was discussing this with was indeed working on lambda calculus and provability of side effects. At least in theory it is possible to account for all classes of side effects and remove any risk.
Also, what other people have said here, functions can be immutable artefacts with a fixed hash (just their own content) which mitigates a whole cluster of supply chain issues at once
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.
> 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.
Unlike a dependency a function is an immutable artefact. You write it once, done, you get a checksum that matches that exactly. You can even guarantee it’s the function because of it… so not really at all like leftpad or npm, where commit hashes and versions are only loosely correlated to actual code
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.
I think the biggest adoption stopper would be that building a dependency chain (like say a JSON parser) could already be quite many functions. As the end user you don’t care about the architecture of JSON, you just want to consume it and get an object. In the end you might virtually end up with libraries again, because in some sense abstractions over functions are libraries.
There’d still be a win though because if you store the execution AST in a common database you can provide consistently tested primitives over many languages…
However I think outside of functional programming circles no one really actually cares enough about this to tackle it
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
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.
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).
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.
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 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.
Time passes. Do you know what its like talking to a group of game developers, and finding out none of them knew what an Amiga was.
I try to rage against the dying of the light, with limited success.
When my daughter went into a classroom (middle school I believe is the US term) that was not her own, a surprised teacher asked "Who are you?" She immediately responded with "I'm the new number two, you are number six"
The teacher did not get the reference, but I won parenting that day.
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 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.
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.
I work on a ton of different stuff, and this clause comes up for every job. I get them to remove it, or I don't accept the job offer.
For me, this is a red/green flag on management. The clause is legal boilerplate, inserted because it's standard and they can. They don't actually care that much about anything you might build outside of work. If they won't (or can't) remove it then the organisation is inflexible and the people who are hiring me have no power within it. Or the people who are hiring me don't understand my point of view. This is a bad sign either way.
I have had one "win" with it; I worked for a company run by a trio of absolute arseholes. One of them called a meeting and tried to bully me into handing over one of my projects because of this clause. I explained that my contract didn't have that clause because they removed it before I signed it. He got angry. But couldn't actually do anything about it.
> remove it then the organisation is inflexible and the people who are hiring me have no power within it
Bingo. That’s my assessment as well, usually this stage is where any company tries to show their best behavior, good way to filter out the bad ones. But surprisingly it’s getting very common, contracts used to be before a one pager stating the salary and some other benefits, right now it’s a submission contract, and setting up the power dynamics before you even do anything. Another contract I turned down was also full of questionable clauses (like you should work more than 48h a week when needed, overriding the common law with maximum 48hrs, and up to interpretation: “needed”), and none of the benefits discussed were written there, not even a reference to XYZ internal policy or similar, meanwhile, they had so much written against you not just while doing the work but even after you leave, that they could ruin your future career if they chose to. I believe there should be a federal centralized system govern these contracts and ensure each contract is in compliance, easy to implement by having a contract builder that add clauses to it while giving margin to each party to customize other clauses to their liking. Otherwise, a lot of people will get exploited, that contract I had with that company they refused to change anything justified by it being a “template”.. it doesn’t feel like a contract anymore since contracts are made to be negotiated, it feels like signing up for a SaaS service where if you don’t agree to the entirety of it, you are out, except for jobs you’re not the customer.
> 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
PSA: If you're in California, these kinds of employment contract terms are (mostly) illegal and unenforceable.
Labor Code 2870 outright invalidates any employment contract provision which attempts to claim ownership of IP rights to anything “that the employee developed entirely on his or her own time without using the employer’s equipment, supplies, facilities, or trade secret information” unless it relates to the employer's business or results from other work performed for the employer.
Labor Code 96(k) prohibits employers for disciplining or firing an employee who engages in “lawful conduct occurring during nonworking hours away from the employer’s premises,” with an exception for contracts that prohibit conduct by the employee that is in direct conflict with the employer’s “essential enterprise-related interests.”
So blanket prohibitions are out. If you're doing something that closely relates to your employer's products/business or could be construed as a conflict of interest, that's when you should consider written permission, but a company can't say “no” unless it actually relates to the company's business.
California is relatively unique in these worker protections, and they're a big reason why Silicon Valley became what it is.
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.
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.
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”
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.
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.
Do you all really have your random public git repos accidentally being used in production by Facebook? No one’s ever made one of my one-commit git repos a key component of corporate infrastructure.
Or do you mean that the meaning of what it is to “publish” something has shifted?
Exactly, I’m confused why people are feeling obligated to put more effort than they have interest for these projects. If Facebook did start using my project in production, then that would of course be their dumb decision that they would be responsible to fix!
I still publish everything. If someone wants to come and ask me to do something they can happily find out I likely will not.
> I'd happily share if "share" still meant "drop a gist." It doesn't, anymore.
It still does. Feel free to use https://unmaintained.tech/ on your repo.
Love this. Gonna add it to a few of mine that are quasi abandoned because I'm too burned-out to wade back into them in any detail, per one of the categories described in the article.
> 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.
Some tools I use, like msmtp[0] just publish tarballs and maybe have git repo browser. I strongly believe that github is a tarpit for opensource work. Especially when a new developer is brainwashed in behaving like they’re a business under contract.
[0] https://marlam.de/msmtp/download/
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.
This is why is like pure C/C++ projects with zero dependencies beyond the standard library, and this is certainly what I do for my numerical work. If some external library is needed, the source files of the dependency are downloaded, compiled, and kept as part of the project itself, so that it can always be rebuilt and reused if necessary. Of course, depending on what you do, this may not be practical, although LLMs certainly have made it much easier to generate the dependencies in house, so to speak.
Do the versions of the dependencies that you used no longer exist anywhere?
Fair counter, and that's the right stance. The tax I'm pointing at is the implicit social one: feeling like you owe a response. Plenty of publishers get burned out before they figure out your model.
they exist, but they are likely unmaintained, and may have known security issues.
i have a project that suffers from that. the version of a library it is built with is old and unsecure, but the newer supported version has a completely different API that would require me to rewrite the code that uses the library.
i had a second such case where i discovered a fork of the old version of the library which was still maintained. otherwise there too a rewrite would have been required.
In my experience, the most common problem is that a dependency changes. It drops support for something, API changing, etc. If it's 3 dependencies deep, and one of the deps in the middle isn't maintained anymore, well...
> 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
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.
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.
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.
The signal of quality for me is the number of contributors and the age of the repo. If I see a repo that's several years old and has many contributes over that time it's very likely a reputable project with some value. If I see a 1 month old repo with one user who has dumped the whole thing and then done nothing since, it's likely vibeslop that will be abandoned in a month.
> 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.
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 found Mastodon, feels like usenet in about 1993.
There are odd corners of the web that still work on RSS, and just have people sharing stuff.
But yeah, the entire of mainstream internet discourse can be safely ignored.
HN, though, I still like it here :)
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.
This is basically a problem with Open Source hosted at Github, right? Because Github doesn't allow you to turn off PRs for people outside your organization.
Since Github has been asked to change this policy since time immemorial and has not responded, another possible response is to host your project somewhere else that doesn't have the same policy and/or doesn't have the same volume of spammers. Of course that means that you don't get the benefits of hosting at Github, but the cost/benefit ratio of hosting there has changed over time.
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 EGCS fork of GCC. That one ended happily, as, IIRC, the EGCS maintainers were assigned (by the GNU project) to be the new official GCC maintainers.
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.
You also get people who dump a feature in a PR you don't particularly care about, then that submitter leaves and ages later people start reporting bugs or requests on the feature you didn't even want in the first place.
It's even worse when you are telling the solo maintainer that this is where its going and they just keep accepting every minor contribution to make people happy and boost them if they can.
It's not a bad idea but it ends with just a huge mess of crap.
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.
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.
The reality I keep running into: software that "just works for years" requires dependency hygiene at the ecosystem level, not just the application level. You can write Common Lisp or C or even most of Go that way and your code will still run in 20 years. The moment you depend on a modern frontend framework or even a modern backend one, you've committed to following its release cadence — which is often "we deprecate things twice a year."
Framework authors have their own incentives (relevance, employment, hiring funnel) and aren't optimizing for your project's longevity. The only way to write 20-year code today is either (a) work in an ecosystem that genuinely values stability (Lisp, C, parts of Erlang/OTP, Postgres) or (b) accept the tax of a modern stack and budget for it explicitly.
Most teams do neither, which is when projects rot fastest.
> even most of Go that way and your code will still run in 20 years
While reading this, I was literally working on patching my open source go app [1] because this is what came out of the stdlib in the last few months: CVE-2025-30204, CVE-2026-33487, CVE-2026-25679, CVE-2026-27137, CVE-2026-32280, CVE-2026-32281, CVE-2026-32283, CVE-2026-33810, CVE-2026-33811, CVE-2026-33814, CVE-2026-39820, CVE-2026-39836, CVE-2026-42499
ref: https://github.com/mickael-kerjean/filestash
Unless you just... Keep using the old version of the framework? No one is making you upgrade
Until you run out of hardware that can run an OS old enough that the old version of the framework works, sure. Even then, you may find it hard to add new dependencies without getting current on the framework, since most ecosystems require you to pick a winning version in the case of a "diamond" transitive dependency.
You can, and sometimes that's the right answer. Where it gets hard: security CVEs that need patching but the fix is only in the new major, transitive deps that bump and bring incompatibilities, hiring a contractor who doesn't know your locked version. None of those are insurmountable, but they're real tax.
the problem is that you have to keep all the artifacts around so you can keep building with the old framework. especially in the npm world that is incredibly annoying. my solution for javascript at least is to avoid build tools alltogether, and build the site in such a way that it runs without a build step only using frameworks that support that. since the code runs in the browser there are no security concerns because you can't trust that code anyways.
Which brings us to the next layer of modern dependency management insanity:
The fact that basically none of these multi-million dollar companies are vendoring their entire dependency tree.
At most companies, even ones worth millions of dollars, it would be impossible for them to rebuild their software if someone ripped a package off of npm’s registry or whatever.
Different languages definitely have differently expectations and cultures around this stuff. If an npm package hasn’t been updated in 2 years, I’m suspicious. I’m gonna check the downloads, check GitHub issues and stuff to see kind of problems people are having, Google around to see if people are using something else.
If a clojars package hasn’t been updated in 6 years, I don’t even think about it!!
Anything connected to the internet or integrated with 3rd party systems will have to be maintained regularly forever. Anything that is self contained will last forever.
Main reason I avoid buying anything that requires an app. Because one day that app won't be maintained anymore and it just wont work, bricking the hardware in the process.
This again! Software can be both _mature_ and _useful_. If you trip across a piece of software that's both of mature and useful, your first action should be clone it's git repo into your own storage and save project state. Then you should work against your repo posting pull requests for the greater community. But if no one consumes the pull requests, move on.
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.
Unless you code doesn't speak to a network or any untrusted user. But people are making software that fits this criteria less and less often.
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
Or in the past code just sat unpatched via obscurity because fewer people were looking. After all there are plenty of exploits from injection to CSS that we have fixed or migrated away from for code from the far past
Separating the runtime from the business logic doesn't really work because the business logic has the authority to do anything it has the authority to do. It's the https://xkcd.com/1200/ problem all over again.
Some things just don’t have security issues found regularly
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...
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.
> The person planning the fork presumably views the mainline project maintainers somewhat negatively in that moment as well.
This isn’t necessary. Maybe not even common. Forks can start as a testing ground or an experimental feature fork and grow from there.
We see headlines about the angry forks, but usually it’s just friendly differences.
The problems arise when one person wants to control the project, deny contributions, but also gets angry when someone forks the project to implement those things. They put the open source license on the repo but didn’t expect other people to actually do open source things with it.
As a maintainer of a fork I don't think this is true. Upstream is perfectly fine and nice people, just with different needs than my community. So rather than try to scope creep their nice project, we work on a fork. Everyone wins.
If the license is open source there's nothing a maintainer can do except whine when you fork. Stick your fingers in yours (metaphorical) ears and keep on working.
> 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?
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?
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.
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.
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)
It's just a fun reference to a song/psa ad called "Dumb Ways To Die"
oh, wasn't aware of the song so i missed that entirely :)
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.
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.
The person I was discussing this with was indeed working on lambda calculus and provability of side effects. At least in theory it is possible to account for all classes of side effects and remove any risk. Also, what other people have said here, functions can be immutable artefacts with a fixed hash (just their own content) which mitigates a whole cluster of supply chain issues at once
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.
In what ways do version pining/lockfiles not solve this problem?
I think the function should be anonymous (have no name). Import should name it.
> 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?
Unlike a dependency a function is an immutable artefact. You write it once, done, you get a checksum that matches that exactly. You can even guarantee it’s the function because of it… so not really at all like leftpad or npm, where commit hashes and versions are only loosely correlated to actual code
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.
I think the biggest adoption stopper would be that building a dependency chain (like say a JSON parser) could already be quite many functions. As the end user you don’t care about the architecture of JSON, you just want to consume it and get an object. In the end you might virtually end up with libraries again, because in some sense abstractions over functions are libraries. There’d still be a win though because if you store the execution AST in a common database you can provide consistently tested primitives over many languages… However I think outside of functional programming circles no one really actually cares enough about this to tackle it
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...
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.
I wish more projects would archive themselves to send a clear signal.
I'd be interesting to quantify the cost of inconsistent funding to the supply chain.
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).
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.
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
[2]: https://github.com/nickjj/docker-django-example
[3]: https://github.com/nickjj/docker-node-example
No worries, future Skynet will publish upgrades to these.
Joke aside, these do represent surface of attack.
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?
Time passes. Do you know what its like talking to a group of game developers, and finding out none of them knew what an Amiga was.
I try to rage against the dying of the light, with limited success.
When my daughter went into a classroom (middle school I believe is the US term) that was not her own, a surprised teacher asked "Who are you?" She immediately responded with "I'm the new number two, you are number six"
The teacher did not get the reference, but I won parenting that day.
Whatever age range you have to be in to remember the most viral videos from 2012, some measurable percentage of HN's readership probably aren't in it.
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.
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
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.
Tell that to CVEs
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.
I work on a ton of different stuff, and this clause comes up for every job. I get them to remove it, or I don't accept the job offer.
For me, this is a red/green flag on management. The clause is legal boilerplate, inserted because it's standard and they can. They don't actually care that much about anything you might build outside of work. If they won't (or can't) remove it then the organisation is inflexible and the people who are hiring me have no power within it. Or the people who are hiring me don't understand my point of view. This is a bad sign either way.
I have had one "win" with it; I worked for a company run by a trio of absolute arseholes. One of them called a meeting and tried to bully me into handing over one of my projects because of this clause. I explained that my contract didn't have that clause because they removed it before I signed it. He got angry. But couldn't actually do anything about it.
> remove it then the organisation is inflexible and the people who are hiring me have no power within it
Bingo. That’s my assessment as well, usually this stage is where any company tries to show their best behavior, good way to filter out the bad ones. But surprisingly it’s getting very common, contracts used to be before a one pager stating the salary and some other benefits, right now it’s a submission contract, and setting up the power dynamics before you even do anything. Another contract I turned down was also full of questionable clauses (like you should work more than 48h a week when needed, overriding the common law with maximum 48hrs, and up to interpretation: “needed”), and none of the benefits discussed were written there, not even a reference to XYZ internal policy or similar, meanwhile, they had so much written against you not just while doing the work but even after you leave, that they could ruin your future career if they chose to. I believe there should be a federal centralized system govern these contracts and ensure each contract is in compliance, easy to implement by having a contract builder that add clauses to it while giving margin to each party to customize other clauses to their liking. Otherwise, a lot of people will get exploited, that contract I had with that company they refused to change anything justified by it being a “template”.. it doesn’t feel like a contract anymore since contracts are made to be negotiated, it feels like signing up for a SaaS service where if you don’t agree to the entirety of it, you are out, except for jobs you’re not the customer.
> 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
PSA: If you're in California, these kinds of employment contract terms are (mostly) illegal and unenforceable.
Labor Code 2870 outright invalidates any employment contract provision which attempts to claim ownership of IP rights to anything “that the employee developed entirely on his or her own time without using the employer’s equipment, supplies, facilities, or trade secret information” unless it relates to the employer's business or results from other work performed for the employer.
Labor Code 96(k) prohibits employers for disciplining or firing an employee who engages in “lawful conduct occurring during nonworking hours away from the employer’s premises,” with an exception for contracts that prohibit conduct by the employee that is in direct conflict with the employer’s “essential enterprise-related interests.”
So blanket prohibitions are out. If you're doing something that closely relates to your employer's products/business or could be construed as a conflict of interest, that's when you should consider written permission, but a company can't say “no” unless it actually relates to the company's business.
California is relatively unique in these worker protections, and they're a big reason why Silicon Valley became what it is.
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.
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.