9 ms·
Dumb ways for an open source project to die
- tomwheeler 5mo agoOne 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.
- bartread 5mo agoOccasionally 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.
- teddyh 5mo agoAlso 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.
- Izkata 5mo agoBeryl forked from Compiz and even though Compiz was the name people knew, Beryl was more popular for a while because it had like 10-20x more functionality out of the box. At some point they merged back together into Compiz Fusion and lost almost all that additional functionality, as well as most of the momentum it had, then was later renamed back to Compiz.
- chadgpt3 5mo agoWhat's the smart way?
- sva_ 5mo agoThe key term is "responsible sunsetting".
- HerbManic 5mo agoYep, 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.
- account42 5mo agoLetting your project die is a whole lot more responsible than picking a successor maintainer that you are not 100% sure you can trust to be a good steward.
- john_strinlai 5mo ago>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.
- Lerc 5mo agoI 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.
- ZeWaka 5mo ago
- ndepoel 5mo agoHere'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.
- foxglacier 5mo agoIt 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.
- to11mtm 5mo agoI 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).
- sva_ 5mo agoAnother 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 https://en.wikipedia.org/wiki/GIMPshop#Status
- lloeki 5mo ago> Someone [...] pissed the maintainer off enough to stop working on it FTFY, e.g nvim-treesitter: https://github.com/nvim-treesitter/nvim-treesitter/discussions/8627#discussioncomment-16442595 https://github.com/nvim-treesitter/nvim-treesitter/discussio...
- deleted 5mo ago[deleted]
- Aurornis 5mo agoA 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.
- sokoloff 5mo agoIt 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.
- singpolyma3 5mo agoAs 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.
- Aurornis 5mo ago> 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.
- 2OEH8eoCRo0 5mo ago[flagged]
- charcircuit 5mo ago>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.
- deleted 5mo ago[deleted]
- chmaynard 5mo agoThen 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.
- usernametaken29 5mo agoI 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.
- deleted 5mo ago[deleted]
- lelanthran 5mo ago> 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?
- usernametaken29 5mo agoUnlike 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
- ricardobeat 5mo agoYour 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.
- to11mtm 5mo agoI 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.
- kittikitti 5mo agoI 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.
- VimEscapeArtist 5mo agoF# is arguably one of the biggest wasted opportunities in programming languaguages history
- prymitive 5mo agoCall 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”
- avaer 5mo agoThere 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.
- deleted 5mo ago[deleted]
- marcus_holmes 5mo agoI 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 :)
- avaer 5mo agoThanks for the tip! I'm pretty jaded on social media but you gave me a spark of hope.
- gkoberger 5mo agoI 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.
- chasil 5mo agoIs this a play on the rail safety videos? https://m.youtube.com/watch?v=IJNR2EpS0jw https://m.youtube.com/watch?v=IJNR2EpS0jw https://m.youtube.com/watch?v=eq-GYfRjxhM https://m.youtube.com/watch?v=eq-GYfRjxhM https://m.youtube.com/watch?v=yhJJws3kgzY 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."
- 1-more 5mo agoit says so at the end of the article
- ChrisMarshallNY 5mo ago> 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.
- esafak 5mo agoI wish more projects would archive themselves to send a clear signal.
- sebastianconcpt 5mo agoNo worries, future Skynet will publish upgrades to these. Joke aside, these do represent surface of attack.
- killerstorm 5mo agoIt'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/ https://sapaclisp.common-lisp.dev/ you can download code written in 1993 and just load it in latest SBCL.
- cebert 5mo agoDifferent times. The need to patch for security updates alone is increasing rapidly.
- aetch 5mo agoSome things just don’t have security issues found regularly
- killerstorm 5mo agoThe 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
- daedrdev 5mo agoOr 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
- 5mo ago
- apollyx_jojo 5mo agoOne 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.
- jamesu 5mo agoI'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.
- ferngodfather 5mo agoSo 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.
- hilariously 5mo agoIt'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.
- Gigachad 5mo agoYou 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.
- Brian_K_White 5mo agoI 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.
- mickael-kerjean 5mo agoTell that to CVEs
- Brian_K_White 5mo agoTell me how they matter. They don't. If some code is so old or un-used that you would call it "dead" then there are no cve's on it. No one is using it to discover a vulerability, no one is studying it to find a vulnerability, who writes these supposed cves? Even if by some miraculous combination of unlikely contrived coincidenses, someone researches, discoveres, writes up, and submits a cve, and the tracking orgs accept and publish it, so what? You just called it "dead" so who does it affect? What does this "cve" matter? If they do matter because there are users, then it's not "dead". It's just code that exists that may or may not be useful or interesting to someone sometime for something, or not, like a novel or song or painting. If it's half-baked code with some problem if it were used exactly as it sits with no further work, so what?
- zem 5mo agothat 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)
- armada651 5mo ago> 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?
- account42 5mo agoMore important is, how you know that those prospective maintainers won't just use the reputation you build to ship malware. Death is not the worst thing that can happen to an open source project.
- tamimio 5mo agoVery 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.
- marcus_holmes 5mo agoI 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.
- tamimio 5mo ago> 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.
- lacewing 5mo agoThis 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.
- nickjj 5mo agoAnother 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 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 https://github.com/nickjj/docker-flask-example [1]: https://github.com/nickjj/docker-rails-example https://github.com/nickjj/docker-rails-example [2]: https://github.com/nickjj/docker-django-example https://github.com/nickjj/docker-django-example [3]: https://github.com/nickjj/docker-node-example https://github.com/nickjj/docker-node-example
- david_draco 5mo agoI'd be interesting to quantify the cost of inconsistent funding to the supply chain.
- Onplana 5mo agoA 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.
- rectang 5mo agoThis 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.
- sbinnee 5mo agoI 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.
- em-bee 5mo agoit is unfortunate the there is little motivation to publish thesis projects to a wider audience. not to blame the authors here, because that is how the system works. exceptions require extraordinary effort or extrinsic motivation. one project i am working with got a grant that was conditioned on the project being published as open source. it motivated the developers/researchers to reach out to the wider community and even package the project for a linux distribution. that's how i was able to find out about it. i got involved and i am still using it 20 years later. but without that grant this likely would not have happened.
- zhxiaoliang 5mo agoI 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.
- serf 5mo agoleaving 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.
- dlenski 5mo agoThis 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_and_libslirp https://en.wikipedia.org/wiki/Slirp#User-space_networking_an...
- busterarm 5mo agoWith 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.
- rurban 5mo agoGood 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.
- em-bee 5mo agoFOSS projects should register their domains with providers that allow anyone to pay the fee for a domain, even if they don't own it. then, instead of depending on one person, anyone in the community can pay directly to ensure that the domain is renewed.
- rurban 5mo agoGood idea. Which providers allow this?
- em-bee 5mo agoi am afraid i don't have a good answer for now. it used to be gandi, and they may still support it, but since they sold out they massively raised the prices so they can no longer be recommended.
- rurban 5mo agoYes, I switched from namecheap to gandi some years ago. But it went to shit lately
- deleted 5mo ago[deleted]
- throwawaypath 5mo ago[flagged]
- sevenseacat 5mo agoNow 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...