82% of Open-Source Projects Suffer from Tool Rot

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.

is that entropy not self inflicted by swes constantly reinventing the wheel with new languages, frameworks, and libraries? they may be better but constantly having new adoption means nothing ever really lasts long

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

#5

Post by Kuinox » Wed, Nov 16, 2022, 4:23 PM UTC

> It’s important to call out that up until v4 ESLint was vulnerable to a Regular Expression Denial of Service attack (ReDoS).

Oh my god, your vscode/text editor will freeze or crash if your code contain a specially crafted string. What a very import thing to call out.

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

#6

Post by notacoward » Wed, Nov 16, 2022, 4:24 PM UTC

> Once you’ve confirmed the tools are running as expected

Kind of glossing over what's often the hardest part. Sure, ESLint (the author's example) might be easy enough, but who hasn't seen a new compiler or key library cause problems? Bugs, including security bugs, can be introduced as well as fixed. Often these problems are hard to notice (until they bite you hard) and/or work around. While the solution to the easiest part is not unwelcome, software supply chain issues are much more complex and difficult than "once you've confirmed" would suggest.

Also: stealth advertising. :-P

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

#7

Post by michaelmior » Wed, Nov 16, 2022, 4:26 PM UTC

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

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

#8

Post by dewfaced » Wed, Nov 16, 2022, 4:26 PM UTC

I have several intranet applications that I need to port to another web framework because of this specific issue. I guess it servers me right for not choosing the most popular framework for my applications.

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

#9

Post by woodruffw » Wed, Nov 16, 2022, 4:27 PM UTC

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 even slightly stale, despite being stable and working just fine. I can understand part of why that is (e.g. the overhead required to support multiple versions), but I think it's shortsighted of us to treat non-adherence to the "bleeding edge" as a security or code smell.

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

#10

Post by michaelmior » Wed, Nov 16, 2022, 4:28 PM UTC

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.