Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Proposal for `npm tip` #16300
This proposal arose from a conversation I had with @mathieudutour about how to fund authors of small but valuable open-source projects.
tl;dr: proposal for a way to tip package authors from NPM, request for comments and suggestions.
It is very difficult to support yourself whilst contributing to open-source. Typically, maintainers of open-source projects do so in their spare time, with varying degrees of support from the community, whilst working in an unrelated position.
Also, maintaining an open-source project is more than just coding. When you maintain an open-source project of any size there are numerous support tasks to perform: triaging emails and issues, handling pull requests, managing dependencies and, if there are additional contributors on the project, organizing and distributing the workload. This can be extremely time consuming and lead to a feeling of “this is more than I signed up for”.
If you want to work on open-source full time, your options are currently:
Whilst these solutions may work for some people they certainly do not satisfy every case.
What would be nice is a way for open-source developers and package maintainers to receive financial contributions for their work without having to ask for it and for those developers to be able to continue to work in open-source without being restricted by their job or employer.
The main problem is that it is hard for users of open-source software (developers like you and I, businesses, educational institutes, etc.) to give money to the people that create it. There are some projects in place that try to smooth this problem but they all feel disjointed from a developer's workflow and require extensive setup.
Patreon is a good solution, allowing users to contribute to supported projects by pledging an amount to a project each month. The Patreon model has supported artists and designers successfully, along with several game studios (notably the guys behind Dwarf Fortress). The downside to Patreon is that, due to the full-featured nature of the platform, the pledging process is quite involved.
Another solution that exists is to donate to an awesome organization like Open Collective and let them support open-source projects for you. This works pretty well (and it has certainly helped the likes of mocha and webpack) but it still requires a measure of setup and feels quite 'heavy' for what should be a simple task. There is also the caveat that the project you want to support will not necessarily be featured!
A third possibility is Tip4Commit, a platform that allows one-off Bitcoin payments to be sent to supported projects. Tip4Commit requires less setup that the other platforms (there is no account required, for instance), however, as with the other solutions, it does not easily integrate with the development process and requires additional steps to be taken.
The question remains: how can users of open-source software easily contribute to the packages they use, without additional setup and without interrupting their development flow?
This pull request extends
To tip a package, a user must perform the following steps:
The first command,
Once an account has been set up, using the second command,
The pull request includes help documentation with more information about each command.
One improvement that was discussed is the provision of an auto-tipping feature. Auto-tipping would attempt to tip a project whenever
An extension to this would be the ability to set a periodic (daily, weekly or monthly) budget: once the budget has been exceeded the auto-tipper is disabled until the period has elapsed. This would prevent unexpected spending during periods of high-usage. Alternative schemes are conceivable and are discussed in the Questions and answers section, below.
Why is tipping sent using Bitcoin?
Bitcoin lends itself nicely to the problem as it is a digital currency with numerous providers exposing APIs. It is possible for anyone to create a Bitcoin address and begin to send or receive tips, regardless of nationality or locale. A bonus of using Bitcoin is the support of m-of-n addresses: addresses that require multiple keys to sign transactions from the account. This feature could allow packages with multiple authors to collectively manage their tips.
One problem with Bitcoin is that it doesn't handle micro-payments very well: sending a really small amount, such as $0.01, can cost more in fees than the value of the transaction. Coinbase imposes a limit that transaction values must be at least 0.0001 BTC.
It would be nice to implement a truly agnostic tipping system but that was deemed to be beyond the scope of this pull request.
Questions for you
The proposed solution begs many questions and some initial answers have been given here. However, there are lots of unanswered questions and one of the motivations of this pull request is to find some answers to these.
What should happen if a tip is sent a package that has not specified an address?
Currently, nothing. One possibility is that the funds are sent to a 'holding' address and may be redeemed for a number of days by the author. The problem with this is the requirement to maintain such a holding address which, presumably, would need a trusted third-party.
Should it be possible for my employer to pay for my contributions?
This is a motivating question as many employers make extensive use of open-source software and it would be amazing if some opted to use such a scheme to provide some contribution. With the current scheme this is possible by performing the following set-up:
This solution is slightly limited, however, as the employer has no record of what has been installed, nor any assurance that the employee is using the account for work alone. One conceivable scenario is that an employee could be deliberately installing their own packages in order to profit.
Additional development, such as the logging of any tips made and, in the event of the inclusion of auto-tipping, centralised control of budgets, is required for this to work in the wild.
How would you want auto-tipping to handle sub-dependencies?
There are a lot of utility libraries that are used across a large number of packages (e.g.
It is important that, in providing users with the ability to easily tip and support the packages they use, that the way packages are created and deployed is not affected.
Consider the following example:
babel and lodash
Another example is
There is a danger that unscrupulous package maintainers will divide their packages into multiple components to capitalize upon auto-tipping users. This clearly needs to be mitigated against.
How would you like auto-tipping to split the tips across the budget period?
There are several obvious schemes that each have positive and negative aspects, described below. These schemes could be implemented and chosen at the user's discretion, using configuration settings in
The simplest solution is to tip, using a specified amount, each time a package is installed. When the budget has run out the auto-tipper is disabled until the next budget period begins. The downside to this scheme is that packages installed at the end of the month are unlikely to ever receive any contribution.
Another simple solution is to log all installations across the budget period and, at the end of the period, equally divide the budget amongst the packages and send the tips. One possible problem here is that a large number of installations may lead to each share being extremely small - potentially too small to be effectively transacted by the Bitcoin network.
It may be desirable to tip some packages more than others, such as those used in every project (
One possible metric is the frequency of installs of packages, where packages installed more frequently are ranked higher. This seems like a reasonable suggestion.
Another possible metric is the size of packages, using the assumption that larger packages have taken more work to create and, perhaps, deserve more contribution as such. The size of a package could be easily measured in lines of code or tarball size. This metric has two potential caveats, however: the first is that size does imply quality and the second is that, if such a scheme were adopted, it is conceivable that unscrupulous package authors may simply write longer, more verbose code - a practise surely to be discouraged.
Another suggestion is to use code inspection to determine the number of times a given package was imported, where a oft-imported package is given a larger share of the budget. However, determining the number of imports presents it’s own problems: when should the count be taken, does a first import from one project ‘weigh’ the same as the 100th import from another, etc.
A final consideration is that some users may wish to create a custom weighting - to contribute a larger proportion to certain favorite or small projects. This scheme could feasibly be used with any of the others by including a list of package-specific weightings inside the configuration settings.
I would like to acknowledge that I believe some people will be unhappy with this proposal as it allows open-source to be seen in a more financial light. It is possible that, if such a proposal were accepted, more people would contribute to open-source as a means of work and, in some cases, the focus could shift from altruism (or whatever the current motivation may be) to profit-driven. My own feelings on this matter are not clear but I do feel like the possible benefits are numerous and outweigh the possible negatives.
I would also like to make it known that I am not affiliated with Coinbase, Bitcoin, or any of the projects mentioned. In the past I have worked as a cryptocurrency consultant but, although I maintain an interest in cryptocurrency, I am no longer involved. I have never been affiliated with Coinbase and my only connection to the Bitcoin Project is a correction to one of their tests.
One criticism I have seen posted is that a malicious user could include a script in their code that automatically tips them (
I have two other criticisms to add:
Hi @catdad and thank you for contributing to the discussion!
I welcome the opinion of others on both of these points and any other questions. I would like to prompt some discussion surrounding this PR.
Hey, I'm not gonna make an official response to this right now, but I wanted to drop a note that I noticed it and read it and mentioned it to folks, hence tags.
Thanks for taking the time to think through this, write it up, etc, and it seems like the discussion is pretty civil and thoughtful. Please continue being kind to each other while y'all talk about it, and we'll have a more concrete response once we've had the time to talk it through in the team. :)
Great write up and great to see more people thinking about this. I wanted to reference another conversation on the very same topic that we had a couple of months ago here: opencollective/opencollective#178
I think this is definitely worth trying. Maybe at first as a separate package in user land. We would definitely be more than happy to support this and give an API endpoint to donate to an open collective.
My only concern about tipping is that the amounts are small unless you are the creator of Vue.js or Mastodon. We have seen that problem before with GitTip/Gratipay. The real money is in companies and they need an invoice to get any money out. That's what we are trying to solve with open collective. We wrote about this issue here: https://medium.com/open-collective/a-new-way-to-fund-open-source-projects-91a51b1b7aac?source=linkShare-388996e27d02-1493327243
Never let anyone discourage you. Any experiment is always worth trying. There is always something to learn!
Thanks for the feedback and those [very] interesting links to read. When you say Open Collective will be happy to provide an API endpoint, what exactly did you have in mind?
I'm going to wait for the official response from NPM before going any further with this - although I'm still spending lots of time thinking and having regular conversations about it. We'll be in a better position to know how to proceed once we understand NPM's position.
@lukem512 I don't think there will be a concrete response quite yet. I think this sort of thing needs to spend more time being productized and integrated before it can go in the main CLI. I think my preference, tbh, is for this to be a third-party app, and have it be proven there. Once a third-party package manages to be popular enough, I think that's more a time when it would make sense to integrate this into npm. We tend to be pretty conservative about new commands because once they're in, they're incredibly hard to remove if we figure out we did it wrong.
This isn't a no or a final answer. Based on conversations on Twitter, and in here, I think this really just needs a lot more hashing out, and I'm not sure the current PR is the one we'd want to pick up for this.
I think it's really important to find sustainable models for paying open source people. I, for one, am someone who works full time on open source: I don't write literally any proprietary software in my day-to-day, and my prime directive is to serve the community's needs, not wring them for $. I have a lot of solidarity for this sort of push. I'm very interested in the sorts of things Open Collective are doing. I also think models like Patreon can work well for individual developers.
I'm inclined towards closing this specific issue, though: I'm not comfortable, for example, hardcoding currency values right in the CLI. The CLI is the sort of software that, once in legacy, will remain there for many years. This would be the case with most currencies, but BTC in particular has a history of being so unstable that you need to be fairly up-to-date to have a realistic market value. I remember when 1BTC was barely worth several fractions of a cent. I also remember when 1BTC was worth $1000.
So: I'll give it a while longer because there is some good conversation here, but this is a PR, not a general community planning platform. I will likely close this specific PR in the near future, but I encourage you to continue the conversation either in a feature-request issue, or in other community platforms where even more people with different concerns can join the conversation. I really don't know how something like this can fit into npm right now -- nothing seems quite proven or mature enough to be included by default. Note that many, many tools in the community right now enhance npm pretty smoothly simply as external packages: consider the various test runners,
Thank you for taking the time to respond. I honestly assumed as much - as I've mentioned previously my main drive for making this PR was to encourage conversation and to unpick the problems with my proposal and I didn't really expect it to be supported in this early form.
I'll take a look at the packages you've mentioned and try to come up with something more agnostic and extensible.
I appreciate all the comments regarding this, here and elsewhere, and if anyone has anything to add to the conversation please do so whilst this is still open.
well this seems to have been a good stopping point. I'm going to close this PR, as I said before. Thanks again @lukem512 for the thought-out proposal and for getting this conversation started. I look forward to seeing what sort of solutions we can come up with as a community.
Hey everyone! I know it's been a while since this issue was opened, but I just discovered it while building
I punted on solving a lot of the hard problems discussed earlier in this issue thread, like payment methods, deciding how much to allocate to each maintainer, etc. The tool is deliberately simple -- it just tells you that a maintainer is asking for donations and directs you to their donation pages where you can read more and decide how much to donate.
I think it's a simple first step. It raises awareness that you may have dependencies looking for donations, but doesn't prescribe how much to donate or whether to donate at all.
We're also considering supporting a new package.json field. Please share your thoughts!
The repo is here if you're interested in collaborating or discussing further: https://github.com/feross/thanks