DEV Community

Cover image for React's real problem is corporate capture, not technical debt
Aditya Agarwal
Aditya Agarwal

Posted on

React's real problem is corporate capture, not technical debt

Vercel not only took React in but took in the team that creates it. They hired the team that builds it, and now the library you depend on has a landlord. 🔑

You should be more concerned about that than you are.

The Quiet Acquisition

Vercel hired important React core team contributors, including Andrew Clark, Sebastian Markbåge, and other significant members who have a major influence on the future direction of React.

There was no acquisition news. There was no antitrust review. One company simply hired the brains behind the most popular UI library on the planet, and we all just… kept coding.

React Server Components: Feature or Funnel?

When React Server Components were introduced, they were presented as the new revolutionary technology. The promise was attractive - reduced client-side JavaScript, improved performance, and an intelligent rendering approach.

Well, the reality is that the most mature RSC implementation ready for production is in Next.js, although different frameworks have started to pop up that offer different levels of support. And, Next.js performs best on Vercel.

→ React introduces a major new -shifting feature
→ That feature is deeply integrated with one framework
→ That framework is built by the company that employs the React team
→ That company sells hosting optimized for that framework

There is no need for a conspiracy theory. Just track the money flow.

"Open Source" With an Asterisk

React still uses the MIT license. No one disputes that. Open source, however, isn't just the license, it's also about governance.

When one company controls the core team's paychecks, the roadmap stops being neutral. Features that benefit Vercel's infrastructure get prioritized. Features that don't? They wait. 😕

Isn't it interesting? The React documentation suggests Next.js as one of the primary frameworks to use for new projects, among others. Not Create React App, Not Vite, but the framework that happens to be developed by the same company that employs the React team.

That's not a suggestion. That's a sales funnel disguised as documentation.

Why This Matters Beyond React

I've seen this pattern before. A beloved open-source tool gets captured by a single vendor, and the community slowly loses its voice.

The danger isn't that React becomes bad software. It probably won't. The danger is that React's evolution starts optimizing for one company's revenue instead of the broader community's needs.

Developers working with React and tools like Remix, Astro, or plain Vite are likely noticing the shift mentioned above. While RSC support (React Server Components) anywhere outside Next.js varies from experimental to increasingly stable, Vite's official RSC plugin is feature-complete for core functionality. The “unopinionated library” is certainly becoming opinionated. And isn’t it a coincidence the opinions match those of one specific company’s product catalog?

What Would Healthy Governance Look Like?

There have been suggestions about a React foundation, like Node.js joining the OpenJS Foundation after its governance crisis.

→ An independent foundation with multiple corporate sponsors
→ A public roadmap shaped by community RFC, not one company's sprint planning
→ Core team members funded by a pool of stakeholders, not a single employer

This isn't radical. It's how mature open-source projects survive corporate pressure. Linux, Kubernetes, and Node.js all went through versions of this.

React has not. And nobody with the power to change that has any incentive to do so. 🤷

The Bottom Line

The main issue with React isn't class components or problematic useEffect, or even bundle sizes. It's the fact that the developers creating the library are employed by the organization that also provides you with hosting services.

You can still love React and acknowledge this is a problem. I do. But pretending the current arrangement is fine because the code is technically open source is naive. The way it is managed is just as important as the permission to use it.

So here's my question: at what point does corporate capture of an open-source project become a dealbreaker for you — or does it ever?

Top comments (0)