Once they are in the 'official Node-RED sphere' then the Node-RED project has to maintain them.
Given we don't get much help maintaining the existing node-red-nodes repository, I'm not immediately inclined for the project to take on more responsibility. If more people were actively contributing, then it would be a different matter.
That said, there clearly is an issue with contrib nodes becoming unmaintained. I would hope that if there were particular nodes of interest, then individuals could work with the previous maintainer to take on the ownership. Putting the nodes into the Node-RED organisation in github (and all that implies, whether intended or not), isn't necessarily the right first step.
Something else to think about @cymplecy is when the author of the contrib node simply stops responding regardless of personal situation. I can see that happening towards myself if my health further worsens. It wouldn’t just be ownership of a repository, but once packages are registered to npm that name is registered too, and only the original owner can transfer the ownership for that.
A result of that would be (numerous) forked nodes that get published on their own package. It already happens like that, try searching the flows library for “elasticsearch”, they all have the same original contrib node. It makes searching for nodes from the palette even harder as you can’t see the real difference between all of them without checking out the source code.
The idea definitely has merit, but don’t forget about the difficulties it might/can get also deal with ownership towards the OpenJS Foundation, as that what’s moving to the node-red organisation would likely mean as well. Even just forking would make it difficult I believe. But food for thought for sure
Indeed. Any activity like this must start with a conversation with the original maintainer. Get their approval to take it on and not just fork and cause confusion.
A good example is the Cloudant node we have in the IBM Cloud. The original maintainer left IBM a while ago and isn't able to maintain it any more. Having discussed it with him, he has recently added me as an owner to the npm module so I can publish updates. I'm now going to work with the authors of all the forks to try to bring them back together to one node.
I suspect there are other nodes with multiple forks that would also benefit from some rationalisation - particularly those for popular technologies (such as elasticsearch as @afelix mentions). There's a lot of nodes in the flow library that have no real need to be there and just cause confusion. But it's too big a task for one person to do.
Especially if that person is looking after the NR core.
Perhaps a place to start would be to develop a couple of bits of code or even NR flows that could scan the flow library and
Identify nodes that had not been updated for more than (for example) a year and send an email to the maintainer(s) asking whether they are still active and willing to keep the node current or, if not, whether he/she would be willing to transfer ownership.
Compile and publish a list of nodes that are available for "adoption" so that volunteers could ask to take over maintenance.
I'm not convinced this would accomplish much, but it might be worth a try. The problems of multiple forks or abandoned nodes might call for more drastic action, such as purging them from the library and listening for the screams.
I think there is merit to this. Not necessarily the second part (asking about transferring ownership) initially. With some data mining we could identify nodes that look abandoned and approach the maintainer to see if it's active. Part of that will also be the npm download stats as there are plenty of useful nodes that are stable and not needed an update. If the recent npm stats are negligible, the owner confirms it's a dead node and it's clearly not a high value node, would could remove it from the flow library.
Its worth some thought. Yes there's work involved, but the flow library is over due a tidy up and this would one way of tackling it.
I might be speaking before my turn but to future readers: please don’t see this as an open invitation to start scraping the flows library page as it’s already under load (as was mentioned in other topics once or twice in the last view months)
If you’d like to check out the library like that, just clone the catalogue repository and work your way through that JSON file, no need to put stress on more Node-RED resources than strictly needed.
Ouch! That's ugly. I guess it was naive of me to assume only good intentions in the NR community. I recall some earlier discussion of detecting malicious code in contributed nodes, but I don't remember where it went.
The overall contribution guidelines are here - https://nodered.org/about/contribute/
but the net is - find a bug / pick an existing issue - offer to help / propose a solution - discuss here - if it's good then create an issue (or add to existing) - write code - test it - raise a Pull request. You are now a contributor.
Is that a good measure of an abandoned node?
Maybe it was just well written in the first place, and therefore there was no need to carry out tweaks & fixes
There are some really valuable thoughts in this thread.
Helping maintain core nodes
I will admit that I struggle with this. It isn't a lack of willingness to try. But I find that it is hard to clearly see what might need doing and harder still to do any work while they are munged together in a single module.
Would a useful starting point be to create a new forum section? Where we could start to look at key issues and suggestions for these nodes?
Also, if each node had their own list of issues, that would help. Each in its own @node-red module would also make life easier. Maybe that's the place to start?
Maybe some of this already exists and it just needs Nick/Dave to walk us through some stuff?
Another idea might be for a few of us to "sponsor" a core node. To agree to help support & develop it for a while?
Identifying unmaintained nodes
I think that a separate table of nodes that:
hadn't been updated in 2 years and had dependencies that were out-of-date or had known issues with current versions of Node-RED
would be really useful. It would help others in the community know what might need some TLC and know how to help out. As you say, by contacting the owner of the repo first.
Nodes in that table could also be marked in the flows library but a simple list would be really useful as a quick reference.
2b) might be quite hard to work out but 2a) should be scriptable. The whole thing would have to be run periodically by script so that it wasn't adding to resource overheads.
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.
I wouldn't mind an annual e-mail asking if I am willing to respond to issues.