Yes agree, and having experienced this issue a number of times it's very frustrating, and by example, and most recently with node-red-contrib-ringdoorbell where I've raised an issue, but suspect that the author may not respond.
So my next step maybe to try & fix the problem and publish node-red-contrib-ringdoorbell-2 which isn't really a good solution, as well you know.
But as there is only one 'Ring doorbell' node, it maybe the only way forward.
Yes you've raised an issue, you could also offer a Pull Request to fix it. The author may be more responsive to actual offers of help. You can also try a direct email, to check if they are still interested, and then finally yes go ahead and create a new version.
If you get no luck on their issue list, then this can be a useful next step. One tip - npm owner ls <module-name> will list the owners of the module and their email addresses. Useful if a node doesn't list a git repo or other obvious way to contact the author.
If you do go that route, just keep in mind you have no idea why the user hasn't responded. It could be they have turned off github notifications for some personal reason. They may have had to move onto other things. So tread gently and be a positive representative of the NR community.
On the topic of identifying unmaintained nodes... this is certainly something I'm going to look at. If anyone is interested in collaborating, please do message me directly or on slack. I've got access to all the raw data, so as @afelix said, please don't go scraping the flow library site directly.
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.
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....
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.
1 Like
