Add funding support & npm fund subcommand - #54
Conversation
|
thanks for documenting all that @darcyclarke 🙏 |
ljharb
left a comment
There was a problem hiding this comment.
Overall i love this direction; funding sources may stop accepting new funds over time, but are never “invalid”. (as such, it may be wise to support some way to include a funding source but also indicate that it’s expired/disabled)
This is something the support field - or lots of other tooling - can be built on top of. Potentially, GitHub could read from this field for npm packages instead of requiring a FUNDING.yml, as well.
isaacs
left a comment
There was a problem hiding this comment.
This is a good start. However, I think we need to focus it a bit more at this point, or risk painting ourselves into a corner.
I'd remove all the stuff about extra fields, foundations/corporations/patrons/etc., and focus on the behavior:
- We print a nag saying
n packages want your support - We open the url if you do
npm fund <pkg> - We print the list of urls and packages in your tree if you do
npm fund - We create a link on the package page on npmjs.com to the funding page
That is still a far cry from the ideal state, imo, but it's a demonstrable improvement over the current state of play (ie, postinstall that spams the terminal), and can start to encourage better behavior.
Things that are missing (and, imo, at this point really should be, until we've figured out more):
- Show a list of who is funding this package.
- Turn off nags for a given package if I'm funding it.
- npm just take my money and give it to the right people, based on what packages I'm using.
Co-Authored-By: Jordan Harband <ljharb@gmail.com>
@isaacs I think that if npm goes for this option the impact will be huge. Please consider an alternative to mainstream donation-based models! The community doesn't need another "sponsors" program where only webpack, Babel and Sindre Sorhus-like folks get funded because of their popularity (they deserve it but there are plenty of less known projects and folks that should get funding). |
|
Agreed it would be good, but much better to leverage existing platforms which are working on this. For example I think Open Collective is working on something called Back My Stack. (cc. @piamancini who was pinged when we brought this up for Express). |
My experience is that the "existing platforms" do not help all open source maintainers. Open source sustainability seems to be a big, unsolved problem. A big thank you to @darcyclarke, @isaacs, and many others who have been working hard on a solution that can help everyone (hopefully). |
|
for everyone still following this thread, follow up PR in npm/cli is here: npm/cli#273 |
|
For what it's worth, we have been chatting with the OC folks, and intend to continue to work closely with them where it makes sense. Today a lot of people who'd use the |
Bot-generated follow-up to the merge of `accepted/0000-make-scripts-install-opt-in.md`. Assigns RFC number **54**, renames the file to `accepted/0054-make-scripts-install-opt-in.md`, fills in front-matter (`status`, `accepted_at`, `created`), and regenerates `INDEX.md`. Front-matter was synthesized from the file's `# Title` heading. Edit the front-matter or the title in this PR if you need different values, then merge. Co-authored-by: npm CLI robot <npm-cli+bot@github.com>
No description provided.