Live data from Hacker News

82% of Open-Source Projects Suffer from Tool Rot

blog.trunk.io

11–20 of 61 posts

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

#11

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

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

#12

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

Everyone wants to be Tony Stark, nobody wants to be the janitor. Thus things fall apart and get constantly rebuild, in a "good-enough-fashion", which is very reminiscent of biologic life.

We are codes transport mechanism, without us, its not alive. And only good code gets copied, reused, to life on till heat death.

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

#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 syntax support) is desired. The new upgrade can be deferred until that time

- You're doing updates _anyway_ and update eslint as part of that housekeeping.

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

#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 would run the same 20 years ago and will run the same 20 years from now.

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

#17
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.

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

#18
post #13

I didn't see anything about them filtering out repos which have been abandoned, were only for testing, or other such considerations. The title is technically correct, but I feel that most people would interpret it as "82% of active Open-Source projects".

great point. I didn't see a mechanism for filtering out stale projects - if that is a GH concept inside CodeSearch.

TLDR; there are a lot of active projects running rusty / rotten tools

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

#19

Seems like solutions for this already exist with Dependabot and the myriad of other tools for updating dependencies.

there are bots that can resolve this one angle of the problem. they have drawbacks that are great opportunities to improve upon - dependabot loves spamming projects with update notifications and doesn't understand what its actually doing - it is kind of a semi-smart regex parser. valuable but we can do better.

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

#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.

Post reply on HN