[adoxyz]

Can you give examples of times NextJS was changed to solely benefit Vercel?

NextJS is an open-source framework under the MIT license, so if Vercel ever did anything to compromise NextJS, it could just be forked, but to my knowledge and experience with NextJS, they've provided and continue to provide an awesome framework/ecosystem around React.

[therusskiy]

Try deploying NextJS yourself over multiple instances, you are soon going to learn that cache NextJS provides isn't shared across them via something like Redis (I think it's mostly shared on Vercel, but I don't know how they do it).

Aside performance, this has consequences because of their stale-while-revalidate technique for static pages in incremental regeneration. If cache becomes obsolete on 1 instance and it's revalidate on the next request, it's not revalidated on other instances, so users accessing them are going to see stale data until that instance itself does revalidation. Having even a percentage of pages showing stale data can be painful for certain scenarios.

NextJS users been asking for more flexiable caching for some time.

I think it's a pretty good example.

As for forking it, how many companies have enough resources and are willing to go that distance?

[adoxyz]

Caching is a universally difficult problem to solve, but point taken. The majority of my NextJS sites have been deployed to Vercel, but a few have also been hosted on AWS and DigitalOcean. When it comes to incremental regeneration, I didn't use it if the page needed to be 100% up to date for every user, even when on Vercel.

As for the forking it comment, that's exactly the point. Vercel is investing heavily into NextJS, spending millions of dollars on hiring full time developers to work solely on it, and they give NextJS away for free. So having the best Next experience on the platform that they own and control and can fine tune makes sense to me. Nobody is forcing you to use NextJS or any other library.