Open OpenCollective and Github Sponsors for Node.js

[anonrig]

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

[richardlau]

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]

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

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]

• Who would get the money? The Foundation? In that case, I don't think that's up to us.
• Given that we certainly cannot provide the same perks as ESLint, I'm not sure I understand what would be the point.
• Do we have problems that would be solved by having more money?

[anonrig]

• Who would get the money? The Foundation? In that case, I don't think that's up to us.

Eslint is an OpenJSF project and it seems contributors are getting paid not the foundation.

• Given that we certainly cannot provide the same perks as ESLint, I'm not sure I understand what would be the point.

To provide a source of income for people contributing to Node.js and support the contributors.

• Do we have problems that would be solved by having more money?

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]

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]

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]

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]

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]

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]

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]

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]

If it hasn't happened, someone should talk to the ESLint and webpack leadership about the benefits and challenges of having done this.

[mcollina]

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]

until we have enough to distribute it fairly

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:

• for the project, it seems to me that would be a very fertile ground for all sort of drama.
• for me personally, as a contributor: today Node.js is a side-project I'm working on when I feel like it; if there's money involved, it's becoming a job.
• for me, as a TSC member: I'm not looking forward having to deal with any money-related dispute, and I don't see a way to make decisions without bumping into the major conflict of interest it would be. (I guess we could defer to a third party who are not contributing, but that seems even less likely to result into a "fair" distribution).

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.

[marco-ippolito]

I'm +1 on OpenCollective, I'm -1 on distributing the money for feature development.
I believe we should use it for Collab summit, critical security work, infrastructure etc...

[Trott]

I'm +1 on OpenCollective, I'm -1 on distributing the money for feature development. I believe we should use it for Collab summit, critical security work, infrastructure etc...

I would think the Collab summit, critical security work, infrastructure are the things the Foundation should be generously funding. But if there's not enough money there for these things, then doing something like this to supplement it might make sense.

[Qard]

I actually see a lot of benefit to it, if we do it right.

There needs to be a way to match companies which want to put money into development of specific core features with available and trusted developers to sponsor working on that development for some agreed upon budget.

It's very difficult for larger development projects to make progress in Node.js because no one has the financial backing to commit significant time to anything. For example:

• QUIC/HTTP3 has taken a very long time because @jasnell doesn't have the capacity to be putting all his focus into it
• ESM Loaders development has been fairly chaotic because it's a very large subsystem that has been assembled through many small additions with few having the full picture of how everything works to test it cohesively

With financial backing, larger projects like these could make quicker progress and have more thorough testing. As it is presently, we have many complex systems built from small changes atop other small changes and it results in a bit of chaos. It's perfectly fine that the majority of contributions are small, but I feel we're doing a poor job of keeping our core systems well-formed.

[jasnell]

Financial backing really wouldn't have helped with me something like quic since that's not the limiting factor... that is I'm good on money, short on time ... and more money doesn't help with the time issue.

[Qard]

Doesn't help you, but someone else could have picked up the task, if they had the money to cover their time.

[gireeshpunathil]

i think we need to separate the two things from each other:

1. will fund help address project backlog?
2. and can fund be distributed fairly?

on 1: IMO, there are areas where attention would help. Just like security, diagnostics, performance, quality, infra and release are equally important for a major platform like ours that aspire to sustain for long term. If that attention do not come naturally through voluntary engagements, and if there are sources that can fund us, a YES answer comes naturally for me.

on 2: agree with views of many others: TSC may not be able to take a good, fair judgement on this matter, how about we request / delegate that to the foundation, and retain the rights on evaluating which area(s) are high priority for the project at a given point in time?

[Trott]

There needs to be a way to match companies which want to put money into development of specific core features with available and trusted developers to sponsor working on that development for some agreed upon budget.

This is a laudable goal. I see several issues that we might be tempted to underestimate the difficulty of addressing. (That doesn't mean this isn't worth trying to do, though.)

• Finding "companies which want to put money into development of specific core features"
• Developing an "agreed upon budget"
• Dealing with the eventuality that someone does a bunch of work but doesn't complete it or there's disagreement between parties as to whether things have been completed or not
• Finding a way to parcel out work and money that is sufficiently fair to satisfy all the parties in Node.js that need to be satisfied

A simplifying approach (for Node.js, but maybe not for everyone else involved) might be for Node.js to help identify "trusted developers" but to expect the companies and developers to work things out independently, rather than having the money flow through Node.js.

[aduh95]

Financial backing really wouldn't have helped with me something like quic since that's not the limiting factor... that is I'm good on money, short on time ... and more money doesn't help with the time issue.

IIRC there was also a lack of reviews which made progress harder. If we start paying for reviews, we might get more of them, but probably not of better quality.

[Qard]

• Finding "companies which want to put money into development of specific core features"

I don't think we need to do much more than just having some official space for companies to come to us about it. If we don't get a ton of companies coming forward to put up dollars for development work then that's just what we've got to work with. 🤷🏻

• Developing an "agreed upon budget"

I don't think we should be involved in that. I see it solely as a match-making process for companies to find vetted devs to work on Node.js core things and for us to provide a yay/nay ahead of feature work just to make clear if there's any chance of such a thing landing were it built.

• Dealing with the eventuality that someone does a bunch of work but doesn't complete it or there's disagreement between parties as to whether things have been completed or not

I also don't think we should be too much involved in this. Just do match-making but make it clear that the agreement is between those two entities and we claim no liability for any issues which could arise. Those parties need to figure out the contracts on their own.

• Finding a way to parcel out work and money that is sufficiently fair to satisfy all the parties in Node.js that need to be satisfied

I don't think what is "fair" really comes into it if we treat it purely as: some company is putting up dollars for X, let's forward them a person to do X. If other work is not getting dollars then it's just a lack of companies stepping up to fund that, which we don't really have control over. We can encourage companies that they should consider funding certain things or express that certain areas could use more work, but it's ultimately up to those putting up the money to dictate where it goes.

[mhdawson]

I'll be interested to see how the discussion goes in the Next-10 deep dive -nodejs/next-10#273, but my initial thoughts line up with some of what people are expressing so far in this issue:

1. It may difficult to manage small "bounty" type payouts both from the management and fairness aspect
2. Collecting $ that could be directed to specific larger initiatives should be easier to manage. Most likley for activities activities where it's often hard to get volunteers.
3. Collecting $ for extras like supporting collaborator events, etc. may also be easier to manage.
4. It still seems valuable to help connect companies who want work done with collaborators who could do that work, but the project should enable connections, not manage the flow of $ in that case.

[jasnell]

If we were to do anything here, my preference would be to have the initiative managed entirely by the foundation and not the project. The foundation has infrastructure in place for accounting and legal considerations that the project itself is not well suited for. Any funds collected should go to support of the project infrastructure (CI, hosting costs, travel reimbursement budget, etc) and never for feature development or code bounties.

[voxpelli]

My thoughts on this subject is that Node.js should mimic these rather than launching an Open Collective / GitHub Sponsors:

• https://fund.godotengine.org/ (their motivation for it is here: https://godotengine.org/article/godot-developer-fund/)
• https://fund.blender.org/ (corporate sponsorship ranging from bronze, €6k/year to platinum, €240k/year: https://fund.blender.org/corporate-memberships/)
• https://ziglang.org/zsf/

Node.js is an infrastructure / platform level project and an enabler of so many other projects, similar to what Godot is for games and Blender is for everything 3d modelling.

Another prior art is Ruby Central / Ruby Together (https://rubycentral.org/news/ruby-together-and-ruby-central--coming-together/)

If the OpenJS Foundation itself can not be the fascilitator of this money, then a standalone Nodejs Development Fund should be launched as a separate foundation (similar to Ruby Central) that finances the development separately from the technical leadership of the project.

The goal of the Nodejs Development Fund should be to, like the other mentioned here, to hire full time (or close to full time) developers that dedicates their time to Nodejs development

[mhdawson]

Seems like discussion in progressing in the issue, and TSC is aware so removing agenda tag until there is a more specific proposal to discuss.

[ovflowd]

I wanted to weigh in my opinions and 2cents on this matter:

IMO, we should definitely have OpenCollective, but I'm against GitHub sponsors. OpenCollective has tons of transparency and is easy to understand how funds are distributed.
I believe that funds should be used for infrastructure/CI; that's a given. The better the DX for our collaborators, the more physical resources we have.

• We should not disburse based on day-to-day development; this is useful for smaller projects requiring collaborators or collaborations, like eslint, Jest, or webpack.
  We have many collaborators who help with day-to-day development, so this would be a poor use of our resources/funding, easily prone to issues, and hard to maintain by the TSC for such a vast number of collaborators.
• I do believe we should also allow the funds to be used for critical feature development, critical security, and performance work, and any long-term technical proposals that are initiated by WGs or nodejs/node
  • For example, the restructure of tests proposal by @jasnell, the API doc tooling rework, which is a massive amount of work, or implementation of a new complex EcmaScript specification API... These long-term and large initiatives could have funding for their champions.
• I don't believe we should use these funds for the Collaborator Summit or travel in general. The Foundation is there for that and already has many processes for funding travel, summits, networking, and collaboration.

[ovflowd]

I come here from the perspective of a cry for help because I believe we urgently need extra resources. We are getting in a pretty dire situation and need funding, so it is my interpretation of the facts.

cc @nodejs/tsc as I want to urge the people who gave -1 to reconsider and weigh in on my considerations.

This is also how we did on webpack: https://github.com/webpack/webpack-governance/blob/main/OPEN_COLLECTIVE.md

[voxpelli]

IMO, we should definitely have Open Collective, but I'm against GitHub Sponsors. Open Collective has tons of transparency and is easy to understand how funds are distributed.

Fiscal hosting and funding channels are two separate things – one can have fiscal hosting through Open Collective while still receiving money from eg. GitHub Sponsors.

---

Somewhat related is a discussion around which fiscal host one should use on Open Collective if one uses Open Collective.

While most open source projects use the Open Source Collective there are also other available options (eg. Open Collective Europe) and a discussion on whether OpenJSF itself could/would/should act or facilitate fiscal hosting to some degree (openjs-foundation/sustainability-collab-space#8) and what the upsides or downsides of that would be.

GitHub Sponsors is purely a funding channel and provides no fiscal hosting whatsoever – but do support paying out to a fiscal host.

[ovflowd]

Fiscal hosting and funding channels are two separate things – one can have fiscal hosting through Open Collective while still receiving money from eg. GitHub Sponsors.

Ah, yes, that's what I meant. They can still donate through GH Sponsors, but GH Sponsors should not be used for means of disbursion.

[ovflowd]

there are also other available options (eg. Open Collective Europe)

Wasn't OpenCollective Europe shutting down?

[ovflowd]

and a discussion on whether OpenJSF itself could/would/should act or facilitate fiscal hosting to some degree (openjs-foundation/sustainability-collab-space#8) and what the upsides or downsides or that should be.

Is this discussion on the OpenJS side happening for all projects as a means of a new service on the catalog that the foundation offers for their projects? I wasn't aware of such conversations happening, et all, but I haven't attended the Sustainability Collab space yet.

[voxpelli]

Is this discussion on the OpenJS side happening for all projects as a means of a new service on the catalog that the foundation offers for their projects?

That would be the case then, yes. The collab space had its first meeting yesterday so very very new all of it.

Wasn't OpenCollective Europe shutting down?

It was the Open Collective Foundation, see this response from the OCE

[mhdawson]

There is a session planned on funding for the collaborator summit in Dublin. I'll make sure to pull all discussion from this thread into the prep for that as well as any agreement that has been reached in advance.

[mcollina]

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]

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).

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]

No disbursement. We'll keep the funds for selected initiative, as an example security.

[ovflowd]

No disbursement. We'll keep the funds for selected initiative, as an example security.

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]

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]

I think it’s important the decision does not fall on the TSC

The decision will ulimely fall either on the TSC or on the Executive Director of the Foundation.

[voxpelli]

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).

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]

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?

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]

@voxpelli can you expand a bit on as some other projects have collected subtantial enough sums that are substantive.

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]

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