NodeJS Feature Bounty Program

[thescientist13]

Inspired by this exchange I had with @mcollina online and prompted to post here from nodejs/next-10#335 (comment), I am presenting the idea of a feature request / bounty board / forum by which NodeJS users like myself, could sponsor feature / bug development for NodeJS.

Haven't really thought about many of the details around vetting / curating / moderation or whatnot so apologies, but I really love open source and NodeJS, and absolutely value its foundation based governance / "business" model and where and when I have the ability to support it directly, monetarily, I would love to have the opportunity to do so. 💚

Let me know your thoughts! ✌

---

For example, I am very open to sponsoring this feature

[RaisinTen]

Thanks for opening the issue.

I really like the idea of having a page where you can contact all the contractors you can hire.

@nodejs/tsc any thoughts?

[aduh95]

How would it be different from the Sponsor me Support me links in the README?

[RaisinTen]

It should also contain info on the areas of interest and expertise of the contractors, so that it is convenient to identify who to reach out to for the work.

[RaisinTen]

I also feel that the Support me links on the readme aren't super visible to potential sponsors. The page should be in a much more accessible place - perhaps a link on the main https://nodejs.org landing page.

[thescientist13]

@aduh95 / @RaisinTen
Can either of you share with me the section / link in question? I presume you are referring to the NodeJS README? If so, a search on that page finds no reference to the word sponsor for me?

@JakobJingleheimer
Regarding our discussion on this topic, looks like look anyone can send one-off donations through GitHub to the NodeJS project directly through GitHub Sponsors. So in your / our case re: nodejs/node#49445, I could go with that route.

---

So unless I am missing something something in the docs, maybe at least for now the NodeJS website / README could make (direct) sponsoring opportunities more visible / discoverable at present, in parallel to this idea of a bounty program for targeted feature development, since that isn't covered by GitHub Sponsors?

[RaisinTen]

Some of the collaborators list entries in the readme - https://github.com/nodejs/node?tab=readme-ov-file#collaborators have Support me (not Sponsor me) links which you can use.

---

If you sponsor https://github.com/sponsors/nodejs, the money would be used for these activities https://github.com/nodejs/TSC/blob/main/Nodejs-Funding-Sources.md, so it would not fund the development of the feature request nodejs/node#49445 you're interested in sponsoring.

[JakobJingleheimer]

I think for the time-being we can have a gentleman's agreement. I'm not looking to get paid out by the foundation or something; it going into the general nodejs pot is what I want.

---

@thescientist13 sure! That route works 🙂 thank you

[omarsoufiane]

Hello guys,
I'm sorry for this cold intro, but I'm the founder of bountyhub, which is a platform specifically designed to empower open-source communities by offering rewards to contributors. and it supports crowdfunding bounties on specific issues. Can someone refer me to the right person to discuss a potential partnership with the Node.js community for a bounty program?

[RaisinTen]

Bountyhub sounds similar to another such platform I have seen being used in some other open source projects - Algora.

I'm -1 about supporting either crowdfunding platforms. Here are some of the fundamental problems:

• there is a middleman taking a cut
• public nature of the bounties are exploitative
• hard to pick a platform because neither really stand out as superior
• potential beneficiary starts working with 0 funding and only gets paid after working
• can totally imagine folks gaming the system and making AI generated PRs for some $s

The classic way of directly contacting a contractor and working something out with them seems much more flexible.

[omarsoufiane]

@RaisinTen Thanks for the thoughtful feedback. You raised some very valid concerns.

Firstly, while bounties can sound exploitative, especially outside the realm of open source, it's important to remember that contributing to open source is typically driven by goodwill and a desire to give back to the community. Offering a reward is primarily intended to incentivize those specific development efforts. A bounty hunter should keep in mind that his work might not be rewarded if a pull request does not meet certain criteria, in the same way that a contributor should keep in mind that his pull request might not be accepted.
A platform like BountyHub is meant to be an alternative to GitHub sponsoring, rather than a contracting platform like Upwork. The problem with GitHub sponsoring is that only the core team of a project gets the funding, rather than the contributor who solves a particular issue.

Regarding fees and taking cuts, almost all financial platforms are subject to transaction fees. We use Stripe, and Stripe transactions can go up to 5%. For our cut, a big part of that goes into fraud prevention, managing disputes, and supporting the infrastructure. As you can see in GitHub docs:
https://docs.github.com/en/billing/managing-billing-for-your-products/managing-billing-for-github-sponsors/about-billing-for-github-sponsors
Github Sponsors is also a middleman taking a cut.

I mentioned a partnership with the Node.js community in my previous comment, it's because I would like to offer our services for free for Node.js repositories (only transaction fees would apply), and I'm not afraid to say it publicly. Because Node.js is the platform I've been using to build apps for more than a decade, it's the platform upon which BountyHub is built, and it's what makes me earn money in my daily job.

Regarding Algora vs BountyHub, we have similarities and differences; they are older than us and have a larger community, but Algora is not mainly a crowdfunding platform but mostly a platform that serves as an alternative to traditional hiring. Most of their bounties are created by organizations that owns open source projects and hire people to work on their issues, so they are closer to Upwork than they are to GitHub sponsor. BountyHub, on the other hand, is mainly about crowdfunding because it allows multiple people to pledge to the same bounty, and most of our bounty creators are not repository owners but individuals having issues in open source projects.

[JakobJingleheimer]

Collaborators get fringe benefits, some of which are quasi-financial (conference visits, etc). This would help us contribute to the communal pot (so Robin has to do only 99% of it) doing basically what we're already doing.

If a collaborator is going to get a direct payout, I think that's out of scope, and they should make their own arrangement for that.

If the bounty-earner is not a collaborator, it's still possible for them to reap benefits (and we would probably notice a contribution significant enough to earn a bounty, whereby the contribution itself may well support collaborator-ship).

Regarding platforms, maybe we hear out someone who's taken the effort to find this thread before deciding it's a scheme.

• potential beneficiary starts working with 0 funding and only gets paid after working

That's what escrow is for, and why you'd use a platform 🙂

• can totally imagine folks gaming the system and making AI generated PRs for some $s

If it's spam, we ban them. I don't foresee this. But if it becomes a problem, we can course-correct.

---

@RaisinTen at the Paris summit, you recently solicited sponsorship for you to contribute to a feature. Could you outline how you envisioned that working? That could perhaps inform how it may work generally.

[younessmakhfi2]

This sounds like a good idea, I would also like to sponsor some issues if there is an official program by nodejs

[jasnell]

Overall I'm still quite -1 against the basic idea here. I think this is something the tsc needs to very carefully consider before we even get to the point of identifying possible implementation.

[JakobJingleheimer]

I think this is something the tsc needs to very carefully consider

+1 we should for sure have governance on it

[aduh95]

This thread is repeating many arguments from #1553, maybe worth a reading if you want to dig deeper.

If we imagine a system where folks could give money for a specific issue, and the project cannot use the money until the issue is "fixed", it gives pretty bad incentives to the project: to be less regarding on quality of the PR implementing it, probably silencing folks who raise concerns. Whoever decide what "fixed" means, it would them quite a lot of power over the project.

Also worth considering that users would probably give money for user facing features, while us maintainers would probably want to prioritize some other issues (CI reliability, tooling, etc.) where we're already accumulating tech-debt. Maybe there's a balance to be found, in any case let's make sure we don't worsen an already less-than-ideal situation.

[RaisinTen]

BountyHub is meant to be an alternative to GitHub sponsoring

@omarsoufiane replacing GitHub Sponsors with BountyHub would need to be discussed in a separate issue.

---

Could you outline how you envisioned that working?

@JakobJingleheimer if we make the list of interested collaborators more visible, an entity can reach out to them directly. After that, it's up to the parties involved to decide how to proceed, what platform to use, how to negotiate, etc.

---

Problem statement

An entity wants to fund some Node.js work. There are some Node.js collaborators who are interested in doing that work. What can we do to create a self-serve way for the entity to get in touch with these collaborators?

My proposal

Maintain a list of contacts of interested collaborators and their areas of interest and expertise. Put it in a visible place, like a link on the main https://nodejs.org landing page ... that's it.

Here is my summary of the problems I could find in #1553:

1. conflict of interest of someone managing funds
2. fairness of budget allocation
3. money-related dispute
4. disagreement between parties on completion of work
5. disbursing central funds for day-to-day development
6. finding entities who will pay

For 1 - 4 - In my model, there is no middleman, so the project bears no responsibility for resolving conflicts or managing funds. It is the responsibility of the paying entities and the collaborators.

For 5 - There is no connection to central funds like Node.js' GitHub Sponsors / OpenCollective / OpenJSF's bank account, so that's not applicable.

For 6 - The project does not have to find these entities. If they come, great and if not, status quo remains.

I like @Qard's match-making idea from #1553. My proposal is a simplified, lower-responsibility version of that. A self-serve match-making model.

[Qard]

Yep, a system of match-making skills to desired work would be nice. Possibly idealistic, but the pooling of crowdfunding too would be really nice to apply somehow.

In my personal case, I have had several APM vendors ask me to do contract work here and there on async_hooks, AsyncLocalStorage, and diagnostics_channel. If I had a mechanism that I could pool funds and manage relationships with those several vendors I could probably have fulltime work just maintaining those Node.js core features. I can think of a few other people that could probably say the same of the subsystems they work on. A fulltime salary investment is more than many of these companies want to invest individually, but with pooled investment it becomes a lot more doable.

[PaulaPaul]

Since the Foundation has received funding from grants (like Alpha Omega) to provide specific enhancements to projects, and that money goes to companies and individuals who do the work, it seems like there should be a way to do this without risking non-profit status. I thought this concept of 'donor bounties' was interesting: https://ziglang.org/news/announcing-donor-bounties/ (they accepted the first donor bounty for a specific feature in January '24)

[omarsoufiane]

@RaisinTen, what I mean by "alternative" is not replacing GitHub sponsor, but providing another option to the donating entity.
And sure, I can create another issue where I make a proposal on how BountyHub can help NodeJs have a bounty program while keeping governance on it, and we can discuss how to address the concerns you raised.

[RaisinTen]

This got discussed in the last TSC meeting, so I'll remove it from the TSC agenda. You can watch the recording here https://www.youtube.com/live/Q9AvtxFOWQQ?si=nLnvvQjZr9NtJY4Y&t=503.

The next step is to create a concrete proposal in a separate issue, building on my original proposal. I'll do that when I get some time.