Good list, but the most dumbest way was how perl11.org died. The guy who paid for the domain, didn't pay the domain fee anymore without telling anyone else. So we lost it. And then gave up.
Dumb ways for an open source project to die
131–140 of 155 posts
Re: Dumb ways for an open source project to die
#132[deleted]
Re: Dumb ways for an open source project to die
#133Earlier quoted context omitted.
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.
Well if you're adding new dependencies you're already doing new maintenance work and this is a while different ballgame than just to keep what you have working.
Re: Dumb ways for an open source project to die
#134[flagged]
Re: Dumb ways for an open source project to die
#135One 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 w…
Beryl 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.
Re: Dumb ways for an open source project to die
#136> 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?
More 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.
Re: Dumb ways for an open source project to die
#137Earlier quoted context omitted.
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.
Letting 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.
Re: Dumb ways for an open source project to die
#138Call 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 simil…
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.
Many popular dependencies suffer from feature creep. Instead of doing one thing and doing it well, they do five different things, one of them is the one you need, another one introduces horrible vulnerabilities. Next version fill fix an existing vulnerability, but add a new feature with another horrible vulnerability... so all the versions except for the latest one are flagged as dangerous to use.
Re: Dumb ways for an open source project to die
#139Earlier quoted context omitted.
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 Kn…
In what ways do version pining/lockfiles not solve this problem?
Duplicate transitive dependencies throw a wrench in the lockfiles/pinning approach, since most package managers don't make it easy to install multiple versions of the same package (operating under the assumption that packages are large).
There's also a meaningful message difference when you look at a package page that says it's "done" as opposed "dead".
Re: Dumb ways for an open source project to die
#140Earlier quoted context omitted.
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…
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
The idea that everything is so broken that it needs to be patched is just wrong.
A C program which just manipulates strings and other data structures can have a remote code execution vulnerability because C is a shitty language with no memory safety, data and control flow can be mixed, etc.
But that's just not true for high level code, say, in Python. If you don't use some low-level hacks, Python code just cannot corrupt memory, by construction, and it cannot cause RCE. You can execute attacker's code only if you use a language function which might execute code, say, eval or unpickle. But there's only a handful of such constructions and Python developers could easily implement hardening which would forbid any such calls, guaranteeing that only code which was written by developer gets executed.
Yes, occasionally there might be a logic flaw in code which needs to fixed, but it's not same as weekly updates - framework version 1.2.3 uses package 4.5.6 which has a vuln. That's only recent lunacy.
I'm not saying that e.g. everything written in Python in safe - but that old platforms were almost ready for "works forever" software, and we don't have that anymore,.