Why Satisfying User Needs Is Not a Zero-Sum Game – An Interview with Nick O’Leary, Node-RED

Why Satisfying User Needs Is Not a Zero-Sum Game – An Interview with Nick O’Leary, Node-RED

Nick O’Leary is an open source developer with a passion for the Internet of Things. Nick created Node-RED, an open source tool made for users who may not have prior coding experience to “string together” nodes in order to create applications. Node-RED came to life in early 2013 as a side project for Nick O’Leary and Dave Conway-Jones of IBM. Initially meant to be for visualising and manipulating mappings between MQTT topics, Node-RED soon became a tool that could be used much more generally. O’Leary has worked on an extensive list of other interesting projects, including but not limited to an Arduino Client for MQTT and FlowForge, where he is currently serving as CTO and Founder. Node-RED recently released version 2.0, more about the release can be found here.

Node-RED is an At-Large project under the OpenJS umbrella, having joined the foundation in late 2016. At-Large projects are ones deemed by the OpenJS Cross Project Council to be important or impactful to the overall JS ecosystem. Node-RED is a flow based programming tool that was originally developed by IBM’s Emerging Technology Services team. Node-RED allows users to create applications by dragging nodes from a palette into a workspace, but all within a browser window. In short, it is a visual tool that allows for low code programming for event driven applications. We sat down with O’Leary to learn more about the current status of Node-RED and how they are helping users who are not typical software developers.

How do you balance the needs of hobbyist end users versus large corporations? By focusing on building an easy-to-use standalone installer instead of a Docker install, does that mean hobbyists are a priority?

One of the challenges we have is the diverse nature of Node-RED’s target user base. As a low-code programming tool, our users range from the highly technical, to those just dipping their toe into the idea of programming. We always have to strike the balance between the two – which can be a challenge when it comes to deciding how to focus our work.

Once someone has decided to try Node-RED, they find they have to install Node.js first and then run some commands in a terminal window. For a developer, it’s all second nature – but for a user not familiar with the command-line, it can be intimidating and put them off. This is why we’d like to improve the install experience for new users – having it feel more like a native application.

But that shouldn’t detract at all from those who want to run Node-RED in cloud environments and run it more as a hosted service – they are mutually exclusive approaches. We do already have docker images for the project that are very popular.

Ultimately, we are driven by the feedback we receive from the community – whether they’re a hobbyist running on a Raspberry Pi, or a company trying to integrate it into their existing platform.

Satisfying user needs isn’t a zero-sum game – we always look to distill requirements down to what brings the most value to everyone. It also lets us highlight areas where we know we want to do more and invite the community to get more closely involved.

How does the simplified git-workflow (as of Node-RED 1.2) help a hobbyist end user?

For many software developers, using version control is a given – it’s just part of the normal workflow. The question we asked ourselves was how to bring version control to the low-code programming environment of Node-RED, where many of our users are not typical software developers.

The first iteration of this introduced the Projects feature in Node-RED – where the project is backed by a git repository. Within the editor users could commit changes when they wanted to create a snapshot of their work.

The problem we saw was that users who weren’t familiar with git workflows would simply forget to commit their changes, so they weren’t gaining the benefit of proper version control.

This is why we introduced the simplified git workflow in Node-RED 1.2. This workflow automatically commits their changes whenever they deploy a new version of their flows. Users can now forget all about the version control aspect – with it all happening in the background.

Node-RED 2.0 seems to have no one big major new feature. Why did you jump the numbering to 2.0? Do you follow Semantic Versioning (“semver”) for Node-RED? If so, what incompatible changes were made that justify the 2.0 numbering?

Last year we published a release roadmap for the project. This wasn’t a roadmap of specific features, rather a proposed schedule for the releases. Before that point, we had been doing new feature releases on a fairly relaxed basis – as and when we felt there was ‘enough’ to warrant a release. Having got to the 1.0 release, itself a major milestone, we needed to have a more predictable schedule. This was important for the companies looking to adopt Node-RED – to give them confidence in how long any given version would be supported by the project.

Underpinning this was the Node.js release schedule. At the time, Node-RED still supported Node 8 and 10 – both of which were dropping out of support by the Node project. We decided to align our major releases with their support cycle – so that at the end of each April we would do a new major release that dropped support for whatever Node.js version had reached its own end-of-life. To us, dropping support for a particular runtime version has to be a major semver change – even if technically the code will still run on that old version.

This was the primary driver for our 2.0 release – dropping support for Node 8 and 10. In doing so, we were also able to update a number of our dependencies that had already dropped support for those old Node versions. That in itself meant a number of major version number changes in our dependencies – something that took a good deal of developer-time to manage properly.

Our goal is always to minimise the effort needed to upgrade from a previous version. Even if a major version change gives us permission to make some significant change, we don’t want to make it hard for users to upgrade – especially those using it as part of production services.

Have you successfully made Node-RED sustainable? Is joining OpenJS Foundation a part of that strategy?

Being part of the OpenJS Foundation is certainly part of our overall strategy to make Node-RED a sustainable project. We’ve had direct feedback from some contributors that being part of the foundation was a key factor in their decision to use Node-RED and engage with the project and wider community.

We have more work to do to strengthen the pool of contributors to the project. We have a very large and enthusiastic user base who love to share their ideas and feedback. But by Node-RED’s very nature, that doesn’t necessarily mean those users are experienced JavaScript or Node.js developers who can dip into the code and make changes. That can make it a challenge to convert that enthusiasm into sustained contributions to the code.

The project homepage, nodered.org, has a showcase of companies using Node-RED as part of their products or services. Over the last few months, that showcase has grown to over 30 companies, and we know there are many more out there. That is an important part of increasing the project’s sustainability. It’s a virtuous circle of being able to show how the project is being adopted, to give others confidence to adopt it themselves.

How was OpenJS World this year? Will you be attending OpenJS World 2022 and why?

Needless to say it has been an unusual 18 months. With so many events turning virtual, I’ve missed the ability to meet up in person with many people in the community. What’s great about OpenJS World is it isn’t a singular community – it brings together the communities of multiple projects under the foundation. There’s always a great diversity of people and talks from right across the technology spectrum.

Who knows where things will lead over the next few months, but I certainly hope to be at OpenJS World 2022. As good as virtual events are for being able to enjoy the talks without the hassle of travel, you definitely miss out on the face-to-face time with lots of wonderful people.

At-Large projects under the OpenJS Foundation are those which the (Cross Project Council) CPC believes are, or have the potential to be, important to our Impact projects in particular or the ecosystem in general. They may be early-stage projects just getting started, or they may be long-established projects with minimal resource needs.

The OpenJS Foundation provides a beneficial, neutral home for these projects in order to foster collaborative development and provide a path to deeper alignment with other Foundation projects. There are currently more than 38 open source projects under the OpenJS Foundation umbrella.

Resources

The OpenJS Foundation provides a wide range of resources for organizations and individuals involved in the adoption and ongoing development of key JavaScript solutions and related technologies.