Visual Flow Creator

[knolleary]

They can propose changes and we can discuss each one on its merits, with the context of where those ideas have been previously discussed and either added to the backlog or rejected. Just because they have implemented something, it doesn't mean it automatically gets merged back in.

But starting the discussion is the first step.

[sn0wcat]

I'd like to write a few words about the Visual Flow Creator, it's role within the MindSphere platform and how it is currently used. The nodes which you can see in the demo are mostly used for the orchestration in the platform, e.g. for subscription to our time series service, sending the data to our analytics service, etc.

We already thought about releasing some of them to open source but it wouldn't make that much sense because they wouldn't run anywhere else as they make certain assumptions about the environment they are running. (The node which is actually used for connectivity is released as open source under MIT license](https://flows.nodered.org/node/@mindconnect/node-red-contrib-mindconnect))

We did make some changes in the runtime to support running our nodes in serverless environments (AWS lambda, Azure Functions...) . This is something which is probably not so interesting for the classical connectivity scenarios but it makes sense if you are using it more as an orchestration engine in the cloud.

I will be glad to talk more with the core team about this (I am on the Node-RED #slack channel most of the time anyway)

I am sorry that I haven't spotted this topic sooner, we had already some interactions with the core team in the past and I'd explicitly like to thank Nick for helping out to identify the incompatibility with Node-RED 1.10 which I had in the @mindconnect/node-red-contrib-mindconnect node.

Best
@sn0wcat (Principal Architect at Siemens MindSphere)

[jan-kiszka]

A few words also from the IOT2000 side, as these devices were mentioned in this thread: This device family is a separate development, independent of MindSphere - though combinable. We started to preintegrate unmodified Node-RED in its reference image for certain technical reason and to introduce this extremely useful software to users how may not have come across it otherwise. I think the latter worked out fairly well, and that also for the benefit of the Node-RED ecosystem (though this might be tricky to quatify).

The technical reasons are related to the Intel Quark processor used in IOT2020 and IOT2040 which these days even require a customized NodeJS, and also some recompiled nodes with binary elements. As the Quark processor is EOL, contributing changes to upstream projects is now futile, we just continue the support until the device is EOL as well.

We now also preintegrate Node-RED on the new IOT2050 which is using an ARM processor and stock Debian. Here, it is merely the convenience story for users. They are even more free to install their own version as there are no technical constraints anymore. You can be assured that, if we had to patch Node-RED for any good reason, upstream first would be the preference. Luckily, there was no case so far. If you have any concerns or proposals about the way we do that, do not hesitate to reach out, e.g. via issues in the related OSS projects (https://github.com/siemens/meta-iot2050 / https://github.com/siemens/meta-iot2000).

No one is perfect, and we could possibly support Node-RED more directly as @sn0wcat also mentioned. We are already active in many OSS communities, hopefully in Node-RED in the future as well.

[knolleary]

Thank you both @sn0wcat and @jan-kiszka for posting to this thread.

I had a chat with @sn0wcat earlier today as well - and I will admit I had failed to join the dots in my mind between the mindconnect node we had discussed previously and the Visual Flow Creator.

To reiterate what I said in my original reply, there is no obligation for anyone to contribute back to the project. I understand all too well from first-hand experience that just because there's a large company behind something, you cannot assume they are overflowing with spare time to contribute back.

Node-RED benefits by being adopted by more companies and the visibility that brings. If we are able to benefit from some of the experience and knowledge that adoption involves, then so much the better. But there is no one-size-fits-all approach to this.

I look forward to continuing the conversation with @sn0wcat and @jan-kiszka in the future - I'm glad we've made the connection.

[TotallyInformation]

Can I just say that it is great to see dots being joined and community being extended. 2 things that drive open source development. Well done to all concerned.

Everyone benefits when this happens.