4 ms·

I’m not sure this fits my experience. Once a project starts to lose momentum, not many turn that back around. “Code rot” is a real, if nebulous, thing. As less

I’m not sure this fits my experience. Once a project starts to lose momentum, not many turn that back around. “Code rot” is a real, if nebulous, thing. As less people regularly contribute, there is lost internal knowledge as to why certain decisions were made, roadmaps, what the core problem the library seeks to solve, etc. Basically OSS projects are as much the maintainers’ ambitions as they are the code themselves. Personally I am (I think rightfully) hesitant to use a library that hasn’t had a commit in years. Similarly, downward trends in usage are also a pre-indicator of a library’s long term health, as it can signal lack of user trust, better competition, or just that the original need isn’t quite there anymore. So you’re right that it can be picked back up, but I think in practice this is far from the most common outcome.

koito17 3y ago
While I agree lack of experience or internal knowledge is a problem for complex projects (ahem, etcd), most "dead" open source libraries IME suffer from these two properties: 1. the people with the commit bit in the original repository are all gone 2. people fork the repository to fix one minor thing, and never update again I've frequently ran into libraries where there are multiple forks with no activity, and it is not obvious whether there is a "best" choice of fork, and it is unlikely that the next fork will become the successor to the original project. There's a certain social problem that I can't describe very well. Projects should have a form of "succession planning" or else they end up in the state I just described (impossible to commit to the original repo, numerous inactive forks that merged 1 or 2 stale PRs).
- bjourne 3y ago
  2) is exactly what happened to the Python docopt project. It works well for most users but some corner cases trigger annoying bugs that are not fixed because the maintainer is mia. Lots of people have fixed the bugs in their own forks of docopt, but as there is not clear which if the forks is the "successor" to docopt, people keep running into the same bugs and keep forking over and over again.
bombcar 3y ago
The main thing I’ve run into is that you can’t build the project anymore. This is especially common, for example, if you want to revive the source of a Minecraft 1.7.10 mod, say. As more and more code build scripts pull in external things, the harder it is to get them running again years later.
- criley2 3y ago
  Is that actually challenging? My MC launcher can pull in 1.7.10, add a mod loader, and load mods into it just fine. Do you mean if you try to run a 1.7.10 mod in a modern MC version? That's not a realistic goal because of dramatic API changes between versions. There are a number of breaking versions that require basically rewriting mods. But you can still play the on the old version and most modded minecraft players are many breaking versions behind by default. This is the norm in most games, where game updates are routinely expected to break all backwards compatibility. And considering modding minecraft has never been officially supported, it's surprising it works as well as it does. I'm playing a 1.7.10 pack lately actually, still just as good as when it came out!
  - fao_ 3y ago
    Eh? The poster clearly said: > if you want to revive the source of a Minecraft 1.7.10 mod i.e. if you want to change/alter or recompile a mod for version 1.7.10 None of the things you have mentioned apply to this.
    - bombcar 3y ago
      Exactly. You can easily find compiled 1.7.10 mods everywhere, and even the source, but getting the source to build requires some work: https://github.com/GTNewHorizons/ExampleMod1.7.10 https://github.com/GTNewHorizons/ExampleMod1.7.10
ryandrake 3y ago
I’ve never liked the “code rot” euphemism. Code doesn’t rot. What happens is platforms change out from under your code by platform vendors who no longer give a shit about backwards compatibility. If you take a piece of application software, tar it up including its dependencies, you should be able to untar it 15 years later and it should compile and run. If it doesn’t, it’s not your fault as a developer—it’s the fault of everything else that changed and broke that previously working code. If vendors took compatibility seriously, we wouldn’t have “code rot”.
- bdzr 3y ago
  I'm not sure what a better term is, but I think the problem will exist anyway. 15 years of backwards compatibility from software that's often written by volunteers is unreasonable to say the least.
  - Falkon1313 3y ago
    >15 years of backwards compatibility [...] is unreasonable to say the least As a Windows user, it's sad that so many people think that way nowadays. I've encountered one DOS program from the early 90s that doesn't run anymore because it used its own custom memory management which newer systems don't allow, but that one was later re-released in an updated version that still works today. And there were one or two late-90s Windows programs that no longer run either because they have 16-bit components or depended on some then-standard now long-gone libraries to be on the system, but those run in a VM. Other than that, there is plenty of software dating back to the 90s, some to the 80s, that mostly still works fine. It doesn't need constant maintenance and updates. It worked about 30 years ago and still works today and should still work tomorrow. You'll find even older legacy code in major organizations that's still chugging along. That's hard to find in modern software. Now everyone always has to have the latest thing and it has to be updated almost every single day just to keep a massive chain of transitive dependencies from collapsing out from under it. I guess that's why people get rude and ask whether a project is 'dead' even though patches have been released for it multiple times within the last 10 years.
popularonion 3y ago
I’ve run into this with a niche but fairly popular open source program. It had been used by big tech cos for years, while the maintainers moved on one by one until the last guy who seems to have thrown in the towel in 2020. I considered picking it up, but I’d have to make some hard decisions about the code base that wouldn’t make everyone happy, and I just don’t have the context to do that. Another issue is the lack of testing infrastructure. So for everyone who still cares, the path of least resistance is to maintain their own fork or do a rewrite in a different language.

koito17 3y ago

While I agree lack of experience or internal knowledge is a problem for complex projects (ahem, etcd), most "dead" open source libraries IME suffer from these two properties: 1. the people with the commit bit in the original repository are all gone 2. people fork the repository to fix one minor thing, and never update again I've frequently ran into libraries where there are multiple forks with no activity, and it is not obvious whether there is a "best" choice of fork, and it is unlikely that the next fork will become the successor to the original project. There's a certain social problem that I can't describe very well. Projects should have a form of "succession planning" or else they end up in the state I just described (impossible to commit to the original repo, numerous inactive forks that merged 1 or 2 stale PRs).

bjourne 3y ago
2) is exactly what happened to the Python docopt project. It works well for most users but some corner cases trigger annoying bugs that are not fixed because the maintainer is mia. Lots of people have fixed the bugs in their own forks of docopt, but as there is not clear which if the forks is the "successor" to docopt, people keep running into the same bugs and keep forking over and over again.

bombcar 3y ago

The main thing I’ve run into is that you can’t build the project anymore. This is especially common, for example, if you want to revive the source of a Minecraft 1.7.10 mod, say. As more and more code build scripts pull in external things, the harder it is to get them running again years later.

criley2 3y ago
Is that actually challenging? My MC launcher can pull in 1.7.10, add a mod loader, and load mods into it just fine. Do you mean if you try to run a 1.7.10 mod in a modern MC version? That's not a realistic goal because of dramatic API changes between versions. There are a number of breaking versions that require basically rewriting mods. But you can still play the on the old version and most modded minecraft players are many breaking versions behind by default. This is the norm in most games, where game updates are routinely expected to break all backwards compatibility. And considering modding minecraft has never been officially supported, it's surprising it works as well as it does. I'm playing a 1.7.10 pack lately actually, still just as good as when it came out!
- fao_ 3y ago
  Eh? The poster clearly said: > if you want to revive the source of a Minecraft 1.7.10 mod i.e. if you want to change/alter or recompile a mod for version 1.7.10 None of the things you have mentioned apply to this.
  - bombcar 3y ago
    Exactly. You can easily find compiled 1.7.10 mods everywhere, and even the source, but getting the source to build requires some work: https://github.com/GTNewHorizons/ExampleMod1.7.10 https://github.com/GTNewHorizons/ExampleMod1.7.10

ryandrake 3y ago

I’ve never liked the “code rot” euphemism. Code doesn’t rot. What happens is platforms change out from under your code by platform vendors who no longer give a shit about backwards compatibility. If you take a piece of application software, tar it up including its dependencies, you should be able to untar it 15 years later and it should compile and run. If it doesn’t, it’s not your fault as a developer—it’s the fault of everything else that changed and broke that previously working code. If vendors took compatibility seriously, we wouldn’t have “code rot”.

bdzr 3y ago
I'm not sure what a better term is, but I think the problem will exist anyway. 15 years of backwards compatibility from software that's often written by volunteers is unreasonable to say the least.
- Falkon1313 3y ago
  >15 years of backwards compatibility [...] is unreasonable to say the least As a Windows user, it's sad that so many people think that way nowadays. I've encountered one DOS program from the early 90s that doesn't run anymore because it used its own custom memory management which newer systems don't allow, but that one was later re-released in an updated version that still works today. And there were one or two late-90s Windows programs that no longer run either because they have 16-bit components or depended on some then-standard now long-gone libraries to be on the system, but those run in a VM. Other than that, there is plenty of software dating back to the 90s, some to the 80s, that mostly still works fine. It doesn't need constant maintenance and updates. It worked about 30 years ago and still works today and should still work tomorrow. You'll find even older legacy code in major organizations that's still chugging along. That's hard to find in modern software. Now everyone always has to have the latest thing and it has to be updated almost every single day just to keep a massive chain of transitive dependencies from collapsing out from under it. I guess that's why people get rude and ask whether a project is 'dead' even though patches have been released for it multiple times within the last 10 years.

popularonion 3y ago

I’ve run into this with a niche but fairly popular open source program. It had been used by big tech cos for years, while the maintainers moved on one by one until the last guy who seems to have thrown in the towel in 2020. I considered picking it up, but I’d have to make some hard decisions about the code base that wouldn’t make everyone happy, and I just don’t have the context to do that. Another issue is the lack of testing infrastructure. So for everyone who still cares, the path of least resistance is to maintain their own fork or do a rewrite in a different language.