82% of Open-Source Projects Suffer from Tool Rot

Sometimes I wonder if we&#x27;re optimizing for the wrong things in the dependency management space: we used to have a distinction between &quot;bleeding edge&quot; and &quot;stable&quot; distribution schemes, with programmers (and users) picking the appropriate channel based on their stability and feature requires.<p>That seems to have been mostly discarded: we now <i>assume</i> that a development dependency is broken and <i>needs</i> to be updated if it&#x27;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&#x27;s shortsighted of us to treat non-adherence to the &quot;bleeding edge&quot; as a security or code smell.

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

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&#x27;s a compelling reason to update like:<p>- 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<p>- A new feature (lint rule in eslint&#x27;s case, or maybe new JS syntax support) is desired. The new upgrade can be deferred until that time<p>- You&#x27;re doing updates _anyway_ and update eslint as part of that housekeeping.

&gt; It’s important to call out that up until v4 ESLint was vulnerable to a Regular Expression Denial of Service attack (ReDoS).<p>Oh my god, your vscode&#x2F;text editor will freeze or crash if your code contain a specially crafted string. What a very import thing to call out.

&gt; 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.<p>Does this ring true for anyone? This sounds like hell. I am so glad to be in a field that minimizes third party dependencies.<p>The C code I write today would run the same 20 years ago and will run the same 20 years from now.

This seems to equate linters with other kinds of tools, and I think that&#x27;s mistaken.<p>Linters attempt to look for &quot;less than best practices&quot;. When you update a linter, you often <i>also</i> need to update code for the new style rules (unless you just don&#x27;t care about the results). Those reports can be helpful, because those style rules can also warn about real problems like security vulnerabilities. But most are minor issues, so it may make sense to delay them.<p>I would generally prioritize outputs of tools that are designed to find serious problems (like security vulnerabilities), and then update things like linters when I can (but consider those lower priority). We should be unsurprised to find developers prioritizing some kinds of reports over others.

&gt; Once you’ve confirmed the tools are running as expected<p>Kind of glossing over what&#x27;s often the hardest part. Sure, ESLint (the author&#x27;s example) might be easy enough, but who <i>hasn&#x27;t</i> seen a new compiler or key library cause problems? Bugs, including security bugs, can be <i>introduced</i> as well as fixed. Often these problems are hard to notice (until they bite you <i>hard</i>) and&#x2F;or work around. While the solution to the easiest part is not unwelcome, software supply chain issues are much more complex and difficult than &quot;once you&#x27;ve confirmed&quot; would suggest.<p>Also: stealth advertising. :-P

I didn&#x27;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 &quot;82% of <i>active</i> Open-Source projects&quot;.

There are roughly 3 classes of dependencies:<p>1. key system dependencies -- this includes things like Android APIs, IDE APIs, etc. ~ to work on newer versions of those platforms, you need to upgrade and make changes to the code<p>2. other runtime dependencies -- these are dependencies used to make the system run, but that don&#x27;t need to be updated in sync with the target platform ~ this can be things like the version of Spring, a HTTP library, etc.<p>3. development dependencies -- these are dependencies used to build the project<p>The system dependencies result in a treadmill, where if you don&#x27;t keep up with the changes then your application, plugin, etc. will no longer work on the latest version. Just keeping up with these can be a lot of work, especially if you need&#x2F;want to support multiple versions.<p>The other dependencies can cause headaches when upgrading major (or even minor) versions. For example, making sure that all the libraries you use are compatible when upgrading another library or language (Scala, Python, Java, PHP, etc.). This can be a lot of work to make sure that nothing is broken.<p>Development dependencies are typically low on the priority of things to upgrade. If the version of ESLint you are using works and there are no key benefits of performing an upgrade, then it is less likely to be upgraded.

Alternative title: 82% of projects on GitHub have an outdated code formatting library as a dependency.<p>I wouldn’t call this tool rot. This to me seems like fear-mongering to drive conversions of yet another tool for managing dependencies from the company behind this blog post.<p>It would be interesting to maybe analyse usage of React, Django, Laravel or such popular projects which you might be certain are key to a GitHub project and might lead to some interesting observations.<p>Instead i would summarise this article as a graph of a few searches on github that give you as much data as relevant stats page from npm or PyPI - not much.<p>What conclusions can we draw that some projects on github, which we have no idea how big or how used they are, run an outdated code formatter? Maybe 82% of them are archived, abandoned or were one offs to learn the language?

I do a lot of projects that are once and done. Once it&#x27;s out there, there might be a maintenance budget, but it&#x27;s minimal. Stuff just runs, until someone notices that there&#x27;s an issue. (that&#x27;s not so bad with sites that are essentially static SPAs, for ones where there are servers it&#x27;s more risky)<p>It&#x27;s a constant battle to build projects that shipped 18 months ago. One thing wasn&#x27;t pinned. Or the build system used node 12 and doesn&#x27;t run on CI anymore. So Babel needs updated. CDK did a major rev and now we have to force pin the old version.

We have run into this with the HL7 standards development organization. It is no longer possible to build new releases of artifacts from some of the older standards because the build process depends on obsolete custom tools which no longer run on modern operating system versions. In theory it might be possible to update the tools, or construct a virtualized build environment, but in practice they don&#x27;t have enough resources to fight through all the issues.

The open-source community did this to themselves. When the most popular frameworks and foundation tools (e.g. Python) disregard backward compatibility again and again, we have taken broken compatibility for granted and formed habit of pinning specific versions. It was not like this a decade ago. At that time, we more often assumed a minor version bump in dependencies would naturally keep everything running without hassles.

Buuuut is it tool rot though if it still works?

Bar charts are not very useful. The second bar chart here, especially, is hard to learn from. Plotting something like (days since last project release) vs (days since release of tool version used) seems like it might be be much more insightful.

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.

Most maintainer work on their project, they don&#x27;t have the time to work permanent on tooling. Esecially when the tools work for them.<p>You don&#x27;t need always the newest &quot;sht&quot;.

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

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

When did GCC stop being enough?

Seem like a lot of conclusions to take based on the usage of one JS linter alone.