Node-RED Development: The Numbers

Numbers are important but they do not tell stories, words tell a story. This story will investigate the community around Node-RED and who is behind the development and maintenance of Node-RED. This is my interpretation of the numbers and your mileage might vary.

All facts and figures in this piece are generated by this flow and I make no guarantee of completeness nor correctness. The figures shown here are taken from data retrieved at the end of October 2023. Data is taken from this json with download and package details being separately retrieved from NPMjs.com. No other sources of data were utilised.

TL;DR: There is a core group of maintainers who maintain and update Node-REDs core node packages. Many developers have contributed and have potentially moved on, however because of Node-REDs Flow Based Programming nature, this has had no technological consequences. The use-cases for which Node-REDs is utilised remain narrow and focussed, thus continuing to ensure Node-RED remains a niche product.

I will present five suppositions that I have made (for myself) from analysing the data. These suppositions are not the truth, these are my personal interpretations: the story I tell is my own interpretation. The reader might disagree, the raw data is available and open to reinterpretation.

The Basics

Node-RED has a collection of approximately 4709 packages which have been created by a group 2763 developers. The first package for Node-RED was released on the 4th of July 2014, representing some ten years of Node-RED development.

Some assumptions I have made:

A maintainer is consider active if their packages are updated. This implies that if a package is “abandoned”, the maintainer(s) are considered to have left Node-RED. This is obviously not perfect. Hence the numbers here a conservative estimate of the real world situation, in other words, this describes the lower limit.
I have only considered the maintainers and not contributors. There are many more contributors to packages and many more folks are involved in Node-RED package development. However only a maintainer decides which features are integrated and only a maintainer decides when a new release is made. Maintainers represent the bottleneck in the development of nodes: if the maintainer is not available then nothing happens, regardless of how many contributors there are. This is generally not an issue since all the code is Open Source and anyone can create their own copy and release their own package, this is a healthy and normal state of affairs in Open Source development.

It also important to keep in mind that Node-RED follows the Flow Based Programming paradigm, this has a number of consequences for interpreting these numbers.

Supposition 1: Node-RED: alternative approach to updates

The norm currently in software development is that updates are good and demonstrates that the software is being maintained. Much importance is placed on update frequency and release counts. This comes from the popular adage: release early and release often - move fast and break things.

A characteristic of Flow Based Programming (FBP) is that many small components are brought together into a single whole. Which implies that the functionality of individual components is focussed and specific: each component does one thing and one thing only, but it does that to perfection. In part, these components then do not need constant updates and releases because they are “complete”. This was the basis for the development of the early Unix systems.

In FBP, a component for example could be addition: take all inputs, sum them together and output the result. This functionality is focussed and specific, and since addition does not change, this component will not need updating.

This is borne out in the release counts and package age of Node-RED packages:

Number of package releases and package age.

Package age is the time between the initial release of a package and its latest version. In context of release early, release often, these numbers could indicate that packages have been abandoned. But that is not the case in the Node-RED ecosystem. These numbers show that packages are focussed, complete and continue to work with Node-RED.

Further evidence of this, version numbers of packages:

The most popular versions are 1.0.0, 1.0.1, 0.0.1, and 0.0.2. (It is unclear whether a developer begins with a leading 1 or 0 when making their first release.) Both 0.0.1 and 1.0.0 represent an initial release followed by a tweak (1.0.1 and 0.0.2) and then the package is done. This can only be done when the functionality required is clear and immutable.

One final piece of evidence for this are the number of node types that each package defines. Packages define “nodes” that represent the individual components that are brought together in a flow:

Number of node types defined per package

The vast majority of packages define exactly one single node type. This seems to indicate that maintainers have a single bit of functionality they require and define a single node for it. This node can then be combined with existing nodes to expand the functionality of flows.

Within the FBP paradigm updates are made to flows not nodes. Updating flows implies changing the flow of data between nodes, adding new nodes to a flow or creating new flows of data. Updates are focussed on data flow and not computational functionality or features.

Supposition 2: Node-RED is good at keeping maintainers

There has been a steady growth in active maintainers of packages even though the number of new maintainers has been decreasing:

The “active’ness” of a maintainer is assumed to be last time that maintainer updated a package. This does not mean that the maintainer is not contributing in other ways to Node-RED.

For me, these two graphs show that once the Node-RED learning curve has been mastered, developers tend to stay with Node-RED in one form or another. This demonstrates the well thought out design and usage patterns within Node-RED.

Supposition 3: Node-RED: Specific problem spaces

This figure shows the top keywords used to describe packages. Clearly there is a bias towards the IoT problem space. This is borne out even further when viewing the top hundred packages downloaded:

From these graphs, I see Node-RED being mainly applied to systems that monitor IoT based setups, such as home automation (e.g., my fridge should send me an email if it’s out of milk), or notification via other services such as telegram or twitter. These systems use dashboards to control IoT devices (e.g., turning on lights with mobile phones) or display the current state of the system (i.e., is my garage door open?).

From a personal point of view, I see Node-RED being capable of much more. For me, its similar to saying Linux shall be used exclusively for IoT. I would not much mind if it were not for the fact that Node-RED represents (IMHO) the best and most professional example of visual Flow Based Programming (FBP). Additionally it is browser based, no software installation required.

I see Node-RED as the tool to spread the ideas of FBP to a broader audience, to a new generation of developers who might make a paradigm shift away from textual-based programming.

Supposition 4: Dependence on FlowFuse

FlowFuse is the employer of most active developers of Node-RED and also the creators of Node-RED.

The following graph is a list of maintainers for the top hundred downloaded packages (over the last year):

Maintainers of the top 100 download packages

The ~~first three~~ two of the first three all work for FlowFuse and therefore maintain both the Open Source product (Node-RED) and the Commercial Product (FlowFuse).

Correction: In an earlier version I mistakenly assumed dceejay (Dave Conway-Jones) was also employed by FlowFuse, this is not the case. He is the co-inventor of Node-RED.

As I describe in the conclusions, issues arise if development is focussed on just a few knowledgable developers. I see that as being the biggest risk for the future of Node-RED. Many might argue that since Node-RED is Open Source, anyone can fork it and do their own thing. But this leads to fragmentation and loss of focus in my opinion.

Whatever might happen, Node-RED will remain around in some form or another and with it the ideas and ideals of Flow Based Programming.

Supposition 5: Node-RED development: Trend is positive

A look at the update counts per day shows a positive trend:

Updates per day over the lifetime of Node-RED

A slow but steady increase in package updates meaning that maintainers are actively working on packages for Node-RED. This trend is also reflected in the number of active maintainers (figure above) which also shows steady growth.

Overall Node-RED is slowly becoming relevant for a broader audience. It remains to be seen if that audience is willing to accept a paradigm shift or whether those in favour of stagnation will ensure the software development remains textually focussed with AI “wisdom” springling more complexity to the textual representation of our digital futures.

Conclusions

Flow Based Programming (FBP) would benefit from Node-RED becoming more broadly known but it remains a niche product with a core of loyal users and developers. It remains unclear why Node-RED has not reached a broader audience in the ten years of its existence. I could speculate but I have no solid ideas why this should be the case.

In my opionion, Node-RED has the potential to become a generalised visual programming tool, however it fails to live up to that potential. Personally I find that a shame since it also prevents the FBP paradigm from becoming more popular and that is a shame for the software development industry as a whole.

The development of Node-RED is heavily depended on FlowFuse and its vision for Node-RED. Specific features will never make it into Node-RED since FlowFuse has no interest in making Node-RED as good as their own commercial for-money product. More worryingly is the situation that a hand full of developers represent the core of Node-RED development and these are employed by a single company - FlowFuse.

FlowFuse is the maintainer of Node-RED, while at the same time monetising an in-house clone of Node-RED. This represents a situation that ensures any development that is incompatible with the vision FlowFuse has for Node-RED, will not be pursued nor encouraged, and not integrated into Node-RED.

The follow-on effect of this is that new developers and potential maintainers lose interest in Node-RED because they may not pursue a more general use-case for Node-RED. This reduces the pool of developers that can step-up and take on the core maintenace of Node-RED (as Open Source product), should the current crop of developers decide to do something else.

Node-RED, for me, remains finely balanced between becoming a more generalised visual Flow Based Programming tool for a broader audience or a singly focussed application for the IoT problem space. The future will tell.

Update - 2023/11/2

Since posting this on LinkedIn, I have been contacted by FlowFuse and have added their comments here:

“FlowFuse is the maintainer of Node-RED, while at the same time monetising an in-house clone of Node-RED.”

We do not have any in-house clones of Node-RED. We deploy instances of Node-RED for customers, but those instances are running the exact same Node-RED as anybody else can run.

“This represents a situation that ensures any development that is incompatible with the vision FlowFuse has for Node-RED, will not be pursued nor encouraged”

I would also dispute this, as Nick and the NR Community is still putting features into Node-RED that have no reflection or direct benefit to FlowFuse (e.g. locking flows introduced in 3.1 was a major feature)

Last updated: 2023-11-02T13:55:12.267Z

Comments powered by giscus

The author is available for Node-RED development and consultancy.