React and the lesson of supporting someone for 10 years

A dev posted on Hacker News that they have been paying for the education of someone in rural Tanzania for 10 years. It wasn't a one-time donation or a viral campaign. It was a monthly payment, for a decade. I read the Tell HN and thought about something that seems totally unrelated: the node_modules of my last React project.

Bear with me, I'll explain. This isn't a self-help post. It's about how we consume other people's work without thinking about the long run.

What the Tell HN is actually about

The idea is simple. One person decided to pay for the studies of someone who couldn't afford them. They kept it up for 10 years. In the comments, the discussion went where it always goes on HN: whether it's better to help someone directly or donate to an institution, how to measure impact, the risk of creating dependency, whether the power dynamic gets weird.

I won't get into that debate. If you're a dev reading it, you tend to notice something else: what counts is the duration, not the amount. One big donation doesn't pay for ten years of school. What pays for it is a small, boring, steady commitment.

And that's where React comes in.

Why this has to do with React

Your React app depends on hundreds of packages. Go ahead and run:

npm ls --all | wc -l

On a freshly created Next.js project, that number easily goes past a few hundred lines. On a real app, with forms, data fetching, i18n, tests and lint, it reaches thousands.

React itself has Meta behind it. The rest doesn't. The form lib, the date parser, the Babel plugin someone wrote in 2017, the polyfill you don't even know exists. A lot of that is maintained by one or two people, in their spare time.

We've already seen what happens when that commitment breaks:

• left-pad (2016): a dev pulled 11 lines from npm and half the internet stopped building, including projects with React and Babel.
• colors.js and faker.js (2022): the maintainer, tired of working for free for big companies, sabotaged their own packages.
• core-js: the author spent years saying publicly that the project, used by a huge slice of the web, barely paid their bills.

None of these cases came from a lack of good code. They came from a lack of someone holding the other end long enough.

Software doesn't die from bugs. It dies when the last person who cared gets tired.

What changes in your workflow

I'm not going to ask you to sponsor everyone. You can't, and it wouldn't fix anything. But you can swap "infinite consumption" mode for something more grown-up. In practice, I do three things.

1. Find out who you're carrying on your back.

npx npm-fund
# or simply
npm fund

npm fund lists the packages in your project that have a funding link (GitHub Sponsors, Open Collective). The first time I ran it on a client's React project, dozens of names showed up. Many I had never heard of. All of them were in production.

2. Pick a few and stick with them for a long time.

That's exactly the lesson of the Tell HN. Better 5 dollars a month to one maintainer for years than 100 dollars once in a moment of guilt. Maintainers plan their lives around predictable income, just like us. A small recurring sponsorship is worth more than an isolated spike.

If you work at a company, it's a different conversation. Take the npm fund list, filter the critical libs (the ones that would block your deploy if they vanished) and bring it to your manager. A fixed monthly amount for three or four projects costs less than one hour of an incident.

3. Pay with time when you can't pay with money.

Contributing isn't just feature PRs. Answering a repeated issue, improving an example in the docs, reproducing a bug with a minimal CodeSandbox. For someone maintaining a React lib with 2,000 open issues, a well-reproduced bug is gold.

"But I don't get paid in dollars"

That objection is fair and I hear it all the time. Most devs in Brazil get paid in reais, and 5 dollars a month hurts more here than in San Francisco.

Three honest answers:

• You don't need to start with money. Time and care count, like I said above.
• If you're a freelancer or run a company, add a line to the project budget. A small percentage for the critical dependencies. The client won't even notice, and their project gets safer.
• Sponsoring Brazilian maintainers counts too. There are a lot of good people here maintaining tools used in the React ecosystem.

And there's a selfish side I'm not ashamed to admit: a funded lib is a lib that won't leave you stranded in the middle of a migration to React 19.

What I really think

My strong opinion: the JavaScript ecosystem built a culture of treating dependencies like a natural resource. Like water from the tap. You install it, use it, forget it. When it breaks, you open an angry issue demanding things from a stranger who never charged you a cent.

The Tell HN bothered me in a good way because it shows the opposite. One person looked at a long problem and accepted that the solution would also be long. No photos, no announcements, no hype. Ten years of consistency.

We love talking about architecture that scales. Few people talk about commitment that scales over time. And time is exactly the variable that takes down the most open source projects. Version 1.0 ships with excitement. Version 4.2.7, which fixes an edge case in Safari, ships with stubbornness.

Part of the unintentional comedy here: we spend an afternoon choosing between Zustand and Jotai, compare bundle sizes in kilobytes, read benchmarks from three blogs. And we never spend a single minute checking whether the chosen lib has someone who will still be around two years from now. That should be the first criterion.

A short checklist before installing your next lib

Before running npm install on something headed to production, I check:

• How many active maintainers the repo has (Contributors tab, last 12 months).
• Whether issues get replies, even if it's a "won't do".
• Whether there's any funding, even a small amount.
• Whether the lib depends on ten other libs from a single person.

It's not science. It's just not being naive.

Wrapping up

I'm not saying sponsoring a React lib is the same as paying for someone's school. They carry very different weights, and comparing them would be disrespectful to the story in the post. What they have in common is simpler: things that matter need someone willing to show up every month, even when nobody is watching.

Pick a project. Just one. Support it for a year and see what changes. If you want to see what I've been building with these same libs, take a look at my projects.

A dev has been paying for someone's school in Tanzania for 10 years. Every month, no photos, no announcements.

I read this on Hacker News and thought about the node_modules of my last React project.

Hundreds of packages in production, many maintained by one or two people in their spare time. left-pad, colors.js and core-js showed what happens when that end comes loose.

Software doesn't die from bugs. It dies when the last person who cared gets tired.

The lesson I took from it: consistency matters more than amount. 5 dollars a month for years helps more than 100 in a moment of guilt.

Run npm fund on your project, pick one lib and support it for a year. I wrote more about this on the blog, link in the comments.

#OpenSource #React #JavaScript #SoftwareDevelopment #Community