2/3 of Node.Js Users Run an Outdated Version. So OpenJS Announces Program Offering Upgrade Providers (openjsf.org) 26
How many Node.js users are running unsupported or outdated versions. Roughly two thirds, according to data from Node's nonprofit steward, OpenJS.
So they've announced "the Node.js LTS Upgrade and Modernization program" to help enterprises move safely off legacy/end-of-life Node.js. "This program gives enterprises a clear, trusted path to modernize," said the executive director of the OpenJS Foundation, "while staying aligned with the Node.js project and community." The Node.js LTS Upgrade and Modernization program connects organizations with experienced Node.js service providers who handle the work of upgrading safely.
Approved partners assess current versions and dependencies, manage phased upgrades to supported LTS releases, and offer temporary security support when immediate upgrades are not possible... Partners are surfaced exactly where users go when upgrades become unavoidable, including the Node.js website, documentation, and end of life guidance.
The program follows the existing OpenJS Ecosystem Sustainability Program revenue model, with partners retaining 85% of revenue and 15% supporting OpenJS and Node.js through Open Collective and foundation operations. OpenJS provides the guardrails, alignment, and oversight to keep the program credible and connected to the project. We're pleased to welcome NodeSource as the inaugural partner in the Node.js LTS Upgrade and Modernization program.
"The goal is simple: reduce risk without breaking production or trust with the upstream project."
So they've announced "the Node.js LTS Upgrade and Modernization program" to help enterprises move safely off legacy/end-of-life Node.js. "This program gives enterprises a clear, trusted path to modernize," said the executive director of the OpenJS Foundation, "while staying aligned with the Node.js project and community." The Node.js LTS Upgrade and Modernization program connects organizations with experienced Node.js service providers who handle the work of upgrading safely.
Approved partners assess current versions and dependencies, manage phased upgrades to supported LTS releases, and offer temporary security support when immediate upgrades are not possible... Partners are surfaced exactly where users go when upgrades become unavoidable, including the Node.js website, documentation, and end of life guidance.
The program follows the existing OpenJS Ecosystem Sustainability Program revenue model, with partners retaining 85% of revenue and 15% supporting OpenJS and Node.js through Open Collective and foundation operations. OpenJS provides the guardrails, alignment, and oversight to keep the program credible and connected to the project. We're pleased to welcome NodeSource as the inaugural partner in the Node.js LTS Upgrade and Modernization program.
"The goal is simple: reduce risk without breaking production or trust with the upstream project."
Sounds nice, but... (Score:2)
Re: (Score:3)
Just like any other evolving software infrastructure.
Re: (Score:2)
machine boundary checking (Score:3)
It is always amazing how junction points where you would check security conditions, validate parameters, use the compiler's strictest type checking mode, and security best practices are degraded by picking a known problematic weak programming language (JavaScript) for client, server and server back-end process.
Re: (Score:3)
"Businesses will have to spend people, time and money on a moving target"
tell us without telling us you've never heard of Patch Tuesday
Re: (Score:2)
businesses should be doing that anyway, openjs is just providing a new service to assist in migration. to me it sounds more like trying to appear relevant. businesses that do sensible maintenance will not need such a service, businesses that don't probably won't bother with this either. i'd say a less glamurous but more productive effort would be funding audits and backports of security patches to older versions.
updating is a risk in itself and aged software isn't necessarily more risky as long as it is rea
Re: Sounds nice, but... (Score:4, Informative)
As someone who used to managed development stacks at several companies. NodeJS is particularly a PITA to keep up to date with. The other languages that have better tools such as Go and Python do have issues but not as much as NodeJS.
My experience is that unless the NodeJS dev team really craves a new feature of NodeJS, they would rather not upgrade at all since there are less things to learn but also less conflicts to resolve in order to upgrade. There are many libraries in active use that have now become abandonware and these need to either be forked as a new project or fixed.
Unfortunately I have seen devs just copy the abandoned project source code into the private Git repository so that 3rd party tools will no longer flag CVEs. This is bad for the obvious security issue, but also is often a violation of the license. Of course many Devs do not give a crap, and it never becomes an issue until M&A Discovery finds out about it, if it ever does.
Re: (Score:1)
As someone who used to managed development stacks at several companies. NodeJS is particularly a PITA to keep up to date with.
That's why my company forks thousands of docker containers each with their own set of libraries so we never have to update it ever! /s
Re: (Score:3)
Totally. You have 9000 deprecated functions and 1006067 obsolete functions you need to update (that were installed before I got there). These will be removed in the next 3 days. I didn't f***** create the code, I don't have 9 years to update the goddamn code you deprecate or obsolete as abandonware daily, I need like 15 support people to keep up. I hated Node.js when I first tried it (same issues) and it is 1000x worse now.
Re: (Score:2)
Of course it's a PITA to keep up to date because the Node and JS developers live the mantra of "move fast and break things", which is a bad philosophy for commercial development. So project updates are slow and a little at a time, generally to get a new feature or to avoid a CVE that you think affects you.
At my last job, we were at the beginning of a dev cycle which would give us the most testing time, so I started trying to move us forward to a new version of Node, Typescript, and various modules to match.
Re: (Score:2)
They always do. Otherwise they'd still be using MS-DOS because they don't want to upgrade their LOB programs.
There are viewpoints on both sides - I used to work with a company that once something is stable, it was frozen. They were deathly afraid of doing any sort of change for it might break something. This is one viewpoint. Of course, it also meant the software they used was horrendously outdated to the point if you needed to do anyth
This probably ignores most installation... (Score:2)
My personal observation is rather 99%. There are a lot of node.js installations hidden in some software that was last updated when the city of Rome was founded.
Re: This probably ignores most installation... (Score:2)
Which isnâ(TM)t necessarily a bad thing. Consider systems still using software written in COBOL that are still running today with minimum interference.
With node.js if you sneeze you are out of date. There is a balance between keeping things up to date, and not creating new breakages and risks while doing so.
Re: (Score:2)
And for whatever reason, JS packages seem to go from "okay" to "critical security vulnerability" faster than you can say "stwike him down centuwion".
If you run node.js in production, you need to be *on it* constantly, because that stuff goes wonky really, really fast. It's one of the reasons I always advise against any sort of node.js server-side. It works great for developing Vue/React/etc, but sucks balls at running in prod.
Paperwork (Score:2)
The issue isn't technical, its business. Let's just say, in my career, other than when I was the lead architect, I've been stuck dealing with shit-tier quality ass old aged software, because of the amount of paperwork involved for "risk mitigation" due to the fears of poking an otherwise "working" system (security exploits be damned)
reason why (Score:3)
The reason why is node accepts pedantic breaking changes nobody cares about. This adds work to maintainers of downstream libraries and lets be honest, those guys aren't paid enough to deal with this crap. This leads to a situation where we end up having absolutely insane stuff like node version managers because production services at the end of all of this need to take a dependency upgrade that is on a new version of node for an actual reason important to their business, but also can't take a node upgrade because dependencies haven't had time or motivation to upgrade for these pedantic breaking changes.
Re: (Score:2)
Abso-fucking-lutely!
The JS ecosystem (and frankly the python ecosystem too) is made of lunatics who think I have nothing better to do than patch my system every 3 month because they decided that it was more pretty to swap the order to parameters somewhere.
The number of NPM packages that are deployed widely and that just break at an upgrade is staggering. And because fucking JS, you don't get a proper error message at the upgrade recompilation. You need to rely on having a test that catches the difference. W
Re: (Score:2)
> The reason why is node accepts pedantic breaking changes nobody cares about.
It's because right at the start, the "wizards" and "rock stars" that wrote node.js quite clearly wanted to do it all themselves without any need of those stinkin' sysadmins, or even any of those annoying dweebs that know all about the backend. As a result, they designed all sorts of crappy solutions to long since solved problems, and somehow also ended up with a hot cesspool of malware infestations in their package repository a
Maybe upgrade all the time is the problem (Score:1)
Just happened at my work on Friday. NPM based application failed to compile, timed out after two hours on bitbucket. Lots of "old versions" complaints in the log. Developers are going to have fun resolving all the dependency versions.
Needing to change things all the time is the problem, not the solution. The one and only valid reason for frequent updates is security. But if you constantly have to fix security holes then your process is no good.
Good software development is where you rarely have to change thi
Re: (Score:3)
Re: (Score:1)
In addition to bumping the Node version, we had to add some parameters to tell bitbucket to please give us more RAM during the build process. If your build requires too much RAM, they don't tell you anything is wrong. They just hang for two hours and then die.
In the past I've seen kubernetes pods mysteriously fail to start because some dependency is being fetched from an external site that is down. Getting such an environment external dependency free is quite a bit of work.
When LTS is 30 months (Score:2, Informative)
"The total LTS support time is generally around 5 years for every version."
When it takes 18-24 months to get an enterprise project from conception to golive, and then you have to tell the client they need to accept additional costs immediately after golive to stay current on code levels, including a scheduled PROD outage
node.js is a clusterfuck in this regard (Score:2)
These Are the Same People ... (Score:2)
... that are so incompetent they can't figure out how to add comments to their central configuration file (package.json).
They are woefully inept, and have a myopic focus on things 90% of the Node userbase doesn't care about (like forcing everyone to be on the latest Node version).