So I found some bugs in a node I installed and created 2 issues on the repo's github page, hoping that the author may fix the issues I'd found. He responded saying he didn't have time to work on it. Totally understandable. So I decided to fork and contribute some changes. The author hadn't been very responsive (just the one comment) and I wasn't sure if he was open to me submitting some changes, so to test the waters, I created a PR from my own branch to my own master and tagged the author as a reviewer (and invited them as a contributor) and asked if they'd be interested in a PR to their repo.
I haven't heard anything further from the author for the following 2 or more weeks to now. Since then, I've created a similar PR that adds a bunch of new functionality. I'm still testing my changes. I found a bug last night. (It's hard to test, because it's a geofence node and requires multiple people to leave a location to make the tested feature trigger node output.)
I admit I'm somewhat anxious to share my work and this morning (since the work fills a void left to those who don't sign up for a paid IFTTT account - and since the Life360 app will be dropping support of IFTTT in the near future), I started reading about how to publish a new node. Ideally, my changes would be incorporated into the original repo, but if that doesn't happen, I figure creating a separate package would be the way to go.
Though I was tempted to change the node output and the behavior, I maintain both, and only added additional optional features, so as to remain compatible with flows that currently use it.
So if I was to release a separate node, what things should/shouldn't I do WRT:
node name/version (should I change the name and/or versioning?)
author (does the package.json support multiple authors? And is there a convention for author order?)
attribution (what's the best way to refer to the original repo?)
How long should I wait for the original repo's developer to respond to the internal PR's I created? Or should I wait to see if a direct PR gets a response? I think I will submit the bug-fix branch as a PR to the original repo. The new feature branch is branched off of the bug-fix branch, so I figure I will wait to submit that one.
Other related questions:
The repo has a hard-coded client token for the Life360 API. I assume I should create my own token if I create my own node package?
The license is GPL 3.0. Is the change log in git sufficient for the "state changes" requirement, or do I need to create a CHANGES doc and/or add to the README?
Each repo owner / component author is free and likely to have their own policies and preferences in this regard.
That said, any open-source project is by definition there for the forking within the limits of its published license terms.
In my own opinion:
Publishing a forked project is entirely fair and reasonable, especially if the original author is too busy or has lost interest in maintaining the code. Again, care must be taken to follow the terms of the original license. This usually means, at least, giving full credit to the original author and contributors and may attach other strings as well.
As for naming and versioning, that depends on whether the new component is intended as a permanent alternative to the original one. If you plan to maintain your own version indefinitely and evelove it however you see fit, then using an entirely new name and versioning sequence is appropriate.
If the intent is simply to make a few specific fixes available to the community while still planning to hew to the future progress of the original component, then using NPM's scoping mechanism is appropriate while sticking to the original component's versioning.
The latter will make it far easier to pull future versions into your fork from upstream and cause far less confusion going forward for anyone who chooses to use your scoped version rather than the original.
Indeed when a node project is abandoned, probably the only choice is to publish the fork as a new node. However I try to avoid that as much as possible: then the users have to decide which one they have to use (the original or the fork). And perhaps later on the author might get free time again to add other new features on the original node. And then users have to start comparing, which is far from good. So I really like to avoid that! Although the license permits it, I don't like to claim the ownership of somebody else his hard labour...
Don't forget that contributors have also a familly and a daily job, so they won't have immediately time to review all the stuff. But of course, he might have forgotten about it so a polite reminder might do the job..
And keep in mind that your (like you call it) "pedal to the metal approach", is hard to digest after a hard day at work
I think, one key rule, if you will, is to give credit where credit is do... so if you branch or fork a project, make it clear why you did it, and how it is of benefit, of course done professionally.. Even if such is subjective, clearly stating what and why gives the potential user proper context.
Moreover, the title cracked me up... I remember a class on data structure design, where a friend of mine said, a bit too loud... "To Fork Or Not To Fork... Now That IS THE QUESTION." Needless to say... some people in ear shot, did NOT hear what he said correctly. I leave it to you do decide HOW they misunderstood. Unfortunately, the professor lecturing was not sure what he heard EITHER. LOL.
