# \[Article\] Node-RED Development: The Numbers

**URL:** <https://discourse.nodered.org/t/article-node-red-development-the-numbers/82554>\
**Category:** General\
**Created:** [2 November 2023 15:59 UTC](https://discourse.nodered.org/t/article-node-red-development-the-numbers/82554 "2023-11-02T15:59:17Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![gregorius](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gregorius/32/73816_2.png) [@gregorius](https://discourse.nodered.org/u/gregorius)\
**Post date:** [3 November 2023 10:28 UTC](https://discourse.nodered.org/t/article-node-red-development-the-numbers/82554/6 "2023-11-03T10:28:05Z")

</div>

> [@knolleary](#):
>
> In the latter case, that may well require some amount of core Node-RED development work in order to expose the right APIs or extension points.

Imagining Node-RED as the kernel of an operating system (e.g Linux), then those are most important tasks that Node-RED can do: provide APIs for applications (i.e. packages) to dock onto. Linux had the advantage of ~30 years of Unix development and many APIs were already well defined and stable, so it was "easier" to build something that people could use, i.e. Unix developers could easily port their stuff to Linux because of the standard APIs.

Node-RED does not have that, Node-RED has to invent the standards.

Using this analogy has helped me to better place Node-RED into a category. I just hope Node-RED remains a modular kernel and does not become a monolithic kernel - I think that is something you are quite aware of thankfully.

> [@knolleary](#):
>
> In terms of the list of items you've shared - I'm happy to share my thoughts on individual items.

Thank you the clarity and honesty. I agree with your take on those features.

[FlowHub.org](http://FlowHub.org) has developed something more like a flows package manager and I might write something that explains better what I my vision is for it. [Flows.nodered.org](http://Flows.nodered.org) does a great job of being a _node_ package manager, but not for flows. Hence [flowhub.org](http://flowhub.org) tries to make flows first-class members of the Node-RED family. I didn't really plan this but it just happened as I began using it.

> [@knolleary](#):
>
> the existing Import/Export dialog is already pluggable so would seem to be the place to do that.

Which going back to the analogy with the Linux kernel, providing pluggability becomes the "APIs" that Node-RED should define. So perhaps less is more: less core features and more pluggability in every part of the editor.

For example something like the image drag&drop in NR 3.1.0 I personally find problematic since it bloats the flows.json with base64 image data. I don't know whether I would have included it or instead provided a setting for image uploading and then maintain a reference to the image in the flows.json.

If there were a way to make that plugable, I would replace that with something that uploads the image to some service and adds a link to the flows.json - much as this discourse does. The drag&drop part is a great idea, its the storage that I find problematic - to clarify my critical point of view.

> [@knolleary](#):
>
> In terms of a vision, we don't necessarily have something concrete written down that will give you what you're looking for.

Original you definitely created Node-RED for IoT application, at least that's what I've seen. Has Node-RED outgrown that in your opinion? Did you model it on the concepts of FBP or did that happen? What were your influences/thinking in creating Node-RED in the way you did, i.e. visually? I ask to find out whether you came to FBP via solving the itch you had or did you happen upon FBP after the itch was scratched?

---

_[View the full topic](https://discourse.nodered.org/t/article-node-red-development-the-numbers/82554)._