The Hosting Trap: Why Framework Companies Compete on the Wrong Layer

When Gatsby launched Gatsby Cloud in 2020, the pitch was straightforward: the team that built the build system should be best positioned to offer the fastest, most integrated build service. Two years earlier, the company had incorporated and raised $3.8M on the strength of a genuinely popular static site generator. By 2019, a $15M Series A followed, and the commercial story was clear: open-source adoption as funnel, Gatsby Cloud as the business.

The story of how that bet played out is one of the subjects of a recent talk that has been circulating on Lobsters, and the talk is worth watching for the specifics. The particular failure mode worth examining is not the one about VC and open source being misaligned in principle. That argument is well-made elsewhere. The more specific problem is competitive: Gatsby’s open-source framework created the market for Jamstack hosting, and every major hosting company entered that market without bearing the cost of creating it.

The Competitive Arithmetic

Netlify and Vercel were both early and enthusiastic supporters of Gatsby deployments. That support made complete sense from their perspective. Gatsby was one of the fastest-growing open-source projects in the JavaScript ecosystem, and developers who used Gatsby needed to deploy it somewhere. Offering smooth Gatsby integration was cheap; it required engineering support for the build process and some documentation. The cost was modest relative to the customer acquisition value.

The framework company’s situation was the inverse. Gatsby Inc. was paying the full cost of developing, maintaining, and supporting the framework while Netlify and Vercel captured deployment revenue from the community that framework built. By the time Gatsby Cloud launched, both incumbents had already established developer relationships with the same audience. Gatsby was entering a competitive hosting market with no structural advantage except the engineering team’s build expertise, against companies with larger capital bases and more mature infrastructure.

The Vercel comparison is the sharpest illustration of the problem. Vercel had been building Next.js as a deliberate piece of its platform strategy, with the coupling running in the right direction: deployment infrastructure first, framework as the funnel. Features in Next.js frequently required or benefited from Vercel’s edge network. Server components, edge middleware, and incremental static regeneration all had natural homes in Vercel’s platform before anyone else had equivalent infrastructure. The closed loop meant that Next.js adoption directly strengthened Vercel’s competitive position in a way that Gatsby adoption could not replicate for Gatsby Cloud.

Vercel has raised over $313M in total funding. Gatsby’s Series B in 2021 brought their total to roughly $65M. The capital disparity alone does not explain the outcome, but it clarifies why catching up on infrastructure investment was a difficult path.

The Same Problem, 2012 Version

Meteor Development Group ran an earlier version of this experiment. The company raised $31.2M in total, including $11.2M from Andreessen Horowitz in 2012 at a moment when full-stack JavaScript was still somewhat controversial. The DDP protocol that Meteor built for reactive client-server synchronization was technically sophisticated; the Livequery system for MongoDB change detection was ahead of what MongoDB itself natively offered at the time.

Galaxy, Meteor’s hosting product, launched in 2015 to provide managed deployment of the stateful applications Meteor enabled. The challenge was identical to Gatsby’s later problem: deploying a Meteor application to a standard VPS was not technically prohibitive, and the hosting market was increasingly crowded. Meteor’s platform revenue never grew to the scale required to justify the framework development investment, and the company was acquired by Tiny in 2019.

What Meteor had going for it that Gatsby did not was a tighter coupling between framework capabilities and hosting requirements. The reactive data synchronization in Meteor required persistent connections, which added genuine operational complexity that Galaxy could legitimately claim to manage better than a generic hosting environment. The technical lock-in was real, even if insufficient to generate the required revenue growth. Gatsby’s hosting advantage was primarily in build speed, which was valuable but easier for competitors to replicate.

What Open-Source Licensing Forecloses

The structural problem is that an open-source framework license, by design, gives competitors the right to support the framework without contributing to its development. Apache 2.0, MIT, and ISC licenses all permit this. The framework company cannot extract a toll from Netlify or Vercel for the customer acquisition value their framework provides; the license forecloses that option.

This is a trade-off inherent to the model, not a flaw in open-source licensing. A framework that required commercial licenses for deployment providers would have collected no adoption and no community. The choice is between building a broad community and building a defensible competitive position, and the licensing structure makes doing both simultaneously through the same project very difficult.

The dual-licensing model, as HashiCorp explored with Terraform before the OpenTofu community fork, attempts to thread this needle: a permissive license for individual use, combined with a commercial license requirement for entities building products or services on top of the software. The backlash from the Terraform community demonstrates the risk. The community views the license change as a betrayal, the most engaged contributors fork the project, and the goodwill that was the original asset is damaged in proportion to how aggressively the commercial terms are enforced.

The Projects That Survived

The open-source tools that maintained long-term health without a VC growth story tend to share a few properties. They have focused scope, limited extension surfaces, and maintainer structures that do not require external revenue to justify continued investment.

esbuild was developed largely by one person, Evan Wallace, and became one of the fastest JavaScript bundlers available. Its scope is deliberately constrained: it transforms and bundles; it does not manage configuration, plugin ecosystems, or hosting integrations. The project changed hands as Wallace’s interests shifted, and it remains maintained and widely used. Vite, built by Evan You with contributions from a distributed set of maintainers, operates similarly: fast development server and build pipeline, optional plugin layer, no commercial product attached.

Rome Tools raised $4.5M, hired several engineers who had contributed to the project, and dissolved in late 2023. The Biome fork emerged within weeks and continued development under community governance. The code survived the company; the engineering investment transferred intact to the community that the company had briefly absorbed. That is a better outcome than the code disappearing, but it required rebuilding institutional knowledge and development momentum from scratch.

The Lesson the Talk Surfaces

The retrospective circulating on Lobsters treats the $30M figure as a category result rather than a specific management failure, and that framing is more durable. The specific decisions matter less than the structural position: a company that builds a popular open-source tool and then tries to monetize on an adjacent layer it cannot defensibly own.

This does not mean framework companies should not try. It means the business model requires either genuine technical lock-in at the hosting layer, which is difficult to construct on top of an MIT-licensed framework, or a different monetization target entirely. Enterprise support contracts and audit tooling can sometimes generate enough revenue to sustain maintenance without requiring platform-scale growth. Tidelift has been building an intermediary model where enterprises pay for assurances across their open-source dependency graph, with proceeds distributed to maintainers.

None of these paths generate the returns that justify $30M in VC funding. That gap is the actual problem. The hosting strategy was the most plausible attempt to bridge it. The market structure made sure it was not plausible enough.