cloudflare · · 24 min read
Astro, VoidZero, and now Deno: Cloudflare is buying up the frontend toolchain. What should developers do?
In nine months, the Astro team joined Cloudflare, VoidZero was acquired, and the Deno team announced it was joining too. Here's what happened in each deal, how Cloudflare's strategy differs from Vercel's, how to hold "vendor neutral" promises accountable, and a practical checklist for frontend developers and tech leads.
This is an opinion piece. Facts are sourced from public, first-party material wherever possible. Official commitments, my own judgment, and second-hand claims I couldn’t verify are labeled as such, with sources linked inline.
A Friday night countdown
On Friday, October 9, 2026, Ryan Dahl announced on the Deno blog that the entire Deno team was joining Cloudflare. I saw the headline scroll past and assumed it was another acqui-hire. Then I read the post. The Deno runtime gets one more year of monthly fixes and security patches, then official development stops. Deno Deploy keeps running for six months, then shuts down (Deno blog).
That’s not “joining.” That’s a curtain call.
Ryan Dahl created Node.js. In 2018 he started Deno to fix the security and dependency problems he saw in his first project (The New Stack). Eight years later, on Hacker News, he admitted that users kept asking for Node.js compatibility, so Deno kept adding familiar features until it looked more and more like Node. His summary of the problem, roughly: if Node already works, why build another one? (quoted by Simon Willison) Deno set out to take a different road and got pulled back onto the old one by its own users. I’ll admit that stung a little. Plenty of us genuinely believed Deno could open a new path for server-side JavaScript. I was at least half a believer.
On its own, this reads like a respected engineer making a graceful exit. Zoom out, though, and a pattern appears. In January, the Astro team joined Cloudflare. In June, Cloudflare closed its acquisition of VoidZero, the company behind Vite, Vitest, Rolldown, and Oxc. In October, the Deno team followed. In nine months, Cloudflare has put itself at the center of the build tool, framework, and runtime layers.
I’ve written frontend code for years and never seriously asked who “owns” the packages in my node_modules. Now I have to. This post is about what this wave of deals means and how the people who use these tools every day can respond.
Three deals, three founders, three outcomes
People first, strategy later. Acquisitions tend to get compressed into a single headline, but what happens to an open source project afterward depends heavily on why its founders chose to join a platform company in the first place.
Astro: a framework that just wanted websites to be good
Astro launched in 2021. In his post about joining Cloudflare, Fred K. Schott describes the mood of that era: every website was built like an app, shipped whole to the browser, and then patched with layer after layer of performance workarounds (Astro blog). If you built marketing sites back then, you remember waiting seconds for a homepage to hydrate.
Astro’s idea was simple. Most of a content site can be rendered on the server, and only the interactive parts need JavaScript in the browser. Pages stay light and fast, and you can mix React, Vue, and Svelte on the same page (Cloudflare Blog). The first time I rebuilt a docs site with it, the JS bundle was so small I assumed I’d misconfigured something.
It kept growing. Cloudflare’s announcement lists Porsche, IKEA, and OpenAI as users, and Webflow Cloud, Wix Vibe, and Stainless all use Astro as the framework that generates their customers’ sites (Cloudflare Blog). Schott says adoption has doubled every year (Astro blog).
The business model never clicked. Schott is candid about it: they tried a paid hosting product and explored e-commerce, and neither found the kind of traction the framework had. Both also pulled focus from the core team. To be fair to those efforts, Astro DB evolved into the open source database client that’s still built into Astro, and the e-commerce work was open sourced, so “failed products” isn’t quite the right label (Astro blog). On the funding side, Netlify became Astro’s “official deployment partner” in July 2024 with a pledge of $12,500 a month (Astro blog). By September 2025, Cloudflare and Webflow were sponsoring Astro, while Cloudflare and Netlify sponsored TanStack (Cloudflare Blog). In the end, the Astro team chose to join Cloudflare.
The terms weren’t disclosed. All of Astro’s full-time staff became Cloudflare employees. The project stays MIT-licensed with open governance and continues to support deployment targets other than Cloudflare (Astro blog).
VoidZero: Evan You’s third act
Evan You’s story is well known. In his own telling, he spent 2016 to 2023 as an independent developer maintaining Vue and Vite on sponsorship money, and by 2023 the two projects had millions of weekly downloads. That year he founded VoidZero to build a fast, unified toolchain for the whole JavaScript ecosystem. That needed a full-time team, sponsorships couldn’t pay for one, so he raised venture capital (VoidZero blog). A $4.6M seed round led by Accel came in October 2024 (VoidZero), followed by a $12.5M Series A in October 2025, by which point Vite’s weekly downloads had passed Webpack’s (VoidZero).
A few years ago I had to write proposals and sit through meetings to get my team to move from Webpack to Vite. That kind of resistance has mostly evaporated. By VoidZero’s own account, Vite now has over 100 million weekly downloads, the Rust-based Rolldown is Vite 8’s default bundler, Oxlint lints large projects 50 to 100 times faster, Oxfmt is 30 times faster than Prettier, and Vite+ has been relicensed as MIT. Those performance numbers are the project’s own benchmarks (VoidZero blog). The npm API shows roughly 195.6 million downloads of the vite package between October 3 and 9, 2026 (npm API). That figure includes CI runs and bots, so it isn’t a count of real users, but it makes the point about reach.
The problem was the familiar one. Evan wrote that despite rapid adoption, they hadn’t figured out monetization. They tried a mixed license for Vite+ and it didn’t feel right. They built Void, a deployment platform running on Cloudflare, which split an already small team in two (VoidZero blog). The two companies had also worked closely on the Vite Environment API and Cloudflare’s Vite plugin long before acquisition talks started, so the deal wasn’t really a surprise.
Unlike Astro, this deal has public financials. It closed on June 1, 2026 and was announced on June 4. According to Cloudflare’s quarterly filing, the purchase consideration was $164.2M ($98.7M in stock plus $65.5M in cash). Separately, there’s $106.4M in stock-based compensation awards, which is not part of the purchase price. Of that, the remaining $98.8M will be expensed over a weighted average of 3.9 years, contingent on recipients staying employed. That’s accounting expense recognition, not the legal vesting schedule (Cloudflare 10-Q, VoidZero announcement).
A small aside: one outlet ran the headline “Cloudflare acquires VoidZero for $1 million” (ChannelLife). It had confused the $1M Vite ecosystem fund with the purchase price, an error of two orders of magnitude. I laughed, then sighed. If the size of the deal can get garbled that badly, it’s no wonder the community is confused about what these deals actually mean.
Deno: the Node.js creator’s second attempt
Ryan Dahl and Bert Belder co-founded Deno and raised about $26M in total, including a Series A led by Sequoia (TechCrunch). They went on to build Deno Deploy, a direct competitor to Cloudflare Workers.
The turning point was celld, released in August 2026. It’s a single Rust binary built on object storage, designed to support the same programming model as Cloudflare Workers and Durable Objects (Cloudflare Blog). The New Stack didn’t mince words, describing Deno as the startup that had copied Cloudflare’s serverless playbook (The New Stack). In the joint announcement, Cloudflare’s Kenton Varda said they were thrilled to see celld because it was exactly what they’d wanted to build and never had. He also pushed back on a popular theory that Cloudflare deliberately made Workers different to lock users in. His argument: open source and a clear exit path are simply good business (TechCrunch).
I believe about half of that. The other half depends on what they do next.
The outcome is what I described at the top. Ryan Dahl and Bert Belder will lead an effort to make self-hosted workerd a first-class option, folding celld’s code and ideas into workerd, Cloudflare’s open source runtime. The JSR package registry keeps running and moves to Cloudflare. The Deno runtime and Deno Deploy are on a countdown (Deno blog).
Put the three stories side by side and a common thread shows up. Each project had real technical influence, each team publicly admitted it hadn’t solved monetization, and each ended up joining a platform that could fund it. The deal structures, product decisions, and aftermaths are all different, though. “Business failure” doesn’t fit any of them cleanly.
The consolidation wave at a glance
Cloudflare isn’t the only one doing this. Step back and you can see JavaScript infrastructure being absorbed by large companies piece by piece over the past few years:
| Company | Project or team | Date | Layer | What happened next |
|---|---|---|---|---|
| Shopify | Remix team joins | Oct 2022 | Framework | Shopify framed it as the Remix team joining, not a formal acquisition. The plan to turn Remix v3 into React Router v7 was announced in May 2024, and v7 shipped in December 2024 (Shopify Engineering, Remix Blog) |
| Cloudflare | PartyKit | Apr 2024 | Real-time collaboration | Folded into the Durable Objects ecosystem (Cloudflare Blog) |
| Cloudflare | Outerbase | Apr 2025 | Database developer experience | Announced plans to integrate Outerbase into Durable Objects, D1, and the Agents SDK. The announcement doesn’t confirm that integration is complete (Cloudflare press release) |
| Vercel | NuxtLabs | Jul 2025 | Framework and server runtime | Nuxt is the framework, Nitro the server runtime. Vercel committed to keeping both independent and MIT-licensed, with public roadmaps and open governance (Vercel Blog) |
| Anthropic | Bun | Dec 2025 | Runtime and toolkit | Committed to continued MIT-licensed development; Bun powers Claude Code (Reuters, Anthropic) |
| Cloudflare | Astro team | Jan 2026 | Framework | Committed to MIT, multi-platform deployment, open governance, and a public roadmap. Astro 6’s dev server can run directly in workerd (Astro blog, Cloudflare Blog) |
| Cloudflare | VoidZero | Jun 2026 | Build toolchain | Closed June 1, announced June 4. Committed to MIT and no vendor lock-in; the Void platform is planned to be open sourced (VoidZero, Cloudflare Blog) |
| Cloudflare | Deno team joins | Oct 2026 | Runtime and self-hosting | Deno runtime gets one year of maintenance, then development stops. Deno Deploy shuts down after six months. celld’s code and ideas move into workerd (Deno blog) |
Note: earlier examples include GitHub acquiring npm, Netlify acquiring Gatsby, and Vercel acquiring Turborepo, all mentioned by The New Stack (The New Stack). I haven’t verified each date.
A few things stand out to me.
The buyers fall into three groups: cloud and deployment platforms like Cloudflare and Vercel, AI companies like Anthropic, and companies with their own core business, like Shopify. What each wants is easy to guess. Cloud platforms want more apps deployed on them, AI companies want their agents to run faster and more reliably, and a commerce platform wants a good storefront framework.
Most of these deals promise that nothing will change. Deno is the rare case where a core product was explicitly shut down. The New Stack drew the contrast with Bun directly: Anthropic committed to keep developing Bun, while Deno runtime development ends with the move to Cloudflare (The New Stack).
One more thing, and it’s a bit uncomfortable. The New Stack quoted a Hacker News commenter who argued that any JavaScript tool that reaches critical mass is now an acquisition target (The New Stack). I wanted to argue with that. I couldn’t come up with a good counterexample.
Four layers, two strategies: Cloudflare vs. Vercel
The easy read is that Cloudflare is fighting Vercel for developers. That’s true, but the more interesting part is that the two companies have very different theories about how to win frontend.
Break the frontend delivery chain into four layers: build tools, frameworks, runtimes, and deployment platforms.
- Build tools: Cloudflare now has Vite, Rolldown, Oxc, and Vitest. Vercel has Turbopack and Turborepo.
- Frameworks: Cloudflare has Astro, and Workers officially supports React Router v7, Nuxt, SvelteKit, and other major frameworks (Cloudflare Blog). Vercel has Next.js as its flagship, plus NuxtLabs.
- Runtimes: Cloudflare has the open source workerd, plus celld and the incoming Deno team. Vercel Functions go well beyond Node.js and Edge, with official support for Bun, Python, Rust, Go, Ruby, Wasm, and containers (Vercel docs).
- Deployment: Workers, Workers Builds, and the new unified
cfCLI on one side. The Vercel platform on the other.
Vercel’s approach is to make one flagship framework excellent and fit it tightly to the platform. Next.js plus Turbopack plus Vercel is a genuinely good experience, as anyone who’s used it knows. But that advantage rests on the premise that Next.js works best on Vercel. That doesn’t mean Next.js is stuck there. The Next.js team says many apps can be deployed anywhere as a single Node.js server, and the real complexity shows up with cache syncing across instances, on-demand revalidation, streaming, and Edge vs. serverless choices. Next.js 16.2 also shipped a stable Adapter API and a shared test suite specifically to improve cross-platform support (Next.js blog). How hard it is to move a Next.js app depends on the app and its architecture, not on Next.js itself (Cloudflare Blog).
Cloudflare is playing a different game: own the shared foundation, then make the default path lead home. Cloudflare’s blog points out that most frontend frameworks outside Next.js build on Vite, including Astro, SvelteKit, Nuxt, and Remix (Cloudflare Blog). Vite has effectively become the common foundation for most major frameworks that aren’t Next.js.
Cloudflare can’t make Vite proprietary, of course. The moment it did, the foundation would lose its value. So Cloudflare says it won’t turn Vite into a Cloudflare-only tool. Instead, it will build its own app tooling on top of Vite. The cf CLI is based on Vite, and Vite will gain new platform-neutral capabilities for full-stack apps and agents (Cloudflare Blog).
I think local development is where this gets decided. Astro 6’s new dev server is built on the Vite Environments API. With Cloudflare’s Vite plugin, astro dev runs your code inside workerd, so you can call Durable Objects, D1, KV, and Agents locally. Cloudflare stresses that any runtime can get the same capabilities by writing a plugin for that API (Cloudflare Blog). It’s a clever move. The interface is open to everyone, but whoever has the most mature plugin has the smoothest developer experience, and most developers care about whether their tools work well, not about governance.
Then there’s Vinext, which is far more direct. In February 2026, Cloudflare said one engineer used an AI model to rebuild the Next.js API surface on Vite in a week. The early benchmark used a 33-route app and measured build, compile, and bundle performance, not production serving. The project reported builds up to about 4.4 times faster, client bundles up to 57% smaller, and roughly $1,100 in token costs (Cloudflare Blog). Version 1.0 in September deploys to Workers, Netlify, AWS Lambda, and more. It doesn’t literally sync with Next.js every day: Cloudflare says an agent reviews new Next.js canary commits daily, extracts the diffs, and files tracking issues, while compatibility tests run nightly (Cloudflare Blog). The upshot: you can keep writing Next.js APIs without building and deploying on Vercel.
According to second-hand reports, Vercel didn’t take it quietly. Vercel CEO Guillermo Rauch reportedly posted on X that Vinext had seven security vulnerabilities and called it a “vibe-coded” framework (Awesome Agents). I couldn’t verify the original post or the vulnerability details, so treat this as second-hand. Even as industry gossip, though, it shows that the fight between platforms has moved from price and performance to the framework layer.
As AI makes rewriting a framework cheaper and cheaper, I think Cloudflare’s foundation-first strategy scales better, but it also depends more on trust. Vercel competes on experience, and experience can be matched. Cloudflare competes on people believing it’s neutral, and once that belief is gone, it’s very hard to win back.
What “vendor neutral” actually means, and how to check it
Almost every acquisition announcement repeats the same lines: MIT license, no vendor lock-in, community-driven. I believe the people who write those lines usually mean them. But “neutral” covers several different things, and they don’t carry equal weight.
The shallowest layer is the license. MIT guarantees that anyone can copy and fork the code. It doesn’t guarantee that the community can actually take over and keep the project alive. The right to fork always exists on paper, but forking something the size of Vite takes people, credibility, and coordination that very few organizations could muster.
The next layer is money. With the VoidZero deal, Cloudflare set up a separate $1M Vite ecosystem fund, managed by the Vite core team, to support maintainers outside VoidZero and Cloudflare (Cloudflare Blog). In August 2026, Cloudflare announced another $1M in open source funding for its Community Engineers program and a range of projects, separate from the Vite fund (Cloudflare Blog). That’s good. But money answers who does the work, not who makes the decisions.
The layer that matters most is governance. Who sets the roadmap? Where do the core maintainers work? Who arbitrates conflicts of interest? Astro has committed to open governance and a public roadmap. VoidZero says its roadmap is driven by the broader team and community and developed in the open. But as far as public information goes, none of these projects has announced an independent foundation or separate legal entity. For now, the governance promises rest on corporate self-restraint.
The community’s concerns aren’t coming from nowhere. The main Hacker News thread on the VoidZero deal drew around 300 comments, many worried about the roadmap and governance (Hacker News). Some said they avoid VC-backed tools on principle, because those tools eventually get worse, get expensive, or disappear. Others pointed to Cloudflare shutting down BastionZero’s product after acquiring it (The New Stack; that’s an individual’s claim I couldn’t verify). There were optimists too, who saw it as a straightforward talent-and-product deal backed by visible engineering investment.
Of all the official statements, the one I agree with most came from Cloudflare engineering director Steve Faulkner. Speaking to The New Stack, he acknowledged that he’d also seen open source promises broken after acquisitions, and said people should hold Cloudflare accountable (The New Stack).
So how do we hold them accountable? My approach is simple: ignore the press releases and watch the behavior.
- Is the share of core maintainers who don’t work at Cloudflare going up or down?
- Do major new features keep landing first in the Cloudflare adapter, leaving other platforms to wait for community patches?
- Are the Netlify, Vercel, and plain Node adapters as well maintained and reliable as the Cloudflare one?
- Do the promised open source release of the Void platform and the self-hosting capabilities of workerd after the celld merge ship on time and in full?
- Have the governance docs or contribution guidelines been quietly edited?
None of this requires inside information. It’s all on GitHub. The act of watching is itself a form of accountability.
Deno’s ending: a gentle warning worth taking seriously
To be fair, Deno’s wind-down is being handled decently. There’s a clear timeline, migration support for paying customers moving to Workers, JSR keeps running, the code stays open source, and the community is welcome to pick it up (Deno blog). Ryan Dahl says it was a joint decision he agrees with, because he no longer thinks the Deno runtime is where he can do his most important work (quoted by Simon Willison).
Still, I think this is the most important lesson of the whole wave. A platform keeps the parts it needs strategically. Whether the rest survives depends on whether strategy still needs it. Cloudflare wanted the Deno team’s expertise and celld’s self-hosting model. It didn’t need another Node-compatible runtime. And Deno Deploy competed head-on with Workers, so shutting it down was almost inevitable.
Some Hacker News commenters were blunter, suggesting the headline should really say that Deno development has effectively ended through a Cloudflare acqui-hire (HN discussion mirror; take it as a mood reading only). I don’t fully agree, since celld’s ideas really will live on in workerd. But for teams running production systems on Deno Deploy, that distinction doesn’t matter. They have six months to move.
Right now, Vite and Astro sit at the center of Cloudflare’s strategy, and I believe they’ll be treated well. But strategies change, and people leave. As noted earlier, the stock compensation from the VoidZero deal is expensed over a weighted average of 3.9 years, contingent on people staying. That doesn’t predict anything. But I’ve put a reminder in my calendar to check back then and see whether the core people are still there (Cloudflare 10-Q).
AI agents: why build and deploy suddenly matter so much
If you explain all this as a fight for developers, you miss the biggest piece. The primary users of the toolchain are shifting from humans to AI agents.
Evan You said as much in his announcement: as AI changes the landscape, more and more tool usage comes from agents, VoidZero’s mission now includes building better tools for them, and Cloudflare is positioning itself as the cloud for agents (VoidZero blog). Cloudflare’s press release describes a world where developers and autonomous agents alike can go from idea to global production with vite deploy (Cloudflare press release).
Picture a scenario that’s already common. Someone tells an AI site builder: make me a product launch page with a signup form. The agent picks a framework, scaffolds the project, writes components, configures the build, runs tests, deploys, and returns a working URL. It has no brand loyalty and doesn’t check Twitter to see which framework is trending. It takes whichever path has the most documentation, the clearest conventions, and a single command that just works.
Cloudflare’s Astro post makes this point: agents do better on codebases with clear structure and simple defaults, and AI site builders like Wix Vibe generate Astro sites that run on Cloudflare (Cloudflare Blog). Ryan Dahl also says Durable Objects, with cheap serverless execution, persistent state, WebSockets, and a high-level JavaScript API, make an excellent harness for agents (Deno blog).
Connect the dots and the chain is clear:
- Agents writing code need standard scaffolding and builds: Vite and Astro.
- That code needs fast, cheap, isolated execution: Workers and Durable Objects.
- Then it needs one-step deploys and logs: the
cfCLI and Workers Builds.
Whoever makes every link in that chain the default is best positioned to capture the deployments that AI-generated apps produce. No lock-in required. Just being the smoothest path is enough.
Vinext is the extreme case. A week and about a thousand dollars of tokens rebuilt the API surface of a major framework (Cloudflare Blog), which means the implementation itself is getting cheap. My take is that the real value is no longer the code but the standards, community, and developer habits a project has built up. That helps explain why a company that openly hadn’t solved monetization still commanded $164.2M in purchase consideration, before counting another $106.4M in stock compensation (Cloudflare 10-Q, VoidZero announcement).
AI is changing maintenance too. Cloudflare says it used an AI “software factory” to clear Astro’s GitHub issue backlog to zero (Cloudflare Blog), and VoidZero shipped more than 80 releases in its first four months at Cloudflare (Cloudflare Blog). As a user, I’m glad. But I also worry. Projects backed by a big company and AI are moving faster and faster, and the gap between them and independent projects run by a few volunteers on weekends is only going to widen.
What to do: a few concrete scenarios
Enough theory. Here’s how this plays out in practice.
You’re an indie developer with an Astro blog or portfolio on Netlify. Nothing to do for now. Astro has explicitly committed to supporting deployment targets beyond Cloudflare (Astro blog). Just keep an eye on how often the Netlify adapter gets updated.
You run a production API on Deno Deploy. This is the one case that needs action now. Start planning your migration: Cloudflare Workers (paying customers get official migration help), a Node or Bun platform, or self-hosted workerd or celld. Compare the costs (Deno blog). Don’t wait until month five. Internal scripts and tools that depend on the Deno runtime also need a replacement within the year.
You’re a tech lead at a mid-size SaaS company running Next.js on Vercel. Vinext is worth watching, but don’t rush. Its biggest value right now is leverage in pricing negotiations and a credible exit path. Try it on a marketing site or internal tool first, and watch its compatibility and security record. Until there’s a public, authoritative answer on the vulnerability claims, don’t use them as a reason to migrate or as a reason to dismiss Vinext.
You’re building a platform for AI-generated sites or apps. Based on what’s publicly available today, Cloudflare’s stack is highly integrated: Astro or Vite for the generated project structure, Workers for Platforms for multi-tenant apps, Durable Objects for state. The cost is a much deeper dependency on Cloudflare’s runtime APIs. Use it if it fits, but abstract the interface between “generated app” and “hosting platform” in your architecture, and regularly run things on at least one backup platform.
You sit on an architecture board setting frontend standards at a large company. One small thing is worth doing: write “framework and build tools” and “hosting platform” into your standards as two separate decisions. Then keep a health record for critical open source dependencies: where the maintainers work, which version of the governance docs is current, and where the money comes from. Review the recently acquired projects every six months.
Five predictions for the next two to three years
These are my guesses, not inside information. If I’m wrong, feel free to say so.
- Independent JS tooling companies will become rare. They’ll either be acquired or move to foundations. Nobody has solved standalone open source monetization, and agents keep making toolchains more valuable, so the number of buyers will only grow.
- “Move it to a foundation” will become the community’s bargaining chip. The first time a roadmap dispute visibly favors one platform, calls to hand Vite or Astro to a neutral foundation will appear immediately. My guess is Cloudflare will try hard to avoid that and may even set up some form of independent governance proactively. Pure speculation.
- Framework APIs and build implementations will decouple. Compatibility layers like Vinext and OpenNext will let people keep familiar APIs while freely choosing the build and deployment platform underneath. Platforms will compete on whose default path is smoother and whose local and production environments match more closely.
- Self-hosting will get easier. If folding celld into workerd makes self-hosting practical, it will ease lock-in concerns and may push other platforms to offer something similar.
- Toolchains will be designed for agents first, humans second. Docs, error messages, CLI output, and config conventions will all be reworked to be machine-readable first. Part of a frontend engineer’s value will shift from writing code to setting rules and guardrails for agents.
Whether these predictions come true matters less than whether you’re ready if they do.
A practical checklist for frontend developers and tech leads
Personal skills
- Master at least one “local equals production” workflow, such as the Vite Environment API with a runtime plugin.
- Understand how stateful serverless models like isolates and Durable Objects work.
- Deploy the same app to two different platforms yourself to learn where the framework ends and the platform begins.
- Learn to write clear project conventions and deploy scripts for AI agents.
Team stack decisions
- Choose framework, build tools, and hosting separately, and document why.
- Prefer combinations built on open standards that deploy across platforms.
- Add a smoke test in CI for a backup deployment target, such as a plain Node environment.
- Don’t hard-wire business logic to one platform’s proprietary APIs. Add a thin wrapper where needed.
Dependency governance
- Keep a health record for critical open source dependencies: maintainers’ employers, governance docs, funding sources, release cadence.
- Check in on acquired projects every six months, focusing on whether promises are being kept.
- Follow official project blogs and release notes rather than second-hand news.
- Treat community rumors with skepticism and rely on first-party sources.
Do now
- Deno Deploy users: start planning your migration today.
- Projects that depend on the Deno runtime: have an alternative evaluated within a year.
Our ability to leave is the best governance we have
I’m not pessimistic. Astro and Vite have never had this many full-time engineers or this much budget. In the VoidZero announcement, Evan You said that supporting all open source projects and respecting their communities was a precondition for VoidZero joining any company (VoidZero blog). Fred Schott said joining Cloudflare means the Astro team can stop worrying about a business model and focus on the code (Astro blog). For now these are just promises, but as a user, I’m already benefiting from the extra resources.
Still, I’ve come to believe that an MIT license in a LICENSE file doesn’t keep a project free on its own. Someone has to keep watching, promises have to be checkable, and users have to keep the ability to walk away at any time.
The next time you run npm create or add a plugin to your config, it’s worth a moment’s thought: behind that line of code there may be a company worth over a hundred billion dollars. That isn’t necessarily bad. Often it’s good. But it does mean that what we choose to use, and not use, carries more weight than it used to.
You can only hold someone accountable if you’re able to leave. I’m starting with my own projects, beginning with that escape-hatch smoke test.
Mttao GitHub ↗
Exploring technology and life's wisdom