Taking control of contrib nodes when not being maintained

Tried that. No reply.

...and all the other outstanding issues? Future issues?

I gave this as an example, and don't get me wrong, there may be good reasons for this: gone out of business, prioritising workload, health, etc, etc.

I'm just reinforcing the need to generally address this as per Simon's original post, from a user perspective.

Would it be better to have NR Core members publish the npm module, so the plugin name is owned by NR and more easily transferred to a new maintainer? Maybe a plugin review step, then publish, prior to being displayed for installation. I've had to dive through 4 different AWS SDK plugins repositories, before I found one and it was unmaintained.

Not sure if this is feasible, but just throwing an idea out there.

For those interested, here is a dump of the relevant data.

For each node there is column for:

  • when it was first added
  • when it was latest updated
  • how many days since it was created (based on today's date)
  • how many days since it was last updated (based on today's date)
  • how many days was it 'active' (days from created to updated)
  • how many downloads did it get in the last month (minor caveat - any module that has refreshed today will have its downloads set to 0 because thats how it works).
  • the list of npm users associated with the node

I have added colour scales to the - days since updated, days active and monthly downloads columns.

From this we can identify nodes that warrant some further action to see if they should stay in the library. Please do not take any actions yourselves based on this data. I'm sharing this data in the spirit of openness. All of the information within it is freely available via npm.

Of course I could have scripted it, but sometimes dumping data into a spreadsheet and playing around with it is far more effective. And now I have a better sense of what processing needs to be done on the raw data, so I could automate it for next time.

No. We don't want to become the bottleneck or gatekeepers to the community. That was an intentional decision we made at the start. We do not have the resources to review every update that gets made - in a typical day there will be 10+ node updates published. That would be almost a full time job.

This is one of the reasons we added the ability to rate individual nodes in the flow library - so the community can help curate the list. (As I write this sentence, I realise I haven't included the rating score in the spreadsheet. I may go back and add that... or I may not.) So if you've tried a number of AWS related nodes and hit issues, I encourage you to rate the nodes accordingly in the library.

1 Like

Is there no way to extract data about 'issues', ie number of, and days since last issue recorded.
That maybe would help with the selection criteria.

None of that information is held by the flow library - it will be held in what ever issue tracker the node is using.

The information can be mined, but is considerable more work than the quick database dump I did this morning.

Not all nodes identify a git repo and lots of the cloned nodes haven't updated to point at their own repo vs the original node's repo (which is another indicator to note).
It will certainly be worth doing - just needs more time/effort than I can spare today.

1 Like

Following the discussion for a while I like to add a comment now

I’n my personal experience the use of star ratings are very limited. Seen from both sides as a user and a developer

  • “It is easy to criticize” as on shopping sides you will get all kind of criticism which is often not related to the product itself. Without a descriptive text you now nothing. Was the one star rating by accident, because of not reading the doc or because the node do not fit the individual purpose. (On my node i have one one star rating without any feedback no issue no discussion no nothing)
  • You get negative feedback more likely than positive. When was the last time I went back to the library and gave a 5* rating for a node that helps me a lot?

The main reason why I switched from another home automation system to Node-RED is the freedom and the possibilities out of the contrib sphere. So many great nodes so much hard work. We should think twice to give this up. A review mechanism will put up a huge barrier for innovation and fresh ideas. Even the idea to take the ownership from the beginning will take a lot of the motivation to participate.

But I agree there is a problem with none maintained nodes for beginners selecting the right contrib-node. Most of us will always take a look on comments in the forum, look into the issues and revisions and do tests before relying on a contrib-node. Issues on GitHub only by number gives a wrong impression too as many projects use the issues for discussion, feature requests and many other things. Same for any last updated dates (as mentioned before)

Here are some of my Ideas, hope they are not all duplicates:

  • establish a link between the forum and the library by listing links out of the forum where the node is mentioned. A active discussion can say a lot (used by others, feedback, experience, tips and tricks, solutions ...)
  • instead of the stars there could be a tag system were users could give a selection of tags to a node: usefull, limited usecase, incomplete, has bugs, well maintained, seems to be dead (i leave the wording to somebody else). Tags can be counted and there should be a small text box to give a reason to the developer and other users to get into contact. The developers should be able to get into contact to the commentator too - so many miss understanding lead to bad things.

So in the end it is a question of social skills to communicate and own responsibilities.

Finally I like to say that Node-RED is my favorite of many projects (not only IT related). Friendly people, always willing to help newcomers. Especially @knolleary and all the others working hard in maintaining not only the code but also the friendly atmosphere: Thank you so much.

Nick, I've started looking at the nodes from 2014 - how do you want reports? For instance:
node-red-contrib-async - a PR was merged 14 days ago, but it doesn't look like it was actually applied to the code. Should I point this out to the owner?

Then there is node-red-iced-coffeescript - the contact info references a URL that no longer exists.

Sadly this isn't just a problem for node-red-contrib packages. The problem exists for npm packages, useful javascript libs, toolkits and many open source communities.

There is an abandonware effort that we might want to learn from too.


I think that the best way to enrich the data would be to integrate the npms.io API which already has some metrics about quality.

https://api-docs.npms.io/

This would be better than tracking numbers of stars for sure.

However, it is more work as you say. Shouldn't be hard to do though once you've gone from a one-off db query to a script.

I took all the nodes not updated since 2014 and took a look at them. Here is what I found:

Nodes last updated in 2014

Owner active on GitHub - node working
-------------------------------------
node-red-contrib-mapper			owner active - no PRs no issues - works as advertised
node-red-contrib-async			commit was done in Jan 2020 but says it is 5 years since published - asking author about this
thethingbox-node-sensortag		still being downloaded - sites last faq entry references Jessie - many grammatical errors	
thethingbox-node-timestamp		node works, adds msg.timestamp to msg

Owner active on GitHub - node not working or has bug
-------------------------------------
node-red-contrib-collector		owner active - owner recognize bug but it has not been fixed since 2017
node-red-contrib-ds18b20		two PR from 2016 and 2017 waiting to be applied
node-red-contrib-logentries	 	owner active - node gets an error at startup
node-red-contrib-neo4j			owner last active March 2019 - 1 issue (2018) and PR (2017) pending

Owner missing/not active on GitHub
----------------------------------
node-red-iced-coffeescript		owner gone - owners url link no longer exists
node-red-contrib-ssdp-discover	owner gone - node still works
node-red-contrib-pitft-touch	owner last active on GitHub - August 2017
node-red-contrib-iotclouddev 	owner last active on NPM 2yrs ago
node-red-contrib-orchestrate	owner last active June 2018 - no issues or PR's
node-red-contrib-crate			owner last active June 2018 - open issue/bug since may 2018
node-red-contrib-iotclouddev 	owners last activity on NPM 2yrs ago

Odd balls
----------
node-red-contrib-rtcomm         node renamed to lib.rtcomm.node-red
node-red-contrib-jsonpath	 	owner Knowledge Media Institute - The Open University. looks like an early version of JSONata
node-red-node-babascript	 	node says it is under development

Does this help?

4 Likes

What I think is that there needs to be some sort of board of officers that reach out to the author. They can work with the author to take the best steps forward.

The board can also reach out to contributors. These work for other organizations, why not here. We know the few that are the leads here, why not acknowledge them. Maybe NPM and Node-Red both have boards that work with each other...

@dceejay @knolleary would start and ask for counsel from others to round out the board.

Then there can be 1 board discussion a month. They can ask for topics beforhand.

This sounds like overkill for the contributed node problem and just a bit contrary to the spirit of open source. Spotting the issues and appealing to contributors' sense of responsibility to the community is as far as I think we should go.

3 Likes

All things benefit from prudent oversight....

:slightly_smiling_face: Quis custodiet ipsos custodes?

2 Likes

Would it not be possible to consider a Node Store similar to App store for Android. This would encourage developers to produce more nodes and maintain them. There are already valuable contributors that have stepped back because they cannot afford to spend the time developing and maintaining an ever increasing list of nodes. This is a loss to the community and adds more responsibility to the overworked core team. The intention would be that nodes could be purchased at nominal cost ( a few or £ or whatever). This may go against the open source ethos of NR but there is an ever increasing number of practical NR users that are not hard core developers, but are using NR in a practical way. I am sure they would contribute a few /£ to support the development of new nodes if it solves a problem.