For example, node-red-contrib-influxdb-backup has not been updated for three years, but has no open issues and if any problems were found they would be addressed.
No.
I take the values from NPMjs - for each package, they maintain a list of timings, for example for the node-red-contrib-neo4j package:
{
"releases":{
"modified":"2022-06-21T19:42:45.740Z",
"created":"2014-07-08T20:00:58.915Z",
"0.0.1":"2014-07-08T20:01:01.149Z",
"0.0.2":"2014-07-14T07:22:08.535Z",
"0.0.3":"2014-07-14T12:09:45.556Z"
},
"readme":true,
"readmeFilename":true,
"description":"A neo4j query node for node red",
"maintainers":[
{"name":"trivielldev","email":"dev@trivielt.com"},
{"name":"raynerv","email":"raynerv@gmail.com"}
],
"disttags":{"latest":"0.0.3"}}
Here the package would have been "maintained" until the 0.0.3 release on the 14-07-2014. The maintainers are assigned the created date as having started on that date and the last release date represents the time they stopped being active.
This is done across all packages with the "oldest" created date across all packages that a maintainer has being their start date and the "youngest" release is assumed to be the date they stopped working with Node-RED.
I don't use github data.
I can't go over all 4709 packages and make judgement calls whether the maintainer is still working with Node-RED or not, so I make certain assumptions. The main assumption is that if a maintainer isn't updating their packages, they no longer are involved in Node-RED. This is quite obviously a dangerous assumption to make.
You are, of course, most welcome to gather other data and make other conclusions - each to their own and own to their each.
Edit: why do all this? Because a company wanting to use Node-RED would like to know how active the community around Node-RED is, this is definitely not for the hobbyist setting up their home automation system. And of course, there are far more users than maintainers of packages. But if we take a ratio of ten to one, then there are 7000 active users of Node-RED with 724 active maintainers in the last 12 months.
Sorry I might have mis-intrepreted your question: this isn't about whether packages are maintained or not, this is about maintainers being active or not. So if a maintainer does not update their package than yes it could be there is nothing to update since all works or they have moved on.
I assume that they have moved on but that assumption is a conservative, i.e., lower limit. I could make some assumption that X% maintainers are still active even though they no longer create new packages nor update their old packages. But I have no idea how to find out how high/low X is, so I assume it's zero.
Yes, that is a good one. You get lots of issues where you answer but you get zero response back. Then you forget about it, and the issue remains open...
If I was a company, I would be more interested in how active the contributors are of the subset of nodes that I would use. E.g. when I offer video surveillance survices to my customers, then I am not interested e.g. if the modbud nodes are maintained or not...
And if Node-RED itself is no longer maintained? That wouldn't really help then. That's why you also want to know whether there is a healthy community of developers around the core of Node-RED. And most probably the company would maintain their own nodes - if it's for their own hardware. Or fork existing nodes to maintain them in house. A company doesn't like making themselves depended on external developers.
The one that surprises me is the node-red-contrib-flow-manager - not because I've never heard of it (I have) - but because the serial port node, email, random etc are all "extra" ones I include in the script for Pi/debian/ubuntu users - so the fact that dashboard and flow manager are so far and above the others must mean that there is some large scale pulling of those - probably by some containerised deployment - or deployments - or... . Would be interesting to know how it's being used there....
1 Like
See this thread - Node-Red in Browser via Stackblitz - #6 by bloigge
1 Like
It most certainly is a dangerous and sometimes unwarranted assumption.
I'm concerned where this is going. This is making some very broad assumptions and I'm not convinced they are particularly useful.
If I were an enterprise looking to see whether to use Node-RED. I'd be looking for both stability and progression in the core. I'd want more than a couple of developers and I'd want to see involvement over a long period. Then I would compare that against my expected utilisation - is it a temporary tool or a long-term one?
As for contributed nodes, I'd only really be interested in there being a vibrant community. Though for specific uses, obviously, I'd also then look into detail about useful contributed nodes. But then I'd be looking to see how good the code was not just whether it is being well maintained - after all, the nature of Node-RED means that it is potentially pretty easy to fork a node.
And that is certainly the important point. But it is more interesting to see how many node contributors are also core contributors. And that ratio is, I think pretty low for Node-RED. The core is complex and it feels as though relatively few people contribute. However, that is also balanced by having folk from Hitachi and perhaps elsewhere contributing.
This is not an easy subject and I think we need to be careful about the messages we are putting out. Not saying you are wrong to do this, just a word or two of caution.
One thing that was interesting was discovering new packages, the babylonjs has become a favourite of mine.
But the flow managed also surprised me. It does show that folks are interested in fine grain flow management. I was thinking that it be flowfuse customers who would be utilitising the flow manager.
Yes I can maintain my nodes with great enthousiasm, but things can change rapidly (due to illness, familly issues, lack of free time, ...). For software like Node-RED, not only the core needs a community but imho also the nodes that are important for your project...
One picture says it all:
And it doesn't only happen in Nebraska, but also in Belgium 
8 Likes
Thanks Bart!
2 Likes
Julian is right in saying that we should be careful how the data is interpreted but its also important to have this discussion.
One thing I am planning to say is that, taking parallels to Unix, it is quite normal that packages don't need to be updated since their functionality is laser focused and does its job.
That point I find important to bring across since to goes against the current norm in software development.
1 Like
That was just what I needed to keep on going for a couple of years again...
Absolutely!
4 Likes
So for those interested, a draft version of my interpretation of the numbers is available here.
1 Like
This looks great. On the Stackblitz example, it isn't currently possible to install packages through the NR Editor's palette manager, however, the underlying runtime definitely works. With some crafting of the WebContainer process, NodeRed flows could be packaged as self-contained web applications. Maybe even a custom web component??
For those that come after me, here's another one (visual programming tool):
-
A general purpose visual programming interface for lowering programming language's steep learning curve, and introduce an easy way to experimenting with your beautiful project for other developer.
1 Like
Interesting. It doesn't seem as stable as Node-RED and it focuses on a more traditional data in/out approach for each node rather than Node-RED's msg flow approach. Also has a number of display oddities and some of the examples don't seem to work. Also, the core nodes have very limited scope so you need to know where to find other nodes, there doesn't seem to be a catalogue that I could easily see.
The nodes are also extremely granular, the core ones mostly seem to mirror individual JavaScript functions.
So certainly some negatives there.
On the positive side, the node definition boilerplate code is very clean and uses extensions to an existing class which is a much nicer approach than the somewhat fiddly approach used in Node-RED.
1 Like
Thanks for that summary 
Probably the biggest trap for any visual programming tool: granularity (also for a good coffee strangely ;))
Hence subflows and link-nodes --> abstraction so that granularity can be reduced and functionality built up.
1 Like
Indeed (he say's while drinking his very nice coffee from his heavily over-used bean-to-cup coffee machine! 
)
This is one of the key things that set's Node-RED apart from almost every other flow-style tool. While the principal of "do one thing and do it well" is generally applied, it hasn't led to the trap of literally only doing ONE thing. Instead, each node is a useful (mostly single) capability rather than a single function.
