TSC icon indicating copy to clipboard operation
TSC copied to clipboard

Self-serve model for funding Node.js work

Open RaisinTen opened this issue 6 months ago • 29 comments

@nodejs/tsc I'm sharing this concrete proposal to further address any concerns regarding https://github.com/nodejs/TSC/issues/1723#issuecomment-2827713134 before moving forward with implementation.

Problem statement

Companies and individuals want to fund Node.js work. Some Node.js maintainers are open to receiving funding for their contributions. How can we provide a self-serve way for funders to connect with those maintainers?

My proposal

Host a directory of maintainers and their areas of interest and expertise in an easily discoverable place on the Node.js website.

Add a new "Funding" item to the headers list in https://nodejs.org. It would be a link to a new page with contents:

Funding Node.js

This page outlines how you can fund the project and its maintainers.

1. Directed funding for OpenJS Foundation Member

Organizations can become OpenJS Foundation Members and use directed funding to support the project. To learn more about Project Directed Funding, visit https://openjsf.org/projects.

2. Donate via GitHub or Open Collective

The project accepts funding via:

Funds are to be used for specific efforts as decided by the Node.js Technical Steering Committee, including:

  • Security lead
  • CI stability improvements
  • Project health and collaboration

For more details, see Node.js Funding Sources.

3. Fund individual contributors

The following directory lists maintainers who are open to receiving funding:

(Link to a file in https://github.com/nodejs/admin which would contain this directory)

Name Contact Areas of interest and expertise
Jane Doe [email protected] Modules, Website
John Doe [email protected] HTTP, Async hooks

Companies and individuals may connect directly with maintainers. The Node.js project does not oversee these engagements and is not responsible for any disputes or outcomes.

RaisinTen avatar Jun 05 '25 14:06 RaisinTen

FYI @nodejs/nodejs-website

avivkeller avatar Jun 05 '25 19:06 avivkeller

As a nonprofit organization, I don't think this is viable as is with our current policies and programs and it needs a few tweaks:

  1. Being an OpenJS Foundation member and use directed funding to support the project https://github.com/openjs-foundation/cross-project-council/blob/main/project-resources/project-directed-funding-policy.md
  2. Donate (not sponsor) via GitHub or OpenCollective
  3. Fund individual contributors, without listing anyone but pointing to https://github.com/nodejs/node/blob/main/README.md#collaborators, which already has the "support me" link there. We should not mention that they are availble for sponsored work.

Note that the board has not forgotten about this and we will be implementing a partner program for companies to be listed as implementation partners.

mcollina avatar Jun 05 '25 20:06 mcollina

I've updated it to address points 1 and 2.

Regarding point 3, not listing anyone but pointing to the collaborators list has some limitations that might make it less effective for funders and maintainers:

  • It lacks info about areas of interest and expertise of maintainers, which is important for funders who want to support contributions in specific areas.
  • It doesn't include maintainers outside the collaborators list, such as those working on the website, which is a critical part of the project.
  • Not everyone listed there is open to receiving funding or being contacted for this.
  • From a reader's perspective, browsing a section of the GitHub README markdown file feels less accessible and discoverable than seeing this presented on the Node.js website.

That's why I thought a separate, opt-in directory, limited to those open to receiving funding and including info about their areas of interest and expertise, on the Node.js website makes more sense. Any thoughts?

RaisinTen avatar Jun 06 '25 08:06 RaisinTen

This was discussed in the TSC meeting and we agreed to include the list in the Admin repository.

mcollina avatar Jun 11 '25 10:06 mcollina

I have opened a PR to create the list in the admin repo https://github.com/nodejs/admin/pull/981

RaisinTen avatar Jul 07 '25 14:07 RaisinTen

We already allow individual contributors to display a "Sponsor Me" link by their name in the nodejs/node readme. How would this be any different / better? I'm -1 on adding something beyond that.

jasnell avatar Jul 07 '25 14:07 jasnell

@jasnell the status quo has these limitations:

  • The collaborators list is not easily discoverable.
  • It lacks info about areas of interest and expertise of maintainers, which is important for funders who want to support contributions in specific areas.
  • It doesn't include maintainers outside the collaborators list, such as those working on the website, which is a critical part of the project.
  • Not everyone in the collaborators list is open to receiving funding or being contacted for this, so pointing to that list from the funding page doesn't make sense.

Having an easily accessible Funding page on the Node.js website and adding a link to this separate opt-in directory, with those who are open to receiving funding and including info about their areas of interest and expertise would overcome these limitations. That's why I felt it would be better.

RaisinTen avatar Jul 08 '25 06:07 RaisinTen

I don't find any of these "limitations" convincing and I'm still -1.

The collaborators list is not easily discoverable.

I'm not sure how the nodejs/node readme counts as not being easily discoverable? https://github.com/nodejs/node#collaborators ... If anything, some markdown file in the more obscure nodejs/admin is even less discoverable.

For comparison, the nodejs/admin repo receives around 456 unique visitors, while the nodejs/node repo receives around 52,242 unique visitors. It's far more likely that folks will see the nodejs/node readme than it is this other file in the admin repo.

It lacks info about areas of interest and expertise of maintainers, which is important for funders who want to support contributions in specific areas.

That can be easily listed on the target of the "Sponsor Me" link ... for instance, here is @aduh95's https://github.com/sponsors/aduh95 ... this seems far better and far more expressive, not to mention being expressly designed for this purpose:

Image

It doesn't include maintainers outside the collaborators list, such as those working on the website, which is a critical part of the project.

This is a more general problem that is not specific to sponsoring, and this proposal does not improve the visibility for those other kinds of maintainers.

Not everyone in the collaborators list is open to receiving funding or being contacted for this, so pointing to that list from the funding page doesn't make sense.

Which is why adding a "Sponsor Me" link is optional.

jasnell avatar Jul 08 '25 15:07 jasnell

@jasnell

The key here is to drive traffic from the Node.js website. This approach doesn't depend on the existing traffic to individual repos. Instead, a new Funding page will be added to the Node.js site, as outlined at the top, and it would provide a link to this directory. This makes it significantly easier for potential funders to discover the relevant information.

Including areas of interest and expertise in this directory has no downside. If someone wants to fund a specific type of work, they won't have to browse every profile manually. They can quickly narrow down their search to people who mention the relevant categories.

Why wouldn't this proposal improve visibility for those other kinds of maintainers?

RaisinTen avatar Jul 09 '25 06:07 RaisinTen

IMO displaying these people on website is good idea. But keeping them on readme.

Technical solution for that:

  • Having a json file that store information
  • Having a new command on node core utility to keep readme up to date
  • Adding a component on website that shallow json through GH raw

AugustinMauroy avatar Jul 13 '25 09:07 AugustinMauroy

The marketing team at the foundation is adamant about not making the list a part of the Node.js website. Check out the recording from the 34:45 mark: https://www.youtube.com/live/xqs7qlmnFsE?si=z4IyzE2AAj_SKmNr&t=2085

RaisinTen avatar Jul 14 '25 06:07 RaisinTen

The marketing team at the foundation is adamant about making the list a part of the Node.js website. Check out the recording from the 34:45 mark: https://www.youtube.com/live/xqs7qlmnFsE?si=z4IyzE2AAj_SKmNr&t=2085

@RaisinTen I'm trying to follow the conversation here but I was very confused by this last comment as listening to the record it sounds like @mcollina is stating the opposite, quoting from the video:

"I was chatting about this with the marketing team at the foundation and they were adamant that no such list was part of the Node.js website itself, if we host that list somewhere in our org, I think that would be different but they were adamant that the list was not part of the website."

Maybe there's some extra context I'm missing here?

ruyadorno avatar Jul 14 '25 16:07 ruyadorno

@RaisinTen you're aware there's already an issue open on https://github.com/nodejs/nodejs.org/issues/7909, right?

ovflowd avatar Jul 14 '25 16:07 ovflowd

I agree with @jasnell’s -1 on both adding extra markdown documents and the proposed format for showcasing funding. I don't believe this approach will be effective—targeted individual funding from organizations is unlikely to happen.

At the very least, this issue addresses the need to incentivize organizations to contribute to our OpenCollective or GitHub Sponsors.

From there, we could spin off a separate issue specifically focused on disbursing funds to collaborators working on key areas like security, releases, and other critical features. This could even evolve into something like the TSC voting on specific features/issues across the org, which—if completed—could be rewarded financially via OpenCollective. Think of it as a bounty program. I believe this approach would be far more valuable.

For reference, we already do something similar in webpack, and ESLint does as well. These projects have smaller contributor bases, which makes applying a bounty system more practical. In my opinion, simply contributing to a specific area of Node (even security or releases) shouldn’t automatically qualify someone for recurring funding. However, working on high-effort tasks like security bugs or release engineering could justify one-time bounties due to the significant time investment involved.

ovflowd avatar Jul 14 '25 16:07 ovflowd

Note that we do that on webpack (the disbursement thing), so does ESLint and other orgs; Given they have a much more smaller contributor base, hence the application of a bounty program.

ovflowd avatar Jul 14 '25 16:07 ovflowd

Here's a proposal on a possible path forward:

We've had a handful of Collaborators add their Support me links to the readme. We really haven't investigated yet on whether that's been effective at all. @aduh95, @anonrig, @marco-ippolito, @mcollina, @panva, @RafaelGSS, @RaisinTen ... can any of you who have added the "Sponsor me" links indicate whether that has actually been effective for you? Have you been able to acquire new personal sponsorship following the addition of those links? Specifically, have those links actually been useful for you?

If they have been effective, then I'd say we maintain the status quo.

If not, let's definitely consider revisiting having those links on the readme. The biggest issue I have with the proposal here is that it really doesn't make sense to have multiple lists that need to be maintained in two separate places. So if we can move the "Sponsor Me" links off the Readme to a different page that we have reason to believe will be more effective, then let's do that -- still, of course, subject to the constraints that @mcollina outlined here.

jasnell avatar Jul 18 '25 17:07 jasnell

can any of you who have added the "Sponsor me" links indicate whether that has actually been effective for you?

@jasnell I didn't had any new sponsors at all during this time.

anonrig avatar Jul 18 '25 17:07 anonrig

@jasnell I had an expectation that the link would do nothing. It did nothing.

panva avatar Jul 18 '25 17:07 panva

No sponsors for me either :-(

marco-ippolito avatar Jul 18 '25 18:07 marco-ippolito

The status quo has not been effective for me either.

RaisinTen avatar Jul 19 '25 13:07 RaisinTen

My sponsors have essentially be stable as well, those links are not effective.

mcollina avatar Jul 19 '25 14:07 mcollina

those links are not effective.

That makes sense to me. Because, in my opinion, the readme file is not the place I would look to find sponsors. I think a dedicated page with a list of contributors/collaborators and what they have accomplished would be more impactful.

AugustinMauroy avatar Jul 19 '25 14:07 AugustinMauroy

those links are not effective.

That makes sense to me. Because, in my opinion, the readme file is not the place I would look to find sponsors. I think a dedicated page with a list of contributors/collaborators and what they have accomplished would be more impactful.

That's also ineffective.

ovflowd avatar Jul 19 '25 14:07 ovflowd

We can't be sure of that without giving it a try.

RaisinTen avatar Jul 19 '25 14:07 RaisinTen

We can't be sure of that without giving it a try.

I disagree, if we go with that sort of decision making process, we might as well just do random things without any direction in sight.

I don't think it's worth the time and resources, we should be seeking processes that have been proved to work, at least for this specific vector. Sure, bringing new ideas is important, but I doubt doing a manual list will help at all, or at least that's what my experience and gut feeling tells me.

I'd much rather improve the status quo of sponsoring node as a whole and getting us funded and having said funds disbursed to people that have been doing critical work.

ovflowd avatar Jul 19 '25 15:07 ovflowd

I think the key challenge here, regardless of which repo we might put the list is that potential sponsors aren't really likely to be digging through markdown files in a github repo to find individuals to sponsor. It's also going to be quite a burden to manually keep the list up to date and even ensure that all of our Collaborators who want sponsorship have equal visibility.

I would note that it is possible to use the Github graphql API to see if any particular github user has a sponsor profile. It should also be possible to use the API to query the list of all members of the organization. So I wonder if there's a different way we can approach this entirely... It would be interesting, I think, to build a new section of the nodejs.org website that is effectively a "Contributor Directory" that uses the Github API to generate an up-to-date directory of every member of the nodejs github organization with links to their github profiles and, if they have one, a link to their sponsor pages.

For this page:

  1. The order in which members are listed should vary / be random in order to avoid the case where the list always displays the same people at the top, etc
  2. On each view, the page can select individual members with sponsor profiles to highlight at random, like a ticker or carousel type display.
  3. The graphql query can also pull out details from the member's github profile so if they happen to list the projects and areas they are interested in, we can probably find a creative way to surface those. I'm sure AI may be able to help us here in some way.

The key idea is that the page itself is not really focused / limited to sponsorship, per se, but would serve as a directory of everyone in the project -- not just people with a commit bit in the main repo, but all members who have chosen to make their association with the project public.

It would likely take a bit of effort to create such a directory page but I think it would more than likely be far more visible and effective than a manually edited markdown file buried in some arbitrary location in some repo.

jasnell avatar Jul 19 '25 15:07 jasnell

That would really improve the visibility of the contributors.

Can you expand on point 3? What would the surfaced info be like in practice?

RaisinTen avatar Jul 20 '25 08:07 RaisinTen

... What would the surfaced info be like in practice?

I don't know yet. We'd need someone to dig in and investigate this idea further. We can surface details from each contributors public profiles tho... really anything we can access via the API.

jasnell avatar Jul 21 '25 15:07 jasnell

Github Sponsor information is readily available in the API for individuals; for projects, there's the funding field and FUNDING.yml, but it's probably overly complex to focus on "projects" here, since it's about collaborators.

ljharb avatar Jul 21 '25 15:07 ljharb