Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

82% of Open-Source Projects Suffer from Tool Rot

blog.trunk.io

Post reply on HN
Print view View original

21–30 of 61 posts

Re: 82% of Open-Source Projects Suffer from Tool Rot

#21

Post by elischleifer »

Arrath wrote: post #11
elischleifer wrote: post #2

software engineering is a constant fight against entropy. GitHub code search uncovers the scope of tool rot in open source projects.

To be fair I feel like this can be said about nearly any task or process. Documentation is a constant fight against entropy. Working safely is a constant fight against entropy/complacency. And so on

100% - documentation will always go stale. the source of truth is the code however, and making sure the code is kept shiny is the primary task of engineering. documentation is non-load-baring - you can tear it all down and the project will still work correctly. Legacy tooling can literally cause breakages and security concerns.

Re: 82% of Open-Source Projects Suffer from Tool Rot

#22

Post by Macha »

aleyva wrote: post #17
Macha wrote: post #14

The practical consequences of running an outdated eslint version are, for most projects, zero. The cost of upgrading is non zero. So upgrading only happens when there's a compelling reason to update like: - A real security issue - things like the reDoS example cited are part of the crying wolf that causes people to treat security scanners less seriously - A new feature (lint rule in eslint's case, or maybe new JS syn…

But do you really want to wait for a real security issue to emerge? Seems like keeping things updated is a simple, smart form of insurance.

1. How often are security issues found that are already fixed compared to security issues that are still in the latest version and require an even newer version to fix?

2. What are the security issues that can be found in a local tool which has as its only input your own code and it's output is only printed in tooltips for human review? Even if you had a way for specially formed code to run other code in eslint, it's a bit like saying bash has an RCE because you can type a command into it.

Re: 82% of Open-Source Projects Suffer from Tool Rot

#23

Post by woodruffw »

krona wrote: post #20

> It’s important to call out that up until v4 ESLint was vulnerable to a Regular Expression Denial of Service attack (ReDoS). If one points out ReDos 'vulnerabilities' in tooling as a reason to upgrade it, you've instantly lost the argument. By the same logic we should ban TypeScript because its type system is turing complete. This reasoning isn't even wrong.

Well said.

The proliferation of ReDoS "vulnerabilities" has been extremely frustrating (as someone working on accurate and high-signal vulnerability reporting tools), and belies completely perverse incentives in the bug bounty/vulnerability reporting space (reporters are incentivized to obtain CVEs to pressure companies into accepting low-quality reports).

Re: 82% of Open-Source Projects Suffer from Tool Rot

#24

Post by SanjayMehta »

dahfizz wrote: post #15

> Software projects have very short shelf lives. The moment a commit lands on main the software is spoiling; new versions of runtimes and compilers are shipped, dependencies cut new releases with bug fixes and exciting new features, and connected APIs are deprecated. Does this ring true for anyone? This sounds like hell. I am so glad to be in a field that minimizes third party dependencies. The C code I write today w…

Projects which don't consider the build environment to be version controlled have these problems.

When Java came out, we went through the tool hell described in this article.

Re: 82% of Open-Source Projects Suffer from Tool Rot

#25

Post by wiredfool »

I do a lot of projects that are once and done. Once it's out there, there might be a maintenance budget, but it's minimal. Stuff just runs, until someone notices that there's an issue. (that's not so bad with sites that are essentially static SPAs, for ones where there are servers it's more risky)

It's a constant battle to build projects that shipped 18 months ago. One thing wasn't pinned. Or the build system used node 12 and doesn't run on CI anymore. So Babel needs updated. CDK did a major rev and now we have to force pin the old version.

Re: 82% of Open-Source Projects Suffer from Tool Rot

#26

Post by Arrath »

elischleifer wrote: post #21
Arrath wrote: post #11

Earlier quoted context omitted.

To be fair I feel like this can be said about nearly any task or process. Documentation is a constant fight against entropy. Working safely is a constant fight against entropy/complacency. And so on

100% - documentation will always go stale. the source of truth is the code however, and making sure the code is kept shiny is the primary task of engineering. documentation is non-load-baring - you can tear it all down and the project will still work correctly. Legacy tooling can literally cause breakages and security concerns.

> Legacy tooling can literally cause breakages and security concerns.

Absolutely. My domain is a little different, but I've taken to keeping the installers of every version of a specific CAD program I've used, due to compatibility breaking updates that it has had, in the event that I might need to go back and open a design from a few years ago.

Re: 82% of Open-Source Projects Suffer from Tool Rot

#28

Post by 0cf8612b2e1e »

michaelmior wrote: post #10
jhoelzel wrote: post #3

Buuuut is it tool rot though if it still works?

Depends what you mean by works . Of course installing the same version of the tool will in most cases keep doing the same thing it's always done. But it's possible the tool always had bugs that were never noticed, has significant improvements that could benefit the project, etc.

I would settle for knowing I could still build it. It is amazing how fragile build chains are and the amount of maintenance they require. The build tools themselves, let alone pulling in dependencies.

Re: 82% of Open-Source Projects Suffer from Tool Rot

#29

Post by [deleted] »

dahfizz wrote: post #15

> Software projects have very short shelf lives. The moment a commit lands on main the software is spoiling; new versions of runtimes and compilers are shipped, dependencies cut new releases with bug fixes and exciting new features, and connected APIs are deprecated. Does this ring true for anyone? This sounds like hell. I am so glad to be in a field that minimizes third party dependencies. The C code I write today w…

[deleted]

Re: 82% of Open-Source Projects Suffer from Tool Rot

#30

Post by Centigonal »

woodruffw wrote: post #9

Sometimes I wonder if we're optimizing for the wrong things in the dependency management space: we used to have a distinction between "bleeding edge" and "stable" distribution schemes, with programmers (and users) picking the appropriate channel based on their stability and feature requires. That seems to have been mostly discarded: we now assume that a development dependency is broken and needs to be updated if it's…

I think it's also tied up with security - in the past, you could have one release cycle with a stable release coming out every n releases, but now, because of vulnerabilities, larger projects usually need to have two release cycles: one for the bleeding edge, and an LTS that gets security updates ported in. That's a lot of work to maintain, so a lot of projects just nix the LTS.
Post reply on HN