Repository navigation
Open OpenCollective and Github Sponsors for Node.js #1553
Description
I propose enabling Github Sponsors for the Node.js Github organization as well as creating an OpenCollective account.
Eslint already has an OpenCollective account which is enabled for a long time. (https://opencollective.com/eslint)
I don't see why Node.js shouldn't open one. @nodejs/tsc
Activity
richardlau commentedon May 11, 2024
FWIW we already have a LinuxFoundation crowd funding account for bug bounty/security: https://github.com/nodejs/TSC/blob/main/Nodejs-Bug-Bounty-Security-Fund.md
anonrig commentedon May 11, 2024
There is no funding source for collaborators that want to work on things other than bug bounty and security similar to Eslint's OC page.
aduh95 commentedon May 11, 2024
anonrig commentedon May 11, 2024
Eslint is an OpenJSF project and it seems contributors are getting paid not the foundation.
To provide a source of income for people contributing to Node.js and support the contributors.
I think this is a question asked wrongly. We don't need a problem to support contributors or enable them to contribute more to Node.js. Money helps.
aduh95 commentedon May 11, 2024
I'm -1 if it's for paying contributions, that seems impossible to do it fairly, and whoever would be managing the funds would inevitably be in a conflict of interest. I think it's great if contributors can get money thanks to their contributions, but you should cut the middle man and get the money directly.
mcollina commentedon May 12, 2024
The current LFX crowdfunding works well for emergency situations, as we have used it so far. I don't see a problem in keeping using a crowdfunding account and ask for money for relatively specific things, such as security or other non visible tasks. I'm ok of supporting people working on those tasks in those case.
As for generically paying collaborators... I don't think it's feasible to do it in a fair way.
gireeshpunathil commentedon May 13, 2024
if there is a growing list of things in the project's priority list, I would say that is a good problem statement to incentivise contributors. potential issue with lack of contributions in some areas is lack of voluntary time of collaborators, and incentives addresses this at its root - the voluntary work becomes paid work!
I support the intent.
on the other hand I recognise the challenges mentioned in implementing it. shall we try it once? if it doesn't work, so be it and we will fail fast and learn from that. if it shows us some path, we will cut through it, improve as go forward and create some best practices around paid and collaborative open source development - first of its kind!
anonrig commentedon May 13, 2024
Anything performance related stuff requires lots of effort and time. Hence, funding would make an excellent motivator for outside parties. We can talk about "tasks" or just start marketing funding for performance tasks and once we have enough money, we can ask people to apply to funding with their performance related work.
tniessen commentedon May 22, 2024
I think the last comment already highlights part of the problem: some folks might be under the impression that some particular area of work should be a priority, and that we hence should prioritize seeking funding for the contributors of that particular area. As pointed out above, that's unlikely to result in fair opportunities/compensation across the project. Conversely, if we seek funding for multiple distinct areas, or if we prioritize within some generic pool of funding to cover multiple distinct areas/tasks, that is likely to result in some sort of popularity contest instead of fair allocation.
(Admittedly, performance-related stuff sells well on social media, and might already be easier to find funding for than other equally demanding/important tasks.)
jasnell commentedon May 23, 2024
I'm strongly -1 on this. If individual contributors want and are able to set up individual sponsorships then I strongly encourage them to do so but I think the idea of having the project somehow pay bounties for regular contributions when such a service would not generally be possible for all contributors to take advantage of is unfair and would be a mistake. Some contributors may live in jurisdictions where such services may not be legal, available, or may carry additional tax burden, and could even put them at risk. Others may have employment contracts that prevent them from being paid like this, etc. The security related bounties are and have always been a special case.
This also quickly becomes easy for someone to unfairly game the system. Back at the start of my career, over my first two years at IBM, they used to pay employees $3k per article for the IBM developerWorks website. I ended up take great advantage of that by writing 4-5 articles per month! It turned out great for me but ended up draining their budget to the extent that they ended up having to lower the payout for everyone in the subsequent years and eventually had to stop paying entirely.
mhdawson commentedon May 29, 2024
Related Next-10 discussion on funding, those interested in this issue thinking you may be interested in joinin the deep dive - nodejs/next-10#273
Trott commentedon May 29, 2024
If it hasn't happened, someone should talk to the ESLint and webpack leadership about the benefits and challenges of having done this.
mcollina commentedon May 29, 2024
The only way that would be feasible for us to do it is to keep the funds for "extras", and not to distribute it for day-to-day development... until we have enough to distribute it fairly.
aduh95 commentedon May 29, 2024
Even with an unlimited amount of money, I have some doubt about "fair" being achievable: we all going to have different viewpoint on how "valuable" is such and such contributions (and what is a contribution even). Also whatever rule we decide, people will be incentivised to game it. I have a really hard time imagining the project distributing money would be a positive thing:
I'm not trying to argue the status-quo is "fair" either, to be clear, I realize one's gotta be somewhat privileged to work on Node.js. However, I'm unconvinced involving money would make the situation more fair.
30 remaining items
mcollina commentedon Nov 14, 2024
As a follow-up of the collaborat summit, I propose we enable GitHub sponsor on the Node.js project, directing it to an OpenJS bank account. @rginn mentioned that the Foundation would be able to hold to the funds and help manage them and provide an account/card for this.
I propose we hold to the funds and keep them as a war chest for emergencies (for now).
ovflowd commentedon Nov 14, 2024
Can we create a FUNDING.md or OPENCOLLECTIVE.md document first and charter how disbursement should work? Or any related documentation related to Funding policies?
mcollina commentedon Nov 14, 2024
No disbursement. We'll keep the funds for selected initiative, as an example security.
ovflowd commentedon Nov 14, 2024
That is still disbursement. I think it needs to be written and documented what the funds are for and how they are used, that is vital for the community and sponsors.
aduh95 commentedon Nov 14, 2024
I agree with Claudio, it’s quite important that we set up rules for ourselves that are very hard to abuse. Having a hand-wavy informal agreement is the perfect ground for abuse.
In particular, I think it’s important the decision does not fall on the TSC, or at least that any community member could object to money-related TSC decisions and have some external jury which can decide if the objection should be sustained or overruled.
mcollina commentedon Nov 14, 2024
The decision will ulimely fall either on the TSC or on the Executive Director of the Foundation.
voxpelli commentedon Nov 14, 2024
I think there are still unanswered questions, fears, suggestions in this issue that should be answered first.
I personally think GitHub Sponsors would be more symbolic than substantive and could do more harm than good in that it sets lower/cheaper expectation than would be needed to have an actual impact on the Node.js project.
mhdawson commentedon Nov 14, 2024
We could start with a releatively simple version of those two files that basically says that the dollars collected will be generally be directed towards larger/longer term efforts as decided by the TSC.
@aduh95 I think the size of the TSC means that we are not going to get consensus for something that is not in the best interests of the project. We could tweak what it takes in case of objections by TSC members (for example requiring more than 50% of the TSC to vote for a proposal) but I don't think trying to spin up some additional body of people who can override/a decision/oversee the TSC makes sense.
mhdawson commentedon Nov 14, 2024
@voxpelli can you expand a bit on as some other projects have collected subtantial enough sums that are substantive.
mhdawson commentedon Nov 14, 2024
As an example of what we've done before this is the documentatin on how we will use funds from the bug bounty/security fund - https://github.com/nodejs/TSC/blob/main/Nodejs-Bug-Bounty-Security-Fund.md
mhdawson commentedon Dec 4, 2024
PR to document process that would be used - #1658
mhdawson commentedon Jan 6, 2025
I'm removing the agenda tag so that it does not appear on the next TSC meeting. The PR to document that we will open the crowdfunding accounts and how we will manage them initially has landed. My next step is to talk to Ben at the Foundation with respect to the best way to do the initial setup.
RaisinTen commentedon Apr 5, 2025
I see an open collective - https://opencollective.com/nodejs and a github sponsors - https://github.com/sponsors/nodejs for node and the discussion has stopped happening, so I'm closing this issue as completed. If anything else like disbursement needs more discussion, that can be continued in a new issue.